Currently, shutdown does kind of best effort close connections, and is associated with a timeout. Also, shutdown is passed on through the token manager to the transports, and the token manager doesn't take any requests during shutdown.
For high reliability situations, it might be interesting to have a shutdown that behaves better on the TCP side (and presumably could obtain similar properties on the UDP side): The incoming socket gets closed, and could be taken up by a new instance right away (or even in parallel with REUSEPORT), peers are only sent a Release (UDP: maybe cancel observations), but as long as they keep their connections open (or the requests are unanswered, in the UDP case), the server is kept alive.
This is incompatible with the token manager's current stance of "I don't accept anything new and then shut down the transports", so the whole shutdown would need to be revised.
Currently, shutdown does kind of best effort close connections, and is associated with a timeout. Also, shutdown is passed on through the token manager to the transports, and the token manager doesn't take any requests during shutdown.
For high reliability situations, it might be interesting to have a shutdown that behaves better on the TCP side (and presumably could obtain similar properties on the UDP side): The incoming socket gets closed, and could be taken up by a new instance right away (or even in parallel with REUSEPORT), peers are only sent a Release (UDP: maybe cancel observations), but as long as they keep their connections open (or the requests are unanswered, in the UDP case), the server is kept alive.
This is incompatible with the token manager's current stance of "I don't accept anything new and then shut down the transports", so the whole shutdown would need to be revised.