Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 20 October, 2022
Diese Woche bringt @joshuef einige Neuigkeiten über den Fortschritt bei der Kommunikation (Kommunikation zwischen Knoten). Wie geduldige Leser wissen werden, ist dies schon seit einiger Zeit ein Hindernis, aber wir sehen definitiv ein Licht am Ende dieses speziellen Tunnels.
Allgemeines Update
Eine kurze Zusammenfassung dessen, was das Team vorhat.
@anselme hat einen Rogue Key Attack untersucht, der einige andere Implementierungen von BLS betrifft und hat festgestellt, dass unsere auch verwundbar ist. Er hat einen Fix für die blsttc-Kiste eingereicht. Er untersucht auch einen Fehler, der Clients daran hindert, dem Netzwerk in Tests beizutreten.
@chriso arbeitet an Chunk- und Registersignaturen, bei denen Daten (oder ihr Xorname im Fall von Chunk) von den Ältesten signiert werden, um sie im Netzwerk gültig zu machen.
In diesem Zusammenhang nimmt @bochaco Änderungen an der Client-API in Bezug auf Befehle und Chunks vor und debuggt damit verbundene Fehler in CI.
Mostafa ist mit Testfällen für unseren Konsensmechanismus beschäftigt, und @bzee stochert weiterhin bei qp2p herum, wo wir glauben, dass es einen tiefsitzenden Fehler gibt, der die Konnektivität beeinträchtigt.
Kommunikationsfortschritt
Eine Sache, an der wir arbeiten, ist also, unseren Code zur Reduzierung der Verbindung zu entfernen und uns nur auf den zugrunde liegenden „Quinn“-Code zu verlassen, um Verbindungen nach einem kleineren Timeout zu beenden. Auf diese Weise gehen wir weniger davon aus und überlegen nicht mehr, was wann geöffnet ist.
In unseren Tests hat sich dies positiv auf die Client-Tests ausgewirkt und die Wahrscheinlichkeit beseitigt, dass unsere Verbindungen auf halbem Weg geschlossen werden.
Bi-Streams
Parallel dazu gehen wir auch dazu über, die Kommunikation zwischen Clients und Knoten mithilfe von bidirektionalen Streams zu optimieren. Das bedeutet, dass wir die Komplexität der Zustandsverwaltung beseitigen und nur auf eine Antwort von Ältesten warten. Früher (vor langer Zeit im Node-Land) hatten wir diese Art von Streams verwendet, um mit Kunden zu kommunizieren, aber die Verwaltung des Response-Streams war ein komplizierter Albtraum. Aber jetzt ist der Knoten viel einfacher (aufgrund der Arbeit, die in den letzten anderthalb Jahren oder so geleistet wurde), und dies ist viel einfacher zu handhaben.
Reduzierte Wiederholungen
Wir haben auch versucht, alles zu entfernen, was diese Probleme verschleiert hat (z. B. unsere oben erwähnten Kommunikationsabstraktionen) und auch Wiederholungsversuche auf Clientebene. Wir haben jetzt ACK (Bestätigungs-) Nachrichten (sie wurden vor ein paar Monaten eingeführt) an den Client. Diese helfen uns zu sagen, wann ein Befehl von Ältesten gesehen wurde. Aber wir haben immer noch nur abgefragt, bis ein Chunk zurückgegeben wurde. @bochaco hat versucht, hier strenger zu sein… Wiederholungsversuche nicht zuzulassen und nur zu sagen: „Wir haben das ‚ACK‘ gesehen… also warum sehen wir beim ersten Mal keinen Erfolg?“. Dies hat einige Fehler beim Lesen/Schreiben von Dateien aufgedeckt. (Es sieht so aus, als ob das Deserialisieren der Speicherbefehle länger dauern kann als Abfragen … also verarbeiten wir sie zuerst, selbst wenn sie nachher gesendet werden).
Reduzierte Knotenverarbeitungslasten
Um die Handhabung von Node-Befehlen besser zu regulieren, haben wir zuvor Code hinzugefügt, der eingehende Nachrichten hätte organisieren und zur Verarbeitung anordnen sollen. Wir haben tatsächlich gesehen, dass dies überhaupt nicht die Wirkung hatte, nach der wir gesucht hatten (tatsächlich löste es nur aus, dass alle Nachrichten unabhängig von ihrer Priorität nacheinander verarbeitet wurden).
Das Entfernen dieses Codes hat eine Menge Knotenvereinfachung ermöglicht. Am wichtigsten ist, dass wir in der Lage waren, die Verarbeitung von Node-Prozessen sperrungsfrei aus dem Thread zu verschieben (nachdem unser Single-Thread-Push die überwiegende Mehrheit des Sperrcodes entfernt hatte).
Einfluss
Früher konnten wir den Eingang von Nachrichten verfolgen, die zur Verarbeitung in die Warteschlange gestellt, bearbeitet und dann zum Senden in die Warteschlange gestellt wurden. Dieser Vorgang unter Last könnte erhebliche Zeit in Anspruch nehmen. Manchmal war es relativ schnell, unter einer Sekunde. Manchmal kann es bei all der Befehlsverarbeitung und Nachrichtenübermittlung 20 Sekunden dauern.
Jetzt sehen wir, dass Nachrichten routinemäßig an Knoten eingehen, sofort verarbeitet werden und Nachrichten in weniger als einer Millisekunde ausgehen.
Das ist viel näher an dem, was wir vorher von unserer Kommunikation erwartet hätten, und fühlt sich sehr nach der richtigen Richtung an.
Nächste Schritte
Wir möchten die bidirektionalen Streams vollständig in die Clients integrieren und dort einen Großteil der Zustandsverwaltung entfernen. Und wir werden auch darauf abzielen, denselben Fluss in der Kommunikation zwischen Älteren und Erwachsenen zu haben, wo Antworten erforderlich sind, was die Dinge auch dort weiter vereinfachen sollte. Es sollte tatsächlich ermöglichen, dass unsere „ACK“-Nachrichten auch die Speicherung von Erwachsenen widerspiegeln, anstatt nur Älteste zu sagen, dass sie eine Nachricht gesehen haben, was auch bei fehlgeschlagenen Überprüfungen helfen sollte.
Nützliche Links
Fühlen Sie sich frei, unten mit Links zu Übersetzungen dieses Entwicklungsupdates zu antworten, und die Moderatoren werden sie hier hinzufügen.
Als Open Source-Projekt sind wir immer auf der Suche nach Feedback, Kommentaren und Community-Beiträgen. Seien Sie also nicht schüchtern, machen Sie mit und lassen Sie uns gemeinsam das sichere Netzwerk erstellen!