Nahezu jede der üblichen Definitionen eines Prozesses würde den Bedürfnissen dieser Arbeit genügen.
Oder vielleicht gibt es nur einen einzigen dauerhaft bekannten Port, der zu einem Verzeichnisprozess (directory-process) gehört, der eine Tabelle der Zuordnungen von Dauerprozessen zu wohlbekannten Ports führt.
Das Programm, das Dateiverzeichnisse ausgibt, mitteilt, wer an anderen Fernschreibern ist, Subsysteme ausführt usw.
Dem Leser dürfte inzwischen aufgefallen sein, dass ich es nicht mag, mir vorzustellen, dass jedes Mal ein neuer Prozess (bestehend aus einer neuen begrifflichen Kopie eines Programms) gestartet wird, wenn ein weiterer Benutzer das Programm verwenden möchte. Vielmehr denke ich das Programm lieber als einen einzigen Prozess, der weiß, dass er gleichzeitig von vielen anderen Prozessen benutzt wird, und der bewusst zwischen den Benutzern multiplext oder den Dienst für Benutzer aufschiebt, bis er dazu kommt.
Ich verwende in diesem Abschnitt Betriebssystem statt Time-Sharing-System, um hervorzuheben, dass die autonomen Systeme an den Netzknoten entweder vollwertige Time-Sharing-Systeme eigenen Rechts, einzelne Prozesse in einem größeren geografisch verteilten Time-Sharing-System oder einfach autonome Standorte sein können, die kommunizieren wollen.
Bei einer SEND FROM ANY-Nachricht ist der Zusammenführungsstandort der Zielstandort.
Für Leser, die mit dem einst vorgeschlagenen Wiederverbindungsschema (re-connection scheme) für das ARPA-Netz vertraut sind, ist das obige System vergleichsweise einfach, weil es keine dauerhaften Verbindungen gibt, die abgebrochen und verschoben werden müssten; das heißt, Verbindungen bestehen in dem hier beschriebenen System nur flüchtig und können daher zwischen jedem Prozesspaar neu hergestellt werden, das irgendwann zufällig die Portnummern des anderen kennt und einen Anhaltspunkt hat, wo sich beide befinden.
Crowther sagt, dies sei nicht das Konzept des virtuellen Netzes.
Als einer der Erbauer des ARPA-Kommunikationsteilnetzes bin ich für diese Einschränkungen teilweise verantwortlich.
Der Leser, der Zugang zu den ARPA-Arbeitsdokumenten hat, möchte vielleicht Specifications for the Interconnection of a Host to an IMP, BBN Report No. 1822, lesen sowie die ARPA Network Working Group Notes #36, 37, 38, 39, 42, 44, 46, 47, 48, 49, 50, 54, 55, 56, 57, 58, 59, 60.
Dies erlaubt es außerdem, dass Nachrichten vom IMP-Teilnetz vollständig verworfen werden, falls dies jemals nützlich sein sollte.