Introduction
Le résumé qui suit a été transcrit à partir des notes que j'ai prises lors de trois réunions sur le réseau tenues à Houston pendant le Fall Joint Computer Conference de 1970. Bien que j'aie tenté d'être objectif, ces notes présentent inévitablement une vision biaisée des réunions. Cela tient en partie à ma préoccupation pour certains sujets et à une éventuelle mauvaise compréhension de diverses discussions. J'ai tenté de paraphraser fidèlement les propos des participants, mais le sens de certains a pu être déformé.
Participants à la réunion du lundi
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
Réunion sur le réseau
Lundi 16 novembre 1970, 20 h 05
Crocker: Tout le monde n'est pas là, alors parlons jusqu'à ce que d'autres personnes arrivent. Est-ce que tout le monde est satisfait de l'ordre du jour de mon annonce ?
Meyer: Nous devrions parler du logger protocol. L'usage opérationnel du réseau, par opposition aux expériences, dépend de son implémentation.
Présentations à la ronde.
Crocker: J'ai un ordre du jour, mais je veux des suggestions de sujets.
- Je ferai des remarques introductives.
- Je vais énumérer les sujets de préoccupation.
- Englebart parlera du Network Information Center
- Je passerai en revue l'état des sites.
Remarques introductives
- ARPA ne paiera pas le café et les pâtisseries servis, alors mettez la main à la poche pour m'aider à les payer.
- Je vais consacrer tout mon temps à la coordination du réseau à titre officiel. Mes objectifs sont : (a) accroître l'utilisabilité du réseau. (b) établir des niveaux de protocole, (c) ?
Domaines importants
- Un site ou une coalition de sites devrait préparer une méthode permettant de vérifier le NCP d'un site.
- Refonte du protocole NCP. Certains points pourraient être mieux résolus : (a) le contrôle d'erreur, (b) le contrôle de flux, (c) la surcharge - la perte d'états du réseau, (d) la simplification et la restructuration en couches du protocole.
- Interaction de console du système Telnet, ou logger protocol. Comment entrer dans le système et comment obtenir de l'aide en cas de problème.
- Documentation de chaque hôte. Le Network Info Center impliqué. Peut-être chaque site pourrait-il être doté d'un appareil de fac-similé.
- Des consoles plus sophistiquées, en particulier des consoles graphiques, à raccorder via le réseau. Il faudrait un groupe de travail pour formuler et mettre au point un format de traitement des consoles sophistiquées. Il y aura une réunion sur le graphique en janvier dans le Colorado ou l'Utah. Le prix d'entrée est de rédiger une proposition. Je compte jusqu'à 30 personnes. Je choisirai un petit sous-ensemble pour élaborer les spécifications.
- Comptabilité - Au second semestre 1971, davantage de sites arriveront, où la comptabilité est importante. (Ils veulent envoyer des factures.) Larry Roberts dit qu'il y aura une sorte de système bancaire avec des factures qui circulent. Deux types de sites : les sites de facturation, et les sites de recherche à accès gratuit mais limité. Je ne vois pas de problèmes fondamentaux. Que se passe-t-il quand un site de recherche parle à un site de facturation ? Je pense que c'est faisable.
- Mesures - le réseau est un outil, mais c'est aussi un modèle meilleur qu'un progiciel de simulation. Diverses personnes veulent faire des mesures. Cela pourrait être soutenu en conservant des statistiques dans les NCP. Et si on augmentait les NCP pour les inclure ?
Long: Mettre la comptabilité et la mesure dans les NCP coûte de la place. Garder les ajouts au minimum.
Weissman: Et la disponibilité programmée des divers systèmes ?
Crocker: Cela doit être coordonné avec chaque système individuel
? : Que se passe-t-il avec les connexions quand un système tombe ?
Crocker: Et les propositions graphiques ? Je rédigerai mon propre article comme proposition. Il utilise le DEC 340 comme modèle. Modes suppose un système à écran et une mémoire. La sortie et l'entrée sont toutes deux incluses dans l'élaboration des normes. Je veux qu'un protocole compétent soit développé par le groupe de travail.
Crocker: Et la documentation ?
Meyer: La documentation sur l'utilisation des autres systèmes est indispensable. Elle seule peut motiver l'usage opérationnel du réseau.
--: Et si on mettait les documents en ligne sur chaque site, ou au moins les résumés.
Crocker: Quels sites ont des documents en ligne ? (MIT et Harvard) Que pensent les sites de conserver des documents sur un système étranger ?
Crocker: Et si on retravaillait le protocole ?
Harslem: Nous nous sommes connectés au système de l'UCSB et nous déboguons en coopération.
Harslem: Nous sommes impressionnés par l'élimination du marquage et du remplissage (selon le RFC 67).
Crocker: Nous en avons discuté avec les sites. La plupart semblaient l'accepter, mais avec quelques réserves. Et les changements au protocole de base ? Je crois que Meyer a quelque chose à dire.
Meyer: La position de Project MAC est qu'à ce stade nous sommes opposés à tout changement autre que les correctifs critiques. Le temps consacré aux changements est du temps qui ne sera pas consacré au développement d'autres protocoles et systèmes nécessaires et intéressants. Et nous, à Multics, avons un long délai de mise en œuvre pour la création et l'installation des changements.
Weissman: Je préfère introduire les changements en un seul bloc, disons à intervalles de 6 mois, plutôt qu'en petits morceaux.
O'Sullivan: Les systèmes actuels et nouveaux ne peuvent-ils pas fonctionner simultanément ?
Crocker: Si les changements concernent l'IMP, non, car tous les IMP veulent faire fonctionner le même système.
Meyer: Le sentiment au M.I.T. est que, pour réussir, le réseau a désespérément besoin d'être utilisé de façon opérationnelle. Si une autre année passe sans usage opérationnel significatif, il pourrait tomber à l'eau.
--: Et la documentation est essentielle pour motiver l'usage opérationnel.
Engelbart: Peut-être devrions-nous reporter le graphique de plusieurs mois afin de ne pas retarder les machines à écrire. Les machines à écrire sont importantes.
--: Mais serait-ce suffisamment impressionnant pour les gens du DOD ?
Engelbart: Mais si ça se révèle être un sac de nœuds dans deux ans...
--: Mais les deux groupes de développement (machines à écrire et graphique) interagissent-ils ?
Vezza et Engelbart: Oui.
Crocker: Écoutons-en davantage.
Harslem: Nous voulons pouvoir accéder aux fichiers.
Crocker: Alors peut-être l'effort graphique diluerait-il le développement des machines à écrire. Est-ce le consensus de ce groupe que nous ne devrions pas avoir de réunion sur le graphique ?
Vezza: Les nouveaux venus devraient travailler sur le graphique, pas les gens établis. Interdire aux personnes actuelles d'aller à cette réunion.
Meyer: Ce serait très frustrant.
Benjamin: Pourquoi ne pas solliciter des prises de position (mais sans tenir de réunion).
Weissman: La transmission de caractères est plus facile que la transmission graphique. Plus d'expériences nécessaires pour le graphique. Le délai de développement d'un protocole graphique est bien plus long que pour les machines à écrire.
Vezza: Je suis d'accord.
Crocker: Il y aura d'autres réunions dans les prochains jours pour travailler sur les problèmes consistant à faire passer du travail utile par le réseau.
Entracte
21 h 15
Crocker: Engelbart va parler du Network Information Center.
Engelbart: Le NIC s'est développé de façon ad hoc, sans directives précises de l'ARPA. Quels types de choses étaient envisagées ? (1) Des systèmes d'interrogation sophistiqués, (2) des informations de base sur les systèmes de chaque site. Tout le monde se sent très vulnérable quant à l'état de la documentation sur son propre site. Tout le monde est d'accord : de meilleurs documents sont nécessaires. Nous nous voyons comme fournissant les services suivants : 1) collecter de la copie papier ; 2) l'interrogation en ligne des catalogues et index correspondants ; 3) donner accès à ce matériel. Nous avons décidé d'opter pour la copie papier plutôt que pour le mode en ligne, peut-être sur microfiche.
Engelbart: Comme le 940 devait servir au système de documentation, extensible à mesure que l'usage augmente. Nous passons d'un 940 à un 10X pour mieux étendre la capacité de service. La quantité de capacité augmente considérablement. Cela a retardé le travail sur d'autres aspects. Un pari délibéré. Nous nous inquiétons de démarrer. Nous manquons de fonds pour davantage de stockage secondaire et sommes intéressés à utiliser d'autres hôtes pour le stockage tertiaire. Le coût d'implémentation du protocole sur le 940 était trop élevé pour les gains potentiels, alors il a été abandonné. Peu de sites seraient opérationnels d'ici janvier, quand notre 940 devait être expédié.
Engelbart: Nous avons créé un Network Dialogue System. C'est un réseau d'agents humains. À chaque site il y a : a) un agent de communication technique (secrétaire) et b) une personne de liaison technique. Nous encourageons les agents à nous parler et avons créé des numéros de téléphone « Enterprise » pour qu'ils puissent parler sans frais.
Engelbart: Nous envoyons d'abord un petit kit à chaque agent, une collection croissante d'informations de référence sur le réseau. Une personne (agent) à chaque site doit être formée pour gérer l'ensemble des documents et retrouver l'information ou contacter la personne de liaison technique d'un autre site. Cela implique un dialogue public, tenant un registre des documents qui circulent. C'est une sorte de réseau d'« IMP humains », structuré comme suit :
________________________________
| |
| ________________ |
| | local | | one
| | reference | | <== site ____________
| | material | | ( )
| -----------------| | ( )
| | => (____________)
| | || \\
| | || Other sites
| | || \\
| ________ | || ____________
| local =====> | |================ ( )
| users | agent |=====|===============( )
| =====> |________| | (____________)
| |
|________________________________|
- La collection maîtresse contient tout le matériel.
- Chaque collection locale possède un sous-ensemble jugé le plus utile.
--: Et restreindre l'accès aux documents ?
Engelbart: Tous les fichiers sont des fichiers publics dans ce système.
Vezza: Vous pouvez envoyer une note privée plutôt que d'utiliser le service du NIC.
Engelbart: La collection maîtresse contient des livres et d'autres documents. Catalogués en ligne. La copie papier peut être dupliquée. Pour l'information qui passe le test de valeur, le service consiste à stocker, cataloguer, indexer et donner accès aux documents. Nous prendrons en charge un certain nombre de terminaux différents. Nous sommes prêts à fonctionner longtemps avec des éléments en copie papier, mais pouvons mettre en place un service de transcription de la copie papier vers le format en ligne, contre paiement.
Weissman: Et distribuer des boules Selectric OCR aux sites ?
--: Le NIC prendra-t-il ce qu'on lui envoie ou ira-t-il activement le chercher ?
Engelbart: Plus ou moins ce qui nous parvient. Un système existera au printemps 1971, permettant à un agent d'insérer des éléments dans un catalogue. Le dialogue qui s'ensuit déterminera la façon dont la base de données se développe. Nous sommes à peu près sûrs qu'à terme le SRI devra facturer, en raison des nombreux utilisateurs potentiels hors sites primaires cherchant des ressources limitées.
--: Et un NCP pour votre 10X.
Engelbart: Si le NCP de BBN est prêt d'ici février 1971, nous l'utiliserons.
Crocker: Comment les gens y accèdent-ils ?
Engelbart: Chaque site est enregistré. Toute personne qui entre via le compte d'un site a son accès. Nous ne nous préoccuperons pas de la comptabilité avant que la saturation ne survienne. Nous aimerions encourager l'usage du système d'agents pour créer et utiliser un inventaire des ressources de chaque site. Un sous-groupe devrait en parler.
Crocker: Quand les gens peuvent-ils se réunir pour en discuter ? (Demain matin)
Engelbart: Nous avons de bonnes installations pour élaborer des listes de diffusion, des bibliographies privées, des profils de personnel, mais cela dépend de l'intérêt des gens du réseau.
Engelbart: Des agents ont été mis en place avec le MIT, l'UCLA, le RAND, l'UI, l'Utah, etc. Un bon pourcentage de sites
Vezza: Beaucoup de sites envoient des choses en 3e et 4e classe. Cela prend trop de temps.
Crocker: Rapport sur l'état des sites. L'ILLIAC IV ne sera pas opérationnel avant mi-71, sur le réseau plus tard (72 ?). Autres sites possibles : RADC, AWS, NCAR. Actuellement en service : UCSB, RAND. Imminents (janvier 71) : MIT BBN, Harvard, UCLA, Utah, LL, SDC. Un certain pourcentage d'ici la fin de l'année, le reste en janvier.
Heart: Un tout nouveau système IMP (changement majeur) est installé demain. D'autres sites envisagent de se raccorder. Le réseau croîtra considérablement au-delà de ce qui est déjà en place. Nous aussi sommes intéressés par l'information sur les ressources des sites. Pas d'intérêt à long terme, mais nous mettrons l'information sur papier pour aider l'ARPA.
Crocker: Beaucoup de gens baillent. Et le calendrier des réunions ? Pendant les FJCC ? Des réunions de 1 jour ou de 2 jours ? Et des réunions jumelées sur les côtes Est et Ouest ?
Fin de la réunion
Réunion sur le réseau
Mardi 17 novembre 1970, 9 h 15
Crocker: Engelbart parlera plus en détail. Plus tard, on pourra discuter du logger protocol et du transfert de fichiers.
Engelbart: L'élément de base est une collection de documents avec un catalogue pour la décrire. Une entrée comporte beaucoup d'éléments de données, y compris où la trouver. Des techniques pour ajouter et mettre à jour des entrées. Nous le faisons maintenant, mais voudrions en donner la capacité à d'autres sites, en partie parce que nous ne pouvons pas déterminer ce qui a de la valeur. (Affichage de 3 types de sortie imprimée.) 1) Liste du catalogue, par index ordinal dans la collection et index NIC, pour le contrôle des stocks, pour savoir ce qu'il y a. 2) Format compacté sur une ligne. 3) Trié par auteur - une ligne par entrée. Nous aurons des procédures où un utilisateur non formé peut gérer une collection.
Meyer: Comment ces systèmes sont-ils implémentés ?
Engelbart: Nous avons un compilateur de compilateurs sur le 940. Nos sous-systèmes sont écrits dans un langage de haut niveau spécialisé. Nous transférons cela vers le 10X.
Heart: Combien de personnes le 10X peut-il prendre en charge, en chiffres approximatifs ?
Engelbart: Peut-être 100-1000 collections.
--: Peut-être les gens pourraient-ils fournir leurs propres bandes DEC pour du stockage supplémentaire.
Engelbart: Possible, mais cela nécessite un opérateur sur site. Accès lent. Nous n'avons pas d'argent pour plus de stockage, mais envisageons d'expédier des fichiers vers l'UCSB. Nous fournissons l'interrogation en ligne de données en ligne. Prêts à nous soucier de la gestion des données, que nous les stockions ou non.
Crocker: Veuillez décrire les divers sous-systèmes. (Description par Engelbart ci-dessous.)
Heart: Les gens ont-ils essayé de l'utiliser via le réseau ?
Engelbart: Non. Nous n'avons pas de NCP sur le 940. Nous avons décidé de ne pas le mettre dans un système qui disparaît. Le plus gros blocage est le moment où le 10X aura un NCP. Bobrow le développe, mais cela prend du retard.
Heart: Qui va y accéder (au SRI) tôt ?
UI: L'Illinois ne peut accéder qu'au SRI pour commencer.
Postel, UCLA: Nous prévoyons de l'utiliser.
Heart: Ce serait une tâche importante si quelqu'un prenait comme objectif d'entrer dans le système d'Engelbart.
MITRE: Nous allons utiliser d'autres systèmes depuis le 10X de BBN.
Engelbart: Nous essayons d'isoler les sous-systèmes essentiels pour que les gens puissent les utiliser facilement. Les fichiers sont organisés hiérarchiquement et se rempliront au fil des années. Les documents sont référencés par des noms de chemin. (Discussion des systèmes ci-dessous.)
Crocker: Comment entre-t-on dans le système ? (Engelbart décrit la séquence d'entrée vers TOdas.)
Crocker: Comment s'inscrit-on sur le système ?
Engelbart: En fin de compte par entrée personnelle, mais actuellement il y a un identifiant d'utilisateur par site.
Meyer: Je pense que nous ignorons des problèmes non résolus dans l'interfaçage des machines à écrire. Par exemple, la séquence d'entrée vers TOdas, où l'utilisateur tape un ou deux caractères et le système tape le reste des caractères d'un mot-clé, sera frustrante à utiliser depuis un système half duplex comme Multics. Notre système ne reconnaîtra pas une ligne d'entrée tant qu'une nouvelle ligne n'est pas tapée.
Various: Discussion sur la communication 1/2 duplex. Met en évidence la distinction entre a) les systèmes full duplex où le système renvoie l'entrée, par rapport au 1/2 duplex où l'entrée est tapée localement, et b) les systèmes où chaque caractère est reconnu au fur et à mesure de sa frappe, par rapport aux systèmes où la ligne entière n'est reconnue qu'après le caractère EOL.
Crocker: Multics n'est-il pas le seul système half-duplex orienté ligne sur le réseau ?
Meyer: Je ne peux pas le croire. Les systèmes IBM ne fonctionnent-ils pas comme ça ?
Engelbart: Nous pourrions avoir une interface 1/2 duplex sur notre système (SRI). Est-ce le matériel Multics qui impose cette restriction ?
Meyer: Oui, le contrôleur d'entrée-sortie.*
* L'adaptateur de machine à écrire du contrôleur IO de Multics est 1/2 duplex, mais peut accepter des caractères de coupure autres que le caractère « new line ».
Engelbart: Chaque système devrait avoir un préprocesseur pour parler avec les autres systèmes. Nous allons mettre une interface graphique sur le réseau.
Meyer: Comment voyez-vous ces interfaces ? Adhèrent-elles à une norme de réseau, ou chaque système construira-t-il une interface vers vous ?
Engelbart: Protocole de réseau standard.
Crocker: Passons à autre chose.
O'Sullivan: Et les 2741 sur votre système 10X (CMU). Avez-vous de sérieux problèmes d'interfaçage ? (Les 2741 du CMU passent par un progiciel qui les transforme en TTY 37. Aucune difficulté sérieuse.)
Various: Brève discussion sur la façon dont Multics gère l'entrée.
Sundberg, HARVARD: Notre 10X peut accepter une entrée orientée caractère, mais nos sous-systèmes de plus haut niveau préfèrent une entrée orientée ligne.
--: Et l'efficacité de transmettre des messages à travers le réseau un caractère à la fois ?
Crocker: Il y a plus de sortie, qui passe en paquet, que d'entrée, donc l'inefficacité de l'entrée est négligeable.
Engelbart: Nous prévoyons plusieurs ports différents vers notre système. Si chaque système avait un module NIC, il pourrait communiquer avec nous sans nécessiter de login. Nous préférons un système de type batch, où un site envoie un lot de requêtes d'édition en spool, récupère les résultats, et libère les ports. Le problème de transmission des machines à écrire par ligne pourrait être traité de façon similaire à des requêtes mises en spool. Nous encourageons le spool, mais prendrons en charge les utilisateurs interactifs. Nous pouvons prendre en charge plus de personnes en batch qu'en interactif.
* L'adaptateur de machine à écrire du contrôleur IO de Multics est 1/2 duplex, mais peut accepter des caractères de coupure autres que le caractère « new line ».
Vezza: Les gens estiment-ils que la question full duplex / 1/2 duplex est un problème ? Que tout le monde rentre et se renseigne là-dessus. Le M.I.T., avec un système full et 1/2 duplex à 20 feet d'écart, peut aider ici.
O'Sullivan: Il semble y avoir 2 questions : (1) l'écho (full duplex) par rapport au 1/2 duplex. (2) la transmission caractère par caractère par rapport à la ligne entière.
Crocker: Deux définitions : hôte serveur - fournit le calcul ; hôte utilisateur - parasite, gère le terminal de l'utilisateur. Cela considère l'usage du réseau comme un lien entre l'utilisateur local et le serveur distant.
Vezza: Et l'interconnexion 1/2 duplex - full duplex si certains systèmes full duplex renvoient autre chose que ce qui a été saisi.
Crocker: Deux possibilités indépendantes. Faisons un schéma :
| "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: Je soutiens qu'il n'y a en réalité que deux possibilités (marquées par des X).
Postel: Et un système où l'écho est fait à un niveau si bas qu'il ne peut pas être supprimé.
Crocker: Si c'est le cas, c'est comme ne pas renvoyer l'écho.
Van Zoeren: Notre système pense que nous avons des TTY full duplex, mais nos 2741 sont raccordés via un boîtier de transformation logiciel.
Meyer: Que se passe-t-il quand des systèmes sans écho sont raccordés à des systèmes à écho via le réseau ? Je tape ma ligne d'entrée, puis le système à écho répond avec mon entrée, puis une certaine sortie. Mon système ne peut pas filtrer cela car il n'y a aucun moyen de différencier l'écho de la sortie.
Crocker: Ce n'est pas nécessairement une mauvaise chose. Je tape une abréviation de commande vers le SRI ; puis la ligne de sortie suivante est une forme développée de la commande saisie.
Meyer: Notre objectif devrait être un protocole commun unique plutôt qu'un tas de schémas bricolés pour mettre en œuvre la communication entre des paires d'hôtes spécifiques.
Long, SDC: Nous préférons recevoir une ligne complète acheminée à travers le réseau.
Crocker: Distinguons les centres de recherche et les centres de service. Seuls les centres de service sont concernés par une interface half-duplex. (X en bas à gauche sur le schéma). Ceux-ci incluent le SRI, le BBN, Multics.
O'Sullivan: Et le centre de recherche ?
Crocker: Ils peuvent appeler les centres de service, mais peuvent eux-mêmes être difficiles à utiliser.
Illinois: Alors l'ILLIAC IV devra être half-duplex.
Postel: Je pense que le half-duplex, orienté ligne, est plus faible (qu'un protocole full-duplex, orienté caractère).
Sundberg: Harvard peut aller dans les deux sens, mais préfère un système orienté ligne.
Engelbart: Les terminaux graphiques sont plus difficiles à mettre sur le réseau en raison d'une entrée non standard.
Harslem: Vous considérez les touches comme des touches de fonction plutôt que comme des touches d'entrée.
Engelbart: Je m'inquiète des gens qui veulent utiliser le graphique.
O'Sullivan: Nous n'avons pas abordé le problème du type de protocole à établir.
Crocker: Ce n'est pas une chose techniquement difficile. Nous y viendrons plus tard et prendrons une décision.
Meyer: Je ne suis autorisé à prendre aucune décision. Je dois faire un rapport au groupe MAC.
Crocker: D'accord. Alors, une proposition, à accepter par le mécanisme normal. Entracte
Crocker: Je vais proposer comment traiter les cases marquées d'un X, en ignorant les cases hard et ease :
Entrée orientée ligne - ascii 8 bits incluant le caractère End of Line :
n, C1,...,Cn;
Cn=EOL
120>n>>_1 n is the character count in an 8-bit field.
Le nombre de caractères précède la ligne afin de donner au système logiciel la même efficacité qu'au système matériel, l'ordinateur n'a pas à balayer pour trouver l'EOL.
Vezza: Ne recevez-vous pas l'information de longueur avec le message IMP ?
Crocker: Ma philosophie est que les frontières de message IMP devraient être complètement invisibles.
Long: Je m'oppose à scinder les messages de machine à écrire en deux morceaux distincts.
Crocker: Quelle est votre objection, 1) des lignes commençant sur des frontières de message ou 2) un message ne commençant pas sur une frontière de ligne ?
Long: Les deux.
Engelbart: Chaque hôte devrait écrire une interface pour gérer les types de terminaux les plus courants.
Crocker: Le protocole officiel n'autorise aucune signification aux frontières de message IMP.
Engelbart: Je ne veux pas me soucier des frontières de message IMP. Le réseau devrait être invisible (à ce niveau).
Vezza, Long: Nous cédons, nous suivrons.
Meyer: J'aimerais changer la restriction. Le dernier caractère du paquet de ligne n'a pas besoin d'être un EOL (comme lorsqu'une sortie ne passe pas à une nouvelle ligne), mais un EOL ne peut pas apparaître au milieu d'un paquet.
Van Zoeren: Cette restriction ne me plaît pas.
Meyer: Le compte nous dit que tout EOL est à la fin, nous n'avons pas besoin de balayer.
Crocker: L'EOL est le caractère qui dit au système de passer à l'action.
Harslem: Notre système a 46 touches de fonction, pas seulement un EOL.
Crocker: Et si C, E {breakset}; i=n. C'est plus complexe, car il faut transmettre un breakset. Je proposerai cela dans un moment. Et si : connexion orientée message (1/2 duplex)
entre les hôtes Utilisateur et Serveur pour l'interaction de console. Écho local, pas d'écho serveur. Ceci est pour les systèmes de service orientés ligne. Ce sont de légères généralisations des conventions Multics.
Meyer: Je suis sûr que d'autres systèmes que Multics l'utilisent. Ce n'est pas aussi mauvais que vous semblez le penser.
Engelbart: La direction supérieure devrait savoir que c'est mauvais.
Meyer: Ce n'est pas clair. Il y a des questions d'efficacité.
Van Zoeren: Je ne veux pas avoir à transmettre des fichiers de cette façon.
Crocker: C'est pour les consoles, pas pour la transmission de fichiers.
Engelbart: Nous avons besoin d'un schéma unifié pour la transmission de données.
O'Sullivan: (Pour les consoles) nous devons concevoir un moyen de dire à un système où son interruption devrait être simulée.
Crocker: Il y a un problème général de transmission de données pour les bandes et les fichiers.
O'Sullivan: Mais nous avons le problème spécifique de mettre en œuvre les communications de machine à écrire.
Engelbart: Mais ce dont nous avons besoin, c'est d'un moyen général d'envoyer des choses à travers le réseau (afin qu'il soit invisible) et que l'hôte l'interprète comme il le souhaite.
Meyer: Il devrait y avoir une seule interface de console pour le réseau, pas plusieurs sur chaque site.
Crocker: Ce problème est peut-être surestimé.
Engelbart, Meyer, O'Sullivan: Discussion sur la prise en charge de types de terminaux spécifiques.
Engelbart: Je vais tracer un graphique des systèmes en fonction du type de terminal. L'intersection d'un système et d'un terminal accepté par ce système est marquée par un point. Le problème de communication réseau consiste à trouver un terminal chez l'hôte local qui soit aussi pris en charge chez l'hôte cible.
_____|_____|_____|_____|_____
| | | |
systems_____|_____|_____._____|_____
| | | |
_____|_____._____|_____|_____
| | | |
_____|_____|_____|_____|_____
| | | |
terminals
Crocker: Il y a un problème général d'un sous-système qui réagit à l'entrée. Proposons que l'entrée soit envoyée comme un message complet ou en multiples de 8 bits.
Vezza: Nous contraignons trop ?
Meyer: Pourquoi est-il nécessaire d'avoir des multiples de 8 bits ?
Crocker, Engelbart: D'accord, laissons tomber ça.
Fin de la deuxième réunion
Réunion sur le réseau
Mercredi 18 novembre 1970, 20 h 20
(Les notes suivantes sont fortement condensées et ne tentent que de présenter les grands thèmes discutés lors de cette réunion.)
Crocker: Rencontrons-nous au SJCC avec davantage d'organisation préalable. Ayons plusieurs réunions de quelques jours à intervalles de 2-3 mois. Nous avons eu beaucoup de bonnes discussions sur le protocole de niveau suivant. Qu'un sous-groupe le mette au point.
(Harslem se porte volontaire pour remanier le logger protocol proposé dans le RFC 66. Meyer révisera la proposition du RFC 46.)
Meyer: Revenons en arrière, discutons de ces questions, rédigeons des propositions. Plus tard, nous aurons une réunion ouverte pour décider d'une proposition formelle.
Crocker: Un petit groupe est préférable, je choisirai peut-être un sous-ensemble.
Vezza: Il est vrai que les choses ne sont pas réglées ici. Les propositions majeures devraient être couchées sur papier avant une réunion. Nous ne pouvons pas légiférer sur ce que fait un petit groupe. Il n'a pas plus d'autorité qu'un individu.
(Karp du MITRE se porte volontaire pour produire une bibliographie des documents du réseau, peut-être d'ici janvier.)
(Qui a implémenté le logger protocol ? UCSB et UCLA mod 91 l'ont fait ou prévoient de le faire. Le SDC pourrait l'avoir d'ici 21/1, l'a trouvé malcommode, prêt à changer.)
(Discussion sur la transmission de fichiers. Crocker propose qu'un futur changement de protocole puisse attacher une taille d'octet telle que 8, 32, 36 bits à une connexion.)
(Concernant les liens de contrôle, tout est transmis en octets de 8 bits sauf les commandes ECO, ERP, ERR. Aucune objection n'a été exprimée au changement du protocole pour qu'elles aussi soient des multiples d'octets de 8 bits.)
(Discussion sur la façon de spécifier la fin d'un fichier. Transmission préalable du nombre de bits, ou envoi d'un caractère EOR à la fin ? Suggestion que nous voulons une solution globale au problème général d'envoyer un message de longueur arbitraire, plutôt que seulement la transmission de fichiers.)
(Discussion sur les « transaction units » ou tailles d'enregistrement. Quelle est la taille optimale d'une unité de transaction ? Les frontières de message IMP sont invisibles (par décret du protocole) et ne sont pas liées à cette discussion. La taille de bloc de Multics a été évoquée. Ce qui s'en rapproche le plus est la taille de page, 1024 mots.)
(Comment spécifier la fin de fichier. Engelbart dit d'envoyer des paquets de données, puis un paquet EOF. Crocker suggère que la fermeture de la connexion (CLS) peut faire office d'EOF. Vezza suggère que les frontières de message IMP soient utilisées pour déterminer la fin. Si c'est moins qu'un message IMP complet, c'est la dernière partie du fichier. Meyer suggère d'utiliser deux connexions, un canal de données et un canal de contrôle, sur lequel tous les messages de contrôle, tels que le nom de fichier, la longueur en bits, etc., sont transmis.)
(Discussion concernant différentes situations dans lesquelles on voulait le fichier entier, une partie du fichier, ou le fichier entier en morceaux arbitraires.)
Meyer: Pourquoi ne pas reporter cela, et parler des communications de machine à écrire, qui sont les plus critiques.
Vezza: Engelbart veut une solution générale propre.
Crocker: Si nous obtenons une solution ad hoc maintenant, elle pourrait gêner la mise en œuvre d'une solution générale plus tard.
(Crocker propose un format pour transmettre un fichier d'enregistrements de longueur arbitraire d'octets de taille fixe de 8-26 bits. Un enregistrement fait moins de 10^5 octets. Chaque enregistrement est précédé d'un octet de comptage.)
1 2 n 1 2 m
|----------------------------------------------------|
| n | | | | | m | | | | |
|----------------------------------------------------|
<------- record -----------> <-------- record ------->
O'Sullivan: Ce modèle convient-il à un terminal qui a des modes caractère et graphique ?
(Discussion sur les différences entre la transmission au clavier et la transmission de fichiers. Incertitude quant à savoir si une solution globale conviendrait aux deux.)
(Qui veut expédier des fichiers à travers le réseau ? Multics et 6-10, RAND vers UCLA, MITRE utilisant BBN.)
Crocker: Partons en réfléchissant à cela et proposons des solutions plus tard.
(Harslem propose un format pour transmettre des données avec des codes d'opération. Chaque enregistrement consiste en : <opcode> <length> <data>. Donne l'opportunité d'envoyer de nombreux types d'informations d'état.)
(Discussion concernant l'envoi de données et d'informations de contrôle mélangées ou sur des connexions séparées. Questions de pollution des données par rapport aux problèmes de synchronisation et de concurrence. Il est affirmé que les problèmes de synchronie sont facilement surmontés.)
(Suggestion que nous ne connaissons en réalité pas grand-chose à ce domaine. Nous devrions partir et écrire.)
Entracte
Crocker: Que faut-il faire avant de pouvoir se connecter aux autres systèmes ?
Meyer: 3 questions : 1) comment établir la connexion, 2) quel est le jeu de caractères, 3) quel est le mode de transmission (en lien avec le problème full duplex / 1/2 duplex).
(Discussion sur l'orientation du protocole standard vers les systèmes de service, qui sont généralement orientés ligne et 1/2 duplex. Tout système offrant des services doit avoir une interface 1/2 duplex.)
(Discussion sur la possibilité ou l'opportunité pour le logger protocol d'autoriser la transmission de lignes partielles dans un message IMP. Moins efficace de prendre des lignes partielles, raisonnable d'envoyer la ligne complète. Il est souligné que le protocole NCP n'attribue aucune signification aux frontières de message IMP, donc les systèmes doivent être prêts à accepter des lignes à cheval sur les frontières de message IMP. Cependant, il est préférable d'envoyer la ligne complète.)
(Discussion sur la question de savoir si le protocole orienté ligne devrait s'assouplir afin d'accepter la transmission caractère par caractère depuis les systèmes full duplex. Il semble que nous aboutissions à un protocole permettant à tout système d'utiliser un système orienté ligne. Utiliser un système orienté caractère depuis d'autres systèmes est plus difficile et nécessite un protocole séparé.)
Heart: Je suis favorable à une solution immédiate.
Postel: Une fois que quelque chose est en place, il sera difficile de le changer.
Crocker: Je pense que ces réunions se révéleront plus importantes que nous ne l'aurions jamais voulu. Je suis plus préoccupé par les effets à long terme que par la date de démarrage.
Van Zoeren: Si nous ne décidons pas, quelqu'un d'autre décidera de la mauvaise façon.
Note : Ce RFC a été mis sous forme lisible par machine pour être intégré aux archives RFC en ligne par Gottfried Janik 2/98.