Re: Possible bug with UDP and SO_REUSEADDR.

[Terje Eggestad]

On Mon, 2002-04-29 at 12:38, David Schwartz wrote:
> 
> >However, I still can't see any *practical* use of having one program
> >(me) bind the port, deliberately share it, and another program (you)
> >coming along and want to share it, and then all unicast datagrams are
> >passed to you. Not If I haven't subscribed to any multicast addresses,
> >and no one is sending bcasts, there is no point of me being alive.
> >
> >Can you come up with a real life situation where this make sense?
> 
> 	Absolutely. This is actually used in cases where you have a 'default' 
> handler for a protocol that is built into a larger program but want to keep 
> the option to 'override' it with a program with more sophisticated behavior 
> from time to time. In this case, the last socket should get all the data 
> until it goes away.
> 
> 	DS
> 

First of all since we're in agreement that the current behavior is NOT a
bug, this discussion is pretty pointless, however I getting worked up.

In all fairness, I've a colleague that did an implementation of TCPIP a
decade ago, and his in agreement in that the current logic this is the
way implementations worked. Thus we're less likely to break things
leaving this they way they are. 

However you logic is broken.
First of all, I asked for a case where it make sense, not where it's
moronically been done so. If you review your own argument:

> That's why if you mean to share, you should share the actual socket 
> descriptor rather than trying to reference the same transport endpoint
> with two different sockets.

The program that want to "override" shall connect the first on a
AF_UNIX, get the descriptor and be told not to read from the UDP socket
until the AF_UNIX socket to the overrider is broken/disconnected.

Since according to Stevens, what happen here is implementation specific,
the "overriding" you describe is non-portable.

If you look at you other argument: 
>        NO. When you set the SO_REUSEADDR, you are telling the 
> kernel that you intend to share your port with *someone*, but not who.
> The kernel has no way to know that two processes that bind to the same
> UDP port with SO_REUSEADDR  are the two that were intended to 
> cooperate with each other. For all it knows, one is a foo intended to
> cooperate with other foo's and the other is a bar intended to 
> cooperate with other bar's.

The logical deduction from this is that you should never, ever, use bind
to the same address for unicast since the kernel don't have the
sufficient information to route the datagram correctly. I *COULD* agree
to that it should be illegal to duplicate bind to an address.

Trouble is now that is actually legal...

TJ
 
> 
> 
> 
-- 
_________________________________________________________________________

Terje Eggestad                  mailto:[e-mail]
Scali Scalable Linux Systems    http://www.scali.com

Olaf Helsets Vei 6              tel:    [phone] (OFFICE)
P.O.Box 150, Oppsal                     [phone]  (MOBILE)
N-0619 Oslo                     fax:    [phone]
NORWAY            
_________________________________________________________________________