Presque n'importe laquelle des définitions courantes d'un processus conviendrait aux besoins de cet article.
Ou peut-être n'existe-t-il qu'un seul port connu de façon permanente, qui appartient à un processus annuaire (directory-process) tenant une table des associations processus permanent/port bien connu.
Ce programme qui affiche les répertoires de fichiers, indique qui se trouve sur les autres téléscripteurs, exécute des sous-systèmes, etc.
Le lecteur aura sans doute remarqué maintenant que je n'aime pas penser qu'un nouveau processus (constitué d'une nouvelle copie conceptuelle d'un programme) soit démarré chaque fois qu'un autre utilisateur souhaite utiliser le programme. Je préfère plutôt considérer le programme comme un processus unique qui sait qu'il est utilisé simultanément par de nombreux autres processus et qui multiplexe consciemment entre les utilisateurs ou retarde le service à certains utilisateurs jusqu'à ce qu'il puisse s'en occuper.
J'emploie système d'exploitation plutôt que système à temps partagé dans cette section pour souligner le fait que les systèmes autonomes des nœuds du réseau peuvent être soit de véritables systèmes à temps partagé à part entière, soit un processus individuel dans un système à temps partagé plus vaste et géographiquement réparti, soit simplement des sites autonomes souhaitant communiquer.
Pour un message SEND FROM ANY, le site de jonction est le site de destination.
Pour les lecteurs familiers avec le schéma de reconnexion (re-connection) autrefois proposé pour le réseau ARPA, le système ci-dessus est relativement simple, car il n'y a pas de connexions permanentes à rompre et à déplacer ; autrement dit, les connexions n'existent que fugacement dans le système décrit ici et peuvent donc être rétablies entre n'importe quelle paire de processus qui, à un moment donné, connaissent les numéros de port l'un de l'autre et ont quelque indice de l'endroit où ils se trouvent.
Crowther dit que ce n'est pas le concept de réseau virtuel.
Comme l'un des constructeurs du sous-réseau de communication ARPA, je suis partiellement responsable de ces contraintes.
Le lecteur ayant accès aux documents de travail de l'ARPA voudra peut-être lire Specifications for the Interconnection of a Host to an IMP, BBN Report No. 1822 ; ainsi que les ARPA Network Working Group Notes #36, 37, 38, 39, 42, 44, 46, 47, 48, 49, 50, 54, 55, 56, 57, 58, 59, 60.
Cela permet aussi que les messages soient complètement jetés par le sous-réseau IMP si cela devait un jour être utile.