Zum Hauptinhalt springen

RFC 1 - Host-Software (Host Software)

Network Working Group: Steve Crocker
Request for Comments: 1
Institution: UCLA
Datum: 7. April 1969

Zusammenfassung​

Dieses Dokument ist das erste RFC in der Geschichte des ARPANET und diskutiert Designüberlegungen für Host-Software. Das Dokument umfasst einen Überblick über IMP (Interface Message Processor, Schnittstellen-Nachrichtenprozessor) Software, Anforderungen an Host-zu-Host-Software, Verbindungsaufbaumechanismen und vorläufige Experimentpläne. Dieses Dokument markiert den Beginn der Tradition der Internet-Protokolldokumentation.

INHALT (CONTENTS)​

EINLEITUNG (INTRODUCTION)​

Die Software für das ARPA-Netzwerk existiert teilweise in den IMPs und teilweise in den jeweiligen Hosts (HOSTs). BB&N hat die Software der IMPs spezifiziert, und es liegt in der Verantwortung der Host-Gruppen, sich auf Host-Software zu einigen.

Im Sommer 1968 trafen sich Vertreter der ersten vier Standorte mehrmals, um die Host-Software und erste Experimente im Netzwerk zu diskutieren. Aus diesen Treffen entstand eine Arbeitsgruppe von drei Personen: Steve Carr von Utah, Jeff Rulifson von SRI und Steve Crocker von UCLA, die sich im Herbst und Winter trafen. Das jüngste Treffen fand in der letzten Märzwoche in Utah statt. Ebenfalls anwesend war Bill Duvall von SRI, der kürzlich begonnen hat, mit Jeff Rulifson zusammenzuarbeiten.

Etwas unabhängig davon hat Gerard DeLoche von UCLA an der Host-IMP-Schnittstelle gearbeitet.

Ich präsentiere hier einige der erreichten vorläufigen Vereinbarungen und einige der aufgetretenen offenen Fragen. Sehr wenig von dem, was hier steht, ist endgültig, und Reaktionen werden erwartet.

I. Eine Zusammenfassung der IMP-Software (A Summary of the IMP Software)​

Nachrichten (Messages)​

Informationen werden von Host zu Host in Bündeln übertragen, die Nachrichten (messages) genannt werden. Eine Nachricht ist jeder Datenstrom von nicht mehr als 8080 Bits zusammen mit ihrem Header. Der Header ist 16 Bits lang und enthält die folgenden Informationen:

Ziel (Destination)     5 Bits
Verbindung (Link)      8 Bits
Verfolgung (Trace)     1 Bit
Reserve (Spare)        2 Bits

Das Ziel ist der numerische Code für den Host, an den die Nachricht gesendet werden soll. Das Trace-Bit signalisiert den IMPs, Statusinformationen über die Nachricht aufzuzeichnen und die Informationen an das NMC (Network Measurement Center, Netzwerkmesszentrum, d.h. UCLA) zurückzusenden. Die Reservebits werden nicht verwendet.

Das Verbindungsfeld ist ein spezielles Gerät, das von den IMPs verwendet wird, um bestimmte Arten von Überlastung zu begrenzen. Sie funktionieren wie folgt. Zwischen jedem Paar von Hosts gibt es 32 logische Vollduplex-Verbindungen (logical full-duplex connections), über die Nachrichten in beide Richtungen übertragen werden können. Die IMPs legen die Einschränkung auf diese Verbindungen fest, dass kein Host zwei aufeinanderfolgende Nachrichten über dieselbe Verbindung senden kann, bevor der IMP am Ziel eine spezielle Nachricht namens RFNM (Request for Next Message, Anforderung der nächsten Nachricht) zurückgesendet hat. Diese Anordnung begrenzt die Überlastung, die ein Host einem anderen verursachen kann, wenn der sendende Host versucht, zu viel über eine Verbindung zu senden. Wir bemerken jedoch, dass die Verbindungen ihren Zweck nur erfüllen, wenn die Überlastung von einer oder zwei Verbindungen kommt, da der IMP am Ziel nicht genug Kapazität hat, um alle 32 Verbindungen gleichzeitig zu verarbeiten. Es ist notwendig, dass die Hosts in dieser Hinsicht zusammenarbeiten.

Die Verbindungen haben die folgenden primitiven Eigenschaften. Sie funktionieren immer, und es gibt immer 32 davon.

Mit „funktionieren immer" meinen wir, dass die IMPs immer bereit sind, eine weitere Nachricht über sie zu übertragen. Kein Begriff des Beginns oder Endes einer Konversation ist in der IMP-Software enthalten. Es ist daher nicht möglich, einen IMP über den Zustand einer Verbindung abzufragen (obwohl es möglich sein könnte, einen IMP über die jüngste Geschichte einer Verbindung abzufragen -- eine ganz andere Sache!).

Die andere primitive Eigenschaft der Verbindungen ist, dass es immer 32 davon gibt, ob sie verwendet werden oder nicht. Dies bedeutet, dass jeder IMP 18 Tabellen mit jeweils 32 Einträgen pflegen muss, unabhängig vom tatsächlichen Verkehr.

Trotz der Einwände gegen die Verbindungsstruktur sind die Verbindungen innerhalb der IMPs leicht zu programmieren und sind wahrscheinlich allein aufgrund ihrer Einfachheit eine bessere Alternative zu komplexeren Arrangements.

IMP-Übertragung und Fehlerprüfung (IMP Transmission and Error Checking)​

Nach dem Empfang einer Nachricht von einem Host teilt ein IMP die Nachricht in ein oder mehrere Pakete (packets) auf. Pakete sind nicht länger als 1010 Bits und sind die Einheit der Datenübertragung von IMP zu IMP. Eine 24-Bit-Zyklische Prüfsumme (cyclic checksum) wird von der Übertragungshardware berechnet und an ein ausgehendes Paket angehängt. Die Prüfsumme wird von der Empfangshardware neu berechnet und gegen die übertragene Prüfsumme geprüft. Pakete werden am Ziel-IMP wieder zu Nachrichten zusammengesetzt.

Offene Fragen zur IMP-Software (Open Questions on the IMP Software)​

  1. Ein 8-Bit-Feld wird für die Verbindungsspezifikation bereitgestellt, aber nur 32 Verbindungen werden bereitgestellt, warum?

  2. Der Host soll in der Lage sein, Nachrichten an seinen IMP zu senden. Wie macht er das?

  3. Kann ein Host im Gegensatz zu seinem IMP RFNMs kontrollieren?

  4. Werden die IMPs Codekonvertierung durchführen? Wie wird sie gesteuert?

II. Einige Anforderungen an die Host-zu-Host-Software (Some Requirements Upon the Host-to-Host Software)​

Einfache Nutzung (Simple Use)​

Wie bei jeder neuen Einrichtung wird es eine Phase sehr geringer Nutzung geben, bis die Benutzergemeinschaft mit dem Netzwerk experimentiert und beginnt, sich darauf zu verlassen. Eines unserer Ziele muss es sein, die sofortige und einfache Nutzung durch eine breite Klasse von Benutzern zu fördern. Mit diesem Ziel scheint es natürlich, die Fähigkeit bereitzustellen, jeden entfernten Host zu nutzen, als ob von einem TTY (teletype, Fernschreiber) Terminal aus gewählt worden wäre. Zusätzlich möchten wir eine gewisse Fähigkeit, eine Datei auf eine etwas andere Weise zu übertragen, als einen Fernschreiber zu simulieren.

Intensive Nutzung (Deep Use)​

Eines der inhärenten Probleme im Netzwerk ist die Tatsache, dass alle Antworten von einem entfernten Host unabhängig davon, wie einfach sie sind, etwa eine halbe Sekunde benötigen werden. Für die Fernschreibernutzung könnten wir zu einer Halbduplex-Lokalecho-Anordnung wechseln, aber dies würde einen Teil der Nützlichkeit des Netzwerks zerstören. Die 940-Systeme haben zum Beispiel ein sehr spezialisiertes Echo.

Wenn wir die Nutzung von Grafikstationen oder anderen ausgefeilten Terminals unter der Kontrolle eines entfernten Hosts in Betracht ziehen, wird das Problem schwerwiegender. Wir müssen nach einer Methode suchen, die es uns ermöglicht, unsere ausgeklügeltste Ausrüstung so weit wie möglich so zu nutzen, als wären wir direkt mit dem entfernten Computer verbunden.

Fehlerprüfung (Error Checking)​

Jeff Rulifson vom SRI weist darauf hin, dass Fehlerprüfung an wichtigen Softwareschnittstellen immer eine gute Sache ist. Er verweist auf einige Erfahrungen am SRI, wo dies viel Streit und verschwendete Mühe gespart hat. Aus diesen Gründen möchten wir eine Host-zu-Host-Prüfung sehen. Neben der Prüfung der Softwareschnittstelle würde sie auch die Host-IMP-Übertragungshardware prüfen. (BB&N behauptet, dass die Host-IMP-Hardware so zuverlässig sein wird wie die internen Register des Hosts. Wir glauben ihnen, aber wir wollen trotzdem die Fehlerprüfung.)

III. Die Host-Software (The Host Software)​

Aufbau einer Verbindung (Establishment of a Connection)​

Die einfachste Verbindung, die wir uns vorstellen können, ist, wenn der lokale Host als TTY fungiert und den entfernten Host anwählt. Nach einiger Überlegung der Probleme beim Initiieren und Beenden einer solchen Verbindung wurde beschlossen, Verbindung 0 für die Kommunikation zwischen Host-Betriebssystemen zu reservieren. Die verbleibenden 31 Verbindungen sollen daher als Wählleitungen verwendet werden.

Jedes Host-Betriebssystem muss seinen Benutzerprogrammen ein Primitiv (primitive) zum Aufbau einer Verbindung mit einem entfernten Host und ein Primitiv zum Trennen der Verbindung bereitstellen. Wenn diese Primitive aufgerufen werden, muss das Betriebssystem eine freie Verbindung auswählen und eine Nachricht über Verbindung 0 an den entfernten Host senden, die eine Verbindung auf der ausgewählten Verbindung anfordert. Das Betriebssystem im entfernten Host muss zustimmen und eine Akzeptanznachricht über Verbindung 0 zurücksenden. Falls beide Hosts dieselbe Verbindung auswählen, um eine Verbindung zu initiieren, und beide im Wesentlichen zur gleichen Zeit Anforderungsnachrichten senden, wird ein einfaches Prioritätsschema aufgerufen, bei dem der Host mit niedrigerer Priorität nachgibt und eine andere freie Verbindung auswählt. Ein verwendbares Prioritätsschema ist einfach die Rangfolge der Hosts nach ihren Identifikationsnummern. Beachten Sie, dass beide Hosts wissen, dass gleichzeitige Anforderungen gestellt wurden, aber sie ergreifen komplementäre Aktionen: Der Host mit höherer Priorität ignoriert die Anforderung, während der Host mit niedrigerer Priorität sowohl eine Akzeptanz als auch eine weitere Anforderung sendet.

Die so hergestellte Verbindung ist eine TTY-ähnliche Verbindung im Zustand vor dem Einloggen. Dies bedeutet, dass das Betriebssystem des entfernten Hosts die Verbindung zunächst so behandelt, als hätte sich gerade ein TTY eingewählt. Der entfernte Host wird dieselben Echos erzeugen, dieselbe Anmeldesequenz erwarten und nach denselben Unterbrechungszeichen suchen.

Hochvolumige Übertragung (High Volume Transmission)​

Fernschreiber, die als Terminals fungieren, haben zwei besondere Nachteile, wenn wir die Übertragung einer großen Datei in Betracht ziehen. Der erste ist, dass einige Zeichen spezielle Unterbrechungszeichen sind. Der zweite ist, dass oft spezielle Pufferungstechniken eingesetzt werden, die nur für langsame zeichenweise Übertragung geeignet sind.

Wir definieren daher eine andere Klasse von Verbindungen, die für die Übertragung von Dateien oder anderen großen Datenmengen verwendet werden soll. Um diese Klasse von Verbindungen zu initiieren, müssen Benutzerprogramme an beiden Enden einer etablierten TTY-ähnlichen Verbindung die Einrichtung einer dateiähnlichen Verbindung parallel zur TTY-ähnlichen Verbindung anfordern. Das Prioritätsschema kommt wieder ins Spiel, denn der Host mit höherer Priorität sendet eine Nachricht über Verbindung 0, während der Host mit niedrigerer Priorität darauf wartet. Die Benutzerprogramme sind natürlich nicht davon betroffen. Die Auswahl der freien Verbindung erfolgt durch den Host mit höherer Priorität.

Dateiähnliche Verbindungen zeichnen sich dadurch aus, dass keine Suche nach Unterbrechungszeichen stattfindet und Pufferungstechniken verwendet werden, die für höhere Datenraten geeignet sind.

Eine Zusammenfassung der Primitive (A Summary of Primitives)​

Jedes Host-Betriebssystem muss seinen Benutzern mindestens die folgenden Primitive bereitstellen. Diese Liste ist bekanntermaßen notwendig, aber nicht ausreichend.

a) TTY-ähnliche Verbindung mit Host x initiieren.

b) Verbindung beenden.

c) Zeichen über TTY-ähnliche Verbindung senden/empfangen.

d) Dateiähnliche Verbindung parallel zu TTY-ähnlicher Verbindung initiieren.

e) Dateiähnliche Verbindung beenden.

f) Über dateiähnliche Verbindung senden/empfangen.

Fehlerprüfung​

Wir schlagen vor, dass jede Nachricht in ihrem Körper eine Nachrichtennummer, Bitanzahl und Prüfsumme trägt, die für den IMP transparent ist. Für eine Prüfsumme schlagen wir eine 16-Bit-End-Around-Carry-Summe (end-around-carry sum) vor, die über 1152 Bits berechnet und dann zyklisch um ein Bit nach rechts verschoben wird. Die Rechtsverschiebung alle 1152 Bits soll Fehler bei der Nachrichtenwiederzusammensetzung durch die IMPs erfassen.

Engere Interaktion (Closer Interaction)​

Die oben beschriebenen Primitive zeigen, wie ein Benutzer eine entfernte Einrichtung einfach nutzen kann. Sie geben keinen Aufschluss darüber, wie eine viel kompliziertere Nutzung des Netzwerks durchgeführt werden soll. Konkret sind wir besorgt über die Tatsache, dass an einigen Standorten viel Arbeit investiert wurde, um den Computer hochgradig auf eine ausgeklügelte Konsole reagieren zu lassen. Cullers Konsolen an der UCSB und Englebarts am SRI sind mindestens zwei Beispiele. Es ist klar, dass Verzögerungen von etwa einer halben Sekunde für triviale echoähnliche Antworten die Interaktion bis zu dem Punkt degradieren, an dem die Ausgeklügeltheit der Konsole irrelevant wird.

Wir glauben, dass die meiste Konsoleninteraktion in zwei Teile geteilt werden kann, einen im Wesentlichen lokalen, sofortigen und trivialen Teil und einen entfernten, längeren und bedeutenderen Teil. Als einfaches Beispiel betrachten Sie einen Benutzer an einer Konsole, die aus einer Tastatur und einem Auffrischungsbildschirm besteht. Das Programm, in das der Benutzer tippt, akkumuliert eine Zeichenkette, bis ein Wagenrücklauf auftritt, und verarbeitet dann die Zeichenkette. Während Zeichen getippt werden, zeigt es die Zeichen auf dem Bildschirm an. Wenn ein Löschzeichen (rubout) getippt wird, löscht es das vorherige Nicht-Löschzeichen. Wenn der Benutzer H E L L O <- <- P <CR> tippt, wobei <- Löschen und <CR> Wagenrücklauf ist, hat er neun Tastenanschläge gemacht. Wenn jeder dieser Tastenanschläge dazu führt, dass eine Nachricht gesendet wird, die wiederum Anweisungen an unsere Anzeigestation aufruft, werden wir schnell gelangweilt sein.

Eine bessere Lösung wäre, das Frontend des entfernten Programms -- d.h. den Teil, der nach <- und <CR> sucht -- in unserem Computer resident zu haben. In diesem Fall würde nur eine Fünf-Zeichen-Nachricht gesendet, d.h. H E L P <CR>, und der Bildschirm würde lokal verwaltet.

Wir schlagen vor, diese Lösung zu implementieren, indem wir eine Sprache für die Konsolensteuerung erstellen. Diese Sprache, derzeit DEL genannt, würde von Subsystemdesignern verwendet werden, um zu spezifizieren, welche Komponenten in einem Terminal benötigt werden und wie das Terminal auf Eingaben von seiner Tastatur, Lincoln Wand usw. reagieren soll. Dann würde der entfernte Host als Teil des anfänglichen Protokolls dem lokalen Host den Quellsprachentext des Programms senden, das die Konsole steuert. Dieses Programm würde vom Subsystemdesigner in DEL geschrieben, aber lokal kompiliert werden.

Die Spezifikationen von DEL werden diskutiert. Die folgenden Diagramme zeigen die Abfolge der Aktionen.

         /                                                      \
        |     +-----------+                    +-----------+    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     | terminal  |                    | terminal  |    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     +-----+-----+                    +-----+-----+    |
        |           |                                |          |
        |           |                                |          |
        |           |                                |          |
        |     +-----+-----+                    +-----------+    |
        |     |     |     | Request connection |     |     |    |
   UCLA {     |     |     | -> over link 25    |     |     |    } SRI
        |     |   +-+-+   |  +-+          +-+  |   +-+-+   |    |
        |     |   | OS|---+-=|I|----------|I|=-+---| OS|   |    |
        |     |   +-+-+   |  +-+          +-+  |   +---+   |    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     +-----------+                    +-----------+    |
        |      HOST: UCLA                        HOST: SRI      |
         \                                                     /
         /                                                      \
        |     +-----------+                    +-----------+    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     | terminal  |                    | terminal  |    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     +-----+-----+                    +-----+-----+    |
        |           |                                |          |
        |           |                                |          |
        |           |                                |          |
        |     +-----+-----+ "Please send front"+-----------+    |
        |     |     |     | end control"       |     |     |    |
   UCLA {     |     |     |        ->          |     |     |    } SRI ___
        |     |   +-+-+   |  +-+          +-+  |  +--+---+ |    |    /   |
        |     |   | OS|---+-=|I|----------|I|=-+--|OS|NLS| +----+---|    |
        |     |   +-+-+   |  +-+          +-+  |  +------+ |    |   |___/
        |     |           |       DEL prog.    |           |    |   |    |
        |     |           |        <-          |           |    |   |____|
        |     +-----------+                    +-----------+    |
        |      HOST: UCLA                        HOST:SRI       |
         \                                                     /

C. Nach Empfang und Kompilierung des DEL-Programms (After Receipt and Compilation of the DEL program)​

         /                                                     \
        |     +-----------+                    +-----------+    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     | terminal  |                    | terminal  |    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     +-----+-----+                    +-----+-----+    |
        |           |Trivial                         |          |
        |           |Responses                       |          |
        |           |                                |          |
        |     +-----+------+                    +-----------+   |
        |     |     |      |                    |     |     |   |
   UCLA {     |     |      |  Major Responses   |     |     |   } SRI ___
        |     |  +--+--+   |  +-+          +-+  |  +--+---+ |   |    /   |
        |     |  |DEL  |---+-=|I|----------|I|=-+--|OS|NLS| +---+---|    |
        |     |  |front|   |  +-+          +-+  |  +------+ |   |   |___/
        |     |  | end |   |                    |           |   |   |    |
        |     |  |prog.|   |                    |           |   |   |____|
        |     |  +-----+   |                    |           |   |
        |     |  | OS  |   |                    |           |   |
        |     |  +-----+   |                    |           |   |
        |     |            |                    |           |   |
        |     +------------+                    +-----------+   |
        |      HOST: UCLA                         HOST: SRI     |
         \                                                     /

Offene Fragen (Open Questions)​

  1. Wenn die IMPs Codekonvertierung durchführen, ist die Prüfsumme nicht korrekt.

  2. Das Verfahren zum Anfordern des DEL-Frontends ist noch nicht spezifiziert.

IV. Erste Experimente (Initial Experiments)​

Experiment Eins (Experiment One)​

SRI modifiziert derzeit sein Online-Retrievalsystem, das die Hauptsoftwarekomponente des Netzwerkdokumentationszentrums sein wird, so dass es mit Modell-35-Fernschreibern betrieben werden kann. Die Steuerung der Fernschreiber wird in DEL geschrieben. Alle Standorte werden DEL-Compiler schreiben und NLS über das DEL-Programm nutzen.

Experiment Zwei (Experiment Two)​

SRI wird ein DEL-Frontend für das vollständige NLS einschließlich Grafiken schreiben. UCLA und UTAH werden NLS mit Grafiken nutzen.

Hinweis: Dieses RFC wurde von Celeste Anderson im März 1997 in maschinenlesbares Format konvertiert und in die Online-RFC-Archive aufgenommen.

Verwandte Ressourcen​

  • Offizieller Text: https://www.rfc-editor.org/rfc/rfc1.txt
  • Offizielle Seite: https://datatracker.ietf.org/doc/html/rfc1

Historische Bedeutung​

RFC 1 ist das erste RFC-Dokument in der Geschichte des Internets und markiert den Beginn der ARPANET- und modernen Internet-Protokolldokumentationstradition. Geschrieben von dem jungen Doktoranden Steve Crocker, nannte er diese Dokumente bescheiden „Request for Comments" (Bitte um Kommentare), ein Name, der bis heute Bestand hat. Dieses Dokument verkörpert den Geist der Zusammenarbeit und die offene Haltung der frühen Internet-Pioniere.

Letztes Update am