

Socket Sharding in Nginx Release 1.9.1 - Uncle_Sam
http://nginx.com/blog/socket-sharding-nginx-release-1-9-1/

======
jamescun
I was under the impression the `SO_REUSEPORT` implementation on Linux was
rather broken, as evidenced by HAProxy's graceful reload still dropping
packets[1]. I'm curious as to why Nginx has implemented this when you can
design your Nginx config around the problem while not encountering the broken
implementation.

[1] [http://engineeringblog.yelp.com/2015/04/true-zero-
downtime-h...](http://engineeringblog.yelp.com/2015/04/true-zero-downtime-
haproxy-reloads.html)

~~~
caf
The issue that HAProxy is encountering with SO_REUSEPORT is not an issue for
Nginx's use case.

In the HAProxy case one of the sockets belongs to the old server which is
going away, and a new connection can be assigned to that socket right before
it does so. For Nginx, all of the sockets are accepting new connections.

~~~
otterley
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.

~~~
ArmTank
In nginx worker processes don't open and don't close sockets. They inherit
them from the master process.

~~~
CrLf
But isn't that what reuseport changes? Each worker opening it's own socket?

~~~
ArmTank
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.

------
est
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.

~~~
ArmTank
Why don't you submit a feature request for that?

