@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. This 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 shell 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 <k...@denninger.net> wrote: > The second bind() call does fail but if the application ignores the return > code.... Are you sure all the associated system call return codes 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. > > -- Karl > (On Passport PDA) > > > Original Message > From: Yuri > 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. Why > the presence of the socket that was accepted from (now closed) listening > 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-unsubscr...@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-unsubscr...@freebsd.org" > _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
