Einleitung
Die folgende Zusammenfassung wurde aus Notizen übertragen, die ich auf drei Netzwerkbesprechungen angefertigt habe, die während der Fall Joint Computer Conference 1970 in Houston stattfanden. Obwohl ich mich um Objektivität bemüht habe, geben diese Notizen unvermeidlich eine voreingenommene Sicht der Besprechungen wieder. Das liegt zum Teil an meiner Fixierung auf bestimmte Themen und an möglichen Missverständnissen verschiedener Diskussionen. Zwar habe ich versucht, die Aussagen der Teilnehmer genau wiederzugeben, doch mag die Bedeutung mancher verzerrt sein.
Teilnehmer der Montagsbesprechung
Dick Benjamin MITRE
Jack Bouknight UI-CAC
Al Cocanower MIRUT
Steve Crocker UCLA
Dough Engelbart SRI
Richard Greenblatt MIT-MAC
Eric Harslem RAND
Frank Heart BBN
Allen Joseph ORNL (Oak Ridge)
Peggy Karp MITRE
William B. Kehl UCLA
Bob Long SDC
Jim Madden UI-CAC
Bob Metcalfe MIT-MAC
Edwin Meyer MIT-MAC
Ari Ollikainen UCLA
Tom O'Sullivan Raytheon
Jon Postel UCLA
Chris Reeve MIT-MAC
Tjaart Schipper UCAL-CCN
Michael S. Sher UI-CAC
Bob Sundberg Harvard
Hal van Zoeren CMU
Albert Vezza MIT-MAC
Alfred H. Vorhaus MITRE
Clark Weissman SDC
Netzwerkbesprechung
Montag, 16. November 1970, 20:05 Uhr
Crocker: Es sind noch nicht alle da, also lasst uns reden, bis mehr Leute kommen. Sind alle mit der Tagesordnung in meiner Ankündigung zufrieden?
Meyer: Wir sollten über logger protocol sprechen. Die operative Nutzung des Netzes, im Gegensatz zu Experimenten, hängt von seiner Implementierung ab.
Vorstellungen reihum.
Crocker: Ich habe eine Tagesordnung, möchte aber Vorschläge für Themen.
- Ich werde einleitende Bemerkungen machen.
- Ich werde die Themen auflisten, die von Belang sind.
- Englebart wird über das Network Information Center sprechen
- Ich werde den Status der Standorte durchgehen.
Einleitende Bemerkungen
- ARPA bezahlt den Kaffee und das Gebäck, die serviert werden, nicht, also gebt bitte etwas dazu, damit ich sie bezahlen kann.
- Ich werde mich in offizieller Funktion hauptamtlich der Netzwerkkoordination widmen. Meine Ziele sind: (a) die Nutzbarkeit des Netzes auszubauen. (b) Protokollebenen festzulegen, (c) ?
Wichtige Bereiche
- Irgendein Standort oder ein Zusammenschluss von Standorten sollte eine Methode vorbereiten, mit der der NCP eines Standorts überprüft werden könnte.
- Überarbeitung des NCP-Protokolls. Einige Fragen könnten besser gelöst werden: (a) Fehlerkontrolle, (b) Flusskontrolle, (c) Überlastung - Verlust von Netzwerkzuständen, (d) Vereinfachung und Neu-Schichtung des Protokolls.
- Telnet-System, Konsoleninteraktion oder logger protocol. Wie man in das System hineinkommt und wie man Hilfe bekommt, wenn man in Schwierigkeiten ist.
- Dokumentation der einzelnen Hosts. Network Info Center ist beteiligt. Vielleicht könnte jeder Standort mit einem Faksimilegerät ausgestattet werden.
- Anspruchsvollere Konsolen, insbesondere Grafik-Konsolen, sollen über das Netz angeschlossen werden. Es sollte eine Arbeitsgruppe geben, die ein Format für den Umgang mit anspruchsvollen Konsolen formuliert und ausarbeitet. Im Januar wird es eine Grafik-Besprechung in Colorado oder Utah geben. Der Eintrittspreis ist, einen Vorschlag zu schreiben. Ich rechne mit bis zu 30 Leuten. Ich werde eine kleine Teilmenge auswählen, um Spezifikationen zu entwickeln.
- Abrechnung - In der 2. Hälfte von 1971 werden mehr Standorte hinzukommen, wo die Abrechnung wichtig ist. (Sie wollen Rechnungen verschicken.) Larry Roberts sagt, dass es eine Art Banksystem geben wird, bei dem Rechnungen herumgereicht werden. Zwei Arten von Standorten: abrechnende Standorte und freie, aber zugangsbeschränkte Forschungsstandorte. Ich sehe keine grundlegenden Probleme. Was passiert, wenn ein Forschungsstandort mit einem abrechnenden Standort spricht? Ich denke, es ist machbar.
- Messungen - das Netz ist ein Werkzeug, aber es ist auch ein Modell, das besser ist als ein Simulationspaket. Verschiedene Leute wollen Messungen vornehmen. Das könnte unterstützt werden, indem Statistiken in den NCPs geführt werden. Was ist damit, die NCPs zu erweitern, um diese aufzunehmen?
Long: Abrechnung und Messung in die NCPs zu packen kostet Speicherplatz. Ergänzungen auf ein Minimum beschränken.
Weissman: Was ist mit der geplanten Verfügbarkeit der verschiedenen Systeme?
Crocker: Das muss mit jedem einzelnen System koordiniert werden
? : Was passiert mit den Verbindungen, wenn ein System ausfällt?
Crocker: Was ist mit Grafik-Vorschlägen? Ich werde mein eigenes Papier als Vorschlag schreiben. Es verwendet die DEC 340 als Modell. Modes geht von einem Scope-System und einem Speicher aus. Sowohl Ausgabe als auch Eingabe sind in die Standardisierung einbezogen. Ich möchte, dass aus der Arbeitsgruppe ein kompetentes Protokoll entwickelt wird.
Crocker: Was ist mit der Dokumentation?
Meyer: Dokumentation darüber, wie man andere Systeme benutzt, ist ein Muss. Nur das kann die operative Nutzung des Netzes vorantreiben.
--: Was ist damit, Dokumente an jedem Standort on-line zu stellen, oder wenigstens Zusammenfassungen.
Crocker: Welche Standorte haben Dokumente on-line? (MIT und Harvard) Wie stehen die Standorte dazu, Dokumente auf einem fremden System zu halten?
Crocker: Was ist mit der Überarbeitung des Protokolls?
Harslem: Wir haben uns in das UCSB-System eingeloggt und debuggen gemeinsam.
Harslem: Wir sind beeindruckt davon, Markierung und Auffüllung abzuschaffen (gemäß RFC 67).
Crocker: Wir haben das mit den Standorten besprochen. Die meisten schienen es zu akzeptieren, aber es gab Vorbehalte. Was ist mit Änderungen am Basisprotokoll. Ich glaube, Meyer hat etwas zu sagen.
Meyer: Die Position bei Project MAC ist, dass wir zu diesem Zeitpunkt Änderungen ablehnen, die nicht kritische Korrekturen sind. Zeit, die für Änderungen aufgewendet wird, ist Zeit, die nicht für die Entwicklung anderer notwendiger und interessanter Protokolle und Systeme aufgewendet wird. Und wir bei Multics haben eine lange Vorlaufzeit für die Erstellung und Installation von Änderungen.
Weissman: Ich ziehe es vor, Änderungen in einem Stück einzubauen, sagen wir in Abständen von 6 Monaten. statt in kleinen Stücken.
O'Sullivan: Können nicht gegenwärtige und neue Systeme gleichzeitig laufen?
Crocker: Wenn die Änderungen den IMP betreffen, nein, weil alle IMPs dasselbe System betreiben wollen.
Meyer: Die Stimmung am M.I.T. ist, dass das Netz, um ein Erfolg zu werden, dringend operativ genutzt werden muss. Wenn ein weiteres Jahr ohne nennenswerte operative Nutzung vergeht, könnte es den Bach runtergehen.
--: Und Dokumentation ist entscheidend, um die operative Nutzung voranzutreiben.
Engelbart: Vielleicht sollten wir die Grafik um mehrere Monate verschieben, um die Schreibmaschinen nicht zu verzögern. Schreibmaschinen sind wichtig.
--: Aber wäre das für die DOD-Leute beeindruckend genug?
Engelbart: Aber wenn sich das in zwei Jahren als ein Wurmnest erweist...
--: Aber interagieren die beiden Entwicklungsgruppen (Schreibmaschinen und Grafik)?
Vezza und Engelbart: Ja.
Crocker: Lasst uns mehr darüber hören.
Harslem: Wir wollen auf Dateien zugreifen können.
Crocker: Dann würde die Grafik-Anstrengung vielleicht die Schreibmaschinen-Entwicklung verwässern. Ist es der Konsens dieser Gruppe, dass wir keine Grafik-Besprechung haben sollten?
Vezza: Neueinsteiger sollten an der Grafik arbeiten, nicht die etablierten Leute. Verbietet den derzeitigen Leuten, zu dieser Besprechung zu gehen.
Meyer: Das wäre sehr frustrierend.
Benjamin: Warum nicht Positionspapiere erbitten (aber keine Besprechung abhalten).
Weissman: Zeichenübertragung ist einfacher als Grafikübertragung. Mehr Experimente sind für die Grafik nötig. Die Vorlaufzeit für die Entwicklung eines Grafik-Protokolls ist viel länger als für Schreibmaschinen.
Vezza: Ich stimme zu.
Crocker: In den nächsten Tagen wird es weitere Besprechungen geben, um an den Problemen zu arbeiten, wie man nützliche Arbeit über das Netz bekommt.
Pause
21:15 Uhr
Crocker: Engelbart wird über das Network Information Center sprechen.
Engelbart: NIC entstand als eine Ad-hoc-Sache, ohne spezifische Anweisungen von ARPA. Welche Arten von Dingen waren vorgesehen? (1) Anspruchsvolle Abfragesysteme, (2) Grundlegende Informationen über die Systeme an jedem Standort. Jeder fühlt sich wegen des Zustands der Dokumentation am eigenen Standort sehr verwundbar. Alle sind sich einig: bessere Dokumente sind nötig. Wir sehen uns als Anbieter der folgenden Dienste: 1) Sammeln von Papier-Material; 2) on-line-Abfrage von Katalogen und Indizes davon; 3) Zugang zu diesem Material geben. Wir haben uns für Papier statt on-line entschieden, vielleicht auf Mikrofiche.
Engelbart: Die 940 sollte für das Dokumentationssystem verwendet werden, erweiterbar mit steigender Nutzung. Wir wechseln von einer 940 zu einer 10X, um die Dienstkapazität besser auszubauen. Die Kapazitätsmenge steigt beträchtlich. Das hat die Arbeit an anderen Aspekten aufgehalten. Ein bewusstes Glücksspiel. Wir sind besorgt darüber, überhaupt in Gang zu kommen. Uns fehlt es an Mitteln für mehr Sekundärspeicher und wir sind daran interessiert, andere Hosts für Tertiärspeicher zu nutzen. Die Kosten für die Implementierung des Protokolls auf der 940 waren für die möglichen Gewinne zu hoch, also wurde es aufgegeben. Wenige Standorte wären bis Januar in Betrieb, wenn unsere 940 ausgeliefert werden sollte.
Engelbart: Wir haben ein Network Dialogue System geschaffen. Das ist ein Netzwerk menschlicher Agenten. An jedem Standort gibt es: a) einen technischen Kommunikationsagenten (Sekretär) und b) eine technische Kontaktperson. Wir ermutigen die Agenten, mit uns zu sprechen, und haben „Enterprise“-Telefonnummern eingerichtet, damit sie gebührenfrei sprechen können.
Engelbart: Wir senden zunächst ein winziges Kit an jeden Agenten, eine wachsende Sammlung von Netzwerk-Referenzinformationen. Eine Person (der Agent) an jedem Standort soll darin geschult werden, den Satz von Dokumenten zu handhaben und Informationen abzurufen oder die technische Kontaktperson eines anderen Standorts zu kontaktieren. Das beinhaltet einen öffentlichen Dialog, bei dem ein Verzeichnis der hin- und hergehenden Dokumente geführt wird. Das ist eine Art „human IMP“-Netz, wie folgt strukturiert:
________________________________
| |
| ________________ |
| | local | | one
| | reference | | <== site ____________
| | material | | ( )
| -----------------| | ( )
| | => (____________)
| | || \\
| | || Other sites
| | || \\
| ________ | || ____________
| local =====> | |================ ( )
| users | agent |=====|===============( )
| =====> |________| | (____________)
| |
|________________________________|
- Die Master-Sammlung enthält das gesamte Material.
- Jede lokale Sammlung enthält eine Teilmenge, die als am nützlichsten gilt.
--: Was ist mit der Beschränkung des Zugangs zu Dokumenten?
Engelbart: Alle Dateien sind in diesem System öffentliche Dateien.
Vezza: Man kann ein privates Memo schicken, statt den NIC-Dienst zu nutzen.
Engelbart: Die Master-Sammlung enthält Bücher und andere Dokumente. On-line katalogisiert. Papier-Material kann vervielfältigt werden. Für Informationen, die den Werttest bestehen, soll der Dienst Dokumente speichern, katalogisieren, indexieren und Zugang dazu bieten. Wir werden eine Reihe verschiedener Terminals unterstützen. Wir sind darauf vorbereitet, lange mit Papier-Exemplaren zu arbeiten, können aber gegen Bezahlung einen Dienst einrichten, der Papier in on-line-Form überträgt.
Weissman: Was ist damit, OCR-Selectric-Kugelköpfe an die Standorte zu verteilen?
--: Wird NIC nehmen, was geschickt wird, oder es aktiv aufspüren?
Engelbart: Mehr oder weniger, was uns zugeht. Im Frühjahr 1971 wird ein System existieren, das es einem Agenten erlaubt, Einträge in einen Katalog einzufügen. Der ablaufende Dialog wird bestimmen, in welche Richtung die Datenbank wächst. Wir sind ziemlich sicher, dass SRI schließlich Gebühren erheben muss, weil viele potenzielle Nutzer, die nicht an Primärstandorten sind, begrenzte Ressourcen suchen.
--: Was ist mit einem NCP für eure 10X.
Engelbart: Wenn BBNs NCP bis Februar 1971 fertig ist, werden wir es verwenden.
Crocker: Wie bekommen die Leute Zugang?
Engelbart: Jeder Standort ist registriert. Jede Person, die über das Konto eines Standorts hineinkommt, hat dessen Zugang. Wir werden uns erst dann um die Abrechnung kümmern, wenn eine Sättigung eintritt. Wir möchten die Nutzung des Agentensystems fördern, um eine Übersicht der Ressourcen an jedem Standort zu erstellen und zu nutzen. Eine Untergruppe sollte darüber sprechen.
Crocker: Wann können sich die Leute treffen, um das zu besprechen? (Morgen früh)
Engelbart: Wir haben schöne Einrichtungen für die Entwicklung von Verteilerlisten, privaten Bibliografien, Personalprofilen, aber es hängt vom Interesse der Netzwerk-Leute ab.
Engelbart: Agenten wurden bei MIT, UCLA, RAND, UI, Utah usw. eingerichtet. Ein guter Prozentsatz der Standorte
Vezza: Viele Standorte verschicken Sachen als Post 3. und 4. Klasse. Dauert zu lange.
Crocker: Statusbericht der Standorte. ILLIAC IV wird erst Mitte 71 in Betrieb gehen, später im Netz (72?). Andere mögliche Standorte: RADC, AWS, NCAR. Derzeit in Betrieb: UCSB, RAND. Kurz bevorstehend (Januar 71): MIT BBN, Harvard, UCLA, Utah, LL, SDC. Ein gewisser Prozentsatz bis Ende des Jahres, der Rest im Januar.
Heart: Morgen wird ein brandneues IMP-System (große Änderung) eingebaut. Einige weitere Standorte denken darüber nach, dazuzukommen. Das Netz wird beträchtlich über das hinaus wachsen, was schon an Bord ist. Auch wir sind an Standort-Ressourceninformationen interessiert. Kein langfristiges Interesse, aber wir werden Informationen zu Papier bringen, um ARPA zu helfen.
Crocker: Viele Leute gähnen. Was ist mit den Besprechungsterminen? Während der FJCCs? 1-Tages- vs. 2-Tages-Besprechungen? Was ist mit getrennten Besprechungen an der Ost- und Westküste?
Ende der Besprechung
Netzwerkbesprechung
Dienstag, 17. November 1970, 9:15 Uhr
Crocker: Engelbart wird ausführlicher sprechen. Später können wir eventuell logger protocol und Dateitransfer besprechen.
Engelbart: Die Grundsache ist eine Sammlung von Dokumenten mit einem Katalog, der sie beschreibt. Ein Eintrag hat viele Datenelemente, darunter, wo er zu finden ist. Techniken zum Hinzufügen und Aktualisieren von Einträgen. Wir machen das jetzt, möchten aber die Möglichkeit an andere Seiten geben, teils weil wir nicht bestimmen können, was von Wert ist. (Zeigte 3 Arten von Ausdrucken.) 1) Katalogauflistung, nach Ordinalindex in der Sammlung und NIC-Index. für die Bestandskontrolle, um herauszufinden, was da ist. 2) Kompaktes Format in einer Zeile. 3) Nach Autor sortiert - eine Zeile pro Eintrag. Wir werden Verfahren haben, mit denen ein ungeschulter Nutzer eine Sammlung verwalten kann.
Meyer: Wie sind diese Systeme implementiert?
Engelbart: Wir haben einen Compiler-Compiler auf der 940. Unsere Subsysteme sind in einer spezialisierten höheren Sprache geschrieben. Wir verlagern das auf die 10X.
Heart: Wie viele Leute kann die 10X ungefähr unterstützen?
Engelbart: Vielleicht 100-1000 Sammlungen.
--: Vielleicht könnten die Leute eigene DEC-Bänder für zusätzlichen Speicher beisteuern.
Engelbart: Könnte man, aber das erfordert einen Bediener vor Ort. Langsamer Zugriff. Wir haben kein Geld für mehr Speicher, erwägen aber, Dateien nach UCSB zu schicken. Wir bieten on-line-Abfrage von on-line-Daten. Bereit, uns um die Datenverwaltung zu kümmern, ob wir sie nun speichern oder nicht.
Crocker: Bitte beschreibe die verschiedenen Subsysteme. (Es folgt eine Beschreibung von Engelbart.)
Heart: Haben die Leute versucht, es über das Netz zu nutzen?
Engelbart: Nein. Wir haben keinen NCP auf der 940. Wir haben uns dagegen entschieden, ihn in ein System einzubauen, das verschwindet. Der größte Hänger ist, wann die 10X einen NCP bekommt. Bobrow entwickelt ihn, aber es verzögert sich.
Heart: Wer wird früh darauf zugreifen (SRI)?
UI: Illinois kann anfangs nur auf SRI zugreifen.
Postel, UCLA: Wir planen, es zu nutzen.
Heart: Es wäre eine bedeutende Aufgabe, wenn jemand es sich zum Ziel machen würde, in Engelbarts System hineinzukommen.
MITRE: Wir werden andere Systeme von BBNs 10X aus nutzen.
Engelbart: Wir versuchen, wesentliche Subsysteme zu isolieren, damit die Leute sie leicht nutzen können. Dateien sind hierarchisch organisiert und werden sich im Laufe der Jahre füllen. Dokumente werden über Pfadnamen referenziert. (Es folgt eine Diskussion der Systeme.)
Crocker: Wie kommt man in das System? (Engelbart beschreibt die Eingabesequenz für TOdas.)
Crocker: Wie wird man im System registriert?
Engelbart: Letztlich durch persönliche Eingabe, aber derzeit gibt es eine Benutzerkennung pro Standort.
Meyer: Ich denke, wir ignorieren ungelöste Probleme bei der Schreibmaschinen-Anbindung. Zum Beispiel die Eingabesequenz für TOdas, bei der der Nutzer ein oder zwei Zeichen tippt und das System die übrigen Zeichen eines Schlüsselworts austippt, wird von einem half duplex-System wie Multics aus frustrierend zu benutzen sein. Unser System erkennt eine Eingabezeile erst, wenn eine neue Zeile getippt wird.
Various: Diskussion über 1/2 duplex-Kommunikation. Bringt den Unterschied heraus zwischen a) Full duplex-Systemen, bei denen das System die Eingabe zurückmeldet, gegenüber 1/2 duplex, bei dem die Eingabe lokal getippt wird, und b) Systemen, bei denen jedes Zeichen beim Tippen erkannt wird, gegenüber Systemen, bei denen die ganze Zeile erst nach dem EOL-Zeichen erkannt wird.
Crocker: Ist Multics nicht das einzige half duplex, zeilenorientierte System im Netz?
Meyer: Das kann ich nicht glauben. Arbeiten die IBM-Systeme nicht so?
Engelbart: Wir könnten eine 1/2 duplex-Schnittstelle an unserem System haben (SRI). Ist es die Multics-Hardware, die diese Einschränkung erzwingt?
Meyer: Ja, der Ein-/Ausgabe-Controller.*
* Der Schreibmaschinen-Adapter des Multics IO-Controllers ist 1/2 duplex, kann aber Break-Zeichen außer dem „new line“-Zeichen akzeptieren.
Engelbart: Jedes System sollte einen Präprozessor haben, um mit anderen Systemen zu sprechen. Wir werden eine Grafik-Schnittstelle ins Netz bringen.
Meyer: Wie siehst du diese Schnittstellen? Halten die sich an einen Netzwerk-Standard, oder wird jedes System eine Schnittstelle zu dir bauen?
Engelbart: Standard-Netzwerkprotokoll.
Crocker: Gehen wir weiter zu anderen Dingen.
O'Sullivan: Was ist mit 2741ern an deinem (CMU) 10X-System. Hast du ernste Schnittstellenprobleme? (CMUs 2741er laufen durch ein Softwarepaket, das sie in TTY 37s umwandelt. Keine ernste Schwierigkeit.)
Various: Kurze Diskussion darüber, wie Multics die Eingabe handhabt.
Sundberg, HARVARD: Unsere 10X kann zeichenorientierte Eingabe annehmen, aber unsere höherstufigen Subsysteme bevorzugen zeilenorientierte Eingabe.
--: Was ist mit der Effizienz, Nachrichten Zeichen für Zeichen durch das Netz zu übertragen?
Crocker: Es gibt mehr Ausgabe, die gepackt geht, als Eingabe, also ist die Ineffizienz der Eingabe vernachlässigbar.
Engelbart: Wir planen, mehrere verschiedene Ports in unser System zu haben. Wenn jedes System ein NIC-Modul hätte; könnte es ohne die Notwendigkeit eines Logins mit uns kommunizieren. Wir bevorzugen ein Batch-System, bei dem ein Standort einen gespoolten Stapel von Bearbeitungsanforderungen schickt, Sachen zurückbekommt und Ports freigibt. Das Problem der zeilenweisen Schreibmaschinen-Übertragung könnte ähnlich wie gespoolte Anforderungen behandelt werden. Wir ermutigen Spooling, werden aber interaktive Nutzer unterstützen. Wir können mehr Batch als interaktive Leute unterstützen.
* Der Schreibmaschinen-Adapter des Multics IO-Controllers ist 1/2 duplex, kann aber Break-Zeichen außer dem „new line“-Zeichen akzeptieren.
Vezza: Haben die Leute das Gefühl, dass die Frage full und 1/2 duplex ein Problem ist? Lasst alle Leute zurückgehen und das herausfinden. M.I.T. mit einem full und 1/2 duplex-System 20 feet auseinander kann hier helfen.
O'Sullivan: Es scheint 2 Fragen zu geben: (1) Echo (full duplex) gegenüber 1/2 duplex. (2) Einzelzeichen- gegenüber Ganzzeilen-Übertragung.
Crocker: Zwei Definitionen: Serving host - liefert Rechenleistung; using host - parasitär, verwaltet das Terminal des Nutzers. Das sieht die Netznutzung als Verbindung zwischen lokalem Nutzer und fremdem Server.
Vezza: Was ist mit der Zusammenschaltung 1/2 duplex - full duplex, wenn einige full duplex-Systeme etwas anderes zurückmelden als eingegeben wurde.
Crocker: Zwei unabhängige Möglichkeiten. Zeichnen wir ein Diagramm:
| "2741" | "33, 35, 37" |
| hard wire | 2 separate |
| local echo | lines all |
| computer does | printed |
| not echo | |
____________|_________________|___________________|
Process | hard | X |
each | | |
character | | |
____________|_________________|___________________|
Process | X | easy |
only after | | |
EOL | | |
____________|_________________|___________________|
Crocker: Ich behaupte, es gibt wirklich nur zwei Möglichkeiten (mit X markiert).
Postel: Was ist mit einem System, bei dem das Echo auf so niedriger Ebene erfolgt, dass es nicht gelöscht werden kann.
Crocker: Wenn dem so ist, ist es wie ohne Echo.
Van Zoeren: Unser System denkt, wir haben full duplex-TTYs, aber unsere 2741er sind über eine Software-Transformationsbox angeschlossen.
Meyer: Was passiert, wenn nicht-echomeldende Systeme über das Netz an echomeldende Systeme angeschlossen werden? Ich tippe meine Eingabezeile, dann antwortet das echomeldende System mit meiner Eingabe, dann mit irgendeiner Ausgabe. Mein System kann das nicht filtern, weil es keine Möglichkeit gibt, Echo von Ausgabe zu unterscheiden.
Crocker: Das ist nicht unbedingt etwas Schlechtes. Ich tippe eine Befehlsabkürzung an SRI; dann ist die nächste Ausgabezeile eine erweiterte Form des eingegebenen Befehls.
Meyer: Unser Ziel sollte ein gemeinsames Protokoll sein statt einer Reihe von zusammengeflickten Schemata, um Kommunikation zwischen bestimmten Host-Paaren zu implementieren.
Long, SDC: Wir ziehen es vor, eine vollständige Zeile zu empfangen, die durch das Netz geführt wird.
Crocker: Unterscheiden wir zwischen Forschungszentren und Dienstzentren. Nur die Dienstzentren sind mit einer half duplex-Schnittstelle befasst. (X unten links im Diagramm). Dazu gehören SRI, BBN, Multics.
O'Sullivan: Was ist mit dem Forschungszentrum?
Crocker: Sie können Dienstzentren anrufen, aber sind selbst vielleicht schwer zu benutzen.
Illinois: Dann wird ILLIAC IV half duplex sein müssen.
Postel: Ich denke, half duplex, zeilenorientiert ist schwächer (als ein full duplex, zeichenorientiertes Protokoll).
Sundberg: Harvard kann beides, bevorzugt aber ein zeilenorientiertes System.
Engelbart: Grafik-Terminals sind schwerer ins Netz zu bringen wegen nicht standardisierter Eingabe.
Harslem: Du denkst an die Tasten als Funktionstasten statt als Eingabetasten.
Engelbart: Ich mache mir Sorgen um Leute, die Grafik nutzen wollen.
O'Sullivan: Wir haben das Problem noch nicht angesprochen, welche Art von Protokoll eingerichtet werden sollte.
Crocker: Das ist keine schwierige technische Sache. Wir kommen später dazu und treffen eine Entscheidung.
Meyer: Ich bin nicht befugt, eine Entscheidung zu treffen. Ich soll der MAC-Gruppe Bericht erstatten.
Crocker: Okay. Dann ein Vorschlag, der über den normalen Mechanismus angenommen werden soll. Pause
Crocker: Ich werde vorschlagen, wie man mit den X-markierten Kästen umgeht, unter Ignorierung der hard und ease-Kästen:
Zeilenorientierte Eingabe - 8 bit ascii einschließlich End of Line-Zeichen:
n, C1,...,Cn;
Cn=EOL
120>n>>_1 n is the character count in an 8-bit field.
Die Zeichenzahl steht vor der Zeile, um dem Softwaresystem die gleiche Effizienz zu geben wie dem Hardwaresystem; der Rechner muss nicht nach dem EOL suchen.
Vezza: Bekommst du die Längeninformation nicht mit der IMP-Nachricht?
Crocker: Meine Philosophie ist, dass IMP-Nachrichtengrenzen völlig unsichtbar sein sollten.
Long: Ich lehne es ab, Schreibmaschinen-Nachrichten in zwei getrennte Stücke aufzuteilen.
Crocker: Was ist dein Einwand, 1) Zeilen, die an Nachrichtengrenzen beginnen, oder 2) Nachrichten, die nicht an einer Zeilengrenze beginnen?
Long: Beides.
Engelbart: Jeder Host sollte eine Schnittstelle schreiben, um die gängigsten Terminaltypen zu handhaben.
Crocker: Das offizielle Protokoll erlaubt nicht, dass IMP-Nachrichtengrenzen irgendeine Bedeutung haben.
Engelbart: Ich will mich nicht mit IMP-Nachrichtengrenzen herumschlagen. Das Netz sollte unsichtbar sein (auf dieser Ebene).
Vezza, Long: Wir geben nach, wir machen mit.
Meyer: Ich möchte die Einschränkung ändern. Das letzte Zeichen im Zeilenpaket muss kein EOL sein (wie wenn eine Ausgabe nicht zu einer neuen Zeile vorrückt), aber ein EOL darf nicht mitten in einem Paket vorkommen.
Van Zoeren: Diese Einschränkung gefällt mir nicht.
Meyer: Die Zahl sagt uns, dass jedes EOL am Ende steht, wir müssen nicht suchen.
Crocker: Das EOL ist das Zeichen, das dem System sagt, dass es handeln soll.
Harslem: Unser System hat 46 Funktionstasten, nicht nur ein EOL.
Crocker: Wie wäre es mit C, E {breakset}; i=n. Das ist komplexer, weil man ein breakset übertragen muss. Ich werde das gleich vorschlagen. Wie wäre es damit: nachrichtenorientierte (1/2 duplex) Verbindung
zwischen User- und Server-Hosts für die Konsoleninteraktion. Lokales Echo, kein Server-Echo. Das ist für zeilenorientierte Dienstsysteme. Das sind leichte Verallgemeinerungen der Multics-Konventionen.
Meyer: Ich bin sicher, dass andere Systeme außer Multics es benutzen. Es ist nicht so schlimm, wie du zu denken scheinst.
Engelbart: Das obere Management sollte wissen, dass es schlecht ist.
Meyer: Das ist nicht klar. Es gibt Effizienzfragen.
Van Zoeren: Ich will Dateien nicht auf diese Weise übertragen müssen.
Crocker: Das ist für Konsolen, nicht für Dateiübertragung.
Engelbart: Wir brauchen ein einheitliches Schema für die Datenübertragung.
O'Sullivan: (Für Konsolen) sollen wir einen Weg finden, einem System zu sagen, wo sein Interrupt simuliert werden soll.
Crocker: Es gibt ein allgemeines Problem der Datenübertragung für Bänder und Dateien.
O'Sullivan: Aber wir haben das spezifische Problem, die Schreibmaschinen-Kommunikation zu implementieren.
Engelbart: Aber was wir brauchen, ist eine allgemeine Art, Sachen durch das Netz zu schicken (so dass es unsichtbar ist), und den Host es interpretieren zu lassen, wie er will.
Meyer: Es sollte eine Konsolenschnittstelle für das Netz geben, nicht mehrere an jedem Standort.
Crocker: Dieses Problem ist vielleicht überbewertet.
Engelbart, Meyer, O'Sullivan: Diskussion über die Unterstützung bestimmter Terminaltypen.
Engelbart: Ich werde einen Graphen von Systemen gegen Terminaltyp zeichnen. Der Schnittpunkt eines Systems und eines Terminals, das von diesem System akzeptiert wird, ist mit einem Punkt markiert. Das Netzwerkkommunikationsproblem ist eines, ein Terminal am lokalen Host zu finden, das auch am Zielhost unterstützt wird.
_____|_____|_____|_____|_____
| | | |
systems_____|_____|_____._____|_____
| | | |
_____|_____._____|_____|_____
| | | |
_____|_____|_____|_____|_____
| | | |
terminals
Crocker: Es gibt ein allgemeines Problem, dass ein Subsystem auf Eingabe reagiert. Schlage vor, dass Eingabe als vollständige Nachricht oder in Vielfachen von 8 bits gesendet werden sollte.
Vezza: Schränken wir zu sehr ein?
Meyer: Warum ist es notwendig, Vielfache von 8 bit zu haben?
Crocker, Engelbart: Okay, werfen wir das weg.
Ende der zweiten Besprechung
Netzwerkbesprechung
Mittwoch, 18. November 1970, 20:20 Uhr
(Die folgenden Notizen sind stark gerafft und versuchen nur, die wichtigsten auf dieser Besprechung diskutierten Themen darzustellen.)
Crocker: Treffen wir uns zur SJCC mit mehr vorheriger Organisation. Halten wir mehrtägige Besprechungen in Abständen von 2-3 Monaten ab. Wir haben viel gute Diskussion über das Protokoll der nächsten Ebene gehabt. Lasst eine Untergruppe das ausarbeiten.
(Harslem erklärt sich bereit, das in RFC 66 vorgeschlagene logger protocol neu zu entwerfen. Meyer wird den Vorschlag in RFC 46 überarbeiten.)
Meyer: Gehen wir zurück, diskutieren diese Fragen, schreiben Vorschläge. Später haben wir eine offene Besprechung, um über einen formellen Vorschlag zu entscheiden.
Crocker: Eine kleine Gruppe ist besser, vielleicht wähle ich eine Teilmenge aus.
Vezza: Es stimmt, dass hier nichts geklärt ist. Wichtige Vorschläge sollten vor einer Besprechung schriftlich vorliegen. Wir können nicht vorschreiben, was eine kleine Gruppe tut. Sie hat nicht mehr Autorität als ein Einzelner.
(Karp von MITRE erklärt sich bereit, eine Bibliografie der Netzwerkdokumente zu erstellen, vielleicht bis Januar.)
(Wer hat logger protocol implementiert? UCSB und UCLA mod 91 haben es oder planen es. SDC hat es vielleicht bis 21/1, fand es umständlich, ist bereit zu ändern.)
(Diskussion über Dateiübertragung. Crocker schlägt vor, dass eine künftige Protokolländerung eine Byte-Größe wie 8, 32, 36 bit an eine Verbindung anhängen könnte.)
(Bezüglich Steuerverbindungen wird alles in 8-bit-Bytes übertragen außer den Befehlen ECO, ERP, ERR. Es wurde kein Einwand dagegen erhoben, das Protokoll zu ändern, so dass auch sie Vielfache von 8-bit-Bytes sein müssen.)
(Diskussion darüber, wie man das Ende einer Datei angibt. Vorherige Übertragung der Bitzahl oder ein EOR-Zeichen am Ende senden? Vorschlag, dass wir eine globale Lösung für das allgemeine Problem wollen, eine Nachricht beliebiger Länge zu senden, statt nur für die Dateiübertragung.)
(Diskussion über „transaction units“ oder Satzgrößen. Was ist eine optimale Größe einer transaction unit? IMP-Nachrichtengrenzen sind (per Protokoll-Dekret) unsichtbar und hängen nicht mit dieser Diskussion zusammen. Die Multics-Blockgröße wurde angesprochen. Das Nächste ist die Seitengröße, 1024 Wörter.)
(Wie man das Dateiende angibt. Engelbart sagt, Datenpakete senden, dann ein EOF-Paket. Crocker schlägt vor, dass das CLSen der Verbindung als EOF wirken kann. Vezza schlägt vor, IMP-Nachrichtengrenzen zur Bestimmung des Endes zu verwenden. Wenn weniger als eine vollständige IMP-Nachricht, ist dies der letzte Teil der Datei. Meyer schlägt die Verwendung von zwei Verbindungen vor, Datenkanal und Steuerkanal, über die alle Steuernachrichten wie Dateiname, Bitlänge usw. laufen.)
(Diskussion über verschiedene Situationen, in denen die ganze Datei, ein Teil der Datei oder die ganze Datei in beliebigen Stücken gewünscht wurde.)
Meyer: Warum das nicht aufschieben und über die Schreibmaschinen-Kommunikation sprechen, die am kritischsten ist.
Vezza: Engelbart will eine saubere allgemeine Lösung.
Crocker: Wenn wir jetzt eine Ad-hoc-Lösung bekommen, könnte sie die spätere Implementierung einer allgemeinen Lösung behindern.
(Crocker schlägt ein Format vor, um eine Datei beliebig langer Sätze aus Bytes fester Größe von 8-26 bit zu übertragen. Ein Satz ist kleiner als 10^5 bytes. Jeder Satz wird von einem Zähl-Byte angeführt.)
1 2 n 1 2 m
|----------------------------------------------------|
| n | | | | | m | | | | |
|----------------------------------------------------|
<------- record -----------> <-------- record ------->
O'Sullivan: Passt dieses Modell zu einem Terminal, das Zeichen- und Grafikmodi hat?
(Diskussion über Unterschiede zwischen Tastatur- und Dateiübertragung. Unsicherheit, ob eine globale Lösung zu beidem passen würde.)
(Wer will Dateien durch das Netz schicken? Multics und 6-10, RAND an UCLA, MITRE über BBN.)
Crocker: Gehen wir weg und denken darüber nach und schlagen später Lösungen vor.
(Harslem schlägt ein Format vor, um Daten mit Operationscodes zu übertragen. Jeder Satz besteht aus: <opcode> <length> <data>. Gibt die Möglichkeit, viele Arten von Statusinformationen zu senden.)
(Diskussion darüber, Daten- und Steuerinformationen gemischt oder auf getrennten Verbindungen zu senden. Fragen der Verunreinigung der Daten gegenüber Synchronisations- und Wettlaufproblemen. Es wurde behauptet, dass Synchronieprobleme leicht überwunden werden.)
(Vorschlag, dass wir wirklich nicht viel über diesen Bereich wissen. Wir sollten weggehen und schreiben.)
Pause
Crocker: Was muss getan werden, bevor wir uns in andere Systeme einloggen können?
Meyer: 3 Fragen: 1) wie man die Verbindung herstellt, 2) was der Zeichensatz ist, 3) was der Übertragungsmodus ist (bezogen auf das full und 1/2 duplex-Problem).
(Diskussion darüber, das Standardprotokoll auf Dienstsysteme auszurichten, die im Allgemeinen zeilenorientiert und 1/2 duplex sind. Alle Systeme, die Dienste anbieten, sollen eine 1/2 duplex-Schnittstelle haben.)
(Diskussion darüber, ob es für logger protocol möglich oder wünschenswert ist, die Übertragung von Teilstücken von Zeilen in einer IMP-Nachricht zuzulassen. Weniger effizient, Teilstücke von Zeilen zu nehmen, vernünftig, eine vollständige Zeile zu senden. Es wurde darauf hingewiesen, dass das NCP-Protokoll IMP-Nachrichtengrenzen jede Bedeutung verwehrt, so dass Systeme darauf vorbereitet sein müssen, Zeilen zu akzeptieren, die IMP-Nachrichtengrenzen überspannen. Es ist jedoch am besten, eine vollständige Zeile zu senden.)
(Diskussion darüber, ob sich das zeilenorientierte Protokoll biegen sollte, um Einzelzeichenübertragung von full duplex-Systemen anzunehmen. Es scheint, dass wir ein Protokoll entwickeln, das jedem System erlaubt, ein zeilenorientiertes System zu nutzen. Ein zeichenorientiertes System von anderen Systemen aus zu nutzen, ist schwieriger und erfordert ein separates Protokoll.)
Heart: Ich bin für eine sofortige Lösung.
Postel: Wenn etwas erst einmal drin ist, wird es schwer sein, es zu ändern.
Crocker: Ich denke, diese Besprechungen werden sich als wichtiger erweisen, als wir je wollten. Mir geht es mehr um die langfristigen Auswirkungen als um das Anfangsdatum.
Van Zoeren: Wenn wir es nicht entscheiden, wird es jemand anderes auf die schlechte Art entscheiden.
Hinweis: Dieser RFC wurde von Gottfried Janik 2/98 für die Aufnahme in die Online-RFC-Archive in maschinenlesbare Form gebracht.