>> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Apr 30 2002 - 22:00:16 EST