Dans une conversation, on a tous un jour été confronté à la situation ou notre interlocuteur nous parle de façon continue sans nous laisser le temps de réagir. Au bout d’un certain temps on ne se rappelle plus du début de sa phrase. Une partie de l’information a été transmise en vain. Dans les environnements numériques un problème similaire peut se poser. Afin d’éviter de transmettre des unités de données pour rien, on peut mettre en place un service permettant à un récepteur de contrôler le rythme d’émission d’un émetteur. Ce service s’appelle le contrôle de flux.

Dans les réseaux, l’émission trop rapide de donnée par un émetteur vers un récepteur peut provoquer une saturation de celui-ci qui ne sera pas capable de stocker les unités de données lui parvenant. Les données contenues dans celles-ci sont alors perdues. Ce problème est fréquemment du à une différence de ressources entre l’émetteur et le récepteur, en termes de puissance de calcul, de mémoire ou de bande passante disponible. Par exemple si l’un d’entre eux est un superordinateur et l’autre un téléphone portable.

On peut imaginer plusieurs mécanismes pour implanter le service de contrôle de flux. Si la saturation est un évènement relativement rare on peut utiliser un mécanisme réactif dans lequel le récepteur indique sa saturation et demande à l’émetteur d’arrêter d’émettre. (L’équivalent du « attends un peu » humain.) Il utilisera par la suite une invitation à émettre afin de relancer la communication lorsque des ressources seront de nouveau disponibles. Du fait du temps de transmission du message entre le récepteur et l’émetteur plusieurs unités de données circulant dans l’autre sens peuvent être perdues. Ce type de mécanisme est utilisé dans des protocoles tels que HDLC ou Ethernet.

Si la saturation est un évènement plus fréquent, le récepteur peut au contraire indiquer par avance à l’émetteur combien d’unité de données ou quelle quantité de donnée il est prêt à accepter. Cette stratégie est adoptée dans les protocoles TCP et HDLC.

Dans ces protocoles, ceci se traduit par l’utilisation d’un objet appelé fenêtre (window) et défini par un intervalle. Lors de son utilisation dans le protocole HDLC chaque unité de donnée est numérotée. La fenêtre permet à l’émetteur de contrôler les numéros des unités de donnée qu’il peut émettre sans saturer le récepteur.

• Lors de chaque émission la borne supérieure de la fenêtre est incrémentée.
• Lors de la réception de cette unité de donnée, le récepteur envoie un acquittement à l’émetteur. Dans HDLC cet acquittement est appelé RR pour « Receive Ready », « prêt à recevoir ».
• Lors de sa réception, la borne inférieure de la fenêtre est incrémentée.
• La taille de la fenêtre c'est-à-dire la différence entre les bornes supérieure et inférieure qui indique le nombre d’unité de données envoyées

mais non encore acquittées.

Par ailleurs la taille de la fenêtre est limitée par une taille maximale. Celle-ci correspond au nombre d’unités de données que le récepteur peut recevoir sans être saturé.

Dans HDLC sa valeur initiale est décidée au démarrage de la communication. Elle peut varier dans d’autres protocoles.

Examinons un exemple dans lequel la taille maximale de la fenêtre est de 2, le compteur est ici codé sur 3 bits. Les identifiants seront donc codés de 0 à 7. Le chronogramme ci-dessous illustre l'exemple.

• Au démarrage l’émetteur peut en théorie émettre les unités de données numérotées de 0 à 1. Les valeurs des bornes inférieures et supérieures de la fenêtre sont égales à 0. Lorsqu’il reçoit des données de l’utilisateur, il vérifie que la taille de la fenêtre n’est pas supérieure à sa taille maximale. Comme cette taille est ici de 0 il utilise la borne supérieure pour numéroter l’unité de donnée. L’unité de donnée D(0) est alors émise.
• Il incrémente ensuite la borne supérieure à 1.
• L’émetteur reçoit de nouvelles données de la part de l’utilisateur. Il vérifie de nouveau que la taille de la fenêtre n’excède pas sa taille maximale. La valeur étant cette fois-ci de 1, D(1) est envoyée et la borne supérieure de la fenêtre est de nouveau incrémentée à 2.
• Des données sont reçues de nouveau depuis l’utilisateur. La taille de la fenêtre est maintenant de 2. Comme sa taille maximale est atteinte l’émission est retardée jusqu’à la réception d’un acquittement.
• Cet acquittement RR(0) arrive un peu plus tard. La borne inférieure de la fenêtre est alors incrémentée à 1. La taille de la fenêtre est alors de 2-1 c'est-à-dire 1. Ceci permet l’émission des données au travers de D(2) et l’incrémentation de la borne supérieure qui passe de 2 à 3.
• Les acquittements RR(1) et RR(2) lorsqu’ils sont reçus par l’émetteur provoquent de nouveau l’incrémentation de la borne inférieure qui passe successivement de 1 à 2 puis de 2 à 3. La taille de la fenêtre est alors de nouveau nulle.

Pour conclure la présentation, un petit exercice. On suppose que l’on utilise le protocole de contrôle de flux dont nous venons de parler.

On suppose chez l’émetteur une taille maximale de fenêtre de 3. L’émetteur reçoit une PDU RR(4) alors que sa fenêtre est dans l’état que nous voyons ici à l’écran.

Quel est la forme de la fenêtre parmi ces propositions ?

La bonne réponse est la réponse D, en effet à la réception de RR(4), la borne inférieure est incrémentée de 1 passant de 4 à 5. Par ailleurs la valeur maximale pouvant être prise par la borne supérieure est également incrémentée de 1 et passe donc à 0, les valeurs étant codée sur 3 bits.

◁ Précédent | ⌂ Sommaire | Suivant ▷