Safe Network Entwickler Update ­čçę­čç¬ 7. Juli 2022

Dies ist eine maschinelle ├ťbersetzung. Das Original in Englisch ist hier: Update 7 July, 2022

Gutschrift an Spatium f├╝r die 4 Titelbilder, die Sie in den kommenden Wochen sehen werden :heart_eyes:

Einige vielversprechende Neuigkeiten an der Bug-Jagd-Front, da das Team ein fieses kleines Lebewesen aufgesp├╝rt hat, das w├Ąhrend der Datenreplikation bei der Abwanderung Deadlocks verursachte. F├╝r technisch Interessierte war der fragliche Fehler ein Hinweis auf einen lesegesperrten Knoten, der auch nach dem L├Âschen bestehen blieb, und das Aufsp├╝ren wurde durch die laufende Arbeit zum Entfernen von Multithreading und Vereinfachen des Codes erm├Âglicht. Daher dachten wir, es w├Ąre ein guter Zeitpunkt, die Leute ├╝ber die Arbeit, die wir in dieser und anderer Hinsicht in sn_node machen, auf den neuesten Stand zu bringen. @joshuef ├╝bernimmt diese Woche das Steuer.

Allgemeiner Fortschritt

@yogesh ist damit besch├Ąftigt, die Codebasis umzugestalten, um SledDB loszuwerden. Wie in den vorherigen Updates erw├Ąhnt, waren wir auf dem Weg, SledDB (zum Speichern von Registern) zu ersetzen, da es Probleme mit Schreibbeschr├Ąnkungen gab und auch nicht aktiv gewartet wurde. Daher haben wir in den vergangenen Wochen ein paar Alternativen verglichen, wobei jede ihre Vor- und Nachteile hatte. Als Ergebnis der Analyse entschied sich das Team f├╝r die interne Disk-Storage-Implementierung, die wir bereits zum Speichern von Chunks einsetzen. Dies ist eine Keep-it-simple-Implementierung, die keinen Schnickschnack hat und mit den anderen Alternativen auf Augenh├Âhe arbeitet, w├Ąhrend uns dies auch von einer weiteren externen Abh├Ąngigkeit befreit, die m├Âglicherweise nicht optimal gepflegt wird. Derzeit unterst├╝tzt es nur das Speichern von Chunks und muss daher ├╝berarbeitet werden, um das Speichern von Registern zu unterst├╝tzen, wof├╝r die Arbeit in vollem Gange ist.

@qi_ma hat sich die Churn-Tests angesehen, die fehlgeschlagen und langsam waren, teilweise ÔÇô wie wir glauben ÔÇô wegen des in der Einf├╝hrung (und unten) beschriebenen Fehlers. Es wurden auch falsche Nachrichten an Kunden gesendet, die durchaus Teil desselben Problems sein k├Ânnten.

Ebenfalls in dieser Woche kehrte @Heather_Burns nach der Seuche triumphal ins britische Parlament zur├╝ck, wo sie MaidSafe bei einem Runden Tisch kleiner Technologieunternehmen und Start-ups vertrat, die als Kollateralschaden bei der Entschlossenheit der Regierung, das Internet rund um Facebook zu regulieren, stehen. Heather berichtet, dass die Abgeordneten, mit denen sie sich getroffen hat, einige der wenigen sind, die das tats├Ąchlich ÔÇ×verstehenÔÇť und verhindern wollen, dass dies geschieht. Hoffentlich wurde unsere Botschaft laut und deutlich geh├Ârt. Versehentlich hat sie m├Âglicherweise auch die Regierung zerst├Ârt. Hoppla.

Zustand des Knotens

Viele Leute fragen sich vielleicht, wie der Zustand des Knotens jetzt ist und warum wir bestimmte Aufgaben ├╝bernommen haben.

Hier ist ein kleiner ├ťberblick ├╝ber den Zustand der Knoten:

Weniger Sperren

In den letzten Wochen haben wir den Knoten auf ein Single-Threaded-Setup umgestellt. Dies hatte angeblich keine gro├čen Auswirkungen auf die Leistung (obwohl es die Dinge ein wenig verbessert hat), aber das Ziel hier war die Vereinfachung der Codebasis. Mit nur einem Thread, um den wir uns k├╝mmern m├╝ssen (standardm├Ą├čig ÔÇŽ k├Ânnen wir bei Bedarf immer noch andere erstellen), m├╝ssen wir nicht so viele Checks und Balances im gesamten Code haben, damit er gleichzeitig arbeiten kann.

Das deutlichste Beispiel daf├╝r ist die M├Âglichkeit, RwLocks (Lese-Schreib-Sperren) aus der Codebasis zu entfernen. Diese winzigen Strukturen erm├Âglichen es dem Code, zu warten, bis ein bestimmtes Datenelement in einem anderen Thread nicht ge├Ąndert wird, bevor wir es bearbeiten. Sauber!. Ja. Aber auch gef├Ąhrlich. Viele der j├╝ngsten Fehler und Probleme, die wir in sn_node sortiert haben, sind auf diese endlosen Wartezeiten zur├╝ckzuf├╝hren (eine Situation, die wir als Deadlock bezeichnen).

Hier gl├Ąnzt der Wechsel zu Single-Threaded sn_node wirklich, da wir die ├╝berwiegende Mehrheit davon aus der Codebasis entfernen k├Ânnen und damit eine ganze Klasse von Fehlern l├Âschen (und es ist auch sehr schmerzhaft, Fehler zu debuggen!). Der Code ist also nicht nur sauberer, klarer und vern├╝nftiger, sondern sollte auch beim Booten weniger fehleranf├Ąllig sein!

Wir haben das jetzt zu etwa 80 % geschafft. Nachdem viele Sperren ├╝ber internen Knoten-Strukturen entfernt und durch eine Sperre h├Âherer Ebene ersetzt wurden, ist es viel einfacher, dar├╝ber nachzudenken (obwohl der ├ťbergang einen weiteren Deadlock aufgedeckt hat!). Ein gutes Beispiel f├╝r die Verbesserungen der Einfachheit, die sich in Geschwindigkeit verwandeln, ist in einigen unserer https://maidsafe.github.io/safe_network/dev/bench/ zu sehen.

Das ist ein gro├čer Gewinn.

Testnetze

Ein weiterer Bereich, in dem wir an Verbesserungen gearbeitet haben und dies auch weiterhin tun werden, sind Testnetze und Debugging. Einige Testnet-Fehler sind das Ergebnis einer ausgefallenen Infrastruktur, sagen wir zum Beispiel, wir haben ein DigitalOcean-Droplet gestartet, aber der Knoten hat dort aus irgendeinem Grund nicht richtig gestartet. Die jüngsten Änderungen haben Knotenneustarts stabiler gemacht und Hintergrundschleifencode bereinigt, was in Situationen wie dieser hilfreich sein sollte.

Wir versuchen auch, die Logging-Situation zu verbessern, mit einigen klareren Cmd-Logs, die getrennt von den ausf├╝hrlicheren Run-Logs ausgegeben werden. Diese sollten f├╝r Leute einfacher zu analysieren sein, und wir werden sie hoffentlich in die ElasticSearch-Instanz einbinden k├Ânnen, die wir f├╝r interne Testnetze haben.

Mitgliedschaft

Die Mitgliedschaft verbessert sich weiter, obwohl sie mit der Single aufgehalten wurdeGewindeschalter. Wir versuchen, die L├╝cke zwischen dem, was Knoten verstehen und wor├╝ber sie abstimmen, und dem, was innerhalb eines ÔÇ×SectionAuthorityProviderÔÇť (SAP) geteilt wird, zu schlie├čen. Dies sollte auch die Stabilit├Ąt verbessern.

Funktionsst├Ârung

Eine weitere Klasse von Fehlern, die wir jetzt angehen, ist eine eher ÔÇ×MetaÔÇť-Klasse von Fehlern ÔÇô Knoten, die andere Knoten als dysfunktional (und damit offline) bewerten. Dies gut zu machen, ist schwierig (wann ist ein Knoten dysfunktional oder hat er eine vor├╝bergehende schlechte Zeit?). Dieser Schmerz ist bei der kontinuierlichen Integration (CI) akut zu sp├╝ren, wo die Maschinen weniger leistungsstark sind, und so k├Ânnen wir manchmal sehen, dass Nodes offline abgestimmt werden, was einen Testzyklus unterbrechen kann ÔÇŽ

Zu diesem Zweck haben wir k├╝rzlich die Testsuiten in sn_dysfunction erweitert und versuchen, diese weiter zu erweitern und zu verbessern, um zu reproduzierbaren Situationen zu gelangen, in denen wir wissen k├Ânnen, dass Offline-Abstimmungen aufgrund fehlerhafter Knoten auftreten.

Arbeitsspeicher und CPU

Mit den Single-Thread-├änderungen, der j├╝ngsten ├ťberarbeitung der Datenneuver├Âffentlichung und mit einigen Vereinfachungen in der Node-Codebasis l├Ąuft sn_node im Allgemeinen wirklich gut, mit einer durchschnittlichen Speichernutzung von ~130 MB f├╝r einen ├älteren (auf einem Mac; lokales Testnet), ~70 MB f├╝r Erwachsene.

Im Moment sind alle gro├čen Spitzen f├╝r uns klare rote Flaggen, und das ist ein wirklich guter Ort, um zu sein, da es das Auffinden der Ursache solcher Probleme viel einfacher macht.

Daten

Die k├╝rzliche Entdeckung von ÔÇ×SchlittenÔÇť-Bugs hat das Gef├╝hl der Stabilit├Ąt der Daten ged├Ąmpft, aber wir arbeiten daran, das gerade jetzt zu entfernen. Diese ├änderung sollte hoffentlich die Datenspeicherung in sn_node vereinfachen und vereinheitlichen, sodass das Verhalten ├╝ber alle Datentypen hinweg konsistenter sein sollte.

Und SoooooooÔÇŽ

Auch wenn es sich nicht immer so anf├╝hlt, als w├╝rden die Dinge f├╝r die Community vorankommen, da nicht jeder sieht, woran t├Ąglich gearbeitet und was verbessert wird, gehen die Dinge definitiv in die richtige Richtung. Jedes Testnetz, das wir hochfahren, ist (im Allgemeinen) stabiler, aber wenn es aus irgendeinem Grund einen Fehler gibt, wird es mit all diesen j├╝ngsten ├änderungen und mit den Statistiken des ElasticSearch-Servers, die Tr├Âpfchen verfolgen, viel einfacher zu erkennen, wo Probleme liegen, und wird hoffentlich auch nur einfacher!


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!