Histoire des communications informatiques
James Pelkey (texte original en ligne)

Chapitre 1 Introduction
Chapitre 2 Arrière-plan (Dans lequel on retrouve le télégraphe et le télephone aux US... le modem ... le microprocesseur)
Chapitre 3 Communications de données : émergence 1956-1968
Chapitre 4 Réseautage : Vision et commutation de paquets 1959 - 1968
Chapitre 5 Communications de données : concurrence sur le marché 1969-1972
Chapitre 6 Réseautage : Arpanet 1969-1972
Chapitre 7 Communications de données : ordre du marché 1973-1979
Chapitre 8 Réseautage : Diffusion 1972-1979
Chapitre 9 Réseautage : Émergence 1979-1981
Chapitre 10 Réseautage : concurrence sur le marché 1981-1983
Chapitre 11 Normes : une institution habilitante 1979-1984
Chapitre 12 Réseaux : Ordre du marché : LAN 1983-1986
Chapitre 13 Communications de données : Adaptation 1979-1986
Chapitre 14 Interconnexion de réseaux : émergence 1985-1988

En tant que NMC, les responsabilités de l'UCLA allaient de la collaboration avec BBN pour garantir l'intégration des capacités de mesure nécessaires dans les IMP, à la surveillance et à l'analyse constantes du réseau une fois celui-ci opérationnel. Sachant que Roberts souhaitait étendre le nombre de sites connectés à Arpanet le plus rapidement possible, le plan du NMC prévoyait trois mois de tests avec les quatre premiers IMP avant l'extension du réseau. John Postel, un autre étudiant diplômé travaillant avec Estrin et Kleinrock sur la mesure des performances informatiques, se souvient :
Nous avons donc abandonné toutes ces idées concernant l'exploration de l'intérieur d'un autre ordinateur et avons commencé à réfléchir à la manière de mesurer les réseaux. Outre son rôle au sein du groupe définissant le logiciel hôte à hôte, Crocker a géré la préparation du site de l'UCLA. Le matériel nécessaire pour connecter leurs ordinateurs à l'IMP était une priorité absolue. Crocker a envisagé de faire appel à un prestataire externe pour réaliser la connexion, mais un devis de 19 000 $ et un délai de six mois l'ont incité à confier la tâche à Mike Wingfield, un étudiant diplômé, qui a réalisé un prototype fonctionnel en moins de six semaines pour 4 000 $. La première interface IMP était un " boîtier d'environ 30 cm de côté, peut-être un peu plus grand, et élégant ". Crocker a rapidement souhaité que tout le reste se déroule aussi facilement. Il se souvient :
Bon, on avait un petit souci avec le logiciel. Rien d'étonnant, vu qu'on préparait notre logiciel, et je savais que BBN avait des difficultés avec un petit problème de synchronisation au niveau des IMP et qu'ils étaient vraiment inquiets de ne pas pouvoir respecter les délais. J'ai regardé le calendrier et je me suis dit : " Bon, le 1er septembre, c'est la Fête du Travail. Pas de problème, c'est férié, c'est un lundi. " Du coup, j'ai raisonné comme ça : " Premièrement, BBN est en retard. Deuxièmement, le 1er septembre est férié, donc ça va encore bouger un peu. Ils vont nous l'expédier et Honeywell viendra essayer de faire fonctionner la machine, puis BBN enverra une équipe pour voir s'ils peuvent faire fonctionner leur logiciel en plus. J'ai donc au moins deux semaines de marge. " BBN a résolu son problème, a regardé le calendrier et a dit : " On ne ratera pas la première date. " " On l'a transporté par avion ", et il s'est retrouvé sur notre quai de chargement un samedi, fin août. Le jour même, quelqu'un est arrivé, l'a mis à l'intérieur, l'a branché, et le programme a continué de tourner là où il s'était arrêté. Ils avaient un IMP fonctionnel. Du coup, toutes les raisons qui me faisaient croire que j'avais deux semaines se sont réduites à deux jours environ. Et voilà. C'était une journée catastrophique. C'était en septembre 1969.

Kleinrock se souvient également de l'arrivée opportune de leur IMP :
Il faut reconnaître à BBN le mérite d'avoir réussi à connecter tout ça, et dès le premier jour, on avait des données qui circulaient. Le lendemain, je crois que les paquets circulaient et que les messages fonctionnaient. Ça a marché, et ce satané truc a fonctionné !

Un cap important, qui semblait encore hors de portée quelques semaines auparavant, a été franchi. BBN a livré le deuxième IMP à SRI début octobre, et l'UCSB et l'Université de l'Utah ont reçu les leurs en novembre et décembre, respectivement.

6.4 Changements dans la gestion de l'IPTO - 1969
En septembre 1969, alors que le projet semblait prendre son envol, Taylor démissionna de l'IPTO. Comme Taylor l'avait orchestré, Roberts lui succéda à la direction. La transition se fit sans heurt, Roberts ayant déjà assumé la plupart de ses nouvelles responsabilités. Cependant, chaque nouvelle tâche l'obligeait à dégager du temps pour Arpanet. Sa solution : déléguer une partie du travail à Wessler et augmenter son propre volume horaire. Une personne moins compétente, moins impliquée ou moins capable de supporter un tel rythme aurait dû renoncer à s'impliquer activement dans Arpanet. Mais pas Roberts. En réalité, l'autorité et le pouvoir budgétaire accrus liés à sa nouvelle fonction lui donnèrent encore plus d'influence pour obtenir l'attention et la coopération des sites connectés à Arpanet - un atout qui allait s'avérer crucial pour que Roberts fasse d'Arpanet non seulement un réseau opérationnel, mais aussi un élément indispensable au sein de la communauté ARPA

6.5 Logiciels hôte à hôte - 1970
Le groupe d'échange de sites a continué de s'agrandir à mesure que de plus en plus de sites prenaient au sérieux la connexion à l'Arpanet.
Tandis qu'un noyau dur d'étudiants de troisième cycle et d'informaticiens se réunissait irrégulièrement, près d'une centaine de participants assistaient aux réunions bisannuelles organisées sur les côtes est et ouest. Ces réunions étaient marquées par de vifs débats, parfois si passionnés que le seul moyen de se faire entendre était de couvrir les objections des autres, les membres s'efforçant de comprendre ce qu'ils faisaient et ne faisaient pas. Il n'y avait pas de réponses et même les questions restaient parfois difficiles à formuler clairement.
Crocker se souvient :
Nous souhaitions une plateforme générique, mais nous ne savions pas vraiment comment y parvenir. Nous étions en difficulté, et la première conception que nous avons élaborée, sous la pression croissante, était une solution spécialisée permettant de se connecter d'un endroit à un autre, mais c'était à peu près tout.
La tension au sein du groupe de travail sur les communications hôte à hôte, entre la création d'un logiciel fonctionnel et le désir de réaliser quelque chose d'exceptionnel, transparaît dans la RFC 1000 de 1969 : " Face à la pression d'obtenir un résultat fonctionnel et à la confusion générale quant à la manière d'atteindre la grande généralité à laquelle nous aspirions tous, nous avons préféré tergiverser et définir un premier ensemble de protocoles ne prenant en charge que les terminaux distants et le transfert de fichiers. Plus précisément, seules les relations asymétriques utilisateur-serveur étaient prises en charge. " Le groupe de travail s'était donc contenté de connecter des terminaux distants à des ordinateurs et de transférer des fichiers - la même application qui avait frustré Roberts lors de son expérience de 1966 aux laboratoires Lincoln.

Le 21 novembre, lors de la première démonstration du logiciel de protocole par le groupe hôte-à-hôte de l'UCLA, Roberts et Wessler ne cachèrent pas leur déception. Il savait que pour convaincre les sites réticents d'étendre le réseau, il faudrait davantage de fonctionnalités que la simple connexion aux ordinateurs d'autres sites, notamment pour ceux qui en possédaient déjà. La connexion à distance n'était pas une application suffisamment convaincante. Il devait créer un sentiment d'urgence et fixer des objectifs plus ambitieux pour que le réseau devienne réalité.

Début décembre 1969, Roberts rencontra le groupe d'intervention hôte à hôte dans l'Utah et exprima son mécontentement quant aux résultats obtenus, les incitant à adopter une approche plus offensive. (Extrait du RFC 1000)
Larry nous a clairement fait comprendre que notre première étape était insuffisante, et nous avons dû revoir notre copie. Au cours des mois suivants, nous avons conçu un protocole symétrique hôte-à-hôte et défini une implémentation abstraite de ce protocole, appelée Programme de contrôle réseau (NCP). (" NCP " a ensuite été utilisé pour désigner le protocole, mais il désignait à l'origine le programme du système d'exploitation qui gérait les connexions. Le protocole lui-même était alors simplement appelé protocole hôte-à-hôte.) Outre ce protocole hôte-à-hôte de base, nous avons également envisagé une hiérarchie de protocoles, avec Telnet, FTP et quelques protocoles dérivés comme premiers exemples. (Voir le schéma 6.5.0 : Relations hiérarchiques des protocoles Arpanet.)

Diagramme 6.5.0 Relations hiérarchisées des protocoles Arpanet.

" Crocker se souvient du problème que posait le modèle maître/esclave des communications informatiques et de la nécessité d'une architecture en couches :
L'une des difficultés majeures résidait dans le fait que, jusqu'alors, la conception d'un système d'exploitation informatique reposait implicitement sur l'idée que le système d'exploitation était au centre du système et que tout périphérique connecté à l'ordinateur était un périphérique esclave. On pouvait connecter des bandes magnétiques, des disques, des lecteurs de cartes, des imprimantes, etc., mais l'initiative revenait à l'ordinateur, qui décidait quand communiquer avec ces périphériques et quand écouter. Si l'on tentait de connecter deux ordinateurs, ils ne pouvaient communiquer que comme si l'un était le maître. Or, si l'un était le maître, l'autre était forcément l'esclave. Nous aspirions à une vision beaucoup plus flexible, où l'initiative pourrait se trouver indifféremment de part et d'autre, et où un modèle de communication coordonné et coopératif serait mis en place. Cependant, les applications qui viennent immédiatement à l'esprit, comme la connexion à distance, le déplacement de fichiers ou la saisie de tâches à distance, restent toutes soumises au modèle maître/esclave. Nous souhaitions qu'il s'agisse de cas particuliers, et non des seules possibilités. Nous savions donc qu'en intégrant ces éléments à notre modèle de base, les projets plus ambitieux se heurteraient toujours à ces limitations : la possibilité de télécharger un programme, ou de faire d'une machine un substitut d'une autre. Un système de communication interprocessus générique était donc indispensable, sur lequel on pouvait ensuite construire les autres éléments.
Nous savions qu'il nous fallait des couches, mais leur nombre importait peu. En réalité, les éléments étaient construits les uns sur les autres, avec un minimum d'engagement à un certain niveau, sur lequel on pouvait ensuite construire. C'est ainsi que toutes les idées avancées concernant la coopération entre ordinateurs pour diverses tâches ont pu être mises en œuvre. À cette époque, au lieu de considérer le réseau comme un simple système de messagerie électronique, ce qui était en quelque sorte une idée secondaire, on envisageait des bases de données partagées, l'équilibrage de charge, ou encore le transfert de tâches d'une machine à l'autre ".

Au début de 1970, le groupe d'échange informel (initialement composé de quelques étudiants de troisième cycle discutant librement des possibilités d'utilisation d'Arpanet) s'était transformé en un réseau de plus d'une centaine de participants confrontés à la nécessité de rendre Arpanet fonctionnel sans perpétuer des modes de communication informatique qui entravaient l'avenir par les contraintes du passé. La nécessité d'une plus grande formalisation impliquait la reconnaissance de l'importance de ce groupe d'échange informel. Cela a conduit à un changement de nom : le Réseau de travail (NWG).
L'implication de Robert Metcalfe auprès du NWG en 1970 témoigne de la prise de conscience croissante de l'importance d'Arpanet. Metcalfe, doctorant à Harvard à la recherche d'un sujet de thèse et d'un emploi pour subvenir à ses besoins, s'est vu proposer par un ami du projet MAC du MIT un poste axé sur la conception de mémoire ou la connexion d'ordinateurs à Arpanet. Ayant entendu dire que les réseaux étaient un domaine en plein essor, l'ARPA y investissant massivement, Metcalfe se souvient : J'ai dit : " Réseau ", mais je ne savais pas ce qu'était un réseau. Je n'en avais aucune idée !
Metcalfe apprit alors qu'ARPA avait octroyé des fonds à Harvard pour connecter son PDP-10 à l'Arpanet, mais que l'université ne disposait d'aucune personne pour réaliser le projet. Metcalfe affirma pouvoir s'en charger, mais Harvard hésitait à confier la tâche à un étudiant de troisième cycle aussi enthousiaste. Loin de se décourager, Metcalfe imagina une solution ingénieuse :
Je suis retourné au MIT et j'ai négocié un accord. J'ai obtenu leur accord : en tant qu'employé du MIT, je connecterais leur PDP10 au réseau et le MIT fournirait à Harvard une copie de mon logiciel. Je suis retourné à Harvard et j'ai dit : " J'ai une super affaire pour vous ! "
Harvard refusa de nouveau et confia le projet à BBN, qui le confia à son tour à un autre étudiant diplômé de Harvard. L'indomptable Metcalfe commença alors à assister aux réunions entre les deux établissements en tant que représentant du MIT. Il se souvient :
Le laboratoire de recherche informatique avait besoin de quelqu'un pour développer le logiciel réseau de son nœud. Ils m'ont donc demandé : " Ça te dirait de t'en charger ? " J'ai répondu : " D'accord. " Et j'ai commencé à assister aux réunions animées par Steve Crocker.

6.6 Topologie du réseau - 1969-1970
Durant l'été et l'automne 1969, Roberts s'est confronté au problème de la topologie du réseau : l'interconnexion des nœuds, ou sites. Fort de son expérience auprès des compagnies de téléphone, il savait qu'il devait commander les lignes de communication bien à l'avance. Il a donc commencé à simuler des topologies de réseau sur ordinateur et a rapidement compris qu'il avait besoin de l'aide d'un expert.

Pièce 6.5.0 Croquis préliminaire de Larry Roberts sur la topologie d'Arpanet

Roberts s'est tourné vers le Dr Howard (Howie) Frank. Frank avait fondé Network Analysis Corporation (NAC), une entreprise spécialisée dans la conception topologique, s'appuyant sur ses travaux novateurs menés au sein de l'Office of Emergency Preparedness (OEP). Frank se souvient de l'appel de Roberts demandant une réunion :
Arpanet était un réseau à quatre nœuds. C'était tout. Il avait une feuille de papier millimétré sur son bureau et me montrait les extensions du réseau. À l'époque, il était déployé sur la côte ouest. Mais il n'y avait rien sur la côte est. Il devait commander des lignes de communication et il m'a dit : " Je ne sais pas ce que je fais. Je ne fais que tracer ces lignes. Pourriez-vous trouver une meilleure solution ? " Alors, nous lui avons rédigé une proposition et notre contrat a débuté en octobre 1969. Larry avait une date limite. Une vraie date limite. Il a dit : " Je peux annuler les commandes jusqu'à cette date. " Nous avons analysé la configuration qu'il nous avait fournie et nous avons développé les toutes premières techniques de conception de systèmes informatiques distribués, qui étaient primitives comparées à celles que nous avons développées par la suite. Je dirais qu'en deux ou trois mois - pas plus - nous sommes revenus avec une conception environ 25 % moins chère et offrant un débit supérieur de 40 % à celle qu'il avait proposée. Nous avons travaillé comme des forcenés car c'était vraiment un projet difficile.

Frank et Kleinrock partageaient un intérêt pour la conception de réseaux, bien que chacun abordât le problème sous un angle différent. Quelques mois avant d'obtenir son doctorat à Northwestern, un camarade de classe dit à Frank : " Ta thèse est à la librairie. " Frank se souvient :
Je me suis précipité à la librairie et j'y ai trouvé une monographie de Len intitulée " Sur les réseaux de communication, le flux de messages stochastique et le délai ". Ma thèse s'intitulait " Sur les graphes probabilistes de certaines applications ". Je l'ai donc ouverte et l'ai parcourue pendant trois minutes, pour me rendre compte qu'elle n'avait rien à voir avec mes recherches. Le domaine était le même, certes, mais il s'intéressait aux files d'attente et aux réseaux, tandis que je me penchais sur l'existence même des structures fondamentales. En substance, il injectait du trafic et observait son comportement. Je disais : " Il existe une incertitude sous-jacente au réseau lui-même. " Kleinrock utilisait des termes comme " capacité ", mais en réalité, ce n'est pas une quantité déterministe. Les liens peuvent être absents pour des raisons de fiabilité ou de vulnérabilité. Ils peuvent être attaqués ou les nœuds peuvent être introuvables. Or, je m'intéressais au phénomène fondamental de la connectivité : comment parler de connectivité lorsque les éléments sont incertains ?

En 1966, Frank rédigea un article inspiré par celui de Baran, " On Distributed Communications ", et par un article du Journal of Mathematical Biophysics portant sur les effets des radiations sur les cellules humaines. Constatant les similitudes entre les réseaux perturbés par un bombardement nucléaire et ceux de Baran, Frank développa une série d'équations reproduisant par simulation l'ensemble des résultats obtenus par Baran. Cet article, intitulé " Vulnerability of Communication Networks ", paru dans les IEEE Transactions on Communication Technology en 1967, lui valut un poste à l'Office of Emergency Planning (OEP). Il y analysait le processus d'approbation des demandes de permis pour le pipeline du golfe du Mexique par la Federal Power Commission et développa de nouvelles techniques qui s'avérèrent précieuses pour l'extension du réseau Arpanet.

6.7 Centre de mesure du réseau - 1969-1970
En décembre 1969, une fois les quatre modules IMP installés, le Centre de Mesure du Réseau (NMC), sous la direction de Kleinrock, commença à générer des configurations de trafic de données anormales à l'aide de générateurs de trafic artificiels intégrés aux modules IMP et aux hôtes, afin de saturer le sous-réseau et de le rendre inopérant. Cette initiative mit le NMC en conflit direct avec BBN, car ce dernier devait résoudre les problèmes. Kahn, de BBN, nourrissait également des inquiétudes, notamment concernant les risques de blocage, lorsque le réseau se figeait complètement. En décembre, il se rendit au NMC et se souvient :
Le tout premier test que j'ai réalisé sur le réseau était un test d'interblocage. Nous avons réussi à le bloquer. Dave Walden a collaboré avec moi sur l'expérience et a pu en être témoin. Je crois qu'il a fallu six mois avant que les autres ne commencent progressivement à en comprendre les implications.
C'était une période très frustrante, car malgré les résultats, je ne parvenais à transmettre cette idée à personne.
C'est à cette époque qu'est née une amitié durable, tant professionnelle que personnelle, entre Kahn et Cerf. Cerf se souvient :
L'ensemble du système était en grande partie l'œuvre de Bob, et il est venu à l'UCLA pour tester concrètement ses performances. Il avait des théories sur les points faibles du système, théories qui ne faisaient pas l'unanimité, mais il était déterminé à prouver ces points faibles en générant du trafic à l'UCLA et en le forçant à traverser ce réseau à quatre nœuds de diverses manières. Nous avons donc travaillé ensemble : je développais le logiciel de génération et de mesure du trafic, et il concevait les expériences à mener pendant trois ou quatre semaines à l'UCLA. Cette collaboration se poursuit encore aujourd'hui !
À bien des égards, BBN est devenu le nouveau AT&T, semblant indifférent aux utilisateurs du réseau. Mais du point de vue de BBN, l'objectif restait de satisfaire son client, Roberts, et de garantir un réseau fonctionnel. Il ne s'agissait pas de se préoccuper du moindre problème découlant de tests réseau poussés à l'extrême. Kleinrock se souvient avoir dit à BBN :
Au début, lorsqu'ils ont présenté leur proposition, nous avons examiné leur algorithme de routage, qui nous intéressait beaucoup, et nous avons dit : " Il y a des boucles. Un paquet peut faire des allers-retours, ou tourner en rond. " Ils ont répondu : " Non, il n'y a pas de boucles. " Mais il y en a ! Ils ont insisté : " Non. " . Alors nous leur avons fait une simulation et nous leur avons dit : " Regardez, il y a des boucles. " Ils ont rétorqué : " Il n'y a pas de boucles. " Puis, nous avons implémenté ce réseau à quatre nœuds et nous leur avons montré les boucles ; la réponse fut : " Si, il y a des boucles. "
Ces premiers travaux ont permis de mieux comprendre le comportement phénoménologique des réseaux. Kleinrock explique :
Donnez-moi un réseau et je peux analyser ses performances très simplement. Nous avons développé des formules mathématiques exactes ainsi que des approximations pour comprendre les réseaux. Nous avons également prouvé l'importance cruciale de la mesure. Nous avons pu mettre en évidence les blocages et les dégradations de performances, et en expliquer les causes. Nous avons constaté que le contrôle de flux était un point clé. Par exemple, les problèmes de séquencement, c'est-à-dire le maintien de l'ordre des opérations, provoquent des blocages. Le rôle du contrôle de flux est d'assurer la fluidité des opérations. Pour ce faire, on met en place des mécanismes de contrôle. Ces mécanismes sont appelés contraintes. Si le réseau ne peut pas respecter une contrainte, il plante.
Ainsi, ce qui est censé aider peut aussi être fatal, ou dégrader les performances. Nous disposions d'un catalogue complet de dégradations et de blocages que BBN a finalement corrigés. Ces problèmes sont encore présents dans tous les réseaux actuels.
Malgré des problèmes persistants et des divergences d'opinions, le réseau fonctionnait.
En juin 1970, il comprenait le SDC et la RAND sur la côte ouest, ainsi que le BBN, le MIT et Harvard sur la côte est. Parallèlement, les tests de performance du réseau continuaient de révéler des problèmes, dont la plupart seraient corrigés, y compris certains considérés comme insolubles.
(Fin 1971, il est devenu évident que le système de contrôle de flux rencontrait de graves problèmes. BBN s'est alors attelé à la conception d'un nouveau système).
Mi-1972, le système révisé était prêt à être installé après avoir subi des tests approfondis en laboratoire sur un réseau à petite échelle (3 à 4 nœuds). " Étude de gestion ARPANET par Cabledata Associates, Inc., janvier 1974, p. 9
À la mi-1970 , une version rudimentaire du Centre de contrôle du réseau fut mise en place au BBN. (Rapport final d'ARPANET, p. III-55) .
Quatre nœuds supplémentaires furent ajoutés avant la fin de l'année : Stanford, Lincoln Labs, Carnegie Mellon et Case Western.

6.8 Premières surprises - 1969-1970
De grandes promesses, des fonctionnalités modestes et d'agréables surprises ont marqué les débuts d'Arpanet.
La vision d'un calcul distribué où utilisateurs et programmes exploiteraient de multiples ressources distribuées et simultanées, qu'il s'agisse d'autres programmes ou simplement de cycles de calcul, est restée une simple promesse. L'absence de protocoles de communication entre hôtes, fondements sur lesquels devaient reposer les fonctions de haut niveau du calcul distribué, limitait les fonctionnalités du réseau. De fait, la seule application concrète demeurait une version primitive de la connexion à distance. Bien qu'instructive, cette connexion à distance ne constituait pas une avancée majeure. Malgré tout, les premières surprises ont démontré la valeur du réseau.
La première surprise fut la possibilité pour un utilisateur de basculer entre les connexions de terminaux d'ordinateurs locaux connectés à l'IMP par simple commande. La majeure partie du trafic des terminaux restait au sein des IMP hôtes, sans jamais accéder au sous-réseau. (Voir le schéma 4.5 - Trafic intra-IMP.) Cette facilité de basculement entre les connexions de terminaux d'ordinateurs locaux représentait un avantage considérable pour ceux qui avaient besoin d'accéder à plusieurs ordinateurs et préfigurait le besoin qui, une décennie plus tard, donnerait naissance aux réseaux.

Diagramme 6.8.0 - Trafic intra-IMP

Une autre surprise fut que les utilisateurs du réseau ne se soient pas plaints du manque de fonctionnalités ; car c'était tout ce qu'ils souhaitaient : un accès terminal aux ordinateurs distants. Roberts se souvient :
Au départ, je m'attendais à ce que le trafic se fasse d'ordinateur à ordinateur : transfert et utilisation à distance de logiciels, interaction entre machines - les utilisateurs travaillant sur leur propre machine et ayant besoin d'une autre machine pour certaines tâches. Mais il s'est avéré que la plupart des gens utilisaient simplement le réseau comme un terminal individuel sur l'autre machine, faisant office de terminal distant.
Le concept d'informatique distribuée était encore à venir à bien des égards, et le besoin immédiat était un système de communication bien plus performant pour permettre aux utilisateurs d'accéder à leurs ordinateurs distants.
Le simple fait de fournir un accès terminal à l'Arpanet a motivé l'innovation d'un second type d'IMP : le processeur d'interface terminal (TIP). (Voir le schéma 4.6 : Le processeur d'interface terminal.) L'avantage des TIP résidait dans la possibilité pour les terminaux de se connecter directement au réseau, sans avoir à passer par les ports d'un ordinateur. Les ports des ordinateurs étant limités et coûteux, leur monopolisation par des terminaux nécessitant uniquement une connexion réseau représentait un gaspillage. Une fois disponibles, les TIP ont permis aux sites dépourvus d'ordinateurs d'accéder à l'Arpanet.

Diagramme 6.8.1 Le processeur d'interface terminal


BBN a obtenu le contrat de développement d'un TIP au milieu de l'année 1970 et a livré le premier TIP en août 1971. Kahn se souvient :
Le TIP était une révolution, car soudain, on se retrouvait avec un IMP, et la question était de savoir comment y connecter tous ces terminaux. En réalité, ce que nous avons fait à l'époque était une erreur, dictée par les contraintes économiques. Les premiers IMP utilisaient 16 Ko de mémoire. Or, on pouvait en intégrer 32 Ko. Nous avons donc utilisé les 16 Ko inférieurs pour l'IMP et les 16 Ko supérieurs pour le TIP. Le TIP était un IMP doté, en entrée, d'un multiplexeur permettant de gérer tous ces terminaux et de les charger en mémoire. Voilà en quoi consistait le TIP : un ensemble de logiciels écrits dans 16 Ko de mémoire, plus ce multiplexeur que nous appelions alors contrôleur multiligne ; il avait été conçu par Severo Ornstein. Le TIP permettait de connecter jusqu'à soixante-trois terminaux au réseau. Grâce au TIP, l'ARPANET a pris son essor.

La plus grande surprise, et de loin, fut cependant le courrier électronique. Si Roberts était convaincu que le courrier électronique deviendrait une application réseau importante, il n'apparaissait dans aucun des cahiers des charges initiaux, et la plupart admettent avoir été totalement surpris. Kahn se souvient :
Le trafic de messagerie électronique était prédominant. On a beaucoup expérimenté au début, en déplaçant des graphiques. Mais en termes de nombre total d'actions effectuées, l'activité liée à la messagerie électronique était probablement plus importante, même si certaines autres activités ont sans doute transmis davantage de données.
Au départ, le courrier électronique consistait simplement en un message d'une personne à une autre. Mais avec l'essor de son utilisation, le besoin de fonctionnalités supplémentaires a nécessité des innovations. Roberts a codé l'une des premières améliorations : une " astuce TECO " permettant à l'utilisateur de choisir le message à lire au lieu d'être contraint de les lire dans l'ordre de réception. (TECO (Text Editor and Corrector) était un ancien langage d'édition. Le terme " astuce " désigne un logiciel innovant, mais peu maintenu, et est généralement employé avec respect.)
Dan Lynch, qui deviendra important plus tard, affirme que Ray Tomlinson et Dan Murphy, tous deux de BBN et auteurs de TENEX, ont écrit le programme Email original.
Tomlinson et Murphy ont créé Email parce qu'ils disposaient d'un PDP10 pour développer TENEX. Ils n'avaient qu'une seule machine, un gros engin, vous imaginez ? Deux gars, une seule machine, et ils travaillaient par roulement, douze heures par jour. Douze heures de travail, douze heures de repos, parfois en même temps, parfois non. Dès que leur système de fichiers a été suffisamment stable, ils ont commencé à s'écrire des notes et à les enregistrer sur le disque : " J'ai fait ça. Ça fonctionne maintenant. " . De petits messages échangés qui conservaient l'historique. Quand ils ont dû interfacer le système avec Arpanet, ils se sont dit : " Allez, faisons-le pour que ça fonctionne d'une machine à l'autre. " Ils ont franchi le pas car ils développaient aussi le code réseau.
Le courrier électronique a instauré un nouveau mode d'interaction et de communication : pratique, il pouvait être envoyé par l'expéditeur et consulté par le destinataire à sa convenance, et l'on n'était pas obligé de répondre immédiatement à un message, mais pouvait prendre le temps de la réflexion. Dès ses débuts, le courrier électronique a été un mode de communication informel. Personne ne se souciait des fautes de frappe ni de la structure. Seuls les messages courts et concis primaient.
Ainsi, même si Arpanet ne représentait pas initialement le nouveau paradigme de l'informatique distribuée envisagé par Roberts, il a permis la création d'une communauté numérique d'informaticiens et, avec le temps, d'autres utilisateurs, et, plus important encore, il a prouvé que la commutation de paquets fonctionnait.

6.9 Logiciel hôte à hôte : Le programme de contrôle de réseau - 1970-1971
Le calcul distribué sur l'Arpanet nécessitait que les protocoles de communication soient créés par un NWG très engorgé.
La réunion du NWG de mars 1970 à l'UCLA s'ouvrit sur une présentation des protocoles de communication hôte à hôte et mit en lumière la question cruciale de la transmission d'une connexion d'un ordinateur à un autre. Un débat animé s'ensuivit. Crocker et les membres du NWG, qui participaient aux réunions depuis deux ans, étaient partisans du calcul distribué : les processus ou programmes exécutés sur un ordinateur devaient pouvoir transmettre automatiquement les connexions à un autre. Un ordinateur pouvait servir de centre d'authentification, par exemple, pour effectuer l'authentification et la sécurité avant d'autoriser l'accès au système. Une fois authentifiés, l'ordinateur d'authentification connecterait instantanément les utilisateurs à l'ordinateur demandé. Bien que cela puisse paraître simple, dans un réseau composé d'un grand nombre d'ordinateurs et d'utilisateurs, garantir des connexions sans erreur représentait une complexité considérable.
Crocker avait fondé sa réflexion sur sa compréhension du système d'exploitation Multics développé au MIT et pensait que la présence d'experts Multics à la réunion faciliterait les échanges. Crocker se souvient :
Cette fonctionnalité de reconnexion a suscité beaucoup de controverses, car elle était plus complexe que le reste du protocole. Il y a eu des résistances, et, étonnamment, les équipes de Multics se sont montrées les plus réticentes. Elles affirmaient que nous ne pouvions pas implémenter de telles choses, arguant que nombre d'idées du protocole que je considérais comme inspirées de Multics - dont nous avions en quelque sorte pris Multics comme modèle pour ce que devait être un véritable ordinateur polyvalent et multi-utilisateurs - étaient trop complexes.
En fin de compte, des problèmes pragmatiques se sont posés quant aux autorisations de programmation au sein du groupe Multics, et les personnes affectées au NWG se sont trouvées exclues des niveaux inférieurs.
L'incertitude institutionnelle ressentie par les membres du NWG quant à leur rôle et leur autorité a compliqué la création des protocoles hôte à hôte, notamment pour Crocker dont le rôle n'avait pas encore été officiellement reconnu. Crocker hésitait à soulever ces questions auprès de Roberts, conscient de son statut d'étudiant diplômé. Il estimait que Roberts avait des priorités plus importantes. Comble de confusion, Crocker pensait être sous la responsabilité de Kleinrock. Mais comme les problèmes du NWG ne relevaient pas de Kleinrock, et que ce dernier avait d'autres priorités urgentes, Crocker est resté largement sans encadrement. Ce manque de responsabilité hiérarchique a exacerbé la tendance d'un ingénieur inexpérimenté et créatif à rechercher une meilleure solution au détriment de la réalisation de la tâche, et Crocker n'a pas fait exception. À cette structure formelle ambiguë s'est opposée la résistance des sites ARPA à l'ensemble du projet.
Une réunion cruciale du NWG à Atlantic City en mai 1970 n'a guère contribué à dissiper les incertitudes au sein du groupe. Crocker a demandé à Roberts quel était le caractère officiel du NWG et quel était son rôle. Crocker se souvient que Roberts lui a répondu devant tout le monde : " Bon, quel est votre problème ? C'est vous le chef. " Une résolution de problème à la ARPA.
Parallèlement, les documents présentés lors de la réunion ont révélé la profondeur et l'innovation des réflexions qui se développaient au sein du groupe. Ces présentations comprenaient :
" Développement de réseaux informatiques pour le partage des ressources : Roberts et Wessler
" Le processeur de messages d'interface pour le réseau informatique ARPA : Heart, Kahn, Ornstein, Crowther et Walden
" Méthodes analytiques et de simulation dans la conception de réseaux informatiques : Kleinrock
" Considérations topologiques dans la conception du réseau informatique ARPA : Frank, Frisch et Chou
" Protocole de communication hôte-hôte dans le réseau ARPA : Carr, Crocker et Cerf
Crocker se souvient :
Je me souviens que Frank Heart avait présenté un schéma qui illustrait en quelque sorte le spectre du problème : les protocoles de communication hôte à hôte étaient représentés par une fine bande à une extrémité, et les communications de données, les lignes téléphoniques longue distance, par l'autre. Les protocoles IMP résolvaient ce problème situé précisément au milieu. Je me souviens l'avoir regardé et m'être dit : " Voilà votre point de vue. " De mon point de vue, tout ce qui concernait les couches inférieures constituait la couche la plus basse, et il nous restait un vaste territoire à démêler.
En juin 1970, les membres du NWG se réunirent à l'UCLA et à Harvard pour finaliser les protocoles et aborder les questions de mise en œuvre. Le problème de la reconnexion demeurait cependant insoluble. Frustré, Crocker demanda conseil à Crowther, le concepteur logiciel principal de l'équipe BBN. Crocker se souvient de la conversation :
Il a dit : " Pourquoi ne pas simplement faire en sorte que les hôtes envoient leur message, et si celui-ci tente déjà de se reconnecter (ce que nous appelons le protocole de reconnexion), il répondrait négativement ou l'ignorerait. Sans réponse, on réessaierait, et finalement, quelqu'un y arriverait. " J'étais stupéfait ! J'étais sous le choc, pas au sens négatif du terme, mais je n'arrivais pas à imaginer d'où pouvait venir une telle idée, car elle était basée sur des statistiques, ce qui ne correspondait pas à ma façon de concevoir les choses. Je voyais les choses comme des puzzles imbriqués, où toutes les pièces s'emboîtent parfaitement. L'idée d'un processus statistique, dont il est assez facile de comprendre la forte probabilité de convergence rapide, ne posait pas de problème en soi, mais ce n'était tout simplement pas ma vision du développement logiciel.
Les réunions s'éternisant sans aboutir à une solution, Crocker commença à recevoir des instructions.
Le 5 août, Wessler lui rendit visite et lui donna finalement un ordre direct : " Ça ne se passe pas bien, abandonnez cette partie du protocole. " . Plus tard en août, Crocker se rendit à l'ARPA et Roberts lui proposa un poste à l'IPTO. Pendant l'année qu'il fallut pour finaliser les conditions de son embauche, Crocker continua de diriger le NWG. Afin d'aider les sites dont les ordinateurs n'étaient pas encore connectés à l'Arpanet, il constitua une équipe de facilitateurs, dont Postel et Metcalfe, pour fournir une assistance spécialisée à la demande.
Une avancée majeure a eu lieu mi-février 1971 lors d'une réunion à l'Université de l'Illinois.
Un sous-comité, baptisé " comité de correction des anomalies du protocole hôte-à-hôte ", a été formé pour rédiger un rapport intérimaire. Ce comité a essentiellement finalisé la conception du protocole hôte-à-hôte. Cependant , la documentation des protocoles, nécessaire à leur codage et à leur mise en œuvre par les sites utilisateurs, s'avérait bien plus complexe : la documentation était encore incomplète et la mise en œuvre risquait de prendre beaucoup de temps. Roberts, toujours impatient, souhaitait que les sites achèvent leurs implémentations au plus vite et deviennent des nœuds Arpanet actifs. Afin de sortir de l'impasse documentaire, lors de la réunion du NWG en mai 1971, Alex McKenzie, de BBN, " s'est attelé à la rédaction d'une spécification définitive du protocole hôte-à-hôte - non pas pour inventer un nouveau protocole, mais pour consigner les décisions prises. Grâce à ce document, chaque site pouvait alors commencer à créer le code informatique nécessaire à la communication de ses ordinateurs avec les autres ordinateurs connectés au réseau

6.10 ALOHANET et Norm Abramson : 1966 - 1972
L'ARPANET n'était pas le seul réseau de communication novateur entrepris par l'IPTO à la fin des années 1960.
La genèse d'ALOHANET a débuté en 1966 lorsque Norm Abramson a rejoint le corps professoral du département d'ingénierie de l'Université d'Hawaï. Il pensait prendre un risque considérable, car s'il pouvait poursuivre ses recherches en ingénierie, il renonçait à la stimulation intellectuelle de Harvard et de Stanford, où il avait passé les sept dernières années. De plus, il devait trouver lui-même des financements. Le destin lui sourit alors, car il obtint les fonds qui lui permettraient d'apporter une contribution durable au développement des technologies de réseau avec son réseau à commutation de paquets radio : ALOHANET.
Ayant appris la création d'un nouveau programme de l'ARPA, THEMIS, dont la mission était de soutenir la recherche dans les universités de second rang, Abramson et deux de ses collègues professeurs, Wes Peterson et Ned Weldon, ont uni leurs forces pour former une équipe possédant des compétences en communication et en informatique. Abramson se souvient :
Nous avons donc cherché un sujet de recherche qui nous semblait pertinent pour le Département de la Défense et qui nous intéresserait, et nous nous sommes dit : " Les communications informatiques, ça a du sens. " Le système téléphonique ne paraissait pas pertinent à l'époque, surtout à Hawaï, et nous pensions tenir un sujet intellectuellement stimulant, un projet que nous pouvions vendre à l'ARPA. Voilà comment tout a commencé.
En 1967, Abramson organisa, par l'intermédiaire d'un ami commun, une rencontre avec Bob Taylor, directeur de l'IPTO. Interrogé sur leurs objectifs précis, Abramson se contenta de hausser les épaules. Lors d'une autre réunion en 1969, il se souvient avoir fait part à Taylor et Roberts de son sentiment de contrainte excessive quant à l'utilisation d'un seul canal de communication par utilisateur en radiocommunication. Relancé sur la question d'une alternative, Abramson ne put qu'exprimer sa frustration.
Il existe une solution bien plus judicieuse pour la radio que d'attribuer un seul canal à chaque utilisateur du réseau. C'est absurde ! Ça ne marchera pas !
On ignore aujourd'hui où les idées d'une seule personne ont pris naissance et où elles se sont arrêtées. Ce qui est certain, c'est que lors d'une réunion tenue plus tard en 1969, sans la participation de Taylor ni de Roberts, la décision cruciale de transmettre directement les informations des utilisateurs dans une unique rafale de paquets à haut débit, désormais connue sous le nom de canal ALOHA, a été prise. Autrement dit, chaque terminal transmettait ses données à l'hôte en utilisant le même canal radio. En cas de collision, un terminal ne recevait pas d'accusé de réception et devait retransmettre. Aucun terminal ne disposait de son propre canal de diffusion : tous les terminaux utilisaient le même canal.

Extrait d'un article rédigé en 1985 par Norman Abramson :
Dès le départ, il était évident que la nature du canal radio offrait de nouvelles possibilités de conception système, impossibles avec les systèmes utilisant les liaisons téléphoniques point à point classiques. Au fur et à mesure de la planification du réseau, ce point clé a pris une importance croissante. Il aurait été réjouissant de pouvoir affirmer que cette différence fondamentale entre les canaux radio, avec leurs capacités de diffusion ou d'accès multiple, et les liaisons filaires (ou micro-ondes) point à point classiques, était perçue dès le début du projet. Malheureusement, cette prise de conscience n'est apparue qu'avec le temps ; comme souvent dans la réalité, notre clairvoyance n'était pas aussi grande qu'avec le recul.
Dès le début du projet, il était toutefois admis que le fonctionnement intermittent, caractéristique des terminaux informatiques interactifs, constituait un argument convaincant contre l'attribution de canaux point à point selon une méthode conventionnelle d'accès multiple par répartition en fréquence (AMRF) ou d'accès multiple par répartition dans le temps (AMRT). Une forme de partage d'une ressource de canal de communication commune apparaissait nécessaire .
Une fois de plus, le fonctionnement intermittent des terminaux informatiques interactifs obligeait les architectes des systèmes de communication à repenser la conception des réseaux de communication de données. Mais quelle idée saugrenue que de croire que tous les terminaux partagent simultanément le même canal !
Vint ensuite la construction d'un réseau de démonstration pour prouver la faisabilité du projet. Deux étudiants de troisième cycle, Charlie Bass et John Davidson, sous la direction d'Abramson - tous deux qui deviendront des figures importantes de l'histoire des communications informatiques -, acquirent une précieuse expérience en travaillant sur ALOHANET. La source d'aide la plus inattendue, compte tenu de ses nombreuses obligations, fut peut-être Roberts lui-même. Abramson écrit :
Outre ce soutien financier à ALOHANET, Roberts a également contribué au succès du projet d'une manière qui ne se prête généralement pas aux financements publics. À proprement parler, Roberts a agi comme un membre à part entière de l'équipe de recherche, apportant plusieurs résultats techniques majeurs (dont la première dérivation de la capacité du canal ALOHA à intervalles de temps fixes et la première analyse de l'effet de capture dans les canaux ALOHA) .
ALOHANET était constitué de plusieurs terminaux distants, tous reliés par des canaux radio à un ordinateur central de l'Université d'Hawaï. Il s'agissait d'une topologie en étoile centralisée, sans aucun canal à sauts multiples. Chaque utilisateur émettait sur une fréquence et recevait sur une autre, ce qui empêchait toute communication entre eux : les utilisateurs devaient recevoir les transmissions sur une fréquence différente de celle utilisée par les autres. À son apogée, ALOHANET prenait en charge quarante utilisateurs répartis sur les îles d'Oahu et de Maui. Les terminaux utilisateurs se connectaient à l'ordinateur central via une unité de contrôle de terminal (TCU) communiquant à 9 600 bits par seconde. Après l'installation de la première TCU en 1971, Abramson organisa une fête pour célébrer ce succès. (En 1972, Abramson se concentra sur l'application des concepts développés pour ALOHANET aux communications par satellite. Le 17 décembre 1972, une interface IMP reliant l'ordinateur central d'ALOHANET à ARPANET par satellite fut installée.)

Le réseau ALOHANET n'a jamais été commercialisé, car cela aurait nécessité l'approbation de la Federal Communications Commission (FCC), l'agence gouvernementale chargée de réglementer l'utilisation des fréquences radio. Abramson écrit :
En tant que projet de recherche, c'était assez intéressant, mais je n'aurais pas envisagé d'aller plus loin et d'étudier les systèmes opérationnels ou commerciaux .

6.11 Réseau NPL et Donald Davies 1966 - 1971
Lorsque Donald Davies devint directeur de la division d'informatique du Laboratoire national de physique en août 1966, il disposa enfin des ressources budgétaires nécessaires pour mettre en place un réseau explorant les principes de la commutation de paquets qu'il préconisait depuis longtemps. Davies allait mener une initiative très différente de celle de Roberts. Il explique :
Nous avons compris que nous ne pourrions jamais construire un réseau Arpanet. Nous n'avions aucun mandat pour créer un réseau national et nous ne pouvions imaginer qui l'utiliserait. Nous n'avions rien de comparable à l'ARPA pour constituer notre communauté.
En cherchant à définir les objectifs de conception du réseau, son équipe s'est rendu compte qu'il suffisait de se pencher sur un problème auquel elle était confrontée quotidiennement dans son laboratoire : comment assurer un accès informatique commun à la prolifération croissante de terminaux ? Leur solution, un ordinateur appelé processeur d'interface, était essentiellement un multiplexeur de terminaux semblable aux TIP d'Arpanet. Seul le processeur d'interface du NPL permettait de connecter jusqu'à 512 terminaux à un ordinateur local à un débit de données combiné pouvant atteindre un mégabit par seconde .
Une fois le processeur d'interface conçu, les chercheurs du NPL se sont demandés s'il ne pouvait pas offrir plus que de simples connexions aux terminaux. Car, comme pour toutes les nouvelles " boîtes noires ", leur existence ouvre de nouvelles perspectives, non envisagées lors de leur conception initiale. Dans le cas des processeurs d'interface, l'équipe de Davies a compris qu'ils pouvaient partager bien plus qu'un simple accès aux terminaux. Davies se souvient :
Ce que nous avons surtout constaté avec les petits ordinateurs de l'époque, c'est que malgré leurs excellentes performances pour l'époque, l'ajout de stockage s'avérait très coûteux. En effet, il fallait ajouter des baies de disques, d'imposantes armoires qui coûtaient plus cher que l'ordinateur lui-même. Nous avons donc décidé de fournir à tous nos mini-ordinateurs, PDP-8 et autres, un système de stockage centralisé, un serveur de fichiers, utilisant les technologies les plus récentes. Nous avons donc construit un serveur de fichiers pour tester ce réseau.
Dans une communication présentée à la conférence IFIP d'Amsterdam en 1968, Davies aborda pour la première fois le concept de " réseaux locaux ", soulignant la nécessité d'une interconnexion locale entre ordinateurs et entre terminaux et ordinateurs. L'histoire a confirmé que Davies avait, une fois de plus, forgé une expression, tout comme il l'avait fait auparavant avec " commutation de paquets ".
Lors de sa mise en service en 1971, le protocole de communication hôte à hôte, initialement simple, s'est révélé insuffisant et a dû être entièrement réécrit afin d'accélérer la transmission des paquets. Une fois le nouveau logiciel de protocole installé en 1973, le réseau traitait plus d'un million de paquets par jour.

6.12 Démonstration de la CICC 1971-1972
Au milieu de l'année 1971, Roberts, frustré, cherchait désespérément à rendre Arpanet pleinement opérationnel.
L'absence de protocoles de communication entre hôtes constituait le principal obstacle. D'autres problèmes se posaient également, comme celui de convaincre les nouveaux sites d'accélérer les démarches nécessaires à la connexion de leurs ordinateurs au réseau. Si chaque site rencontrait des difficultés similaires, chacun présentait aussi des spécificités, et rares étaient ceux qui agissaient avec la même urgence que Roberts.
Conscient de la frustration de Roberts, Kahn suggéra d'organiser une démonstration publique pour encourager la finalisation du réseau.
Roberts apprécia l'idée et demanda à Kahn de la superviser. Kahn accepta et recommanda que la démonstration ait lieu lors d'une conférence informatique conjointe, soit au printemps, soit à l'automne. Roberts, cependant, préférait une toute nouvelle conférence, la Conférence internationale sur les communications informatiques (ICCC), qui devait se tenir du 24 au 26 octobre 1972 à Washington D.C. Persuasif, Roberts obtint gain de cause.
De la mi-1971 jusqu'à l'ICCC, Kahn consacra la quasi-totalité de son temps à l'organisation de la démonstration. Il recruta Al Vezza du Project MAC du MIT pour l'aider, et ils impliquèrent bientôt d'autres personnes. Le NWG contribua en organisant un concours, ou " fly-off ", lors de sa réunion d'automne au MIT. Crocker se souvient :
Le jeu consistait à tenter de se connecter à l'hôte de tous les autres. Nous avions donc une grande matrice et, pendant un ou deux jours, les participants devaient essayer d'établir une connexion Telnet de leur hôte vers l'autre, dans les deux sens, car ces connexions sont asymétriques à ce niveau. SDC s'est distingué par son absence totale de préparation. Le reste a plus ou moins fonctionné.
Une étape importante en matière de connectivité entre ordinateurs a été franchie. Comme prévu, des améliorations du réseau étaient nécessaires pour rendre la démonstration de l'ICCC plus efficace, notamment une nouvelle méthode de connexion à distance appelée Telnet.
Le plan de l'ICCC prévoyait l'installation d'un TIP (Test d'Innovation Program) équipé de terminaux informatiques à l'hôtel Hilton de Washington D.C., lieu de la conférence. Les participants intéressés pourraient ainsi se connecter à l'un des hôtes Arpanet et exécuter une application en ligne. Cela impliquait toutefois la création et le débogage d'applications pratiques intéressantes, appelées " scénarios ", ou, si une application existait déjà, son adaptation au réseau.
Une autre tâche consistait à installer et à rendre opérationnels les terminaux informatiques. Kahn profita de cette occasion pour convaincre les fabricants de terminaux de prêter des appareils à l'ARPA et de veiller à leur configuration pour communiquer avec le TIP. Une troisième tâche importante était de préparer la salle pour la démonstration, notamment en prenant les dispositions nécessaires avec AT&T pour les lignes louées.
Pour aider les sites hôtes à connecter leurs ordinateurs à Arpanet et à créer des scénarios, Kahn a constitué un groupe d'une cinquantaine d'animateurs, dont Cerf, Metcalfe et Postel. Ce nouveau groupe a déchargé le NWG de toute implication continue dans la démonstration, lui permettant de concentrer ses efforts sur la mise en œuvre de protocoles de plus haut niveau, notamment ceux nécessaires aux applications de calcul distribué.
À peu près à la même époque, Crocker a considérablement réduit le temps qu'il consacrait à Arpanet, travaillant désormais sur d'autres projets de l'ARPA.
En septembre, Kahn a demandé à Metcalfe de collaborer avec le NIC du SRI afin de documenter les scénarios de travail et de créer un manuel pour les participants à l'ICCC. Metcalfe a passé deux semaines au SRI à rassembler 19 scénarios " pour illustrer la variété et la sophistication, tout en conservant la simplicité " .
L'ICCC allait s'avérer être pour la commutation de paquets ce que l'Exposition du Centenaire de Philadelphie en 1876 fut pour le téléphone : la révélation publique d'une rupture technologique majeure.
Pour les 800 professionnels de la communication informatique, fonctionnaires et universitaires présents à l'ICCC, voir le TIP installé sur une estrade au milieu de la salle, entouré de 36 terminaux informatiques et entouré de dizaines de scientifiques de l'ARPA, impatients de présenter leur nouvelle acquisition, dut ressembler à une attraction de foire sur une planète extraterrestre. Et puis, s'asseoir à un terminal et, en quelques frappes, se connecter via un ordinateur de l'UCLA à un autre du MIT et utiliser instantanément une application, puis se connecter tout aussi facilement à n'importe quel autre ordinateur participant, la désorientation dut être comparable à celle ressentie sur cette planète étrangère - rien d'étonnant, donc, à ce que le scénario le plus consulté ait été celui des conditions météorologiques sur Terre.
Pour la plupart, un ordinateur était une machine unique, rangée en toute sécurité dans une salle climatisée et sécurisée. L'idée de pouvoir accéder à des ordinateurs dans tout le pays depuis une salle de conférence d'un hôtel Hilton était tout simplement inédite. Quant aux scientifiques de l'ARPA, les liens tissés lors de la démonstration et le fait de vivre au quotidien avec leur invention les ont emplis d'enthousiasme et d'optimisme quant à l'avenir informatique qu'ils étaient en train de façonner.
Kahn a peut-être la meilleure perspective sur l'événement :
C'était un véritable tour de force de réussir à le mettre en place. J'ai oublié le jour de la semaine où la conférence a commencé, mais nous n'avons eu accès à la salle que vers 7 h du matin le jour où elle devait être opérationnelle. Imaginez un peu : installer tout un système informatique en seulement cinq ou six heures ! Les participants devaient arriver dans la salle pour utiliser le réseau l'après-midi même. Il a donc fallu installer le faux plancher, les lignes téléphoniques longue distance, tous les terminaux, et faire tout cela en six heures seulement. Ça a fonctionné à merveille. Tout était prêt.
Le terminal d'expérimentation (TIP) était installé en plein centre de la salle de bal, sur un plancher surélevé. Des rampes tout autour permettaient aux visiteurs d'y accéder et d'en sortir, et de gérer le câblage. L'agencement permettait de circuler librement dans la salle et d'assister à toutes les démonstrations. Les participants pouvaient s'installer aux bornes, choisir un scénario et le réaliser. Des cabines étaient disposées sur les côtés et au centre. Chaque cabine était gérée par une personne, et d'autres personnes étaient responsables de zones spécifiques de la salle, comme Bob Metcalfe, Vint Cerf ou Jon Postel. Elles circulaient librement et prêtaient main-forte là où c'était nécessaire. Une trentaine de personnes au moins y participaient. Nous organisions également des démonstrations à l'extérieur de la salle de bal, avec du personnel aux entrées, et nous avions une salle séparée pour la projection d'un film.
Les deux premiers jours, avant le début de la conférence, alors que le système était opérationnel, tous ces experts réseau étaient là pour faire fonctionner leurs démonstrations. Avec une centaine des meilleurs informaticiens du pays réunis dans une même pièce, il y avait forcément une réponse à n'importe quelle question. Personne ne quittait la pièce avant minuit passé. Personne ne voulait partir. Si nous n'avions pas décidé de fermer les portes à clé, ils seraient peut-être restés là toute la semaine. Finalement, nous avons tout démonté sans cérémonie.
Metcalfe se souvient d'un incident :
On m'avait confié la tâche d'accompagner dix vice-présidents d'AT&T. Je faisais donc la démonstration du système, et pour la seule et unique fois de toute la présentation, le TIP a planté. La seule fois. Il est resté hors service pendant une dizaine ou une vingtaine de secondes. Il a fini par redémarrer. La connexion a été rétablie et il n'a plus jamais planté. Mais ce fut une véritable révélation pour moi, car quand j'ai levé les yeux, ils étaient ravis de ce plantage. Ils ne cachaient pas leur joie. Cela leur confirmait que la commutation de circuits était meilleure et plus fiable que la commutation de paquets, qu'ils jugeaient instable et vouée à l'échec. Et moi qui travaillais sur ce système depuis deux ou trois ans, j'étais vraiment furieux.
Davies a assisté à la Conférence internationale sur la citoyenneté (CICC) et se souvient de l'impact qu'a eu le fait de voir tout le monde réuni :
L'Arpanet a joué un rôle clé car il a permis de démontrer les concepts de la commutation de paquets à grande échelle. La réunion de l'ICCC à Washington D.C. a été absolument cruciale car, pour la première fois, on pouvait voir une vaste communauté de personnes travailler ensemble. Ce fut un tournant décisif, car c'était la première fois que tant de personnes étaient réunies, toutes convaincues du succès et de l'importance du projet. Auparavant, chaque fois que j'en parlais, je le défendais en disant : " Oui, malgré vos objections, ce sera important ! "
À l'ICCC, l'enthousiasme était palpable. Une immense force intellectuelle était présente ; toutes ces personnes se concentraient sur la mise en œuvre du projet. Il ne s'agissait plus d'un ou deux excentriques comme Larry Roberts et moi. On discutait des possibilités. Ce n'était plus seulement théorique, c'était du concret. La différence était donc énorme. Je pense que le succès de cette démonstration a profondément marqué tout le monde.

Le choc des deux cultures - commutation de circuits contre commutation de paquets - avait commencé. Les événements à venir étaient imprévisibles, même avec les enseignements tirés de ces années charnières. Pour cette petite communauté, mais en pleine expansion, de défenseurs des réseaux, le changement était à la fois inévitable et bienvenu. En réalité, la soirée de lancement de l'ICCC marquait aussi une soirée d'adieu. Crocker, désormais à l'ARPA, allait quitter le monde des communications. Kahn avait accepté un poste à l'ARPA et avait quitté BBN peu après l'ICCC. Metcalfe avait déjà commencé à travailler pour le centre de recherche avancée de Xerox Corporation, le Xerox PARC, après avoir été recruté par Taylor, qui avait quitté l'Université de l'Utah pour le PARC. Cerf avait accepté un poste à l'Université de Stanford et sa dernière activité à l'UCLA fut sa participation à l'ICCC. Quant à Postel, il est resté à l'UCLA pour terminer son doctorat et a commencé à travailler avec Dave Farber, un scientifique important pour la suite de notre histoire.

Roberts replace la démonstration réussie d'Arpanet dans son contexte :
J'ai clairement été influencé par toute la communauté, car j'ai discuté avec tout le monde et cherché à recueillir des idées. Je pense qu'il faut s'intéresser à la mise en œuvre : qu'est-ce qui permet au projet de se concrétiser, tout le processus ? J'ai vu beaucoup de gens avec des idées, ils les évoquent, mais personne ne les reprend et elles ne sont pas développées. Il faut ensuite croire en la viabilité économique du projet, avoir suffisamment confiance pour le mener à bien, et c'est précisément ce qui s'est passé avec l'Arpanet. Je ne pense pas qu'il s'agisse d'une invention ; ce n'était pas une percée théorique comme celle d'Einstein. C'était un ensemble d'idées qui circulaient à l'époque. Les informaticiens avaient toujours utilisé des blocs et les lignes existaient depuis toujours ; ce n'était pas nouveau. En fait, je ne crois pas vraiment que Paul Baran ou Donald Davies aient beaucoup influencé la conception, car ils y ont été peu impliqués. Donald m'a incité à utiliser des lignes à plus haut débit que je ne l'aurais fait, et Paul avait réalisé le routage " patate chaude ", que nous avons d'abord considéré comme un bon exemple avant de poursuivre. Voilà donc les éléments que nous avons appliqués, mais le véritable enjeu était de concrétiser ce projet, de démontrer son importance, sa rentabilité et son impact, et de s'assurer de sa réalisation.

6.13 En perspective
La démonstration publique d'Arpanet à l'ICCC a prouvé qu'en quelques frappes au clavier, il était possible d'accéder à des ordinateurs très éloignés les uns des autres depuis un même terminal, sans avoir à établir de connexion avec chacun d'eux. Même trente-cinq autres utilisateurs, connectés au même terminal, accédaient à des ordinateurs différents, voire aux mêmes ordinateurs, chacun croyant avoir l'usage exclusif du réseau. Aussi banale que puisse paraître cette prouesse à Roberts, elle a marqué un tournant décisif dans les communications informatiques. Le concept révolutionnaire de la communication entre ordinateurs par simple envoi de paquets de données à la demande sur un réseau partagé, au lieu de nécessiter l'établissement d'un circuit, l'envoi de données et la fermeture du circuit, était désormais validé.
Arpanet, premier réseau à commutation de paquets, a transformé à jamais l'évolution des communications informatiques.
Bien que les nombreux informaticiens ayant participé à Arpanet se soient dispersés après l'ICCC, ils ont emporté avec eux les idées novatrices et l'énergie optimiste de cette époque. Très vite, nombre d'entre eux ont innové dans le domaine des communications informatiques d'une manière totalement imprévisible.

L'histoire de l'une de ces innovations - les réseaux locaux, et plus précisément Ethernet - sera présentée ci-après. Mais d'abord, il convient de raconter comment les entreprises de communication de données ont répondu au besoin croissant d'interconnexion des ordinateurs

Chapitre 6