-
Notifications
You must be signed in to change notification settings - Fork 325
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
Multicast: dont block local peer discovery for syncthing #778
Comments
+1 |
please make it at least configurable in the site.conf plus disable it by default. (sorry, but any broadcast traffic on the network can break the neck of an already "big" network. ) |
Local peer discovery is about 1 packet per 30-60 seconds. If this will break your network then your network will also break without this "traffic" soon. But local peer discovery brings another nice aspect, since the exchanged payload data (exchanged via unicast) won't go through any exit node and so it doesn't bind more resources than it really has to. Please keep in mind, that we try to build a cool and decentral network and not a highly optimized commercial internet access solution ;) |
We already allow BitTorrent local peer discovery, so adding Syncthing support would make sense. The gain from the reduced traffic between the mesh and the internet should more than outweigh the small increase in broadcast traffic if anybody actually uses Syncthing (and if almost nobody uses it, the additional broadcast traffic will be negligible anyways). One thing to note for all of these local peer discovery protocols: They won't work anymore as soon as we switch to a layer-3-mesh. In the long run, it would be great if we could find a way to fit a Avahi proxy into our firmwares (one that is made for mesh networks and doesn't generate more traffic than necessary) - then all such softwares like Syncthing would just need to implement Avahi/Bonjour instead of inventing the wheel again and again ;) |
Making this configurable in the site.conf would of course be a very nice addition as well. Doing so should be simple, as the ebtables rule files already use a Lua-based DSL. |
couldn't this be a package includable via site.mk if you want to allow this kind of multicast traffic? |
I feel that it makes sense to differentiate node-local, site-local an network-wide announcements. The current scheme that is utilizing ff02 and ff05 does not support this. Mmfd could play a role when forwarding multicast traffic in a l3roamd mesh. |
Closing in favour of the more generic issue #2020. |
@lemoer Since Gluon v2021.1, if the network has been updated properly, then Syncthing Local Peer Discovery should now work with a limited number of nodes which have a syncthing client (< 16). Let me know if this indeed works or if you get close to this limit. That would be good motivation to implement the next steps to scale this, with the plans we have in the drawer for batman-adv :-). Edit: I've also added the Syncthing local peer discovery port to gluon-statistics-mcast. If you'd want to check how/if it's forwarded. |
Syncthing is kind of an opensource alternative to BitTorrentSync. I think it would be very nice, if we could add ebtables rules to allow the local peer discovery.
The text was updated successfully, but these errors were encountered: