What is a safe amount of time that I can wait before responding to a browser, without getting a Timeout?

Question

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!

Treatment

Answer 1

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..

• http://ajaxpatterns.org/XMLHttpRequest_Call
• http://geekswithblogs.net/lorint/archive/2006/03/07/71625.aspx
• http://ajaxblog.com/archives/2005/06/01/async-requests-over-an-unreliable-network

Handal

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... – Treatment

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. – Handal

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. – Gytle

@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) – Treatment

I know this comment is really late, but your next request could indicate the ACK by encoding the last received message ID in the URL. You have to do another request after a timeout or a message reception anyway, so the ACK can piggyback on that. – Diaghilev

Answer 2

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 minutes
Internet Explorer 7 and Internet Explorer 8 - 60 minutes

As you can see, it gets larger overtime.

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,

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.

Nickerson

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... – Treatment

+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. – Uuge

@ZZCoder, it looks either the values changed or the prior documentation is wrong. I've updated your answer accordingly. The timeouts are in fact getting longer in IE. – Caelum

Nice information there. However the browser is not the only thing that can cause timeouts. All sorts of stuff lies between the browser and the server: The client OS, proxies, NAT routers, etc... all of which can potentially get you disconnected (nice case) or the connection to simply become dropped and be left dangling on both sides. – Hispanicism