(I'm the author/founder.) Old one did distributed breadth-first graph exploration: https://github.com/zerotier/ZeroTierOne/wiki/OLD-Multicast-Algorithm-Notes h

(I'm the author/founder.) Old one did distributed breadth-first graph exploration: https://github.com/zerotier/ZeroTierOne/wiki/OLD-Multicast-Algorithm-Notes https://github.com/zerotier/ZeroTierOne/wiki/OLD-Multicast-A... It was nifty and cool and worked pretty well for small to mid tier stuff, but biggest disadvantages in practice were: (1) Peers seem to drop the potato more often than I predicted when I simulated it, leading to a lot of truncated propagations. It also has no geo-awareness, so if your propagation graph goes through sub-Saharan Africa you're likely to see a lot of packet loss. I think my simulations implicitly assumed all high-end first-world broadband links, when reality includes the whole world and a lot of slow/crummy cellular. (2) High latency, which caused problems for people who wanted low-latency multicast for SDN-type applications (enterprise stuff). In the beginning I never considered those applications, but they're emerging as a major user base. (3) Imposed a high CPU cost, since to prevent flooding every packet had to be cryptographically signed by its originating node. That's a lot of ECC256 signatures and verifications. (4) Mobile-unfriendly, since mobile devices really want to be able to enter long-term hibernation and not have to wake to help others propagate their multicasts. Mobile might even want to turn off most multicast, only allowing ARP and NDP or even emulating these for no multicast at all. (Currently working on iOS and Android ZT1 ports.) This also applies to tiny low power embedded devices, and I've had some interest from Internet-of-things experimenters. There's no write-up on the new algorithm yet, but it's basically sender-side replication with lazy but deterministic gathering. It gathers recipients up to the limit from supernodes and from peers. (In reality supernodes are peers-- they're merely peers designated as such.) I remember initially passing on that idea since I was afraid it would be too heavy on the sender, but observing real traffic flows shows that in aggregate the multicast traffic load ends up close to the same. Sender-side replication is also inherently fair -- sender pays the price -- so you don't need such heavy signature/verification checks to ensure that somebody can't flood the network. This way it's no easier to flood with multicast than with unicast. (Obviously anyone can DDOS but that's another matter.) In the longer term I plan to add some support for merging of multicasts going to the same local network or site, but I'm not sure how yet... it's probably going to intersect with R&D work I'm doing right now on enterprise supernode federation for SDN applications and similar stuff.