Can multiple apps listen for TCP on the same port?

[Someone Somewhere]

@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 <karl at 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 at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>
>
> %SPAMBLOCK-SYS: Matched [@freebsd.org+], message ok
>
>
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>