@Dusk Viele sagen, dass P2P-Netze von selbst schneller werden, sobald nur genug Knoten vorhanden sind. Aber dieser Aussage habe ich lange nicht so recht geglaubt, bis ich in den „Core Components“ des $DUSK gelesen habe und mir aufgefallen ist, dass Kadcast nicht auf zufälligem Gossip basiert, sondern auf einem strukturierten Overlay. Das Ziel ist, die Bandbreite zu reduzieren und die Latenz besser vorhersehbar zu machen. Diese Entscheidung hat meine Einschätzung verändert: Die Effizienz eines Netzwerks hängt nicht nur von der Anzahl der Knoten ab, sondern auch davon, über welche Verbindungsbeziehungen eine Nachricht ihren Weg zum Ziel findet.
Für Betreiber von Knoten ist das keine abstrakte Idee. Sobald die Routen stärker strukturiert sind, werden die Knoten noch mehr von der Qualität des Nachbarerkennens und der Netzwerk-Konnektivität abhängig. Und wenn dann die Betriebsumgebung die UDP-Kanäle oder Kadcast-Adressen blockiert, wird die theoretisch vorhersehbare Latenz nicht automatisch zu einer tatsächlich nutzbaren Netzwerkleistung. Was Betreiber dann möglicherweise sehen, sind Nachrichten, die nicht ankommen, oder dass Blöcke zurückfallen – und sie müssen selbst beurteilen, ob es ein Problem der Version ist, der Netzwerkstrategie oder ob die Konfiguration schlicht nicht stimmt.
Konkrete Druckszenarien sind ebenfalls ein Thema. Wenn Marktaktionen zunehmen, möchte die Anwendung, dass Transaktionen schneller bestätigt werden. Doch ein entscheidender Knoten wird von einer Firewall am Kommunikationsweg gehindert. Dieses System ist nicht so einfach wie „je mehr Knoten, desto sicherer“. Die Erreichbarkeit der Knoten kann ebenso darüber entscheiden, ob Nachrichten sich wie vorgesehen verbreiten – und die Aufwandskosten für die Fehlersuche landen am Ende bei den Personen, die die Knoten betreiben. Deshalb schaue ich mir die Netzwerkleistung von DUSK heute nicht mehr nur danach an, wie lange Blöcke brauchen oder wie viele Knoten vorhanden sind. Stattdessen möchte ich die Nachbarschaftsbeziehungen von Kadcast abgleichen, die Kommunikationsports prüfen und prüfen, ob es intuitive Monitoring-Signale gibt, die Aufschluss darüber geben, ob zurückliegende Knoten betroffen sind. @Dusk hat sich für strukturiertes Routing entschieden – und ob es die Vorhersagbarkeit wirklich in die Hände der Betreiber überführt, ist genau der Teil, den das Netzwerk #dusk beweisen muss.
Für Betreiber von Knoten ist das keine abstrakte Idee. Sobald die Routen stärker strukturiert sind, werden die Knoten noch mehr von der Qualität des Nachbarerkennens und der Netzwerk-Konnektivität abhängig. Und wenn dann die Betriebsumgebung die UDP-Kanäle oder Kadcast-Adressen blockiert, wird die theoretisch vorhersehbare Latenz nicht automatisch zu einer tatsächlich nutzbaren Netzwerkleistung. Was Betreiber dann möglicherweise sehen, sind Nachrichten, die nicht ankommen, oder dass Blöcke zurückfallen – und sie müssen selbst beurteilen, ob es ein Problem der Version ist, der Netzwerkstrategie oder ob die Konfiguration schlicht nicht stimmt.
Konkrete Druckszenarien sind ebenfalls ein Thema. Wenn Marktaktionen zunehmen, möchte die Anwendung, dass Transaktionen schneller bestätigt werden. Doch ein entscheidender Knoten wird von einer Firewall am Kommunikationsweg gehindert. Dieses System ist nicht so einfach wie „je mehr Knoten, desto sicherer“. Die Erreichbarkeit der Knoten kann ebenso darüber entscheiden, ob Nachrichten sich wie vorgesehen verbreiten – und die Aufwandskosten für die Fehlersuche landen am Ende bei den Personen, die die Knoten betreiben. Deshalb schaue ich mir die Netzwerkleistung von DUSK heute nicht mehr nur danach an, wie lange Blöcke brauchen oder wie viele Knoten vorhanden sind. Stattdessen möchte ich die Nachbarschaftsbeziehungen von Kadcast abgleichen, die Kommunikationsports prüfen und prüfen, ob es intuitive Monitoring-Signale gibt, die Aufschluss darüber geben, ob zurückliegende Knoten betroffen sind. @Dusk hat sich für strukturiertes Routing entschieden – und ob es die Vorhersagbarkeit wirklich in die Hände der Betreiber überführt, ist genau der Teil, den das Netzwerk #dusk beweisen muss.
