Re: Possible bug with UDP and SO_REUSEADDR.

[David Schwartz <davids@webmaster.com>]

>>    1) The two instances are cooperating closely together and should be
>>sharing
>>a socket (not each opening one), or
>>
>>    2) The two instances are not cooperating closely together and each own
>>their
>>own socket. For all the kernel knows, they don't even know about each
>>other.
>>
>>    In the first case, it's logical for whichever one happens to try to 
read
>>first to get the/a datagram. In the second case, it's logical for the
>>kernel
>>to pick one and give it all the data.
>>
>>    DS

>IMHO, in the second case it's logical for the kernel NOT to allow the
>second to bind to the port at all. Which it actually does, it's the
>normal case. When you set the SO_REUSEADDR flag on the socket you're
>telling the kernel that we're in case 1).
>
>TJ  

	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.

	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.

	Of course, in this case you don't even need SO_REUSEADDR/SO_REUSEPORT since 
you only actually open the endpoint once.

	DS