Peer-to-Peer beschreibt, wie Anwendungspakete reisen, und nichts weiter. Die Peers mussten einander weiterhin finden, nachweisen, wer sie sind, und manchmal auf ein Relay zurückgreifen, wenn sich kein direkter Pfad aufbauen ließ. Das sind drei getrennte Dienste, und eine Bereitstellung kann für Daten Peer-to-Peer sein, während sie für alles andere vollständig zentralisiert ist. Designs zu vergleichen heißt, diese Aufgaben zu vergleichen, nicht den Pfeil im Diagramm.

Ein Diagramm ohne zentralen Weiterleitungspfeil kann eine Registrierungsstelle, einen Discovery-Dienst und ein Relay verbergen, die alle operativ notwendig sind.

Direkter Pfad, gemeinsame Steuerungsebene

Zwei Maschinen, die Pakete direkt austauschen, können weiterhin von einer gemeinsamen Stelle abhängen, die ihre Zertifikate ausgestellt hat, und von einem Dienst, der jeder sagte, wo die andere zu finden ist. Keine der beiden Rollen leitet Anwendungsverkehr weiter, deshalb lässt die Topologiezeichnung sie weg. Wenn diese Stelle oder dieser Dienst ausfällt, können bestehende Sitzungen weiterlaufen, während ein neuer Peer nicht beitreten kann. Der Unterschied zwischen dem Beginn einer Sitzung und deren Fortsetzung ist die erste Frage, die man an jedes Design stellen sollte.

Zeichnen Sie jede Aufgabe getrennt, auch wenn ein einziger Host alle erledigt. Sonst zeigt die Zeichnung eine dezentrale Datenebene und verbirgt die betriebliche Realität, dass jeder neue Peer dieselben zwei Dienste braucht.

Discovery, Vertrauen und Relay sind drei Aufgaben

Nebulas Design ist ein nützliches Beispiel, weil seine Dokumentation diese Dienste auseinanderhält. Hosts tragen Zertifikate für die Identität, Leuchttürme beantworten die Frage nach dem Wo und helfen bei der NAT-Durchquerung, und Relays leiten Verkehr weiter, wenn sich kein direkter Pfad aufbauen lässt. Die Relay-Rolle ist bewusst von der Leuchtturmrolle getrennt, ein erreichbarer Leuchtturm verspricht also nicht, dass ein bestimmtes Paar miteinander sprechen kann. Andere Produkte ziehen die Grenzen anderswo, deshalb ist dies ein Beispiel und keine Vorlage.

Halten Sie für eine geplante Bereitstellung den unterstützten Rückfallweg für ein Paar fest, das sich nicht direkt verbinden kann. Ein fehlgeschlagener Hole-Punch ist ein Datenpunkt über ein Netz, kein Beweis, dass zwei NAT-Peers sich niemals finden können; die gegenteilige Behauptung, direkte Konnektivität funktioniere unter beliebiger Richtlinie, ist ebenso unbelegt.

Woran die einzelnen Abhängigkeiten scheitern

Prüfen Sie vier Fälle getrennt, während die getestete Abhängigkeit nicht verfügbar ist: bestehender Peer-Verkehr, eine ganz neue Peer-Verbindung, ein Peer, dessen Endpunkt sich geändert hat, und ein Zugang, der gerade widerrufen wurde. Jeder stützt sich auf andere Dienste und scheitert anders. Bestehende Sitzungen können einen Discovery-Ausfall überstehen, während ein widerrufener Schlüssel weiterhin abgelehnt wird, und ein neuer Peer kann aus Gründen scheitern, die nichts mit Weiterleitung zu tun haben. Testen Sie sie einzeln, statt aus einem Fall zu schließen.

Eine Verbindung, die einen einzelnen Ausfall übersteht, belegt keine unbefristete Unabhängigkeit. Sie belegt, dass der von Ihnen verursachte Ausfall nicht derjenige war, der diesen Pfad bricht, was immer noch nützlich ist, sofern Sie festgehalten haben, was Sie verursacht haben.

Fragen Sie, welchen Ausfall Sie überstehen

Anforderungen, die ähnlich klingen, führen zu unterschiedlichen Designs. Einen einzelnen Weiterleitungsengpass zu vermeiden ist nicht dasselbe wie eine vom Anbieter gehostete Steuerungsebene zu vermeiden, und beides deckt sich nicht damit, weiterzuarbeiten, während ein Koordinator ausfällt. Benennen Sie, welche dieser drei die Bereitstellung erfüllen muss, und prüfen Sie dann die Zuordnung. Ein Design, das das erste erfüllt und am zweiten scheitert, ist verbreitet und nicht unehrlich, solange es niemand vollständig dezentral nennt.

Halten Sie fest, wer Discovery, Vertrauen und Relays betreibt und wie jedes davon ersetzt wird. Dieser Eintrag befähigt die nächste Person, eine echte Frage zu beantworten: Welche Ausfälle übersteht dieses Netz, und wer pflegt den Zustand, der weiterhin geteilt wird?

Das Wort dezentral verdient seinen Platz, wenn es diese Ausfälle benennt. Ohne diese Liste beschreibt es ein Diagramm statt eines Systems.

Ähnliche Artikel