Zusammenfassung

  • James E. White wollte mit RFC 707 wiederkehrende Befehls- und Antwortabläufe in ARPANET-Anwendungsprotokollen durch ein gemeinsames Procedure Call Protocol und eine Laufzeitumgebung vereinheitlichen.
  • Der RFC berichtet von einem Prototyp für einen PDP-10 unter TENEX, betont aber, dass entfernte Aufrufe IPC-Nachrichten benötigen, teurer als lokale Aufrufe sind und nicht jede nützliche Kommunikation als Prozedur abbilden.

Wenn eine Operation ein Gespräch verlangt

Ein Dateiname lässt sich mit einer Absicht ändern; das FTP-Protokoll von 1973 beschreibt dafür dennoch zwei Schritte: RENAME FROM, anschließend RENAME TO. Der Client führt damit nicht nur eine Operation aus, sondern steuert einen Dialog aus Befehl und Antwort. Auch Remote Job Entry definierte einen eigenen Strom von Befehlen und Rückmeldungen, darunter Fortschrittsmeldungen während laufender Arbeit. Anwendungen mussten ihre Dienstlogik und die jeweilige Gesprächsform gemeinsam implementieren.

RFC 707, A High-Level Framework for Network-Based Resource Sharing, setzte genau dort an. James E. White vom Augmentation Research Center des Stanford Research Institute (SRI) sah die wiederholte Befehls-/Antwortmechanik als gemeinsame Schicht. Ein Programm sollte einen Vorgang als Prozedur mit Parametern formulieren können, statt für jeden Dienst erneut ein eigenes Vokabular des Austauschs zu pflegen.

Ein einheitlicher Aufruf über IPC

Das vorgeschlagene Procedure Call Protocol (PCP) kombinierte CALL- und RETURN-Nachrichten, Transaktionskennungen, Argumente und Resultate. Mehrere Aufträge konnten offen bleiben. Eine Laufzeitumgebung an jeder Installation sollte den Aufruf vorbereiten, mit der Gegenstelle kommunizieren und das Ergebnis an das aufrufende Programm übergeben. Vorgesehen waren blockierende und nicht blockierende Aufrufe sowie Rückrufe des Servers an den Client.

Die Laufzeit vereinheitlichte die Programmierschnittstelle, nicht den Transport. Remote Job Entry und FTP lieferten konkrete Dialogformen; PCP sollte ihre wiederkehrende Mechanik bündeln. White ließ niedrigere IPC-Schnittstellen ausdrücklich zugänglich, denn asynchrone Abläufe und andere sinnvolle Kommunikation passen nicht immer in ein Prozedurmodell.

Was die TENEX-Implementierung belegt

Der RFC datiert den Beginn der ARC-Arbeiten auf Juli 1974. Innerhalb von zwölf Monaten habe es drei Entwurfsiterationen gegeben; anschließend sei eine Laufzeitumgebung für einen PDP-10 mit TENEX entworfen, dokumentiert und als Prototyp implementiert worden. Der Bericht sagt, die TENEX-Fassung habe die Spezifikation implementiert und die beschriebenen Möglichkeiten sogar übertroffen.

Damit dokumentiert das Papier mehr als eine abstrakte Idee: ein benanntes System und eine vom Projekt berichtete Implementierung. Es belegt jedoch weder eine Verbreitung über viele Installationen noch Interoperabilität zwischen unterschiedlichen Rechnern oder eine Nutzung im gesamten ARPANET. RFC Editor führt RFC 707 heute als Legacy mit Status UNKNOWN. Der IETF Datatracker ordnet das Dokument vor der formalen Quellenregistrierung ein und weist ihm keine formale Stellung im heutigen IETF-Standardprozess zu. Auch diese gegenwärtigen Angaben ersetzen keine historische Nutzungserhebung.

Die Grenze, die das Papier selbst zieht

RFC 707 formuliert seine Warnung schlicht: Lokale Prozeduraufrufe sind billig, entfernte nicht, weil dafür IPC-Nachrichten nötig sind. Entwickler müssen abwägen. Verteilte Programme können asynchron weiterarbeiten; nicht jede nützliche Netzwerkinteraktion ist eine Prozedur. Das Run-time darf die darunterliegende Kommunikation nicht vollständig verdecken.

Der historische Befund ist daher eng gefasst: RFC 707 bündelt wiederkehrende Dialogarbeit in einem Vorschlag, berichtet von einem TENEX-Prototyp und benennt die Kosten, die er nicht beseitigt. Die verfügbaren Quellen belegen weder eine flächendeckende Einführung noch einen direkten Ursprung späterer RPC-Systeme. Gerade die Grenze zwischen bequemer Syntax und teurer Kommunikation macht den Entwurf lesenswert.

Quellen