views:

263

answers:

1

I am writing an on line chat room based on AJAX/COMET. My design is:

Request

----------------- wait -------------------------> send dump data

----------------- wait -------------------------> send dump data

----------------- wait -------------------------> send dump data

----------------- wait -------------------------> send dump data

----------------- wait -------------------------> send dump data

------ something happened, get response.

Another request ..... ....

As you see, the server hold the request and wait something happened, if there is some event happened, just push data and finish request. Then the client will issuse another request. There is tick in request, so if there is event happened betweenhe t gap of two requests, server knows that there is pending event for the client.

Before the browser timeout, the server also send some idle data to prevent client from timeout.

Now, here comes the problem: what are timeout behavior of different browsers? I know that browser sends request and wait for data, if it take too long time to wait, it will timeout. But what are those timeout behavior of different browsers? And are there any header that can control the timeout behavior of browser? By knowing the timeout behavior of browsers, so that I can decide how to deal with them. Where can I find those data?

+2  A: 

Actually, since the client could be going through proxies, the explicit values of the timeouts for different browsers don't mean as much as you'd think.

Rather, I'd ask why you're asking - you're going to have to deal with timeouts, and no amount of streaming to the browser is going to prevent it every time. So it'd be best to simply requery the server from the client when the connection drops - which is one reason why a lot of people recommend long polling which is what you seem to be trying to do. Regardless of whether you choose a streaming solution or a long poll, you have to allow for connection resets.

For a simple hidden iframe client setup, it's not too hard to do - and it's equally easy for XHR requests, depending on what client side framework you're using.

The timeout for most modern browsers seems to be rather large in IE (60 minutes? Wow), and shorter in FF (about:config says 300 seconds - eek) - but as I said, that doesn't help you against a proxy, where the timeout could be as short as 2 minutes or less, depending on how the proxy admin configured it.

So, in summary - timeouts happen. You can't stop them. Code your client to reconnect when they happen (with a limit to prevent a spin on server down), and don't worry about it further. Besides being more robust, it'll probably also make your code more performant, since you won't be periodically pumping useless data to every client.

Jim Driscoll