[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