maxLifetime

[ghost]

It can be useful to force close connections after 30 minutes or so, and have them reconnect so that load balancing can be recalculated.

Without this upper limit it can be difficult to scale up/down server instances in case of fragmented distribution of long held connections.

You could also have the server itself close down all clients at the same time, every 30 minutes but that would create a spike.

[ghost]

This can be cheaply implemented with a simple integer comparison every time the timeout resets. A multiple of 6 minutes means a simple 8 bit integer can track 24 hours.

[ghost]

Timeout system in uSockets can be optimized to require 40% less CPU-time. Currently we jump to every socket and check its 4-second integer and then bumps it. This requires a random load and store. By instead only reading a timestamp and comparing it with the timestamp of the server (updated every 4 seconds) we can do with only a random load, which is 40% cheaper in my testing.

So the change is:

a timestamp, unsigned short, is a multiple of 4-seconds. This gives a range from 4 seconds to 70 hours which is a good range for both idleTimeout and maxLifetime. Then every socket holds 2 of these; idleTimeout and maxLifetime.

Every time we sweep sockets, we only do a random load of idleTimeout (saving 40% CPU-time).

On idleTimeout reset (timeout or when receiving data) we compare the maxLifetime timestamp (which is essentially free since we have that socket in cache at that point).

So all in all, this change should improve performance not decrease it.