Am Rande des IT-Kosmos kann man abstürzen. Grenzen von P2P

Unsere schöne neue Welt der digitalen Identitäten kann am „Edge“ umgesetzt werden. Auch im Projekt kamen wir zu diesem Ergebnis und machten uns an die ersten prototypischen Implementierungen, die so auch später in einem Reallabor eingesetzt werden sollten. Doch plötzlich funktionierte nichts mehr. Timeout! Alarm! Misst!

Selbst wenn wir von unserem Gesamtvorhaben nur den kleinsten Teil (Ablesen des Zählerstandes zum Beginn eines Ladevorgangs) testeten, kam es zu Problemen. Die Unit-Tests, die wir vor allem anderen geschrieben hatten, versagten ihre Dienste und selbst der sonst immer hilfreiche Reboot von allen Systemen brachte keine Lösung. Wir setzten noch einmal bei „0“ auf und schufen eine neue Alice und einen neuen Stromzähler, doch ungefährtnach der selben Umfang und Dauer von Tests kamen wir wieder auf einen Zustand, bei dem scheinbar nichts mehr funktionierte und der Code an einer Stelle hängen geblieben ist für eine Ewigkeit: Abrufen des Datensatzes zur Weiterverwendung an Bob. Einige console.logs zeigten, dass dies hunderte Male vorher funktionierte, bevor urplötzlich dies nicht mehr weiterging.

In dem kleinen Micro-Kosmos, den wir uns geschaffen hatten existierte nicht viel. Alice, Stromzähler, ein paar Zeilen Code. Aber sowohl Alice, als auch der Stromzähler waren selbstbestimmt und wurden „lose“ durch die DIDs miteinander gekoppelt. „Offline first“ sorgte dafür, dass wir die Kommunikation zwischen Alice und Stromzähler kappen konnten, dann zwar keine neuen Ladevorgänge gestartet werden konnten (bzw. Zählerstände abrufbar waren), aber dennoch alles weiterlief. Naja, bis zum Auftreten des Problems…

Der eigentliche Fehler, den wir gemacht hatten, war eine Kleinigkeit, die das Volllaufen des Zwischenspeichers (Cache) zur Folge hatte. In dessen Folge lief so lange alles ohne Probleme weiter, wie Alice und Stromzähler eine Datenverbindung hatten, da der „Resolver“ dafür sorgt, dass er an der Quelle des Datensatzes nachfragt, wenn der Datensatz nicht im eigenen Zwischenspeicher vorhanden ist. Kappt man nun die Kommunikation, so kann die DID nicht „aufgelöst“ werden und der Prozess steht so lange, bis eine Auflösung wieder möglich wird. Will zum Beispiel Alice auf Basis des Beginn- und Endzählerstandes die Energiemenge des Ladevorgangs berechnen, so wird sie einfach Ende - Anfang = Menge berechnen, was im Hintergrund zu einer Auflösung der Referenzen führt, um an die Daten zu kommen. Die Berechnung bleibt „hängen“.

Zur Vollständigkeit sei hier gesagt, dass es bei TCP/IP basierter Kommunikation ohnehin keine „stehende Verbindungen“ gibt, sondern es sich um kleine Datenpakete handelt, die nacheinander ankommen und (im Falle von TCP) bestätigt werden. Auf die Feinheiten, die man ebenfalls in den Grundlagen der Informatik lernt, braucht es hier nicht ankommen. Auch zur Vollständigkeit: Der Grund für die (kurze) Kommunikationsunterbrechung beim Testlauf war eine WLAN-Verbindung, die nicht perfekt gewesen ist.

Der Lerneffekt, den wir sehr unmittelbar für uns hatten, wird jedoch klar: Egal wie trivial die Teilaufgabe ist (hier: Differenz zweier Zahlen berechnen), mach Dir klar, wo die Daten liegen und wie deren Abruf erfolgt. Murphy’s Law wird Dich immer heimsuchen.

Änderungserkennung (Events) und P2P

Ein häufig genutztes „Pattern“ bei der Softwareentwicklung ist, dass man mit der weiteren Programmausführung wartet, bis ein bestimmtes Ereignis eingetreten ist. Auch bei der vorangegangenen Erfahrung wurde ursprünglich dieses Muster genutzt, da die Berechnung (weitere Ausführung) erst erfolgt, wenn die Daten (Ende und Anfang) verfügbar sind.

In der Praxis legt man jedoch in seinem Programmcode gerade für komplexere Ereignisse/Reaktionen ein „Abonnement“ auf das Ereignis an. Bei der Programmiersprache Javascript sind dies die typischen objekt.on('WelcherEvent',function() { ... komplexe Reaktion ... }); . Die Herausforderung bei diesem Muster ist jedoch, dass die „komplexe Reaktion“ nur dann erfolgt, wenn der Event auch empfangen wird.

Zum Rumspielen hatten wir TyDIDS im Browser ausgeführt und in einem Fenster den Wert aktualisiert und wie von Geisterhand wurde in einem anderen Browserfenster der Wert aktualisiert. Dies funktionierte so lange, bis die Verbindung zwischen den beiden Browsern kurz unterbrochen gewesen ist. Mit einem Reload wird jedoch wieder der letzte Wert angezeigt (P2P Verbindung steht wieder).

Für die Softwareentwicklung bedeutet dies, dass man seine „Abos“ für Events regelmäßig erneuern sollte, da diese sonst irgendwann nicht mehr funktionieren werden und bei einem Ereignis der Code nicht ausgeführt wird.

Seiten: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Inhalt nicht verfügbar.
Bitte erlauben Sie Cookies, indem Sie auf Übernehmen Sie auf das Banner