Dezentrale P2P-Netzwerke einfach erklärt.

Ein dezentrales Peer-to-Peer-Netzwerk verbindet Geräte möglichst direkt miteinander. Jeder Teilnehmer – ein Peer – kann Verbindungen aufbauen, Informationen empfangen und selbst an andere weitergeben. Eine dauerhaft zentrale Vermittlungsstelle ist für die eigentliche Kommunikation nicht erforderlich.

Dezentral bedeutet nicht, dass es gar keine bekannten Einstiegspunkte geben darf. Entscheidend ist, dass das Netzwerk nach dem Einstieg nicht von einem einzelnen Server abhängt.

Was ist ein Peer-to-Peer-Netzwerk?

In einem klassischen Client-Server-Modell sprechen viele Clients mit einem zentralen Server. In einem P2P-Netzwerk können die Teilnehmer dagegen direkt miteinander kommunizieren. Ein Gerät kann gleichzeitig Daten annehmen und eigene Anfragen senden.

Die Architektur eignet sich besonders, wenn Geräte auch bei wechselnden Netzwegen erreichbar bleiben sollen oder Informationen ohne unnötige Zwischenstation ausgetauscht werden können.

Wie finden sich Geräte im Netzwerk?

Das Finden anderer Teilnehmer wird Discovery genannt. In der Praxis ergänzen sich mehrere Methoden:

1. Einige bekannte Startadressen helfen beim ersten Kontakt.
2. Im lokalen Netz können Geräte kurze UDP-Hinweise austauschen.
3. Bereits verbundene Peers können weitere erreichbare Teilnehmer nennen.
4. Historische Verbindungen helfen nach einem Neustart beim Wiederverbinden.

Eine UDP-Nachricht muss dabei nicht alle Informationen des Netzwerks enthalten. Wenige aktuelle Verbindungstipps genügen, damit ein Gerät erste direkte Pfade prüft. Danach kann das P2P-Protokoll den genaueren Discovery-Austausch übernehmen.

Warum NAT den Direktkontakt erschwert

Viele Router verwenden Network Address Translation, kurz NAT. Das Gerät besitzt intern eine private Adresse, während nach außen eine gemeinsame öffentliche Adresse sichtbar ist. Eingehende Pakete können deshalb nicht automatisch dem richtigen Gerät zugeordnet werden.

Mögliche Hilfen sind eine explizite Portweiterleitung, UPnP, ICE mit STUN-Kandidaten oder als Rückfall ein gerouteter Pfad über einen bereits erreichbaren Peer. Kein einzelnes Verfahren funktioniert in jedem Netzwerk. Robuste Systeme halten deshalb mehrere Möglichkeiten bereit.

Latenz mit der Round-Trip-Time messen

Die Round-Trip-Time, kurz RTT, ist die Zeit vom Absenden einer kleinen Anfrage bis zum Empfang der unmittelbaren Antwort. Mit Absendezeit $t_{s}$ und Antwortzeit $t_{a}$ gilt:

$$RTT = t_{a} - t_{s}$$

Soll daraus die einfache Laufzeit für nur eine Richtung geschätzt werden, verwendet man bei ungefähr symmetrischem Pfad:

$$t_{einfach} \approx \frac{RTT}{2}$$

Das ist nur eine Näherung: Hin- und Rückweg können über unterschiedliche Router laufen. Für die Auswahl eines reaktionsschnellen Pfads ist die gemessene RTT trotzdem ein nützlicher Vergleichswert.

Ein kleines Ping-Beispiel in JavaScript

Das folgende Beispiel serialisiert Messungen pro Peer. Mehrere gleichzeitige Aufrufe dürfen auf dieselbe nächste Messung warten, aber es läuft nie mehr als ein Ping zur selben Zeit:

class PeerPingQueue {
    #running = null;

    measure(sendPing) {
        if (!this.#running) this.#running = this.#measureOnce(sendPing);
        return this.#running;
    }

    async #measureOnce(sendPing) {
        const started = performance.now();
        try {
            await sendPing(new Uint8Array([0]));
            return performance.now() - started;
        } finally {
            this.#running = null;
        }
    }
}

Die Nutzlast besteht nur aus einem Byte. Wichtiger als ihr Inhalt ist, dass die Gegenseite unmittelbar antwortet und der Messstream danach sauber beendet wird.

Warum mehrere Netzwerkpfade sinnvoll sind

Ein Laptop kann gleichzeitig über WLAN, Ethernet, VPN und IPv6 erreichbar sein. Diese Pfade haben unterschiedliche Eigenschaften. Der schnellste Pfad ist nicht immer der stabilste, und ein heute erreichbarer Port kann nach einem Netzwechsel verschwinden.

Ein Multipath-Ansatz darf deshalb mehrere Verbindungen zum gleichen Gerät bewusst bestehen lassen. Die Anwendung kann je nach Aufgabe einen passenden Pfad verwenden, ohne funktionierende langsamere Verbindungen vorschnell zu schließen.

• Direkter Pfad: meist geringe Latenz und wenig Zusatzlast.
• Alternativer Interface-Pfad: bleibt bei einem einzelnen Netzausfall verfügbar.
• Gerouteter Pfad: hilft, wenn direkte NAT-Verbindungen nicht möglich sind.

Checkliste für robuste P2P-Verbindungen

• Mehrere Discovery-Quellen kombinieren
• Doppelte laufende Verbindungsversuche erkennen
• Verbindungsverläufe kompakt und zeitlich sortiert speichern
• Kleine Ping-Streams unabhängig von Anwendungsdaten behandeln
• Mehrere echte Pfade zum gleichen Gerät zulassen
• Fehler einzelner Verbindungstipps als normalen Betriebsfall behandeln

Fazit

Ein dezentrales P2P-Netzwerk wird nicht durch einen einzelnen cleveren Trick stabil. Zuverlässigkeit entsteht aus mehreren kleinen Mechanismen: bekannte Einstiegsadressen, lokale Discovery, Verbindungstipps, NAT-Hilfen, gemessene Latenz und alternative Pfade.

Wer diese Bausteine getrennt behandelt, kann neue Geräte schnell ansprechen und zugleich mit schwierigen Hotel-, Mobilfunk- oder Firmennetzen umgehen. Genau diese Trennung macht die Architektur später erweiterbar.