3 ms·

I made extensive use of the SO_REUSEPORT flag a couple decades back to build agents that on the same machine would have their own UDP socket which received data

I made extensive use of the SO_REUSEPORT flag a couple decades back to build agents that on the same machine would have their own UDP socket which received data from a local piece of software. Basically, by using that flag each socket received a copy of the buffer, so that each agent could act upon the contents ("is it for me? - if yes then read this field and act accordingly, otherwise ignore"). Very handy, despite all limitations of UDP. It allowed me to keep the code very tight and specific for every agent, although network buffer structures were all in common so upgrading the protocol to all agents was easy. With some adaptations, it worked both on Windows's POSIX stack and Unix.

ww520 5y ago
This sounds very handy for broadcast within a box type of applications.
robotresearcher 5y ago
My recollection of SO_REUSEPORT behavior is that it will deliver a datagram to one listener, rather than all of them. The kernel will distribute datagrams fairly between listeners over time, so none are starved. This makes it super easy to share load over multiple servers, but doesn't get the same datagram to multiple listeners. This seems to confirm: https://lwn.net/Articles/542629/ https://lwn.net/Articles/542629/ Maybe the exact behavior varies by platform. I've never used it on Windows.
- squarefoot 5y ago
  > Maybe the exact behavior varies by platform. Yes, that was the case. Also I probably confused SO_REUSEADDR, which in Windows is implemented quite differently, with SO_REUSEPORT. Anyway, I can confirm that on Windows (2000) I could open N programs whose receiving socket was bound on the same address:port and all of them would receive a copy of the transmitted datagram. If say I run 5 copies of the same agent, all of them would display the same data. Those were stand alone applications without any shared memory, so apparently the system made a copy of the buffer for each socket. I'm not sure however if I tested this particular behavior also under Unix, since I needed it only on the graphical interface, but on Windows it definitely worked.
- haneefmubarak 5y ago
  I haven't confirmed the behavior on BSD manually, but based on skimming https://stackoverflow.com/a/14388707/2334407 https://stackoverflow.com/a/14388707/2334407 and https://www.freebsd.org/cgi/man.cgi?query=setsockopt&sektion=2 https://www.freebsd.org/cgi/man.cgi?query=setsockopt&sektion... , I'm inclined to believe their implicit claim that the original behavior of SO_REUSEPORT is to duplicate everything to each listener. In fact, it looks like Linux copied the behavior of SO_REUSEPORT_LB and called it SO_REUSEPORT. Ahhh, the joys of "portability"...
  - thaumasiotes 5y ago
    The freebsd page doesn't claim that it delivers everything to every listener. It says that's possible if multicast or broadcast is configured. That won't happen by default. > This option permits multiple instances of a program to each receive UDP/IP multicast or broadcast datagrams destined for the bound port.
RyanHamilton 5y ago
Are you sure? I didn't think SO_REUSEPORT was that old. ~2013 on linux.
deleted 5y ago
[deleted]

ww520 5y ago

This sounds very handy for broadcast within a box type of applications.

robotresearcher 5y ago

My recollection of SO_REUSEPORT behavior is that it will deliver a datagram to one listener, rather than all of them. The kernel will distribute datagrams fairly between listeners over time, so none are starved. This makes it super easy to share load over multiple servers, but doesn't get the same datagram to multiple listeners. This seems to confirm: https://lwn.net/Articles/542629/ https://lwn.net/Articles/542629/ Maybe the exact behavior varies by platform. I've never used it on Windows.

squarefoot 5y ago
> Maybe the exact behavior varies by platform. Yes, that was the case. Also I probably confused SO_REUSEADDR, which in Windows is implemented quite differently, with SO_REUSEPORT. Anyway, I can confirm that on Windows (2000) I could open N programs whose receiving socket was bound on the same address:port and all of them would receive a copy of the transmitted datagram. If say I run 5 copies of the same agent, all of them would display the same data. Those were stand alone applications without any shared memory, so apparently the system made a copy of the buffer for each socket. I'm not sure however if I tested this particular behavior also under Unix, since I needed it only on the graphical interface, but on Windows it definitely worked.
haneefmubarak 5y ago
I haven't confirmed the behavior on BSD manually, but based on skimming https://stackoverflow.com/a/14388707/2334407 https://stackoverflow.com/a/14388707/2334407 and https://www.freebsd.org/cgi/man.cgi?query=setsockopt&sektion=2 https://www.freebsd.org/cgi/man.cgi?query=setsockopt&sektion... , I'm inclined to believe their implicit claim that the original behavior of SO_REUSEPORT is to duplicate everything to each listener. In fact, it looks like Linux copied the behavior of SO_REUSEPORT_LB and called it SO_REUSEPORT. Ahhh, the joys of "portability"...
- thaumasiotes 5y ago
  The freebsd page doesn't claim that it delivers everything to every listener. It says that's possible if multicast or broadcast is configured. That won't happen by default. > This option permits multiple instances of a program to each receive UDP/IP multicast or broadcast datagrams destined for the bound port.

RyanHamilton 5y ago

Are you sure? I didn't think SO_REUSEPORT was that old. ~2013 on linux.

deleted 5y ago

[deleted]