[PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour

Ermal Luçi eri at freebsd.org
Fri Nov 29 18:46:01 UTC 2013


On Fri, Nov 29, 2013 at 6:59 PM, Tim Kientzle <kientzle at freebsd.org> wrote:

>
> On Nov 29, 2013, at 4:04 AM, Ermal Luçi <eri at freebsd.org> wrote:
>
> > Hello,
> >
> > since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to
> > share the same port and possibly listening ip …
>
> These flags are used with TCP-based servers.
>

Every one has its own use-case!


>
> I’ve used them to make software upgrades go more smoothly.
> Without them, the following often happens:
>
> * Old server stops.  In the process, all of its TCP connections are closed.
>
> * Connections to old server remain in the TCP connection table until the
> remote end can acknowledge.
>
> * New server starts.
>
> * New server tries to open port but fails because that port is “still in
> use” by connections in the TCP connection table.
>
> With these flags, the new server can open the port even though
> it is “still in use” by existing connections.
>
>
> > This is not the case today.
> > Only multicast sockets seem to have the behaviour of broadcasting the
> data
> > to all sockets sharing the same properties through these options!
>
> That is what multicast is for.
>
>
Multicast has its defined scope and its applications though i think its
interpreting the same socket options
and respecting the options for what they should do and how they should
behave.


> If you want the same data sent to all listeners, then
> that is multicast behavior and you should be using
> a multicast socket.
>
> > The patch at [1] implements/corrects the behaviour for UDP sockets.
>
> You’re trying to turn all UDP sockets with those options
> into multicast sockets.
>

Not really the idea is how you do support the use case of having two
daemons using the same port numbers
but speaking different protocols.
The best would be to merge these daemons but in the case you cannot there
should be some support on it.
At the very end there are only 65k ports :).

Probably a sysctl for the feature might be a further compromise on it?


>
> If you want a multicast socket, you should ask for one.
>
> Tim
>
>


-- 
Ermal


More information about the freebsd-current mailing list