The SO_REUSEPORT socket option

Posted Mar 14, 2013 11:34 UTC (Thu) by andresfreund (subscriber, #69562)
In reply to: The SO_REUSEPORT socket option by jezuch
Parent article: The SO_REUSEPORT socket option

> > I guess it was not feasible to fix "multiple servers accept() on the same socket" to distribute connections more evenly?

> My thought exactly.

One argument for SO_REUSEPORT is that it makes it easier to use independently started processes on the same socket. E.g. with it you can simply start the new server - potentially in a new version - and shutdown the old one after that, without any service interruption. At the moment you need to have a unix socket between the servers, send over the tcp socket file handle, start accept()ing in the new server and then shutdown the old one.

(Log in to post comments)

The SO_REUSEPORT socket option

Posted Jun 8, 2014 5:40 UTC (Sun) by wahern (subscriber, #37304) [Link]

The current implementation doesn't actually support that. That's because each socket has its own queue, and when the 3-way handshake completes a connection is assigned to exactly one of those queues. That creates a race condition between accept(2) and close(2).

So, no, this doesn't support seamless server restarts.

Ironically it's the BSD semantics which support seamless server restarts. In my tests OS X's behavior (which I presume is identical to FreeBSD and other BSDs) is that the last socket to bind is the only one to receive new connections. That allows the old server to drain its queue and retire without worrying about any dropped connections.