Arbeitstitel: Askemos oder wozu ist denn das Freenet gut?

Dies ist ein Versuch, Aufgabe, Funktion und Entwicklungsstand von Askemos zusammenzufassen.

Mit der Reifung verteilter Speichermedien wie z. B. Freenet (oft bezeichnet als großes Crypto-Raid) stellt sich die Frage, welcher Nutzen sich aus diesen ableiten läßt. Oft werden kulturelle Werte wie Freiheit und Zensurresistenz angeführt, diese Motivation erreicht nur einen Teil des möglichen Publikums.

Betrachtet man solche verteilten Speichermedien schlicht als Speicher, dann stellt man zwei angenehme, jedoch nicht grundsätzlich notwendige Eigenschaften fest: Netzwerktransparenz und Anonymität. Das heißt es ist erstens möglich, Daten ohne Ansehen ihres "Aufenthaltsortes" zu verarbeiten und zweitens ist unerlaubtes Beobachten ausgeschlossen.

Was spricht eigentlich dagegen, grundsätzlich alle Daten auf einem solchen Medium abzulegen? Was muß getan werden, damit dies praktikabel wird?

Nehmen wir vorerst an, daß diese Fragen seien klärbar und fragen weiter, worin der Nutzen liegt. Die Allgegenwart aller Dateien aller Rechner am Internet auf allen anderen Rechnern erscheint nicht unmittelbar erstrebenswert, selbst dann nicht, wenn sie grundsätzlich nur verschlüsselt vorliegen. Wohl aber kann man sich vorstellen, daß Endgeräte (z. Bsp. Personal Computer, Telefone etc.) nach Authorisierung den eigenen "Desktop" und nur diesen empfangen können.

Schon ein Fortschritt, jedoch nicht qualitativ. Was aber ist der eigene Deskop? Dateien und Programmzustände. Würde man diese beiden zu jedem Zeitpunkt (in angemessen kurzen Intervallen, z. Bsp. für Desktop-Anwendungen nach jedem Mausklick in einem versteilten Speichermedium ablegen, dann könnte jedes Endgerät jederzeit auf jede Anwendung in gerade jenem Zustand schalften, den die Anwendung hatte, als sie letztmalig benutzt wurde. Nach dem Ausfall eines Endgerätes kann so genau und zwar ganz genau an der Stelle weitergearbeitet werden, an der der Abbruch erfolgte. Die Datensicherheit geht dadurch gegen 100%.

Jetzt liegen die Daten nun schon einmal in einem gemeinsamen Speicherpool, dann lassen sich natürlich nicht nur Endgeräte, sondern auch "serverseitig" neue Anwendungen realisieren. Diese Anwendungen fangen beim Groupware-Kalender an und erklären eMail definitiv zu einem historischen Kommunikationsmedium, denn sie können sozusagen direkt wie die Benutzer-Endgeräte die Daten benutzen.

Alle Daten überall - immer; beschränkt nur durch die Schlüssel der Eigentümer.

Der Anwendung auf dem Server möchte man in einer solchen Umgebung natürlich mit einem gewissen Mißtrauen begegnen dürfen. Wir reden hier schließlich von billigen Fertiginstallationen oder -geräten, nicht von teuer zertifizierten Einzelinstallationen. Dem Prinzip der verteilten Speicherung folgend, kann man jedoch auch die Ausführung redundant auf mehrere Maschinen verteilen, schließlich haben wir ihre Programmzustände ja sowieso schon bei jeder Änderung im versteilten Speicher abgelegt.

Läßt man nun über jede Änderung zunächst mindestens von drei Geräten abstimmen, dann werden fehlerhafte Geräte nur noch Störungen verursachen, wenn die Anzahl der defekten Geräte einen hohen Prozentsatz aller beteiligten Geräte erreicht.

Damit funktioniert das Netzwerk als Ganzes für die Anwender wie ein einziger Computer, an jedem Endgerät. Man spaart sich endlose Stunden Installation und Backup. Einfach die neue Maschine einschalten, Schlüssel einspielen, Passwort dazu, fertig. Eine neue Freiheit.

  +"Niemals wieder Ärger mit blauen Bildschirmen"

vielleicht doch besser nicht ;-)
ch nicht korrekt, da nur der Ärger verschwindet,
der blaue Bildschirm >;->

Basis dieser könne sich "Provider" für Serverleistungen anbieten, die gegenseitig zertifizierte Server bereitstellen um Kundenanwendungen laufen zu lassen. Provider kann dabei jeder werden: Software installieren, Schlüssel generieren, fertig.

Was tut Askemos / fiXml dazu?

Askemos realisiert eine Ausführungsumgebung, die Anwendungen obiger Art auf entsprechenden Servern laufen läßt.

Dazu zwingend notwendig existiert ein Berechtigungssystem, daß ohne administrative Zentralgewalt funktioniert.

Zur Anbindung von Endgeräten steht derzeit HTTP und SMTP zur Verfügung, weitere sind geplant und in Arbeit.

Alle Daten und Programmzustände werden bei jeder Veränderung in XML-Strukturen abgelegt. Dies erfolgt derzeit wahlweise in einem XML-Objektspeicher (mit hoher Geschwindigkeit) und/oder in gewöhnlichen Dateien.

Ausführung mit Abstimmung (byzantinische Protokolle) funktioniert im Prototyp derzeit jedoch nur mit unmittelbarem Zugriff (direkt per OID, keine Pfadangaben).

Der Prototyp erreicht auf einem Pentium I I 200 M Hz Laptop mit 196 M Byte Hauptspeicher auf dem 3 Askemos-Server in Abstimmung (zzgl. Netscape, emacs etc.) laufen ca. 2 commits pro Sekunde, wobei jeweils ein 20 K Byte XML-Dokument "aktuelle Programmzustand" geschrieben wird. Ohne Abstimmung ca. 10 commit pro Sekunde.

  Oh, das ist nicht schlecht! Hätte das Verhältniss gröber vermutet.

(Aufgrund der Messung wurden Optimierungen vorgenommen, neuere Versionen sind entsprechend schneller.)

Dazu kommt eine Scripting-Umgebung, die zum Einen ständig - wie oben beschrieben - transparent im persistenten Speicher gehalten wird. Zustätzlich sind diese Programme rein funktional programmiert. Dies kommt dem Nutzer nur mittelbar zu Nutze: funktionale Programmierung entspricht im Grunde den Methoden Mathematik und ist derzeit die Vorraussetzung um Programme formal verifizieren, also ihre Richtigkeit beweisen zu können.