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

[Zdenek Bouresh]

Hello Ross,

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, but intended behavior. making 1. an exception
due to how multicast is implemented (different) in freeBSD.

Here is why:
We know that one should not bind() to a multicast address, 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 (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

In short if you join a group with IN_ADDRANY, the indended behavior is you
that you DO get all multicast groups sending on the same port, which is the
case in Live.

If you do want to receive only packets from a specific address and port, you
must not use IN_ADDRANY and  you should bind() the socket to the required
multicast address to receive packets only from this address /port/

All this is reported as intended behavior and the reason there is no FIX in
the linux kernel
The above documents and discussion explain it.

Here is what linux net dev team has to say about the reported "bug".

That's how it has always worked in the original socket implementation (BSD)
> and derivatives. The control for socket reception is the binding, so if you
> want only mcast X packets, you need to bind to X. If you bind to INADDR_ANY,
> that *means* you don't care what the destination address is and you'll
> receive all unicast and multicast packets with a matching port and protocol.


The above explains why the Linux patch has been declined.

I hope you can add support for this in live as I believe both are valid uses
cases.

I also hope that my research on the matter helps and shows that its not a
linux bug or a live bug but a case that live does not currently handle, (A)
not bindng and using INADDR_ANY
Some apps take advantage of this for messaging for example, in my case and I
believe in most live555 cases its actually the opposite that we need.

Thank You,
looking forward to resolving this scenario in live555. Its a great library.

Zed.




On Sun, Sep 19, 2010 at 3:12 PM, Ross Finlayson <finlayson at live555.com>wrote:

> If your application is receiving - on a socket - traffic that was sent to a
> multicast address that that socket did not subscribe to, then that is
> definitely a problem with the operating system, not with your application,
> and not with our libraries.
>
> Because you say that you are unwilling to change your operating system[*],
> and because you say that you can't stop your incoming traffic (for different
> multicast addresses) from using distinct port numbers, then there's no help
> that I can give you.  Sorry.
>
> [*] Note that FreeBSD - as far as I can tell - does not appear to have this
> problem.  If I were you, I'd try using FreeBSD instead of Linux.
> --
>
> 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/04baa153/attachment-0001.html>