[Spread-users] spread-5.0.0rc1 : data_link.c : algorithm to choose interface(s) for multicast binding changed ?

[John Lane Schultz]

Martin,

Here’s the difference between the two versions in how they bind and how they join multicast groups for your configuration file.  I used 151.1.1.1 as my example.

##########################
Spread v4.4:

mr = DL_init_channel(RECV, 239.192.2.2, 239.192.2.2, port)  /* multicast recv data */
bind(mr, [239.192.2.2, port]);
join(mr, multiaddr=239.192.2.2, interface=INADDR_ANY)

ur = DL_init_channel(RECV | DL_BIND_ALL, 239.192.2.2, 155.1.1.1, port)  /* unicast recv data */
bind(ur, [155.1.1.1, port])
join(ur, multiaddr=239.192.2.2, interface=155.1.1.1)

tr = DL_init_channel(RECV, 0, 155.1.1.1, port+1)  /* unicast recv token */
bind(tr, [155.1.1.1, port+1])

##########################
Spread v5.0:

ur = DL_init_channel_gen(RECV, NULL, 155.1.1.1)  /* unicast recv data */
bind(ur, [155.1.1.1, port])

DL_join_multicast_gen(ur, 239.192.2.2, 151.1.1.1)
join(ur, multiaddr=239.192.2.2, interface=151.1.1.1)

tr = DL_init_channel_gen(RECV, 0, 155.1.1.1, port+1)  /* unicast recv token */
bind(tr, [155.1.1.1, port+1])

mr = DL_init_channel_gen(RECV, NULL, 239.192.2.2)  /* multicast recv data */
bind(mr, [239.192.2.2, port])

DL_join_multicast_gen(mr, RECV, 239.192.2.2, 151.1.1.1)
join(mr, multiaddr=239.192.2.2, interface=151.1.1.1)

##########################

The reason why you see v4.4 joining the same group on different interfaces is that v4.4 joins 239.192.2.2 on interfaces INADDR_ANY and interface 151.1.1.1 on different file descriptors.

Meanwhile, v5.0 joined 239.192.2.2 both on interface 151.1.1.1 on two different file descriptors.

The extra join on the unicast recv file descriptor is probably only necessary on Windows where the extra multicast recv file descriptor isn’t even created.

Cheers!

-----
John Lane Schultz
Spread Concepts LLC
Cell: 443 838 2200

On Dec 14, 2016, at 7:18 AM, Martin Schu <martin.sc11111 at gmail.com> wrote:

Hi John,

we have some strange observation:
With spread-4.4.0 running on some of our hosts we see a wrong binding of an additional interface for multicast, which makes no sense to us and might be causing problems due to wrong routed traffic.
With spread-5.5.0rc1 this malfunction is gone. Only the correct interface is bound.

Maybe you can help us to understand what is happening here. Below is the output of netstat -g on the same host with same configuration. Only the spread installation was updated! No other change.

Any advice is greatly welcome. We don't understand what causes that wrong interface binding.

Best regards,
Martin

** spread.conf:
Spread_Segment  239.192.2.2:8982 {
        host1 155.1.1.1  { 155.1.1.1 }
        host2 155.1.1.2  { 155.1.1.2 }
        host3 155.1.1.3  { 155.1.1.3 }
}
Spread_Segment  239.192.2.4:8982 {
        host4 155.1.1.4 { 155.1.1.4 }
        host5 155.1.1.5 { 155.1.1.5 }
        host6 155.1.1.6 { 155.1.1.6 }
}

** spread-4.4.0 
running:


$ netstat -g
IPv6/IPv4 Group Memberships
Interface       RefCnt Group
--------------- ------ ---------------------
lo              1      224.0.0.1
eth0            1      224.0.0.1
eth1            1      224.0.0.1
eth2            1      239.192.2.2  
!!!WRONG!!!

eth2            1      224.0.0.1
eth3            1      239.192.2.2    
CORRECT

eth3            1      224.0.0.1
eth4            1      224.0.0.1



** no spread running:


$ netstat -g
IPv6/IPv4 Group Memberships
Interface       RefCnt Group
--------------- ------ ---------------------
lo              1      224.0.0.1
eth0            1      224.0.0.1
eth1            1      224.0.0.1
eth2            1      224.0.0.1
eth3            1      224.0.0.1
eth4            1      224.0.0.1



** 
spread-5.0.0rc1 
running:


$ netstat -g
IPv6/IPv4 Group Memberships
Interface       RefCnt Group
--------------- ------ ---------------------
lo              1      224.0.0.1
eth0            1      224.0.0.1
eth1            1      224.0.0.1
eth2            1      224.0.0.1
eth3            2      239.192.2.2  CORRECT
eth3            1      224.0.0.1
eth4            1      224.0.0.1