The SO_REUSEPORT socket option [LWN.net]

The SO_REUSEPORT socket option

Posted Mar 15, 2013 16:51 UTC (Fri) by giraffedata (guest, #1954)
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?

"Incoming connections and datagrams are distributed to the server sockets using a hash based on the 4-tuple of the connection—that is, the peer IP address and port plus the local IP address and port."

That probably explains it. If you used this technique on multiple threads accepting on the same traditional socket, you would be fixing one thing and breaking another. Today, if a thread is blocked in accept() and no other thread is, and a connection request arrives, the thread gets it. It sounds like with a SO_REUSEPORT socket, the connection request would wait until its predetermined accepter is ready to take it.

to post comments

The SO_REUSEPORT socket option

Posted Mar 15, 2013 19:00 UTC (Fri) by dlang (guest, #313) [Link]

I'll point out that this is very similar to the CLUSTERIP capability that iptables provides.

CLUSTERIP shares one IP across multiple machines, doing a hash to make decide which machine gets the packet to userspace (they have the option of using the full 4-tuple or only part of it) You then use heartbeat or other clustering software to make sure that there is always some box that will handle the connection (with the expected gaps due to races when machines go down and the clustering software hasn't responded yet)

SO_REUSEPORT sounds like it extends this capability to multiple processes/threads inside one box, but with the re-balancing being done automatically by the kernel (with with very similar races when processes/threads go down and the kernel hasn't responded yet)

This is a very nice new feature to have available.

The SO_REUSEPORT socket option

Posted Feb 8, 2014 18:19 UTC (Sat) by batth.maninder@gmail.com (guest, #81449) [Link] (1 responses)

The ability to route to same tuple sounds like premature optimization. For example, if i have spawned few stateless servers, and if a connection request arrives, it would simply sit in queue till the original server is ready? Most typical architecture for stateful servers is to spawn 3 of them on different physical machines for reliability purposes and have load balancer perform sticky sessions. Another option is to spawn stateless servers with distributed cache to maintain cache. The ability to route connections and even datagrams to the same tuple is really an "application" level concern. What is the original server tuple is not running any more? Do i need to plug in policies for SO_REUSEPORT to determine how to handle failure conditions?

The SO_REUSEPORT socket option

Posted Jun 2, 2020 21:14 UTC (Tue) by nilsocket (guest, #135507) [Link]

I think, one should remember that, this is done for the sake of performance, for those who need it.

It isn't meant to replace load balancers or something similar.

Maybe within a single application, with multiple threads to handle the load, seems like a good option to have.