The Dreaded 2 Connection Limit
by Dylan SchiemannNovember 11th, 2007
A recent discussion in the comments of Comet is always better than polling brought up the point of the 2-connection limit defined in the HTTP specification, and its enforcement by Internet Explorer.
Stepping back for a moment and defining the problem, you are allowed only two simultaneous connections between a client and a web server, making things especially difficult for long-polling and the forever-frame technique, the two staple Comet techniques. Mozilla Firefox by default provides web applications with 8 connections by default, which is enough for Comet developers.
If you really only have two connections, and one dedicated to the Comet connection, you do have a problem. That said, the solution is very straightforward: subdomains! Internet Explorer treats the following four domains as unique and distinct in its calculation of number of connections allowed between client and server:
a.cometdaily.com
b.cometdaily.com
c.cometdaily.com
d.cometdaily.com
As such, using very basic wild card rules, you can serve your Comet code from one subdomain, and your images, JavaScript, and CSS files from the others. Dojo’s support for cross-domain scripting helps resolve cross-domain security restrictions in a trusted manner. This technique is not unique to Comet. Developers using significant amounts of JavaScript and image files frequently rely on this to accelerate performance in Internet Explorer.
One note: we usually limit ourselves to four subdomains, as we find that an eight connection total limit exists in certain situations (such as Mozilla Firefox browsers using the default configuration). This is a hack that works with great success, much like many of the other common hacks in widespread use on the web.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
November 12th, 2007 at 6:42 am
nice solution, although probably more in the hack/workaround category
I really need to get into Comet but at least I am reading now about it. Might soon try to find some example of how to get it running for me (those with cometd I think did not really work for me). Is there actually some tutorial out there?
November 12th, 2007 at 2:30 pm
Dylan,
unfortunately I disagree with you on the “solution” for the 2 connection limit. The limit is there for good reason - to conserve resources on the server. If every client was to make 8 connections to a server, that would increase the number of sockets, file descriptors and buffers needed on that server by 4 times! There is only a limited number of file descriptors available and the approach of allowing more connections will soon exhaust the servers.
Note also that while firefox does allow 8 connections, it only allows 2 to the same host. So if you want more, then you need to reconfigure or do the subdomain trick.
However, I think a much better approach is to accept and embrace the 2 connection limit.
2 connections ar sufficient for efficient 2 way low latency communication. The only problem with them is how to share them between multiple widgets, frameworks, tabs and windows that all may wish to talk to the same server.
That is where projects like cometd and eventually the open ajax alliance can help. Providing higher level abstractions for communications (pub/sub messaging), allows implementations to work at the hard problem of sharing connections between all potential users. Cometd already will share the connections between all users within the same framework and will detect if multiple instances of the framework are instantiated (via multiple frames, tabs or windows).
There are proposals before the open ajax alliance, that will facilitate multiple frameworks sharing the communications. Some frameworks (icefaces for example) have even solved
the cross frame/window communication problem and will allow one frame to perform communication tasks on behalf of another (below the API).
cheers
November 13th, 2007 at 12:58 am
Wow…!
I never thought my comment would generate a counter blog…!
Interesting solution though, I actually thought that it was IPs meaning even _different domains_ on the same IP would be treated as a “max limiting thingie”…
November 13th, 2007 at 9:56 am
Thomas, (un?)fortunately, IE isn’t that smart! As Greg pointed out, this solution is to be used with care and when needed. For example, it works great for Flickr or real estate sites, but most people use it just to get a third connection for IE users, etc.
Now, the day we can start sending images and other files with Comet is the day this hack isn’t needed any more
November 14th, 2007 at 9:02 am
Dylan:
You state:
“The limit is there for good reason - to conserve resources on the server. If every client was to make 8 connections to a server, that would increase the number of sockets, file descriptors and buffers needed on that server by 4 times!”
This is very true, but surely if you have written the server yourself, and actively WANT more connections to improve the client experience, then it’s a valid work-around?
I don’t agree that 2 server connections is sufficient if you are blocking 1 with a comet request. For example, even *IF* all the frameworks play nicely (which is a big assumption, irrespective of the good work being done to try and standardise this), you still have to rely on other hacks. For example, there is a nasty “feature” that IE provides, where a new window in the same process (for example launched with Ctrl-N) also shares the same 2 connection limits, but doesn’t provide JavaScript access to the other window’s DOM. AFAIK this is not a problem that has been solved properly by icefaces…
November 14th, 2007 at 9:03 am
Oops - above quote should have been credited to Greg, not Dylan
December 2nd, 2007 at 9:41 am
I have been reading up on all that is Comet. And I like that someone has proposed an Asynchronous Servlet specification. I was wondering if anyone has proposed an asynchronous HTTP extension? Really continuations for HTTP. Let me paint a picture of what I’m thinking at the moment:
A browser could post a request along with either an Accept or X- header stating that it supports “continuations” or “asynchronous responses”. The server would recognize that and could simply return with a “response token”, which the browser could use to ask for the final response. So then the browser could then poll on behalf of the client for the pending response using the “response token”.
This isn’t officially asynchronous http, but allows for continuations, and at least breaking the one thread per request limitation at the browser end. And you could possibly enhance this very simple model with some sort of long-polling, or a more specific channel ope for server to client pushing, where the browser could ask the server to forward the responses to..
The original request could register a comet channel that it wants the reponse sent to. Then the server would simply return with a response toen (so web server could tie request to response). then the server would simply send the response asynchronously through that back channel ( one channel for all responses to that server, or how ever the browser wants to partition it ).
I really like this idea. Though it would take support from browsers and servers and maybe HTTP specs. It could really push async all the way to the clients, making the whole stack more efficient.
December 6th, 2007 at 12:29 am
Greg: how are the connections supposed to be shared between different windows, exactly?
March 5th, 2008 at 9:53 am
[...] this is the beginning of the end of the Dreaded 2 Connection Limit? Firefox, Opera, and Safari of course have had a default connection limit of 8 connections per [...]
March 7th, 2008 at 4:05 am
Can somebody make an example for this solution.
I haven’t manage run this solution with dojo cometd, looks like the script simply doesn’t publish the data if the cometd initialization Root url is different from the document.domain.
April 3rd, 2008 at 8:52 am
[...] The Dreaded Two Connection Limit [...]
April 24th, 2008 at 8:33 am
[...] test is possible because Lightstreamer does not suffer from the 2-connection limit. Multiple instances of a Comet application or even different Comet applications connecting to the [...]
April 28th, 2008 at 12:01 am
[...] considers all frames talking to the same server to be in collusion when it comes to resources (i.e. 2 connection limit), but then imposes security barriers between them, so they really cannot collude and share those 2 [...]
August 10th, 2009 at 11:45 am
The comment by GregWilkins: “Note also that while firefox does allow 8 connections, it only allows 2 to the same host.” - I feel quite sure is not correct.
The limit for Internet Explorer 5-7 is 2 connection, and for other browsers I think 8 (firefox, safari, chrome). The good news is that it seems like in IE 8 the limit for IE is also raised to 8.
I feel I have had some problems with the subdomain solution, like some versions of IE 7 does still have some limit even if one use subdomains. But I am not sure about this.
January 12th, 2010 at 11:48 pm
Greg,
I know this post is old, but another solution is to use a server such as lightppd, nginx, or cherokee on the front end, as these servers have no trouble with many open connections.
January 26th, 2010 at 11:27 am
[...] are also some esoteric limitations of HTTP spec, followed by some clients, which limit this approach [...]
July 6th, 2010 at 7:20 am
Sho,
The limit is not within the server but within the clients computer. It is true that Nginx can handle 10k concurrent connections but unfortaunately IE7 will only handle 2…there is no way to get around this by changing server type.