Safe Network Entwickler Update ­čçę­čç¬ 14. Januar 2021

Dies ist eine maschinelle ├ťbersetzung. Das Original in Englisch ist hier: Safe Network Dev Update - January 14, 2021

Zusammenfassung

Hier sind einige der wichtigsten Dinge, die seit dem letzten Entwickler-Update hervorgehoben werden sollten :

  • Wir verschieben weiterhin alle Client-Nachrichtendefinitionen und die Serialisierungslogik in die neue Kiste sn_messaging.
  • Die Arbeiten zur Entfernung der Stream-Verwaltung in Knoten, wie im Update der letzten Woche erw├Ąhnt, wurden abgeschlossen und zusammengef├╝hrt
  • Wir haben die Probleme durchgearbeitet und behoben, die durch unser neues Routing-Stresstest-Tool hervorgehoben wurden.
  • Ein gro├čes Dankesch├Ân an einige Community-Mitglieder f├╝r PRs in dieser Woche - @mav und @tfa haben sich beide mit mehreren PRs in verschiedenen Repos zusammengetan, um unsere Arbeit zu unterst├╝tzen und zu verbessern. Immer wieder inspirierend zu sehen :heartbeat:
  • Wir arbeiten noch daran, eine endg├╝ltige Fehlerbehebung zu testen, von der wir hoffen, dass wir die n├Ąchste Iteration des Testnetzes ver├Âffentlichen k├Ânnen.

Safe Client, Nodes und qp2p

Projektplan f├╝r sichere Netzwerk├╝bertragungen
Safe Client-Projektplan
Projektplan f├╝r sichere Netzwerkknoten

In der letzten Woche haben wir einige Zeit damit verbracht, die qp2p-Beispiele zu verbessern, damit sie die Funktionen der Bibliothek separat besser demonstrieren. Gleichzeitig haben wir das Echo-Service-Beispiel erweitert, um die manuelle Portweiterleitung zu unterst├╝tzen. W├Ąhrend der Implementierung haben wir eine kleine Erweiterung identifiziert und implementiert, die den vom Benutzer als Eingabe bereitgestellten Endpunkt ├╝berpr├╝ft. Auf diese Weise k├Ânnen wir einen Fehler viel fr├╝her zur├╝ckgeben, anstatt darauf zu warten, dass das Netzwerk den Knoten identifiziert und als nicht erreichbar meldet.

Wir haben auch alle Client-Nachrichtendefinitionen und die Serialisierungslogik in die neue Kiste sn_messaging verschoben. Wir haben das Protokoll verbessert und verwenden jetzt Msgpack zum Serialisieren aller Nachrichten, die von Clients an Knoten gesendet werden. Dies ist jedoch eine fortlaufende Aufgabe, da einige innere Teile der Client-Nachrichten immer noch die Bincode-Serialisierung verwenden und wir diese daher migrieren m├╝ssen, um auch Msgpack zu verwenden.

Die Arbeit mit den verteilten Schauspieler├╝berg├Ąngen beim ├ältestenwechsel wurde fortgesetzt, d. H. Die Unterzeichnung der Abschnittsmittel f├╝r die neuen ├ältestenkonstellationen. Ein kleiner Fehler, der den ├ťbergang behindert (aufgrund einer fehlgeschlagenen Sig-Validierung), hat einige Zeit in Anspruch genommen, wurde aber gerade erst gefunden. Die n├Ąchsten Schritte im ├ťbergang sollen nun getestet werden.

Zuletzt haben wir mit der Aktualisierung von Client / Knoten fortgefahren, um Client-Herausforderungen zu beseitigen und das * ordnungsgem├Ą├če * Onboarding von Clients wieder zu aktivieren, nachdem Stream`-Management in Knoten entfernt wurde, wie im Update der letzten Woche erw├Ąhnt, abgeschlossen und zusammengef├╝hrt. Dies hat wiederum einige potenzielle Probleme beim Empfang oder Parsen von Client-Nachrichten aufgedeckt, sodass wir uns dort vertiefen.

API und CLI

Diese Woche konnten wir erfolgreich ÔÇ×muslÔÇť Builds f├╝r CLI und authd in unserem CI generieren. Daher ist alles eingerichtet und bereit f├╝r unsere n├Ąchste Version. Dies bedeutet, dass sowohl die CLI- als auch die authd-Anwendung mit jeder sofort einsatzbereiten Linux-Plattform aus dem Release-Paket kompatibel sein sollten. Wir ben├Âtigen die Community, um zu ├╝berpr├╝fen, ob dies tats├Ąchlich der Fall ist, indem wir sie auf so vielen verschiedenen Linux-Plattformen ausprobieren wie m├Âglich. Wir werden die neuen Versionen zu gegebener Zeit ver├Âffentlichen.

BRB - Byzantinische zuverl├Ąssige Sendung

Diese Woche wurde weiter daran gearbeitet, die BRB -Kisten weiter zu polieren. Die DataType-API wurde ge├Ąndert, damit Details zu Validierungsfehlern an den Aufrufer zur├╝ckgegeben werden k├Ânnen. In diesem Sinne wurde die Rost-Crdt-Kiste so erweitert, dass jeder CRDT-Typ, den wir jetzt verwenden, ├╝ber eine validate () -Methode verf├╝gt, die vor dem Anwenden einer Operation aufgerufen werden kann. F├╝r jede BRB-Kiste wurden Pull-Anforderungen f├╝r CI / CD (Continuous Integration und Continuous Deployment & Delivery) gestellt. Wir haben diese Woche noch ein paar ├änderungen vor uns, danach planen wir die erste Ver├Âffentlichung auf crates.io.

Routing

Projektplan

Letzte Woche haben wir erw├Ąhnt, wie das Stresstest-Tool einige versteckte Probleme beim Routing aufgedeckt hat. Diese Woche haben wir uns vorgenommen, sie aufzusp├╝ren und zu reparieren. Ein Problem war, dass nicht ├Ąltere Mitglieder eines Abschnitts nicht wussten, dass eine Trennung aufgrund eines Fehlers bei der Erstellung der ÔÇ×SynchronisierungsÔÇť -Nachrichten stattgefunden hat. Dies wurde behoben und zusammengef├╝hrt. Derzeit wird eine weitere PR ausgef├╝hrt, mit der einige weitere dieser Probleme behoben werden. Die verbleibenden Probleme danach h├Ąngen wahrscheinlich alle mit der Art und Weise zusammen, wie wir mit ├änderungen der Abschnittsmitgliedschaft umgehen. Wir hoffen, diese Probleme durch die Integration des neuen BRB-Mitgliedschaftsalgorithmus zu l├Âsen, der ebenfalls letzte Woche erw├Ąhnt wurde. Diese Arbeit wird m├Âglicherweise sehr bald beginnenschon n├Ąchste woche wenn alles gut geht.

├ähnlich wie bei unserem j├╝ngsten Schritt, alle Client-Nachrichtendefinitionen und die Serialisierungslogik in einer separaten Kiste (sn_messaging) zu speichern, haben wir begonnen, dasselbe mit sn_routing-Nachrichten zu tun. Ziel ist es, die gesamte Nachrichtendefinitions- und Serialisierungslogik von der Kernroutinglogik trennen zu k├Ânnen. Dies sollte uns eine klare Definition der Schnittstelle erm├Âglichen, die von Routing-Diensten bereitgestellt wird, und daher, wie jede Implementierung (in jeder Programmiersprache) mit unserer vorhandenen sn_routing-Implementierung kompatibel gemacht werden kann. Wir befinden uns in einem sehr fr├╝hen Stadium dieses Prozesses, wollten aber hier unser Ziel teilen.

N├╝tzliche Links


F├╝hlen Sie sich frei, unten mit Links zu ├ťbersetzungen dieses Entwickler-Updates 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!