[Live-devel] Many multicast sources with same port problem
Zdenek Bouresh
zdenek at next-stream.com
Fri Oct 1 08:47:28 PDT 2010
On Fri, Oct 1, 2010 at 5:05 PM, Ross Finlayson <finlayson at live555.com>wrote:
> 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/%7Ejmseyas/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=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.
>
Thank you Ross,
I do agree about the portability issue and do undestand you reasons not
wanting to include it in main code.
Perhaps if it ever works, an ifdef solution may make the most sence.
As for the binding, the linux net folks have this undestanding, I am not
going to argue on that one, but explains why there is no officeal patch for
linux.
>
> 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;
>
> --
>
>
>
Thanks for the provided patch, I was really looking for some guidance after
hours of unsuccessful mods to the Groupsock and binding but still same
behaiviour.
Unfortunately none has worked , neither does the above which really had me
hoping for a while.
Any ideas? Did it work for you when you tried it ?
I think the reason its not working is socket requires GroupAddress to bind
to in adition to ifaddress.
According to the linux folks the combination of mcastaddress:port is the one
we have to bind to isolate sockets, else binding on the interface we get all
traffic to all ports on the interface since we only bind to port without
desitnation.
In any case thanks for all your help, I will still be looking for some work
around in the groupsock and in my code before patching the kernel, but so
far no luck.
Does anyone know of a patch for kernles 2.6.29 and above ?
P.S is UDP performance in freeBSD 8.x poor or is it just me?
Thanks again.
Zed
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
--
Zdenek Bouresh
NextStream LTD.
The information contained within this email transmission and any attachments
is confidential and intended solely for the attention and use of the named
individual addressee(s) or entity. It may not be legally revealed or be
disclosed to any other person or third party without the express authority
(prior written approval) of NextStream LTD and/or the original recipient, or
the intended recipients, or both. If you are not the intended recipient, you
must not disclose, copy, distribute, print, rely on or retain this message
or any part of it. The information contained within is strictly prohibited.
If you have received this email in error please notify the sender by reply,
and delete this message from your email system(s). Any hard copies must also
be destroyed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101001/b7c19575/attachment.html>
More information about the live-devel
mailing list