Subject: Re: [AAA-WG]: Support for multi-process

From: Jonathan Wood <[email-masked]>
Date: Mon, 11 Jun 2001 16:43:54 -0700 (PDT)

Further investigation shows that my previous email was
not entirely accurate :(  INIT / SYN collision behavior
for TCP and SCTP are as described, but generating the
scenario is not as described - see below for more details.

> 
> Mark,
> 
> You need to setsockopt SO_REUSEADDR and SO_REUSEPORT to on(1). Not sure you 
> actually need both, but it works that way :-) Note that it needs to be done 
> on both sockets (the one listening/accepting and the one connecting).

This won't work on many systems.

Stevens Unix Networking Programming V1, section 7.5 has a
good discussion on these options. In particular:

"With TCP we are never able to start multiple servers
that bind the same IP address and the same port: a
completely duplicate binding."

I just tried this on Solaris 8, and verified that it does
indeed fail.

Also SO_REUSEPORT does not exist on Solaris. Stevens notes
that this option was introduced in BSD to allow completely
duplicate bindings *when it makes sense*, i.e. for UDP
multicast or broadcast. It looks like your BSD stack is
allowing it for TCP, where it does not make sense.

SCTP sockets have the same behavior as TCP here. The way I
generate SCTP INIT collisions is to have two endpoints
both *connect()* at the same time; neither is listening.
(This is, of course, a race condition; I had to use a
middlebox to delay the INIT packets so that they did
actually cross paths.)

Jonathan

> 
> I can send you some (very very very ugly) code I used for my tests if you 
> want to try it out.
> 
> Of course, all of this is true on a good BSD stack. Don't know how it might 
> turn out on other stacks that might make too strong asumptions about TCP 
> requirements for uniqueness.
> 
> Jacques.
> 
> At 00:36 12/06/01, Mark Eklund wrote:
> >Jacques,
> >
> >On Mon, 11 Jun 2001, Jacques Caron wrote:
> >
> > > It is not a problem to have a process that:
> > > - listens and accepts connections on port 1812
> > > - connects FROM port 1812 to other machines, possibly on port 1812
> > > [replace 1812 with another port number for any other process running on 
> > the
> > > same box]
> > >
> >
> > From your example, it seemed that you could get the above to
> >work.  I have not had such luck.  Maybe I need to go back to TCP
> >101 :).  If I do the following pseudocode,
> >
> >s = socket(AF_INET, SOCK_STREAM, IP_PROTOCOL_TCP);
> >s_addr = (AF_INET, 1812, 1.1.1.1);
> >bind(s, (AF_INET, s_addr, sizeof(s_addr));
> >d_addr = (AF_INET, 1812, *);
> >listen(s, 10);
> >accept(s, d_addr);
> >
> >I now can't get another thread bind to (AF_INET, 1812, 1.1.1.1)
> >so that I can request a connection to (AF_INET, 1812, 2.2.2.2).
> >
> >Is this possible?
> >
> >-mark
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>

---

From: Jacques Caron <[email-masked]>
Date: Tue, 12 Jun 2001 01:58:48 +0200

Mmmm....

I expected that indeed not all stacks would allow it, though I think it's 
more a limitation of the sockets implementation than of TCP itself? It is 
perfectly possible to have multiple sockets/TCP connections associated to 
the same (local addr, local port) pair (as in multiple connections that 
were accepted on a listening socket), and are differentiated by the (remote 
addr, remote port) pair, so I don't quite see why it shouldn't be possible 
(or wouldn't make sense) to also have an active connection from the same 
(local addr, local port) pair...

I guess it wasn't felt as being useful. Too bad. It was worth a try :-/

And now back to our regular state machine programming...

Jacques.

---

From: Barney Wolff <[email-masked]>
Date: Mon, 11 Jun 2001 21:27:19 -0400

In defense of my favorite Unix, the only nonsensical case is
two TCP sockets actually listening on the same addr/port.
There's no reason to prevent two from bind()ing it, if
SO_REUSEADDR is set on both.

Barney Wolff