[Live-devel] Many multicast sources with same port problem

Ross Finlayson finlayson at live555.com
Fri Oct 1 07:05:05 PDT 2010


>I have done some investigation on this issue and here are the 
>results and suggestions.
>
>1. You were right, it works on  freeBSD , but see 2.
>
>2. This is not a Linux bug

I guess we'll just have to disagree on this.


>We know that one should not bind() to a multicast address

Agreed :-)


>, but according to the kernel developers and other multicast 
>developers this is intended in case you want to receive only from 
>one address and port and not all. It depends on whats needed, so no 
>bug..
>.
><http://jungla.dit.upm.es/~jmseyas/linux/mcast.lj/mcast-lj.html>http://jungla.dit.upm.es/~jmseyas/linux/mcast.lj/mcast-lj.html (shows 
>a bind is required)
><http://marc.info/?l=linux-netdev&m=121579883022264&w=2>http://marc.info/?l=linux-netdev&m=121579883022264&w=2
><http://marc.info/?l=linux-netdev&m=121580189427089&w=2>http://marc.info/?l=linux-netdev&m=121580189427089&w=2


I don't agree with the arguments made here.  In particular:

>That's how it has always worked in the original socket 
>implementation (BSD) and derivatives.

is most definitely not true, because (as you have discovered 
yourself) it doesn't work this way in FreeBSD.

I also don't agree with the claim that "Multicast addresses, like 
unicast addresses, are for the entire
machine, not just the socket that does the join", because the 
IP_ADD_MEMBERSHIP operation is explicitly done on a socket (i.e., 
using "setsockopt()").  It also seems wrong that a process should 
have the potential to - by joining a multicast group - control which 
packets that are received by a separate process.  (This is arguably a 
security violation.)

In any case, this is all a moot point, because I'm not going to be 
changing the LIVE555 code to bind to the multicast address (when 
creating a multicast 'groupsock'), because in the past - when this 
suggestion has been made - some people have discovered and reported 
that it doesn't work for them.  It does not appear to be portable 
across different OSs, so I can't put it in the released code.  It's 
not inconceivable that sometime in the future I might make a change 
to support this, but have it #ifdef'd out by default.  This is not a 
high priority, though, and the whole "groupsock" interface will 
eventually be replaced anyway (to make it more consistent with the 
"liveMedia" object model).  So it might not happen for a while, if 
ever.  Sorry.

In the meantime, you *might* be able to get the effect you want by 
making the following small change to "liveMedia/MediaSession.cpp", 
and also changing "groupsock/GroupsockHelper.cpp" to replace the line
	if (port.num() == 0) addr = ReceivingInterfaceAddr;
with
	addr = ReceivingInterfaceAddr;

(or, you could patch your Linux kernel :-)

*** MediaSession.cpp.save	Fri Oct  1 05:49:35 2010
--- MediaSession.cpp	Fri Oct  1 06:02:43 2010
***************
*** 568,573 ****
--- 568,574 ----
   Boolean MediaSubsession::initiate(int useSpecialRTPoffset) {
     if (fReadSource != NULL) return True; // has already been initiated

+   netAddressBits savedReceivingInterfaceAddr = ReceivingInterfaceAddr;
     do {
       if (fCodecName == NULL) {
         env().setResultMsg("Codec is unspecified");
***************
*** 579,584 ****
--- 580,586 ----
       struct in_addr tempAddr;
       tempAddr.s_addr = connectionEndpointAddress();
           // This could get changed later, as a result of a RTSP "SETUP"
+     if (IsMulticastAddress(tempAddr.s_addr)) ReceivingInterfaceAddr 
= tempAddr.s_addr;

       if (fClientPortNum != 0) {
         // The sockets' port numbers were specified for us.  Use these:
***************
*** 892,897 ****
--- 894,900 ----
       return True;
     } while (0);

+   ReceivingInterfaceAddr = savedReceivingInterfaceAddr;
     delete fRTPSocket; fRTPSocket = NULL;
     delete fRTCPSocket; fRTCPSocket = NULL;
     Medium::close(fRTCPInstance); fRTCPInstance = NULL;
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101001/97ff23cd/attachment.html>


More information about the live-devel mailing list