views:

112

answers:

2

I'm making a chat application that works with long-polling to emulate a "push" from server to client.

Basically, the browser asks for updates, and I reply if there's something new. Otherwise, I keep the connection open without responding until there is something to send back.

Now, if 30 seconds have passed and I haven't sent anything, then I do send a response, saying basically "NoNews", and the client will poll again.

What I want to do is obviously keep this connection without replying for as long as possible, before the browser will simply time out and give up on me... I haven't found good documentation on what the Client Timeout is for each browser, and it doesn't seem like it's the same for all of them...

Has any of you made a long-polling application?
Any ideas what the longest safe timeout might be?

Thanks!

+1  A: 

The browser should detect a timeout on an XHR and make another request.

Update:

Detecting timeouts on an XHR is actually complicated, since it's not built-in for some reason. Of course you will also need to handle 502/503 responses, etc..

Tim Sylvester
Interesting, how can I do that?Also, can the server detect this? (ASP.Net 2.0) I know I can technically check whether the client is still connected, but is this 100% accurate?My worry is this race condition: The client will timeout, a message will arrive for the user, the server will send it to the connection it has a handle to, the message goes nowhere because it has timed out in the client, the new request made by the client sees an empty message queue waiting for him, and the message is lost...
Daniel Magliola
On the server side, a timed-out connection will generate an error when you try to write to the socket. Precisely how you detect this depends on the server-side technology you're using, and I'm not very familiar with ASP.Net. Likely, the Response.Write (or whatever it is now) will produce some kind of error. Client-side, you will need to do some extra work, I've updated my answer with some links you may find helpful.
Tim Sylvester
You could make the client send an ACK when they get a message. Thus if you send a message back and get no acknowledgement, then leave it in the queue until they reconnect.
kibibu
@kibibu: That pretty much defeats the purpose of trying to make less requests (which is why I want to make the timeout longer in the first place)
Daniel Magliola
+1  A: 

The read timeout varies between browsers. For example, these are default values for IE,

Internet Explorer 4.0 and Internet Explorer 4.01    5 minutes
Internet Explorer 5.x and Internet Explorer 6.x 60 seconds
Internet Explorer 7 and Internet Explorer 8 30 seconds

As you can see, it gets smaller and smaller. I think 30 seconds is a good setting for now.

In long polling, timeout is your friend. You should take advantage of it, instead of avoiding it. Timeout means you are doing LONGEST polling possible with the browser. Timeout is an error you have to handle even without long polling so there is no extra burden.

You might want read my response to this question,

http://stackoverflow.com/questions/1249605/polling-a-http-server-from-j2me-client

Even though it's for a mobile client, most rules apply to AJAX long polling also. Specifically, I think you will benefit from a notification system so long polling is only used for event notification and all contents are still pulled normally.

ZZ Coder
Thanks for the answer, this is very interesting...Where did you find those timeout values for IE?I couldn't find anything like that...If that is in fact true, then my application wouldn't be working right in IE 7/8, since my current typical time to wait is 30 seconds + a bit of overhead...
Daniel Magliola
See http://support.microsoft.com/kb/181050
ZZ Coder
+1, 30s is where you start running into troubles. Opera, too, hits limits around here. We use 25s in WebSync, to avoid potential minor differences.
jvenema