HTTP Long Polling - Timeout best practice

Question

I play with Javascript AJAX and long-polling. Try to find best value for server response timeout.

I read many docs but couldn't find a detailed explanation for timeout.

Someone choose 20 secs, other 30 secs...

I use logic like on diagram

How can I choose better value for timeout? Can I use 5 minutes? Is it normal practice?

PS: Possible Ajax client inte.net connections: Ethe.net RJ-45, WiFi, 3G, 4G, also, with NAT, Proxy.

I worry about connection can be dropped by third party in some cases by long timeout.

Answer 1

Maybe its your grasp of English which is the problem, but its the lifetime of the connection (time between connection opening and closing) you need to worry about more than the timeout (length of time with no activity after which the connection will be terminated).

Despite the existence of websockets, there is still a lot of deployed hardware which will drop connections regardless of activity (and some which will look for inactivity) where it thinks the traffic is HTTP or HTTPS - sometimes as a design fault, sometimes as a home-grown mitigation to sloloris attacks. That you have 3G and 4G clients means you can probably expect problems with a 5 minute lifespan.

Unfortunately there's no magic solution to knowing what will work universally. The key thing is to know how widely distributed your users are. If they're all on your LAN and connecting directly to the server, then you should be able to use a relatively large value, however setting the duration to unlimited will reveal any memory leaks in your app - sometimes its better to do refresh every now and again anyway.

Taking the case where there is infrastructure other than hubs and switches between your server and the clients, you need to provide a mechanism for detecting and re-establishing a dropped connection regardless of the length of time. When you have worked out how to do this, then:

1. dropped connections are only a minor performance glitch and do not have a significant effect on the functionality

2. it's trivial to then add the capability to log dropped connections and thereby determine the optimal connection time to eliminate the small problem described in (1)

Answer 2

Your English is fine.

TL;DR - 5-30s depending on user experience.

I suggest long poll timeouts be 100x the server's "request" time. This makes a strong argument for 5-20s timeouts, depending on your urgency to detect dropped connections and disappeared clients.

Here's why:

• Most examples use 20-30 seconds.
• Most routers will silently drop connections that stay open too long.
• Clients may "disappear" for reasons like.network errors or going into low power state.
• Servers cannot detect dropped connections. This makes 5 min timeouts a bad practice as they will tie up sockets and resources. This would be an easy DOS attack on your server.

So, < 30 seconds would be "normal". How should you choose?

What is the cost-benefit of making the long-poll connections?

Let's say a regular request takes 100ms of server "request" time to open/close the connection, run a database query, and compute/send a response.

A 10 second timeout would be 10,000 ms, and your request time is 1% of the long-polling time. 100 / 10,000 =.01 = 1%

A 20 second timeout would be 100/20000 = 0.5%

A 30 second timeout = 0.33%, etc.

After 30 seconds, the practical benefit of the longer timeout will always be less than: 0.33% performance improvement. There is little reason for > 30s

Conclusion

I suggest long poll timeouts be 100x the server's "request" time. This makes a strong argument for 5-20s timeouts, depending on your urgency to detect dropped connections and disappeared clients.

Best practice: Configure your client and server to abandon requests at the same timeout. Give the client extra.network ping time for safety. Eg server = 100x request time, client = 102x request time.

Best practice: Long polling is superior to websockets for many/most use cases because of the lack of complexity, more scalable architecture, and HTTP's well-known security attack surface area.