Feature #1876

Use IP multicast for faster broadcast and multicast on netlrts

Added by Sam White over 1 year ago. Updated about 1 year ago.

Target version:
Start date:
Due date:
% Done:



#1 Updated by Sam White over 1 year ago

I think verbs has similar support

#2 Updated by Eric Bohm about 1 year ago

  • Assignee set to Nitin Bhat
  • Tracker changed from Bug to Feature

#3 Updated by Sam White about 1 year ago

I think we probably want to implement this with verbs first, rather than for netlrts, since we care more about verbs performance. But we'd want an LRTS API for this so that we can then implement support for it on whatever machine layers support it.

#4 Updated by Evan Ramos about 1 year ago

It looks like the network protocol aspect of IP multicast is fairly simple. Sending packets is the same as with unicast, only with a group address instead of an individual address. Listeners do the following initialization once:

struct ip_mreq request;
request.imr_multiaddr.s_addr = /* multicast group address, such as */;
request.imr_interface.s_addr = htonl(INADDR_ANY);
int retval = setsockopt(/* socket */, IPPROTO_IP, IP_ADD_MEMBERSHIP, (char *)&request, sizeof(request));
if (retval != SOCKET_ERROR) { /* success... */ }

The IP multicast API does not help with choosing a group address. Our implementation must pick one. (Querying techniques require raw sockets, which need root privileges at some stage for access to be granted to a program.) Two concerns arise from this:

  • Performance: Network hardware must filter unwanted packets received from a multicast group address.
  • Correctness: I'm not certain this is relevant, but if Converse receives packets from a different Charm++ instance on the same cluster, will it know to reject them?

This is my estimation of what IP multicast support needs:

  • Constructing the LRTS and machine layer infrastructure for hardware-level broadcasts
  • Testing at init time that all nodes are reachable with IP multicast, falling back to unicast if not usable
  • Handling any correctness issues that may arise from suboptimal network hardware implementations
  • Add user-facing configuration of group address

Also available in: Atom PDF