Date: Mon, 1 Dec 2014 16:09:31 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Joe Holden <lists@rewt.org.uk> Cc: FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: Can multiple apps listen for TCP on the same port? Message-ID: <CAJ-Vmo=btHf-aKqti2s9e5r2Mz0EN4qmunEjezWgtrumH6eJYQ@mail.gmail.com> In-Reply-To: <547C9F7A.5000803@rewt.org.uk> References: <547C5DD3.90604@rawbw.com> <20141201150225.GB64370@apollo.corbe.net> <547C88AD.40407@rawbw.com> <20141201153712.4304976.24709.1746@denninger.net> <CAMW5ToZh2oqry1TKma67MmiAHjMbUZmE%2B0POKHDaeP1cVQpoCw@mail.gmail.com> <CAJ-VmokGVnqeY6nm55q2Q83bTc_%2BKsq0FvCobx6L_qhXi%2Bg3gA@mail.gmail.com> <547C9F7A.5000803@rewt.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1 December 2014 at 09:03, Joe Holden <lists@rewt.org.uk> wrote: > Was there a specific reason why we couldn't just extend REUSEADDR/PORT to= do > this a la Linux? Just a simple round robin would make those useful perhap= s Because REUSEADDR/REUSEPORT have different meanings, doubly so if you're using multicast. I created a new socket option so we wouldn't have to try and untangle that mess of "what was it supposed to do in this context" which may have broken applications that rely on the existing behaviour. -adrian > > On 01/12/2014 16:21, Adrian Chadd wrote: >> >> Hi, >> >> I introduced a socket option in -HEAD that lets you bind multiple >> things to the same listen ports. >> >> They're only load balanced if you're using RSS and set up RSS socket >> options as well; otherwise only one gets the incoming requests. >> >> IP_BINDMULTI and IP6_BINDMULTI. >> >> >> -a >> >> >> On 1 December 2014 at 08:14, Someone Somewhere >> <somewheresomeoneis@gmail.com> wrote: >>> >>> @Yuri , are you sure that the second instance of nc does not accept any >>> connection? >>> I did a simple test : -> >>> #: nc -l 12345 (shell 1) >>> #: nc localhost 12345 (shell2) >>> at this point netstat shows that there is no one listening on 12345. Th= is >>> means any process should not be able to bind over port 12345(over TCP). >>> # nc -l 12345 (shell 3, shell 1 , 2 still active) >>> this instance of nc starts listening which I could verify via netstat >>> cmd. >>> # nc localhost 12345 (shell 4) >>> this nc instance connected to the nc started in previous step over shel= l >>> 3. >>> >>> Test ran on Fedora 20. >>> [will try this on freeBSD VM if you confirm that this is what you are >>> trying] >>> >>> >>> Could you verify if your second nc(server) instance is listening on the >>> same socket number? >>> >>> >>> -Kunal. >>> >>> >>> >>> On 1 December 2014 at 21:07, Karl Denninger <karl@denninger.net> wrote: >>> >>>> The second bind() call does fail but if the application ignores the >>>> return >>>> code...=E2=80=8E. Are you sure all the associated system call return c= odes are >>>> being checked? >>>> >>>> The right way to do this Imho is to have a parent process that calls >>>> bind >>>> and listen, gets the notification of an incoming connection via select= () >>>> (allowing detection of exceptions as well) and then calls accept() and= , >>>> now >>>> having a connected file handle, fork()s and executes whatever is to >>>> handle >>>> the connection with the parent closing the handle so as to not orphan >>>> the >>>> handle when the child exits. >>>> =E2=80=8E >>>> -- Karl >>>> (On Passport PDA)=E2=80=8E >>>> >>>> >>>> Original Message >>>> From: Yuri=E2=80=8E >>>> Sent: Monday, December 1, 2014 10:26 >>>> To: Daniel Corbe >>>> Cc: freebsd-net@freebsd.org >>>> Subject: Re: Can multiple apps listen for TCP on the same port? >>>> >>>> On 12/01/2014 07:02, Daniel Corbe wrote: >>>>> >>>>> Generally the answer to your question is no. Two applications cannot >>>>> occupy the same port on the same protocol at the same time. >>>>> >>>>> To expand on this answer and to hopefully shed some light on why the >>>>> behavior you're observing with your application is absolutely correct= ; >>>>> the calling application (in this case, nc) has to explicitly call >>>>> bind(2) >>>>> before it can begin accepting connections. If that port is already in >>>>> use then the call to bind(2) will fail. And in your case I suspect nc >>>>> is simply choosing to silently fail. >>>> >>>> >>>> Here the question is what does it mean "occupy the port"? The first >>>> instance isn't listening any more. The listening socket was closed. Wh= y >>>> the presence of the socket that was accepted from (now closed) listeni= ng >>>> socket in the first instance is considered "occupying it"? >>>> >>>> Actually no system call in the second instance ever fails. >>>> >>>> Yuri >>>> _______________________________________________ >>>> freebsd-net@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>>> >>>> >>>> %SPAMBLOCK-SYS: Matched [@freebsd.org+], message ok >>>> >>>> >>>> _______________________________________________ >>>> freebsd-net@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=btHf-aKqti2s9e5r2Mz0EN4qmunEjezWgtrumH6eJYQ>