3

I have a custom non-blocking I/O server that supports (among other things) HTTP and websockets.

I have two timeout concepts for connections:

  • idle: connections that don't do anything are closed after (by default) 5 minutes of inactivity
  • lifetime: connections that are older than a certain age (1 hour by default) are killed once they become inactive (so without the idle time required)

These are (in my opinion) generally good settings when it comes to HTTP but for websockets it is a bit harder.

The "inactivity" can be bypassed by sending a heartbeat over the websocket from time to time, however the lifetime requirement conflicts with the ideology of websockets.

There are a number of options:

  • explicitly configure a global lifetime of 0 (infinite) or some high number for the server if you are planning to use websockets, but this would be for everything on the server (also regular HTTP traffic)
  • get rid of the default lifetime and simply allow infinite by default
  • exempt websockets (and other such protocols) from the lifetime requirements and perhaps add a second lifetime for long lived connections

So in general the question is: how do you protect against long lived connections while still enabling protocols like websockets to work correctly without too many unneeded interruptions?

Is the "lifetime" setting even a good idea?

  • Obviously websockets and lifetime don't go together well. I don't see how lifetime adds anything useful over idle. timeout that's based only on inactivity will protect you from certain long lived connections anyway. It will not kill connections on which activity is happening, but I don't see why you want to kill them. – arahant Mar 17 '17 at 13:38
  • I have left the lifetime variable in place but have removed the default value for it. The main reason to add it was to detect and close connections that were (maliciously) sending bytes in small amounts continuously and hence never going idle. – nablex Mar 22 '17 at 16:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.