Connections limit and multiple browser tabs

285 views
Skip to first unread message

simorgh

unread,
Aug 8, 2008, 8:14:18 PM8/8/08
to Google Web Toolkit
Hi,

My app keeps permanently open one connection that listens for events
pushed by the server. Opening several instances of the app (in
different browser tabs) thus quickly consumes the two (or six for
Firefox 3) connections allowed.

I keep hearing that the solution is to share a single connection among
multiple browser tabs. How is this possible given that JavaScript's
security model is designed to prevent this?

I also keep hearing that cometd would implement this solution. However
http://cometdproject.dojotoolkit.org/documentation/FAQs/multipleTabs
seems to state quite the contrary.

Basically I'm wondering how Google Talk manages to display received
chat massages simultaneously and instantaneously in several browser
tabs.

Assuming that Google Talk is implemented in GWT, how is this done?

Thank you for sharing any insights!

Simorgh

Arthur Kalmenson

unread,
Aug 11, 2008, 8:41:32 AM8/11/08
to Google Web Toolkit
Hello Simorgh,

My understanding is that keeping an open connection to the server is
not a good strategy specifically because of the issue you pointed out.
Instead of keeping an open connection, I suggest you pool the server
every 500ms or 1s or some other interval to determine if it has any
information for you. While Google Talk is not implemented using GWT
(AFAIK), the Google Web Toolkit Applications book discusses building a
similar app and I believe Ryan just pooled the server (I'll have to
check that later). Anyway, your users won't really notice a real
difference if you pool often and you'll save them a lot of pain if
they have multiple tabs open to different AJAX apps.

Hope that helps.

Regards,
Arthur Kalmenson

On Aug 8, 8:14 pm, simorgh <simorgh.ahv...@gmail.com> wrote:
> Hi,
>
> My app keeps permanently open one connection that listens for events
> pushed by the server. Opening several instances of the app (in
> different browser tabs) thus quickly consumes the two (or six for
> Firefox 3) connections allowed.
>
> I keep hearing that the solution is to share a single connection among
> multiple browser tabs. How is this possible given that JavaScript's
> security model is designed to prevent this?
>
> I also keep hearing that cometd would implement this solution. Howeverhttp://cometdproject.dojotoolkit.org/documentation/FAQs/multipleTabs

gregor

unread,
Aug 11, 2008, 10:50:30 AM8/11/08
to Google Web Toolkit
Hi Simorgh,

The position as stated on your dojo link seems to be backed up here:

http://www.openajax.org/runtime/wiki/The_Two_HTTP_Connection_Limit_Issue

Greg Wilkins comments here that the only real solution to this problem
is to have a common javascript space that all tabs could access so
that a single comet channel could be managed from there. I would guess
that this comment implies that sharing a connection between tabs is
currently impossible as Greg seems to know what he is talking about
and would know if it was. I would imagine that such a common space
might provide fertile ground for new black hat evil though.

The only glimmer I can think of (and I have no idea if it would
actually work) is to use a short lived cookie to keep track of the
number of instances of the application running in new tabs and to set
up a rack of sub-domains on the server. So each instance checks the
cookie and if doesn't exist it connects to a.mydomain,com, if it's "a"
it goes for b.mydomain.com etc resetting the cookie as they go. I
believe the sub-domain trick works as the browsers treat them as
different servers, but I don't know if the cookie part is viable.

regards
gregor

simorgh

unread,
Aug 11, 2008, 12:56:02 PM8/11/08
to Google Web Toolkit
Thank you for your replies.

Picking up the ideas with cookies:
Couldn't one tab act as the master and manage the connection with the
server and pass on any information pushed from the server through a
cookie? The other (slave) tabs would need to poll the cookie every
500ms or so, but cookie polling seems less harmful than HTTP/RPC
polling. If the master tab gets closed the remaining slave tabs would
have to elect a new master. To do this, they communicate through a
cookie as well.

I'm still curious about how Google Talk can have a dozen tabs open and
display replies in all of them instantaneously (for more than a dozen
it stops to work on my configuration).

gregor

unread,
Aug 11, 2008, 3:00:05 PM8/11/08
to Google Web Toolkit
I can see two possible problems:

1) The "master" tab doesn't "know" about the other tabs so can't mark
cookies with an id or create a different cookie for each tab
2) Cookies have a size limit

It is interesting that Google Talk allows 12 then folds. What happens?
Does just the 13th not work or do the whole lot stop working. If the
former, if you close down a couple does it recycle their connections
so you can create a couple more? Is the limit always 12?

simorgh

unread,
Aug 12, 2008, 10:24:34 AM8/12/08
to Google Web Toolkit
After the limit new clients won't receive IMs. Also, they cannot send
messages (hitting return doesn't have any effect) anymore.

I wonder what can be deduced about the underlying mechanism from that.
Reply all
Reply to author
Forward
0 new messages