[Spread-users] spread-5.0.0rc1 : data_link.c : algorithm to choose interface(s) for multicast binding changed ?
John Lane Schultz
jschultz at spreadconcepts.com
Wed Dec 14 19:02:01 EST 2016
Martin, Everyone,
I also looked at what would happen under Spread v5.0 if you omitted the interface specification in your configuration. In that case, I think it would bind a recv channel to INADDR_ANY (so traffic on any interface to its port that wasn’t already bound by another process could reach it) and it would join the multicast group on its main address interface. So, you might not need the interface specification any more if you don’t care about limiting on which interface traffic to your port might arrive. That is, if the only reason you were using the interface specification was to force the multicast group join to occur on the correct interface, then that issue might be gone in Spread v5.0. Give it a shot and see, if you like.
r = DL_init_channel_gen(RECV, NULL, [INADDR_ANY, port]) /* recv data */
bind(r, [INADDR_ANY, port])
DL_join_multicast_gen(r, 239.192.2.2, 151.1.1.1)
join(r, multiaddr=239.192.2.2, interface=151.1.1.1)
tr = DL_init_channel_gen(RECV, 0, [INADDR_ANY, port+1]) /* unicast recv token */
bind(tr, [INADDR_ANY, port+1])
I also forgot to mention that in v5.0, I separately make a socket for sending that is always bound to the main address of the daemon:
s = DL_init_channel_gen(SEND | RECV, NULL, [151.1.1.1, 0])
bind(s, [151.1.1.1, 0])
This can be important because Spread v5.0 now enforces that, at the IP level, the source address of received traffic matches that primary address associated with the daemon who claims to have sent it in the packet. So, Spread itself now implements a weak form of IP based “firewalling.” It will ignore packets who source IP address doesn’t match the address of the transmitter marked in the packet.
This is an important change and means, for example, that spmonitor must be run on one of the machines in the current configuration or its traffic will be ignored too. This was done intentionally so that if someone wanted to send traffic to your Spread deployment, then they would either have to forge IP headers or be on one of the machines in your configuration.
Cheers!
-----
John Lane Schultz
Spread Concepts LLC
Cell: 443 838 2200
On Dec 14, 2016, at 12:51 PM, John Lane Schultz <jschultz at spreadconcepts.com> wrote:
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
_______________________________________________
Spread-users mailing list
Spread-users at lists.spread.org
http://lists.spread.org/mailman/listinfo/spread-users
More information about the Spread-users
mailing list