Shutdown : getting back listeners on shutdown and faster shutdown

[joelwurtz]

Hey,

I'm currently trying to implement a way of keeping connections alive during the restart of a server using xitca. This implementation will rely on using SCM_RIGHTS by passings listener fd to another process.

I think it's possible without doing any changes to current implementation, but not sure it would be the proper way, by doing this :

1. Server create a unix socket to get fds from older one with a timeout
2. If timeout is reached it means there is no existing server, and we get a empty fds vec
3. Once i get the fds vec (from either timeout or existing server), i try to create lisener based on this by either :

• Create a listener from RawFd if it exists
• Create a listener (and bind it) from a socket adress if it does not exists

4. Dedup / clone each listener, so i can retain existing listener without changing xitca API
5. Listen for signal to shutdown
6. On receive the shutdown signal (SIGTERM / ...), tell the server to shutdown
7. Connect to the unix socket and sends fds from listener created in step 3
8. Wait for complete shutdown

At the moment it only keeps fds of listener, not existing connections as there is a lot of work needed and seems to be only possible if using ktls (ref rustls/rustls#1247)

I was wondering if the step 4. could be avoided by getting back the listener on shutdown ?

Also current shutdown will have to wait for either the graceful timeout or hoping existing h1 / h2 / h3 connections have been closed

But i think it could be possible to close them faster by sending an event (using tokio channel ?) to each implementation dispatcher that close the connection if there is no current request :

1. for h1 this could be done here : https://github.com/HFQR/xitca-web/blob/main/http/src/h1/dispatcher.rs#L215 we could either select read or the shutdown signal, and stop the run on shutdown event, this would close the connection but at least there should be no pending request / response at this point

2. for h2 this could be done here : https://github.com/HFQR/xitca-web/blob/main/http/src/h2/proto/dispatcher.rs#L149 when queue is empty we select either the ping pong event or the shutdown event, this is also safe since it means there is nothing in queue, also we will not stop the loop but instead call io.graceful_shutdown which would refuse new connections and handle remaining request if some of them were sent during this

3. for h3 this could be done here : https://github.com/HFQR/xitca-web/blob/main/http/src/h3/proto/dispatcher.rs#L65 in a similar way that it would be done for h2: if queue is empty we check for shutdown event otherwise we handle the elements in the queue. On shutdown event we would also call the graceful shutdown method of connections to properly handle remaings request if any

By doing this i think we can have faster and proper shutdown, i do believe right now the timeout can abruptly stop the existing connections and requests

I can do a PR if you want for that, my only concern is how the event shutdown should be done, should this use a tokio channel ? or another implementation ?