Re: [go-nuts] net: Multicast groups with the same port

[Mikio Hara]

On Thu, Aug 9, 2012 at 8:18 AM, <akal...@gmail.com> wrote:

> Anyone understand why this is the chosen behavior of go's net package?

A few reasons.

- The net API should be consistent across over platforms.
old widows doesn't support listening to a multicast address, at least
2000 and XP don't, vista and beyond? not sure.

- Listening to the pair of address:port, then joining to the multicast
group on the specific network interface is the common way, I guess.
If you never specify the multicast interface? share the listening port
to other apps? we believe that you know what you are doing because
IP multicast is the one of most complicated networking technologies
since its birth. ;)

- a pair of address:port
- a group address on a network interface

For now using the different listening port for each multicast group
would be a solution to avoid the crosstalk you've seen.

If you have a nice API design for future Go release, please let us
know <http://golang.org/doc/contribute.html>. Some people want to
join multiple group addresses, classify the group address on incoming
packets.

-- Mikio

[Mikio Hara]

Hi,

On Fri, Aug 10, 2012 at 1:42 AM, <akal...@gmail.com> wrote:

> As far as I know, the Windows O/S supports listening to multicast.

Hmm...
<http://stackoverflow.com/questions/6140734/cannot-bind-to-multicast-address-windows>

>> - a pair of address:port
>> - a group address on a network interface
>

> If I understand right, you're talking about the duality of the bind() call.

By the way syscall.Bind assigns a name to a socket, a pair of address:port,
for local delivery. It affects UDP socket table or similar.

syscall.Setsockopt with ADD_MEMBER_SHIP, MULTICAST_IF injects
a group address and a multicast interface into IP multicast listener table.

There are at least two different tables, two distinct lookup processes.

> You can bind a socket to an IP, which can be a local interface's IP or a
> multicast group IP.

If I understand correctly, we can bind a socket to:
- a unicast interface IP address on almost every platforms,
- a wildcard address on almost every platforms,
- a group address but it depends on platforms,
- any unicast IP address but it depends on platforms.

> In the case of multicast on linux, I believe that zeroing the multicast IP
> in the call to bind causes the unexpected/undesired behavior I'm observing.

For now ListenMulticastUDP uses a wildcard address listen to make
consistent behavior across over platforms. That also allows to join
additional group addresses.

If you are saying that ListenMulticastUDP on Linux should bind a socket
to a group address, that sounds not good for people who love single-socket-
handles-multiple-groups style. Perhaps we need another UDP multicast API,
need further investigation.

>> For now using the different listening port for each multicast group
>> would be a solution to avoid the crosstalk you've seen.
>

> This is unfortunately not an option for my application as I am not sending
> the multicast data, I'm only receiving.

Then the next option would be the common way: classifying IP destination
address, in this case a group address, on incoming packets by using
syscall.Sockopt with IP_DSTADDR on BSD variants, IP_PKTINFO on Linux
or latest Darwin and syscall.Recvmsg.

-- Mikio