-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kill multicast rate limits inside ZT -- no longer needed, uses memory and CPU #191
Comments
I've considered removing multicast rate limits, since it does sender-size replication. The sender incurs all bandwidth for multicast and if someone is screaming multicast on your network that's a problem with that participant. |
Yes, I agree. It would also save a lot of resources. |
Yeah, let's do it. It's kind of left over from the old peer to peer distributed graph traversal algorithm, which I dumped for sender-side replication for various reasons. Simple is good. |
I actually like deleting code. Feels good. :) |
Let me do this one -- it touches a few things. |
So ... relieving, I was about to make a pull request. ;-) |
:-) And multicast can still be prohibited by filters (netflow). Or if you have an reasonable firewall implementation, rate limiting can be done too by the firewall. |
Yeah -- thing is, with sender-side replication the rate limits are not enforced except by the sender... so there's no security against flooding benefit here. That and a flooder pays all bandwidth, so there is no amplification attack. In the old multicast propagation algorithm I had this rate limiting algorithm to prevent amplification attacks, but the whole thing was too complex/expensive compared to simple sender-side replication. |
Please clarify the title that we are talking about multicast INSIDE a zerotier network. |
Yes, multicast inside a network. |
Not sure what other kind there would be. |
…ere not well supported or easily configurable anyway) -- this is really left over from the old collaborative multicast propagation algorithm. New algorithm (in for a while) has been sender-side replication in which sender "pays" all bandwidth, which intrinsically limits multicast.
The Bounjour Discovery Protocol for nodes to discover each other on a local private network uses multicast instead of broadcasts, and works better in most kinds of multi-nat or multi-router scenarios. |
May I ask, why is multicastLimit still inside the api for network controller configuration, if multicastLimit now means nothing? |
Different concept. The current multicastLimit is the maximum number of recipients. This was the maximum transfer rate. |
Entries from map _multicastRateAccounts in node/Network.cpp do not seem to be removed anywhere.
The text was updated successfully, but these errors were encountered: