[Live-devel] Why does groupsock bind to 0.0.0.0 for streamers?

[Warren Young]

If you say

     $ strace -e bind ./testMPEG2TransportStreamer

you find that it calls bind() twice, once for 0.0.0.0:1234, and another 
time for the "find my IP" hack.

Ultimately, I don't see why it needs to call bind() at all in this 
program since a UDP sender is just tossing packets out onto the network. 
  It's not receiving anything.  (Yes, I saw the "Windoze" case mentioned 
in the nearby comment.  Separate issue.  We're on Linux.)

This causes a problem for us because we have another program -- not 
based on Live555 -- which is simultaneously trying to receive packets 
from a different IP on the same port number, and it gets a bind() 
failure (errno = EADDRINUSE) because the Live555 program has effectively 
claimed total ownership of that port number on all interfaces by asking 
for 0.0.0.0.

I've tried running two instances of testMPEG2TransportStreamer on 
different IPs, and apparently our network stack (Linux 2.6.18) will let 
two programs bind() to 0.0.0.0:1234, but it won't let another program 
bind to, say, 239.255.42.44:1234 at the same time.

We made a one-line change to Live555 (see attached patch) and it fixes 
the symptom for us.  It seems like a reasonable change to me, but I'm 
not sure it isn't some kind of overreach.

We could instead fix this by using different port numbers *and* 
different IPs for our senders and receivers.  (We tried it, and it 
worked.)  We don't want to do that purely because separating senders and 
receivers by putting them on different multicast addresses should be 
enough.  That make a different 5-tuple, so we should be able to keep the 
same port number.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: live555-groupsock-bind.patch
Type: text/x-patch
Size: 351 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130604/8a442bed/attachment.bin>