En seulement quatre ans, du début de 1984 à la fin de 1987, les ventes de multiplexeurs T-1 ont été multipliées par dix : de 30 à 300 millions de dollars. Les entreprises de communication de données qui se croyaient autrefois héritières de « leur » marché des multiplexeurs seront, en 1987, écartées par une start-up entrepreneuriale – NET – et un géant informatique envahissant – Unisys (Timeplex). Durant ces mêmes années, les ventes de leur ancien moteur de croissance, les multiplexeurs statistiques, avaient atteint des sommets et diminuaient rapidement. En 1988, les ventes de multiplexeurs statistiques totaliseraient moins de 200 millions de dollars, bien loin des 900 millions de dollars prévus en 1985. (Sources)
La transition de la transmission analogique à la transmission numérique, et la demande qui en a résulté pour les multiplexeurs T-1, ont représenté un changement beaucoup plus profond que ce que les entreprises de Data Communications avaient en tête. Pour une fois, les entreprises avaient investi dans des multiplexeurs T-1 et avaient goûté aux économies de coûts et à leurs nombreux avantages stratégiques ; ils ont commencé à exiger des produits dotés de capacités pour lesquelles ils se tournaient autrefois vers AT&T. Des produits offrant par exemple un routage adaptatif, une gestion dynamique de la bande passante et une sauvegarde automatique. Ces nouvelles fonctionnalités dépassaient de loin les concepts de gestion de réseau qui avaient évolué pour les réseaux de données point à point construits à l'aide de modems et de multiplexeurs statistiques. (Sources)
Pourtant, aussi avancés que soient les nouveaux multiplexeurs de réseau T-1, à une seule exception près, ils étaient basés sur la commutation de circuits. Cela avait peut-être du sens au début, mais comme ces réseaux étendus étaient censés interconnecter les réseaux locaux, la commutation de circuits a commencé à présenter les mêmes problèmes qui avaient motivé la création du premier réseau informatique : ARPANET. Le trafic informatique et LAN était par nature en rafale et ne s'inscrivait pas idéalement dans les limites des circuits fixes, quelle que soit la vitesse à laquelle ils pouvaient être commutés. À partir du milieu de 1987, ces problèmes ont commencé à être reconnus et les sociétés de multiplexeurs T-1 ont commencé à réagir. Seulement ils ne seraient pas assez rapides, une histoire qui remplit le dernier chapitre de cette histoire : l'interconnexion ou le réseautage. Encore une fois, des entrepreneurs sans le bagage des clients existants ont innové avec des produits qui semblaient au début coexister avec les multiplexeurs T-1. Et puis a commencé à absorber T-1 comme simplement le protocole de couche physique qu’il avait toujours été. (Sources)
En fait, en arrière plan, se jouait la confrontation entre TCP/IP et les protocoles OSI (lire cette page). Nous ne parlons pas ici du modèle OSI, mais des protocoles X.xxx si vous préférez. Les enjeux de l'époque sont présentés dans l'interview de John Heafner, qui, en parlant d'un exposé oral pour la conférence NCC'1984, dit
Pelkey: Do you have a copy of that speech?
Heafner: Probably not. It wasn't a speech, it was just several
pages of notes, proposing: "Do you want to continue this work?"
Basically, what's required is that vendors don't want to key up
for a demo every year or two or whatever. What we needed was some
sandbox where we could really play and do inter-operation testing
and sort of develop the test technology and methodology that was
needed behind all of this. So what was envisioned was basically a
sandbox to play in, and that's what the OSINET is today.
Il est sous-entendu ici que la voie des protocoles OSI ne pouvait
pas être la voie à suivre, notamment pour des questions de
développement du business mais aussi pour des questions
d'interopérabilité des réseaux (LAN et WAN) ! Les protocoles OSI
pouvaient ils répondre à ces nouvelles demandes techniques ? OSINET
devient une organisation de vendeurs et d'utilisateurs, sur la base
du réseau X.25
comme coeur, afin de tester et de démontrer l'intérêt des protocoles
OSI.
Nous connaissons aujourd'hui le vainqueur de cette compétition entre OSI et TCP/IP, mais, à l'époque, il s'agissait bien de rivalités. Ici, quand nous parlons de vainqueur, nous voulons parler de la technologie que le grand public a aujourd'hui à sa disposition, Internet à la maison, pas la technologie réseau seulement adoptée par les entreprises. Cependant, les rivalités marquent une ligne de continuité entre les trois structures de marchés, fondamentales : data communications, networking, internetworking.
Servez vous des éléments à la page 34 de ce polycopié (i.e. les éléments relatifs à X.25), pour répondre aux questions de cet exercice qui porte sur X.25.
L'alternative aux protocoles OSI étaient ceux qui avaient été créés et pilotés par la DARPA : TCP/IP. Seul le gouvernement fédéral américain (via la DARPA et le DoD) a clairement indiqué en 1987 qu'à l'avenir, tous les réseaux seraient interconnectés via OSI et non via TCP/IP. Une poignée de renégats et de vendeurs ont refusé d'abandonner le navire. Lors des salons INTEROP de 1988, TCP/IP s'est révélé robuste et viable malgré la décision selon laquelle OSI serait l'avenir.
Les premiers produits d'interconnexion avaient des fonctionnalités limitées, nécessitant les protocoles de couche réseau pour fournir une interconnexion véritablement transparente. À la fin de 1988, les sociétés dominantes dans le domaine de l'Internetworking – Cisco Systems et Wellfleet – avaient déjà commencé à expédier des produits et des dizaines d'autres étaient entrés sur le marché.
La nécessité des entreprises d'interconnecter leurs ordinateurs dans des réseaux inclusifs et en constante expansion a eu des conséquences indubitables sur l'évolution des marchés des communications de données et des réseaux. À la fin de 1988, aucune entreprise observée dans cette histoire n’a échappé à la transformation, luttant pour réussir et même pour survivre.
Les différents types de produits qui ont été nécessaires, et leurs places respectives dans le modèle de référence OSI, sont décrits à la Figure 1. On remarquera au passage les 4 couches défendues par la Défense américaine (DoD), modèle que nous avant discuté dans un précédent chapitre. Pour les équipements, il s'agit des :
Lire chacun des liens ci-dessus pour comprendre le rôle de chacun de ces équipements et faites un résumé (court, synthétique) de ces rôles.
Retrouvez les RFC qui correspondent aux équipements. Par exemple, “Requirements for Internet Gateways – Draft,” correspond à la RFC 985. Comment sont organisés ces RFC ?
Faites un résumé court des faits marquants présentés sur cette page en recherchant la section /section/14.8/the-nbs-in-action-osinet,-cos,-and-gosip/. Quels étaient les enjeux ?
Faites un résumé court des faits marquants présentés sur cette page en recherchant la section /section/14.11/interop-(tcp-ip)-trade-show-september/. Qui sont les protagonistes et quels sont les enjeux ?
Comme exemple mettant en jeu toutes les couches du modèle de référence OSI, et pour illustrer toutes les notions de réseau vues dans ce cours, nous voudrions maintenant parler des Network sockets. Une socket réseau est une structure logicielle au sein d'un nœud de réseau d'un réseau informatique qui sert de point final pour envoyer et recevoir des données sur le réseau. La structure et les propriétés d'une socket sont définies par une interface de programmation d'application (API) pour l'architecture réseau. Les sockets sont créés uniquement pendant la durée de vie d'un processus d'une application exécutée dans le nœud.
En raison de la standardisation des protocoles TCP/IP dans le développement d'Internet, le terme socket réseau est le plus couramment utilisé dans le contexte de la suite de protocoles Internet et est donc souvent également appelé socket Internet. Dans ce contexte, une socket est identifiée de manière externe par rapport aux autres hôtes par son adresse de socket, qui est le triplet protocole de transport, adresse IP et numéro de port.
Une pile de protocoles, généralement fournie par le système d'exploitation (plutôt que sous forme d'une bibliothèque distincte, par exemple), est un ensemble de services qui permettent aux processus de communiquer sur un réseau à l'aide des protocoles implémentés par la pile. Le système d'exploitation transmet la charge utile des paquets IP entrants à l'application correspondante en extrayant les informations d'adresse de socket des en-têtes IP et du protocole de transport et en supprimant les en-têtes des données de l'application.
L'interface de programmation d'application (API) que les programmes utilisent pour communiquer avec la pile de protocoles, à l'aide de sockets réseau, est appelée API de socket. Le développement de programmes d'application qui utilisent cette API est appelé programmation socket ou programmation réseau. Les API de socket Internet sont généralement basées sur la norme des sockets de Berkeley. Dans le standard des sockets de Berkeley, les sockets sont une forme de descripteur de fichier, en raison de la philosophie Unix selon laquelle « tout est un fichier » et des analogies entre les sockets et les fichiers. Les implémentations ont des fonctions pour lire, écrire, ouvrir et fermer une socket.
Dans les protocoles Internet standards TCP et UDP, une adresse de socket est la combinaison d'une adresse IP et d'un numéro de port, tout comme l'extrémité d'une connexion téléphonique est la combinaison d'un numéro de téléphone et d'un poste particulier. Les sockets n'ont pas besoin d'avoir une adresse source, par exemple, pour envoyer uniquement des données, mais si un programme lie une socket à une adresse source, la socket peut être utilisée pour recevoir des données envoyées à cette adresse. Sur la base de cette adresse, les sockets Internet transmettent les paquets de données entrants au processus d'application approprié.
La socket est principalement un concept utilisé dans la couche transport de la suite de protocoles Internet ou dans la couche session du modèle OSI. Les équipements réseau tels que les routeurs, qui fonctionnent au niveau de la couche Internet, et les commutateurs, qui fonctionnent au niveau de la couche liaison, ne nécessitent pas d'implémentation de la couche transport. Cependant, les pare-feu réseau dynamiques, les traducteurs d'adresses réseau et les serveurs proxy assurent le suivi des paires de sockets actives. Dans les commutateurs multicouches et la prise en charge de la qualité de service (QoS) dans les routeurs, les flux de paquets peuvent être identifiés en extrayant des informations sur les paires de sockets.
Les sockets brutes (raw sockets) sont généralement disponibles dans les équipements réseau et sont utilisés pour les protocoles de routage tels que IGRP et OSPF, ainsi que pour Internet Control Message Protocol (ICMP).
Dans la définition originale de la notion de socket donnée dans la RFC 147, telle qu'elle était liée au réseau ARPA en 1971, "la socket est spécifiée comme un nombre de 32 bits avec des sockets pairs identifiant les sockets de réception et des sockets impairs identifiant les sockets d'envoi". Aujourd’hui, cependant, les communications sockets sont bidirectionnelles.
L'API socket est par exemple discutée sur cette page d'IBM. Veuillez remarquer les 7 étapes fondamentales du cycle de vie d'une socket. Ce cycle de vie est à respecter pour coder avec les sockets. La page suivante donne un exemple écrit en langage C pour implémenter une socket non-bloquante. D'autres exemples sont donnés à partir de cette page, toujours depuis un site IBM.
Installer sur votre machine (si cela n'est pas fait) un compilateur C et exécuter le code de la socket non-bloquante. Veuillez expliciter les étapes nécessaires, depuis la compilation jusqu'à l'exécution, ainsi que les sous-étapes spécifiques à la communication. Sur ce dernier point, il y a déjà des commentaires dans le code source donné. Il ne s'agit pas de les redonner, mais de les synthétiser, c'est à dire éviter d'aller vers trop de détails techniques. A vous de mesurer ce qui est hyper, beaucoup, un peu ou pas du tout technique.
De nombreux langages de programmation offrent une API socket. Généralement, pour ces différentes API, il n'est pas toujours requis de spécifier les 7 étapes du cycle de vie. Certaines étapes sont cachées. La série d'exercices que nous vous proposons permet de mesurer les abstractions proposés dans différents langage comme Python, Go et Rust. Veuillez vous limiter aux exercices consacrés à ces trois langages.