SO_REUSEPORT/ADDR(2/2) — How packets forwarded to multiple sockets —
This post is continuous of SO_REUSEPORT/ADDR (1/2) — How different about the condition of binding .
So if you haven’t read previous one, you have to read previous one before start to read this post.
Previous post summarise mainly the condition of binding multiple socket onto same ip/port between SO_REUSEPORT/ADDR. This post would focus on the area how packets distributed onto the multiple socket bound to the same ip/port with 2 different socket options.
SO_REUSEADDR
UDP broadcast
- All sockets received the packets
UDP unicast
- The most recent created socket only receive the packet
- When new socket came up, all packets will be gone to that new socket
- When the socket receiving packet closed, next recent created socket start to receive
SO_REUSEPORT
UDP broadcast
- All sockets received the packets
UDP unicast
- Load balanced the packets evenly into multiple sockets
- When new socket came up, new socket will also be one of the sockets load balanced
TCP unicast
- Load balanced the packets evenly into multiple sockets (once established the connection, connection cling on specific socket)
SO_REUSEADDR + SO_REUSEPORT
same as the time to specify just SO_REUSEPORT
From point of view about how forwarded, SO_REUSEPORT would always override the behaviour if SO_REUSEPORT is specified. Thus I don’t think SO_REUSEADDR + SO_REUSEPORT combination is reasonable.
Summary
SO_REUSEADDR seems work as Act-Stanby model (always socket that can receive packet is just 1 socket except for broadcast)
SO_REUSEPORT seems work as Act-Act LB, So this feature make you be able to load balanced to multiple process inside a node without any software and just start multiple app.
If you are considering multiple bind for UDP, you can chose prefer behaviour Act-Stanby or Act-Act but if you are considering for TCP you got only 1 option (SO_REUSEPORT)
