I secretly hope Nginx could implement socket fd sharing via sendmsg, so my websocket worker have direct access to the client TCP connection. No more relaying.
Socket Sharding in Nginx Release 1.9.1
11–14 of 14 posts
Re: Socket Sharding in Nginx Release 1.9.1
#12Earlier quoted context omitted.
What happens during the reload case for nginx? At reload time, the previous-generation worker that bound to the socket with SO_REUSEPORT will need to close its listener, just like haproxy.
In nginx worker processes don't open and don't close sockets. They inherit them from the master process.
But isn't that what reuseport changes? Each worker opening it's own socket?
Re: Socket Sharding in Nginx Release 1.9.1
#13Earlier quoted context omitted.
In nginx worker processes don't open and don't close sockets. They inherit them from the master process.
But isn't that what reuseport changes? Each worker opening it's own socket?
No, they don't (and they can't, since they usually don't have such privileges). The master process opens all sockets for each worker process.
Re: Socket Sharding in Nginx Release 1.9.1
#14I secretly hope Nginx could implement socket fd sharing via sendmsg, so my websocket worker have direct access to the client TCP connection. No more relaying.
Why don't you submit a feature request for that?