Zusammenfassung

  • RFC 3018 entwarf einen verteilten 128-Bit-Speicherraum mit Befehlen für Lesen, Schreiben, Allokation, Freigabe, Objektoperationen und Kontrolltransfer zwischen virtuellen Maschinen.
  • Eine Transaktion sollte vollständig auf einmal oder gar nicht ausgeführt werden. Nach Beginn der Ausführung gab es jedoch keine Stornierung; ein Kontrolltransfer konnte laut Spezifikation unmöglich rückgängig zu machen sein.

Solange die Transaktion auf dem Zielrechner vollständig gepuffert wartete, war sie noch beherrschbar. EXEC_TR konnte sie auslösen. CANCEL_TR konnte sie verwerfen.

Nach der Auslösung war sie kein wartendes Paket mehr. Sie war veränderter Speicher, freigegebene Ressource oder ein neuer Ausführungsfaden auf einem anderen Rechner.

RFC 3018 zieht die Grenze selbst. Eine Stornierung nach der Ausführung ist nicht vorgesehen. Braucht das System einen Ausgleich, muss die virtuelle Maschine ihn liefern, weil in der Transaktion Befehle stecken können, die nicht stornierbar sind—als Beispiel nennt der Text den Kontrolltransfer.

Die Experimental-Spezifikation vom Dezember 2000 trug einen weitreichenden Namen: Unified Memory Space Protocol. Sie wollte Anwendungen einen verteilten 128-Bit-Adressraum geben. Der Anwendungscode sollte das Netz nicht als eigene Schnittstelle sehen. Die VM übersetzte einen entfernten Zugriff in UMSP-Befehle: lesen, schreiben, vergleichen, Speicher anfordern oder freigeben, Code bewegen, Objektprozeduren ausführen, springen und aufrufen.

Das Netz verschwand aus der Oberfläche. Seine Zuständigkeiten blieben bestehen.

Der gemeinsame Zeiger vereinte keine Verwahrung

UMSP gliederte die Arbeit in Job, Task und Kontrollfaden. Der Job war die verteilte Anwendung, die Task ihre Vertretung auf einem Knoten, der Thread die konkrete Ausführung. Ein Job Control Point, JCP, verfolgte Tasks und vergab Kontrollkennungen.

Diese Mitte besaß nicht den gesamten Zustand. Lokaler Speicher blieb Sache der VM. Sie musste Zeiger korrekt halten und nach Ende einer Task ungültig machen. Das Protokoll kontrollierte weder den Job-Speicher noch die Benutzer-Threads.

Die 16-Oktett-Adresse kombinierte Netztyp, Knoten und lokale Speicheradresse. Sie vereinheitlichte das Benennen, nicht Takt, Journal oder Wiederherstellungsautorität. Ein Transfer zu einer entfernten Adresse erzeugte dort einen neuen Thread. Ein fortlaufender Codeabschnitt durfte trotzdem nicht über mehrere Knoten verteilt sein.

Die Abstraktion hatte somit echte physische und administrative Nähte. Gerade weil WRITE, FREE, MVRUN, JUMP, CALL, Objekterzeugung und Objektverfahren über dieselbe Oberfläche liefen, musste jede Wirkung ihren eigenen Nachweis behalten.

Vollständiger Empfang war noch keine Freigabe

Das Protokoll unterschied Sequenz und Transaktion. Eine Sequenz ordnete abhängige Befehle; scheiterte ein Befehl, wurden die folgenden abgebrochen. Eine Transaktion durfte voneinander unabhängige Befehle zusammenfassen, musste sie aber vollständig gemeinsam oder gar nicht ausführen.

Ihre Länge musste vorab bekannt sein, weil der Empfänger sie puffern konnte. _BEGIN_TR eröffnete, _END_CHAIN schloss die Kette.

Danach bestimmten Flags das weitere Verhalten. TRR=1 ließ die vollständige Kette sofort laufen. TRR=0 verlangte eine gesonderte EXEC_TR-Anweisung. Vor diesem Zeitpunkt entfernte CANCEL_TR die gespeicherten Befehle ohne Wiederherstellung.

TRE machte den Fehlerpfad zu einer Ausführungsentscheidung. Bei Wert 1 musste eine vollständige, noch nicht ausgeführte Transaktion nach Ablauf ihrer Lebenszeit oder bei einem Notende der Sitzung ausgeführt werden. Bei Wert 0 wurde sie abgebrochen. Die Uhr begann erst nach vollständigem Empfang; null bedeutete unbegrenzte Lebenszeit.

Ein Sitzungsabbruch konnte deshalb eine unvollständige Übertragung, eine fertige wartende Kette, eine bereits freigegebene Kette oder sogar den Auslöser für automatische Ausführung bedeuten.

Vier Nachweise gehören getrennt ins Journal: Identität und Digest der vollständigen Kette, Pufferbereitschaft, Ursache von Freigabe oder Abbruch und beobachtete Ergebnisse der wirksamen Befehle.

Atomarer Start war keine universelle Kompensation

Die Transaktionsaussage bezog sich auf den gemeinsamen Eintritt in die Ausführung. Sie versprach kein allgemeines Zurücksetzen einer bereits veränderten Welt.

Ein entfernter Schreibvorgang kann sofort von einem anderen Thread gelesen werden. FREE kann einen anderswo gehaltenen Zeiger entwerten. Verschobener Code kann eigenständig weiterwirken. Eine Objektprozedur kann außerhalb des Jobs Daten verändern. JUMP und CALL können Ausführung erzeugen, die länger lebt als ihre Ursprungskette.

Eine Kette aus Speicheranforderung, Codeinstallation und Kontrolltransfer kann vollständig gemeinsam starten. Sendet der neue Thread danach eine Nachricht oder löst eine äußere Handlung aus, löscht das Entfernen der ursprünglichen Kette diese Handlung nicht.

Stornierung gilt für das noch Wartende. Kompensation gilt für bereits entstandene Folgen und benötigt Anwendungswissen. Aus einem Opcode lässt sich nicht für jede Folge eine sichere Umkehrung ableiten.

Darum beweist EXEC_TR die Entscheidung, eine bestimmte Kette auszuführen. Es beweist nicht allein, dass jede VM-Aktion endete, alle Außenwirkungen genau einmal auftraten oder der Job sein fachliches Ziel erreichte.

TCP bestätigte Oktette, nicht VM-Wirkung

UMSP verlangte TCP für zuverlässigen Austausch und erlaubte UDP für Daten ohne Bestätigungsbedarf. RFC 793 beschreibt einen zuverlässigen, geordneten Oktettstrom und behandelt Verlust, Duplikate, Schäden und Umordnung. RFC 768 liefert einen wesentlich dünneren Datagrammdienst.

Die Transportgarantie bleibt eine Transportgarantie. Eine TCP-Bestätigung sagt nichts darüber, ob UMSP den Befehl validierte, der richtigen Kette zuordnete, unter der erwarteten Autorität freigab oder auf der richtigen Speicherversion ausführte.

RFC 1831 zeigt die Unsicherheit bei ONC RPC. Eine Antwort über TCP kann im dort beschriebenen Modell eine Ausführung belegen. Ohne Antwort darf der Client nicht schließen, dass nichts geschah; der Server kann vor dem Verbindungsfehler ausgeführt haben. Remote Calls unterscheiden sich von lokalen Aufrufen durch Fehler, Seiteneffekte, Leistung und Authentifizierung.

UMSP ließ den Fernzugriff noch stärker wie einen Prozessorbefehl aussehen. Die bequemere Oberfläche beseitigte die verteilte Ungewissheit nicht.

Der JCP war Koordinator, nicht allwissender Zeuge

Der JCP vergab die globale Job-Kennung, verfolgte Task-Anfang und -Ende und konnte für zentrale Benutzeridentifikation und Angriffsschutz dienen.

Dennoch verwalteten die VMs Speicher und Zeiger. Ein entfernter Thread konnte äußere Wirkungen erzeugen, die der JCP nicht direkt sah. Die Verbindung konnte nach der Ausführung und vor der Antwort brechen. Nach einem Neustart mussten alte Sitzungssegmente unterscheidbar bleiben.

Task-Ende, Job-Ende und nützliches Ergebnis sind daher verschiedene Tatsachen. Ein abgeschlossener Job beweist nicht die Persistenz jeder Schreiboperation, die Einmaligkeit jeder Außenwirkung oder den Erfolg einer späteren Kompensation.

Sicherheit blieb bewusst außerhalb des Anfangskerns

Die Sicherheitssektion erklärt, dass Sicherheitsfragen zur Verringerung der anfänglichen Komplexität nicht in die Mindestfunktion aufgenommen wurden. Die folgenden Punkte sind Empfehlungen für spätere Erweiterungen.

Genannt werden Schutzmittel aus TCP/IP, speziell verarbeitete Ketten für Integrität oder Verschlüsselung und Authentisierungsparameter in Erweiterungsheadern. Authentisierung konnte zwischen den beiden Knoten und dem JCP kombiniert werden. Gegen Man-in-the-Middle setzte der Entwurf auf getrennte Wege und räumte ein, dass ein gemeinsames Gateway den Schutz schwächte.

JUMP und CALL erschienen auch als DoS-Risiko; die VM sollte Ressourcen begrenzen. Aktiver Code vom Server bedrohte den Client, Clientcode auf dem Server erhöhte dessen Schutzbedarf.

Das benennt eine Angriffsfläche, spezifiziert aber keine vollständigen Algorithmen, Schlüssel, Autorisierung, Replay-Abwehr, Sperrung oder Revision.

Der spätere RFC 3552 nimmt einen Angreifer an, der Verkehr lesen, entfernen, verändern oder einspeisen kann. Er ist kein rückwirkender Maßstab für 2000. Er zeigt aber, warum Wegtrennung und noch offene Header kein fertiger Sicherheitsnachweis sind.

Experimental war ein Dokumentstatus, kein Betriebsbeleg

RFC 2026 ordnet Experimental außerhalb des Standards Track ein und sagt, dass solche Dokumente keine Internet Standards sind. Sie können Forschung oder Entwicklung archivieren. RFC 2119 lieferte die Anforderungswörter, RFC 2234 die ABNF.

Die Quellen belegen den Entwurf. Sie belegen keine UMSP-Implementierung, Verbreitung, Interoperabilität oder Störung.

Gerade deshalb lohnt die Spezifikation als Geschichte einer Grenze. Eine gemeinsame Adresse schuf keine gemeinsame Verwahrung. Vollständige Übertragung war nicht Freigabe. Atomare Freigabe war nicht Umkehrbarkeit. Job-Ende war nicht beobachtetes Ergebnis.

Lu Hengs Running-Code Primacy trennt die veröffentlichte Anweisung von ihrer Wirkung im laufenden System. Reality Layers hält Codierung, Puffer, Entscheidung, Ausführung und Ergebnis auseinander. Minimum Initial Specification erklärt den Wert eines kleinen Kerns, verlangt aber, fehlende Verträge für Sicherheit, Kompensation und Beobachtung sichtbar zu lassen.

Diese Begriffe sind analytische Linsen, keine Aussage über die Absicht des RFC-Autors.

Die Kette konnte gemeinsam starten. Was sie danach veränderte, brauchte eigene Beweise und eigene Rückwege.

Sources