Logiciel de réseau

Notion de protocole

Au chapitre précédent, nous avons vu que le système de communication prenait à sa charge le transfert de l'information et toute la gestion nécessaire à sa remise correcte et compréhensible à l'utilisateur. Dans ce contexte, il est nécessaire d'établir un certain nombre de règles de manière à ce que tout se passe bien. De la même façon, nous avons vu qu'il était nécessaire que les interlocuteurs se mettent d'accord sur la signification des messages transmis. De manière plus générale, l'ensemble de ces processus de transmission sont gérés par des mécanismes appelés protocoles.

Exemple simple de protocole : une conversation courante entre deux amis. En fait, un certain nombre de règles implicitement établies régule la conversation. Ces règles sont par exemple : ne pas parler en même temps, parler la même langue et parler du même sujet. Ces règles constituent un protocole.

Structure en couches et hiérarchies de protocoles

La structure en couche apparaît déjà dans l'exemple précédent : les règles de communication peuvent se superposer comme le montre le schéma suivant :

Les communications sur réseau fonctionnent exactement de la même façon. Afin de réduire la complexité de conception du logiciel de réseau et de réaliser l'indépendance logiciel/matériel, on effectue un découpage fonctionnel de l'ensemble du processus communicant en couches ou niveaux d'abstraction. Une couche correspond à un ensemble de fonctions ou de processus cohérents entre eux et assurant une fonction précise globale. Deux couches adjacentes sont indépendantes dans leurs fonctions mais elles s'interconnectent par ce qu'on appelle une interface : c'est au niveau des interfaces que les couches s'échangent des données. Pour donner un exemple concret : une machine à laver ! Considérons la machine à laver comme une couche (sa fonction est alors "laver le linge"). Elle est reliée à deux autres couches : le réseau électrique et le réseau d'eau. Les interfaces sont alors la prise de courant et le tuyau d'alimentation en eau.

Les protocoles correspondent à une implémentation donnée d'une couche. Ce modèle est finalement fondé sur le principe de "diviser pour régner". L'ensemble de ces couches et protocoles est appelé architecture du réseau. L'ensemble des protocoles utilisés par un système ayant un protocole par couche est appelé pile de protocoles (exemple de pile : la pile TCP/IP).

Pour fonctionner, chaque couche s'appuie sur la précédente. Chaque couche doit fournir un certain nombre de services aux couches précédentes, sans que ces dernières aient à connaître les détails de l'implémentation de ces services. Ceci garantit une certaine modularité du système dans son ensemble et surtout l'indépendance des implémentations. Dans un tel système, la couche N d'une machine gêre la conversation avec la couche N d'une autre machine en utilisant un ou des protocoles et les couches sous-jacentes.

Entre chaque paire de couches adjacentes se trouve une interface. C'est cette interface qui définit les services que la couche inférieure fournit à la couche supérieure. Au moment de la conception d'une architecture réseau et toujours dans le respect de l'indépendance des implémentations, il est très important de bien définir ces interfaces. Les couches doivent donc réaliser un ensemble de fonctions bien définies. Nous verrons plus bas que ces interfaces sont construites autour de primitives.

Principes de conception des couches

Du fait qu'une machine peut faire fonctionner plusieurs processus (ou programmes) accédant à des ressources réseau, et que par ailleurs une machine peut avoir plusieurs interlocuteurs (au moins un par application tournante), il est indispensable que chaque couche possède un mécanisme d'identifiaction des émetteurs (les processus) et des récepteurs (les interlocuteurs distants).

Il convient également de s'interroger sur les règles de transfert des données. En effet, une communication peut s'effectuer de différentes façons :

• communication simplex : les données ne voyagent que dans un seul sens,
• communication semi-duplex : les données peuvent voyager dans les 2 sens mais pas en même temps,
• communication duplex : les données peuvent voyager dans les 2 sens en même temps.

Ensuite intervient un problème de qualité de transmission : une couche doit pouvoir détecter et corriger les erreurs dues aux circuits physiques de communication. Il existe beaucoup de codes de détection et correction, mais les 2 extrémités doivent se mettrent d'accord sur le code à utiliser. Par ailleurs, les extrémités doivent disposer d'un système permettant de dire à l'émetteur que le message a été correctement reçu. Deuxième problème de qualité de transmission : la conservation de l'ordre d'arrivée des messages. L'émetteur doit donner les moyens au récepteur de pouvoir remettre les paquets dans l'ordre, en numérotant les paquets par exemple, mais cela ne dit pas comment effectivement reconstruire le message.

Encore un problème important : certains processus ne sont pas en mesure de gérer des messages de longueur quelconque. Il faut donc fournir des mécanismes de désassemblage, de transmission et de réassemblage des messages. Le cas inverse peut également se produire : certains processus, pour des raisons de performance entre autre, vont vouloir transmettre des messages plus petits que ce qu'il pourrait se faire. Il faut alors être capable de réassembler ces petits messages en des messages plus gros.

Voici les principaux problèmes qui interviennent au moment de la conception de couches ; on peut toutefois en citer encore quelques uns tout aussi importants : problèmes d'engorgement du récepteur (lorsque l'émetteur est trop rapide par exemple), problèmes de routage rationnel de messages suivant certaines règles, problème du multiplexage (notamment sur la couche physique) lorsque le nombre de canaux de communication de la couche sous-jacentes sont limités...

Les services

Interfaces et services

Le but de chaque couche est de fournir un certain nombre de services à la couche supérieure. On dit alors que la couche sous-jacente est fournisseur de service à la couche supérieure, utilisateur de service. Les éléments actifs d'une couche sont appelés entités. Ces entités peuvent être des entités logicielles (un processus par exemple) ou matérielles (une puce électronique par exemple). Les entités de la même couche N de 2 machines différentes sont appelés entités paires.

Les services d'une couche N sont accessibles par ce qu'on appelle des points d'accès aux services, ou SAP (Service Access Point). Chaque SAP est identifié par une adresse unique. Typiquement, les SAP du réseau téléphonique sont les prises de téléphone et les adresses sont les numéros de téléphones.

Pour que 2 couches adjacentes puissent communiquer, un certain nombre de règles doivent être mises en place à propos de l'interface. L'entité de la couche N+1 va donner à l'entité de la couche N une unité de données d'interface ou IDU (Interface Data Unit) à travers le SAP. L'IDU est en fait constitué de 2 choses : une unité de données de service, ou SDU (Service Data Unit) et certaines informations de contrôle, ou ICI (Interface Control Information) :

Le SDU constitue l'information que 2 entités paires échangent, mais c'est également ce que la couche N+1 du récepteur va transmettre à la couche N. L'information de contrôle est là pour assister la couche inférieure dans son travail. Elle va par exemple contenir le nombre d'octets contenues dans le SDU (cela peut servir dans la fonction de contrôle de l'intégrité de l'information).

Pour transmettre une SDU, il se peut qu'une entité de la couche N ait besoin de la fragmenter en plusieurs morceaux. Au moment de l'échange avec son entité paire, chaque morceau reçoit des informations de contrôle de protocole, ou PCI (Protocol Control Information) dans un en-tête, et le tout est envoyé séparément comme unité de données de protocole, ou PDU (Protocol Data Unit). Les en-têtes sont utilisés par les entités paires pour transporter leur protocole pair. Ce PDU devient alors le SDU de la couche N qui sera transmis à la couche N-1 via le SAP. Le fonctionnement général est donc le suivant :

Au bout du compte, on se retrouve avec un emboîtement des messages les uns dans les autres. Ce mécanisme d'emboîtement est souvent qualifié de mécanisme d'encapsulation.

Les primitives de service

Un service est défini formellement par un ensemble de primitives ou opérations qu'un utilisateur ou d'autres entités peuvent utiliser pour accéder au service. C'est ce qui concrétise l'interface. On classe habituellement les primitives de service suivant 4 classes :

La plupart des primitives possèdent des paramètres. Par exemple, les paramètres d'un CONNECT.request (requête d'établissement d'une connexion) vont être la machine à laquelle on veut se connecter, le type de service désiré (FTP...) et la taille maxi des paquets échangés.

Un service confirmé est un service pour lequel il y a une demande (request), une indication (indication), une réponse (response) et une confirmation (confirm). Un service non confirmé est un service pour lequel il y a juste une demande (request) et une indication (indication). Typiquement, le service d'établissement de connexion est un service confirmé car l'entité paire doit être d'accord pour établir la connexion. En revanche, le transfert de données peut être non confirmé, suivant que l'on veuille un acquittement ou non.

D'un point de vue implémentation, les primitives correspondent aux fonctions que l'on peut utiliser dans un programme pour accéder au service en question.

Relations des services aux protocoles

Un service est un ensemble de primitives qu'une couche fournit à la couche supérieure. Le service définit les opérations qu'une couche peut effectuer, mais cela ne renseigne pas sur la façon dont sont réalisées ces opérations. L'élément le plus caractéristique du service est l'interface entre deux couches adjacentes.

En revanche, un protocole est un ensemble de règles qui s'appliquent à la signification et au format des messages échangés entre entités paires. Les entités utilisent les protocoles pour implémenter les spécifications de service. Un service peut donc toujours être le même avec 2 protocoles différents.

Protocoles et services sont donc différents, mais ils sont étroitement liés. Il ne faut donc pas les confondre. Le service est une notion plutôt abstraite, alors que le protocole correspond véritablement à ce qui se passe physiquement. Cette distinction répond en fait à des exigences de programmation et d'implémentation modernes. Cela revient à faire la différence entre algorithme et implémentation de l'algorithme.

Services en mode connexion et mode déconnexion

Ces services sont tout simplement ceux abordés dans le chapitre précédent. On va donc juste rappeler ici quels en sont les grands principes.

Le service en mode connecté nécessite d'abord d'établir une connexion entre les 2 interlocuteurs. Le récepteur s'attend alors à recevoir des données de la part de l'émetteur. A la fin de la transmission, la connexion est coupée. Un exemple typique est le téléphone : pour l'utiliser, il faut d'abord décrocher le téléphone et composer un numéro. La personne appelée décroche alors son combiné et la connexion est établit. Les 2 personnes échangent jusqu'à ce qu'elles raccrochent.

Le service en mode non connecté se caractérise par une indépendance des messages transmis. Le récepteur reçoit un message alors qu'il n'a pas forcément été prévenu auparavant par l'émetteur. Les messages peuvent alors suivre des chemins différents, d'où une possible inversion de l'ordre d'arrivée des messages. L'exemple typique de ce service est la poste : quelqu'un écrit une lettre et l'envoie sans prévenir son destinataire. Cette lettre peut alors arriver après la seconde lettre que lui a écrite la même personne. Les deux chemins suivis par les 2 lettres peuvent être différents.

 format imprimable

 concepts

le modèle OSI