2 processes listening on the same ip:port ?
burek021
I'm very confused to see this, because it's the first time in my life
I've actually seen something like this, so I could use some help.
First, take a look at the following images:
http://img38.imageshack.us/img38/4770/screenshot1wb.png
http://img526.imageshack.us/img526/2929/screenshot2i.png
Shortly, you can see two processes are listening on the same tcp pair
(ip:port)! How is this possible?
To reproduce this situation, you can start mysql server on your
localhost bindings, and then start putty (SSH client) and configure a
Tunnel which listens on local port 3306 (the same as mysql) and
forwards it to some remote host.
Thanks to all who can help clear out this confusion :)
Barry Margolin
<182ab383-5e5e-4fc3...@d10g2000yqh.googlegroups.com>,
burek021 <bure...@gmail.com> wrote:
> Hi all,
>
> I'm very confused to see this, because it's the first time in my life
> I've actually seen something like this, so I could use some help.
> First, take a look at the following images:
>
> http://img38.imageshack.us/img38/4770/screenshot1wb.png
> http://img526.imageshack.us/img526/2929/screenshot2i.png
The normal way to get two processes listening on the same port is for a
process to call listen() on a socket and then fork. If the child
doesn't close the socket, it will also be listening on it.
>
> Shortly, you can see two processes are listening on the same tcp pair
> (ip:port)! How is this possible?
> To reproduce this situation, you can start mysql server on your
> localhost bindings, and then start putty (SSH client) and configure a
> Tunnel which listens on local port 3306 (the same as mysql) and
> forwards it to some remote host.
>
> Thanks to all who can help clear out this confusion :)
I'm not sure how this scenario is possible. Putty should get an
EADDRINUSE error when it tries to bind the socket. SO_REUSEADDR
shouldn't override this case (it allows you to bind a socket while there
are established sockets using the port, but it shouldn't allow you to
bind a socket while there's a listening socket).
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Dan Lanciani
| I'm not sure how this scenario is possible. Putty should get an
| EADDRINUSE error when it tries to bind the socket. SO_REUSEADDR
| shouldn't override this case (it allows you to bind a socket while there
| are established sockets using the port, but it shouldn't allow you to
| bind a socket while there's a listening socket).
SO_REUSEPORT, however, will allow totally duplicate bindings on
"modern" systems. One of the early rounds of multicast enhancements
for the BSD stack changed the semantics of tcb matching (and thus of
SO_REUSEADDR) to allow for totally duplicate bindings. This broke
things. IIRC, SO_REUSEPORT showed up as the alternative with slightly
different semantics from the "modern" version. There was so much
confusion that some applications may just use both in hopes of getting
the least restrictive behavior.
Dan Lanciani
ddl@danlan.*com
Barry Margolin
ddl@danlan.*com (Dan Lanciani) wrote:
I was under the impression that SO_REUSEPORT was only applicable to UDP,
and maybe just multicast. There's no such thing as multicast TCP,
AFAIK, so which should TCB matching have to consider this case?
Dan Lanciani
| In article <135...@news1.IPSWITCHS.CMM>,
| ddl@danlan.*com (Dan Lanciani) wrote:
|
| > In article <barmar-EF0FE3....@news.eternal-september.org>,
| > bar...@alum.mit.edu (Barry Margolin) writes:
| >
| > | I'm not sure how this scenario is possible. Putty should get an
| > | EADDRINUSE error when it tries to bind the socket. SO_REUSEADDR
| > | shouldn't override this case (it allows you to bind a socket while there
| > | are established sockets using the port, but it shouldn't allow you to
| > | bind a socket while there's a listening socket).
| >
| > SO_REUSEPORT, however, will allow totally duplicate bindings on
| > "modern" systems. One of the early rounds of multicast enhancements
| > for the BSD stack changed the semantics of tcb matching (and thus of
| > SO_REUSEADDR) to allow for totally duplicate bindings. This broke
| > things. IIRC, SO_REUSEPORT showed up as the alternative with slightly
| > different semantics from the "modern" version. There was so much
| > confusion that some applications may just use both in hopes of getting
| > the least restrictive behavior.
|
| I was under the impression that SO_REUSEPORT was only applicable to UDP,
I don't know about "applicable" in an academic sense, but functionally
it works on stream sockets and allows exactly the situation the original
poster described--at least as of the last FreeBSD system I checked.
| and maybe just multicast.
That's another interesting question. IIRC the original multicast patches
used a different path for actual multicast traffic. This path was able
to duplicate packets and deliver them to multiple datagram sockets bound
to a particular port. The path for unicast packets did not handle this;
thus, while you could bind multiple sockets to the same port/address, only
one would receive a given unicast packet. This caused confusion.
| There's no such thing as multicast TCP,
| AFAIK, so which should TCB matching have to consider this case?
TCP and UDP used (and probably still use) common matching code. That's
why the original multicast patches broke TCP servers that used SO_REUSEADDR
but did not want multiple instances of themselves running. (It would also
break UDP servers that similarly desired exclusion, but I don't think they
typically set SO_REUSEADDR since they weren't as worried about lingering
connections.) SO_REUSEPORT provided the necessary semantics for multicast
while letting SO_REUSEADDR go back to its original function. Unfortunately,
it took a while for the API to settle down and there may have been a time
when SO_REUSEPORT was required to get the original SO_REUSEADDR semantics.
Applications that try to be portable may simply be setting them both.
Dan Lanciani
ddl@danlan.*com