DaWN-Dokumentation · Das Netz
Das Netz zwischen den Knoten
Eine Adresse ist hier kein Ort, sondern ein Schlüssel. Ereignisse müssen einen Protokollwechsel überleben, Geräte nach Wochen ohne Verbindung wieder zusammenfinden — und eine Nachricht ihr Ziel erreichen, auch wenn beide nie gleichzeitig online sind. Der letzte Punkt ist der einzige, für den es noch keine geprüfte Antwort gibt.
Reifegrad dieser Seite
Der gesamte Netzteil hat null Zeilen Code. Das Verzeichnis für seine Bausteine ist leer, und keine Abhängigkeitsliste im Verbund nennt eine der hier genannten Bibliotheken. Was hier steht, sind Festlegungen — durchgearbeitet, begründet, unerprobt.
Problem 1
Eine Verbindung, die den Netzwechsel überlebt
Wer eine Gegenstelle über ihre Adresse anspricht, verliert sie beim Wechsel von WLAN auf Mobilfunk. Die gewählte Transportgrundlage bindet eine Verbindung an eine Kennung statt an ein Adresspaar — der Teilnehmer bleibt derselbe, nur der Weg ändert sich. Dazu kommt Löcherstanzen durch NAT mit einem Rückfall auf ein Relais, das über den gewöhnlichen Web-Port läuft und damit auch dort durchkommt, wo alles andere gefiltert wird.
Warum diese Bibliothek und nicht die naheliegende Alternative mit eingebautem Zwiebelrouting, ist begründet: Deren damals aktuelle Fassung dokumentierte Nachrichtenverlust und hatte keinen nachweisbaren produktiven Einsatz. Warum der Unterbau des Vorgängersystems nicht fortgeführt wurde, ebenfalls. Und warum die verteilte Suchtabelle gestrichen wurde — mit einer Lücke, die bis heute offen ist: Für die Frage, wer einen bestimmten Inhalt vorrätig hat, steht kein Ersatz fest.
Anonymisierung ist keine Eigenschaft dieses Transports, sondern eine Austauschentscheidung: durch Tor oder durch ein Mixnetz, jeweils mit erheblichem Latenzaufschlag. Dass diese Naht vor dem ersten Release sitzen muss, ist der Grund für die strenge Disziplin an der Schnittstelle: Nachrüsten ist in einem dezentralen System nicht möglich, weil es keinen Moment gibt, in dem alle Knoten gleichzeitig umschalten.
Darüber liegt eine eigene Schicht für Verkehrstarnung — sie macht den Strom gegen Deep Packet Inspection unauffällig, statt ihn nur zu verschlüsseln, mit gleichförmigen Zellen oder Tarnung als gewöhnliche Webverbindung.
Problem 2
Ereignisse, die einen Versionswechsel überstehen
In einem Netz ohne zentrale Instanz lässt sich niemand zwingen, gleichzeitig zu aktualisieren. Also muss ein älterer Knoten ein neueres Ereignis prüfen und speichern können, ohne es zu verstehen. Der unveränderliche Umschlag trennt dafür vier formatstabile Felder von einer frei entwickelbaren Nutzlast. Zwei Ereignistypen muss jede Version beherrschen: die Löschung — sonst ist sie netzweit wirkungslos — und den Schlüsselwechsel.
Die Ordnung ergibt sich kausal aus dem Ereignisgraphen, nicht aus Uhren; ein Knoten mit falscher Uhr kann keine Reihenfolge erzwingen. Gleichzeitig entstandene Änderungen vereinigen verschmelzende Datentypen, für jedes Feld der passende. Repliziert wird feldweise statt objektweise, grosse Inhalte laufen über prüfbares Streaming.
Wie sich das gegen ein etabliertes föderiertes System schlägt — und warum dort die Konfliktlösung ungleich aufwendiger ausfällt —, steht ausführlich im Vergleich mit Matrix. Was zum Wachstum der Verwaltungsdaten solcher Datentypen fehlt, ist ausdrücklich als Lücke benannt.
Problem 3
Wenn niemand da ist, der die Nachricht annimmt
In einem Netz ohne Server gibt es kein Postfach. Wer etwas zustellen will, während der andere aus ist, braucht eine Antwort darauf, wo die Nachricht solange liegt. Beschlossen ist die Ablage am Auftrag: Ein Ergebnis wird nicht an ein Gerät geschickt, sondern als Aktualisierung an den zugehörigen Auftrag gehängt und über dessen stabile Kennung adressiert. Der Empfänger hat ein Abonnement darauf und holt es beim nächsten Verbinden ab — unabhängig von Gerät und Adresse. Die Website-Erweiterung als Zwischenspeicher wurde ausdrücklich verworfen: Ein Prozess, der eine Anfrage lang lebt, hält nichts vor.
Durchgespielt
Ein Ergebnis für jemanden, der offline ist
- Auftrag. A beauftragt B mit einer Berechnung. Übertragen wird nicht der ganze Auftrag, sondern ein daraus abgeleiteter Task mit dem Nötigen — und der Kennung des Ursprungs als Bezug.
- A geht offline. Das Notebook klappt zu. B rechnet weiter.
- B ist fertig. Das Ergebnis wird nicht an A geschickt, sondern als Aktualisierung am Auftrag abgelegt, adressiert über dessen stabile Kennung.
- A kommt zurück — an einem anderen Gerät, unter anderer Adresse. Sein Abonnement auf den Auftrag zeigt die Aktualisierung, er holt das Ergebnis ab.
- Zuordnung. Über Ursprungskennung und Task-Identität landet es beim richtigen Auftrag, ohne dass jemand eine Sitzung offengehalten hätte.
Was hier ungeprüft ist: Der Ablauf setzt voraus, dass sich A und B irgendwann begegnen — direkt oder über einen dritten Knoten. Ob die Nachlieferung auch trägt, wenn sie einander nie gleichzeitig online begegnen, ist in der Architektur ausdrücklich als empirisch zu prüfen markiert, nicht als Annahme. Ebenso offen ist, welcher Baustein das Abonnement konkret trägt.
Für einen Sonderfall gibt es eine ausgearbeitete Antwort: den im Browser laufenden Knoten, dessen Tab einschläft. Für eine native Anwendung auf einem schlafenden Telefon dagegen gibt es nichts — Push-Dienste der Plattformanbieter sind abgelehnt, ein Ersatz existiert nicht. Das ist die schwächste Stelle des Entwurfs und als solche benannt.
Problem 4
Wie man überhaupt hineinkommt
Ein Netz ohne zentrale Anlaufstelle hat ein Henne-Ei-Problem: Der erste Kontakt muss von irgendwoher kommen. Statt einer eleganten Lösung mit einem Angriffspunkt gibt es fünf gleichrangige Wege, keiner davon Pflicht — eine zwischengespeicherte Adresse aus der letzten Interaktion, ein Verweis, den jede Interaktion mitträgt, lokale Erkennung ohne Internet, eine Datei auf beliebigen Websites, verschlüsselte Einträge im Namenssystem, und eine mitgelieferte Startliste als letzter Ausweg.
Warum reiner Rundfunk als Verteilverfahren nicht genügt — und woran der Ansatz des Vorgängersystems auf Mobilgeräten scheiterte —, ist eigens begründet.