Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Nov 2013 19:46:00 +0100
From:      =?ISO-8859-1?Q?Ermal_Lu=E7i?= <eri@freebsd.org>
To:        Tim Kientzle <kientzle@freebsd.org>
Cc:        freebsd-net <freebsd-net@freebsd.org>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>
Subject:   Re: [PATCH] SO_REUSEADDR and SO_REUSEPORT behaviour
Message-ID:  <CAPBZQG0FfVbv4zzrU=rxLS9WwRVurDoH%2BNpxE_xTXpEN6wVHQg@mail.gmail.com>
In-Reply-To: <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org>
References:  <CAPBZQG29BEJJ8BK=gn%2Bg_n5o7JSnPbsKQ-=3=6AkFOxzt%2B=wGQ@mail.gmail.com> <4053E074-EDC5-49AB-91A7-E50ABE36602E@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 29, 2013 at 6:59 PM, Tim Kientzle <kientzle@freebsd.org> wrote:

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

Every one has its own use-case!


>
> I=92ve 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 close=
d.
>
> * 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 =93still i=
n
> use=94 by connections in the TCP connection table.
>
> With these flags, the new server can open the port even though
> it is =93still in use=94 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=92re 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
>
>


--=20
Ermal



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPBZQG0FfVbv4zzrU=rxLS9WwRVurDoH%2BNpxE_xTXpEN6wVHQg>