Dabei handelt es sich um einen dezentralen Messenger, ähnlich wie man es z.B. schon von Tox kennt. Es wird kein Account benötigt, man generiert einfach einen Public Key und veröffentlicht diesen dann als Identifier per DHT. Andere Benutzer können einen so dann direkt P2P kontaktieren.
Problem ist noch, dass DHT immer einen Einsprungpunkt benötigt von dem aus man den Rest des Netzes dann entdecken kann. Damit ist leider noch immer eine Verbindung zum Internet nötig.
Allerdings habe ich auf Reddit gefragt ob geplant ist, eine Suche nach DHT-Peers im lokalen Netzwerk zu implementieren. Da hat sich tatsächlich ein Entwickler gemeldet der meinte dass Suche per Netzwerkscan geplant ist. Ich hab gleich mal vorgeschlagen, das lieber per IPv6 Multicast zu machen, aber mit nem Scan wäre es zumindest in Layer 2 Netzen möglich, so lokale Peers zu entdecken.
Dann hätte man jedenfalls einen Messenger der ohne Problem im Internet funktioniert, aber trotzdem vollkommen transparent auf Lokalbetrieb umstellt, sollte mal das Internet im Mesh ausfallen. Und sowieso bleiben lokale Verbindungen ja auch im „Internetbetrieb“ lokal, da das ganze ja P2P ist.
Das wäre imo endlich ein praktikabler „interner“ Dienst. Natürlich abgesehen davon dass sich der Messenger verbreiten muss, was dank WhatsApp knifflig wird.
(Der Messenger kann auch direkt SIP, wer also eh nen SIP-Client braucht kann sich das ja mal anschauen.)
Also Multicast im Freifunk Mesh ist generell eine sehr schlechte Idee, Multicast wird von Batman wie Broadcast behandelt und man flutet so jede Node + Client und nicht nur die an welchen die Mutlicast-Gruppe konfiguriert ist.
Verhält sich in diesem Fall ähnlich weil man alle Nodes gleichzeitig anspricht.
Gibt schon nen Grund warum so Sachen wie SMB, AppleTalk etc von ebtables auf den Nodes gefiltert werden. Zwar wird in diesem Fall Broadcast verwendet aber wie gesagt, Batman kennt nur Broadcast.
Ich wollte ausdrücken, dass selbst wenn der Typ es nur per Scan implementiert, dass es dann zumindest in Layer 2 Wolken tun würde. (Ich kann mir nicht vorstellen dass man sich Freunde macht, wenn man einen solchen Discovery-Scan mehr als das lokale Netz scannen lässt)
Also wie @PetaByteBoy sagt, besser als ein Netzscan
Ohne ein gewisses Broadcasting kommt man ja eh nicht aus wenn man möchte dass eine Anwendung sich autokonfiguriert.
Und da wir tatsächlich von genau einem Paket Overhead sprechen, welches nur anfällt wenn der Client sich verbindet (Multicast: „Hi Leute, ist hier jemand?“ - Unicast Reply: „Jo hier bin ich mit IP XYZ“ - Handshake as usual) halte ich das doch noch für vertretbar, oder? SMB oder AppleTalk werden ja eher rumpollen, denke ich?
Leider nicht, diese kleine Datenmenge reicht schon das global Airtime auf den Nodes dafür belegt wird und das sollte man vermeiden weil dadurch nicht nur der Durchsatz sinkt sondern auch die Latenz steigt.
Broadcasts bzw Multicast ist momentan extrem beschnitten, eigentlich funktioniert gar nichts bis auf die Dinge die wir explizit erlauben. Selbst Avahi ist zu viel…
Aus einem älteren Thread:
Und die Antwort von tcatm:
Vergesst auch nicht, dass Broadcasts im WLAN pro Knoten dreimal gesendet werden und zudem noch mit sehr viel langsamerer Bitrate als Unicast (bei Gluon häufig 12MBit/s). Das 7byte Paket + Header (12 Byte UDP/IP, WLAN, WIFI-Preamble, batman-adv, …) mit sagen wir 50byte belegt also pro Knoten etwa 100µs Sendezeit bei 12 MBit/s. Wenn sich zwei Knoten sehen oder zumindest sich gegenseitig stören, wären es schon 200µs.
In diesem Thread wird zwar von Broadcast geredet, aber da sich Multicasting momentan genau so verhält ist es ein guter vergleich.
Einfache Faustregel: Layer 2 Mesh => Multicast/Broadcast vermeiden wo es nur geht.
Hm, also sind doch eigentlich alle Autodiscovery-Messenger vom Tisch? Weil ganz ohne Broadcast wird es bei sowas ja nicht gehen (wenn man keinen zentral bekannten Broker haben will…)
Vielleicht kann man mit DNS oder well-known locations (evtl auf nem Gateway) noch was machen. Ich hör mich bei Gelegenheit mal um ob da vllt was gehen würde.
Ja das ist generell vom Tisch ohne Multicast-Optimierungen Hoffentlich wird sich das noch ändern.
Alternativ könnte man ne art Unicast DHT System auf den Supernodes nutzen wo die Clients hin verbinden, weil ohne Supernodes haben wir aktuell sowieso nur einzelne Wolken. Das könnte man dann wieder mit Anycasting machen, also als Beispiel die IP 1.2.3.4 auf die Loopback Interfaces der Supernodes legen, so wird immer nur der aktuelle Supernode genutzt. Mit Ipv6 würde das auch so klappen.
Hoffentlich wird sich das noch ändern.