Création d’un protocole de transfert fiable

Créer une communication fiable sur des réseaux n’est pas simple. Les bases de la communication ne garantissent pas que les données soient livrées correctement ou même livrées tout court. Même si les couches physiques et de liaison de données sont très impliquées dans la transmission des informations, elles ne s’assurent pas que les données arrivent intactes à leur destination. Des problèmes peuvent survenir en raison de facteurs comme le bruit, l’affaiblissement du signal ou les collisions. C’est pourquoi la couche de transport à la tâche de s’assurer que les données sont transmises de manière fiable.

Pour atteindre cette fiabilité, les ingénieurs ont créé des mécanismes pour détecter les erreurs, confirmer la réception des paquets et, si nécessaire, renvoyer les données perdues ou fausses. L’approche éducative de cette section montre comment les idées ont évolué pour résoudre ces problèmes. Elle détaille les étapes pour développer un protocole de transfert fiable, en partant du principe que le canal est parfaitement sûr, puis en ajoutant petit à petit des solutions pour divers types d’erreurs.

Si l’on considère que les autres protocoles sont fiables

L’approche utilisée dans cette section débute par une version simplifiée (souvent désignée sous le nom de RDT 1.0). Dans cette première itération, on suppose un canal de communication parfaitement fiable. Cela signifie qu’il n’y a aucune erreur lors de la transmission des paquets, ni de paquets perdus en chemin. Bien sûr, cette hypothèse est purement théorique et sert de point de départ pour les discussions sur les mécanismes de fiabilité.

L’illustration ci-dessous montre exactement ce scénario idéalisé. Les lignes du temps montrent la séquence de messages envoyés de l’émetteur au récepteur. Chaque message, désigné par “M” suivi d’un numéro, est envoyé individuellement, passant de l’émetteur au récepteur. La distance entre les messages représente le temps écoulé, et l’on constate qu’à chaque envoi de message par l’émetteur. Le “OK” indique que le récepteur a correctement reçu et compris le message. 

Toutefois, bien que ce modèle soit élégant dans sa simplicité, il ne reflète pas la réalité des réseaux de communication. Les canaux réels ne sont pas fiables, et des erreurs peuvent survenir à n’importe quel moment. Mais, en comprenant ce scénario de base, on peut construire et ajouter des couches de complexité pour traiter ces erreurs, comme nous le verrons avec les versions ultérieures du protocole.

Si l’on considère du bruit à l’émission

Prenons un moment pour plonger dans une version du protocole de transfert où les canaux de communication ne sont plus aussi parfaits que nous le voudrions. Dans cette approche améliorée (inspirée du concept RDT 2.0), nous abandonnons l’idée d’un canal infaillible et faisons l’hypothèse que des bruits peuvent survenir lors de l’émission. Nous nous rapprochons ainsi de la réalité plus nuancée et imprévisible des transmissions de données.

L’illustration ci-dessous présente un scénario plus complexe et plus proche de la réalité. Dans cette version, le récepteur possède désormais la capacité de fournir un retour à l’émetteur concernant l’état de la réception des messages. Deux types de signaux de retour sont utilisés : “ACK” (ACKnowledgement) et “NAK” (Negative AcKnowledgement). L’ACK indique que le message a été reçu correctement, tandis que le NAK signale une erreur dans le message reçu.

Observons l’illustration plus en détail :

• Le message M1 est envoyé par l’émetteur et reçu avec succès par le récepteur, comme indiqué par le “OK” sur le côté du récepteur. Le récepteur renvoie alors un “ACK” à l’émetteur pour confirmer la bonne réception.
• Le message M2, cependant, rencontre une erreur pendant la transmission, illustrée par l’éclair. Le récepteur détecte cette erreur et signale un “KO”, signifiant que le message n’a pas été reçu correctement. En conséquence, un “NAK” est renvoyé à l’émetteur pour l’informer de l’erreur.
• Le message M2 est à nouveau transmis sans erreur, confirmé par le “OK” du récepteur, et un “ACK” est envoyé en retour à l’émetteur.

Ce mécanisme ACK/NAK est une première étape vers l’amélioration de la fiabilité. Il permet à l’émetteur de savoir si un message doit être retransmis ou non. Cependant, cette méthode présente des limitations, notamment si les signaux ACK/NAK eux-mêmes sont corrompus.

Si l’on considère du bruit dans la confirmation

 Au début, l’accent a été mis sur la détection d’erreurs dans les messages via des signaux d’accusé de réception (ACK) et de non-accusé de réception (NAK). Cependant, un nouveau problème apparaît. Les erreurs peuvent non seulement affecter le message lui-même mais aussi les signaux d’ACK. Comment peut-on alors faire la différence entre un ACK corrompu et un ACK correct ?

C’est ici que les numéros de séquence entrent en jeu. Pour pallier ce défi, l’idée a été d’attribuer à chaque message un numéro de séquence unique, augmentant de manière séquentielle. Ainsi, lorsqu’un accusé de réception est envoyé, il contient également ce numéro de séquence. Si un émetteur reçoit un ACK avec le bon numéro de séquence, il sait que le message précédent a bien été reçu. En revanche, si le numéro de séquence est incorrect ou si l’ACK est corrompu, l’émetteur sait qu’il doit renvoyer le message.

Le danger sans cette méthode de numérotation serait que, dans le cas où un ACK est corrompu et que le message est renvoyé, le récepteur pourrait recevoir le même message en double. Les numéros de séquence empêchent cette redondance inutile en fournissant un mécanisme pour identifier de manière unique chaque instance d’un message. Ainsi, même si un message est envoyé plusieurs fois à cause d’ACK corrompus, le récepteur sait qu’il s’agit de la même instance du message et peut agir en conséquence. Cette évolution, en introduisant les numéros de séquence, a permis d’augmenter considérablement la fiabilité du protocole sans augmenter la complexité de manière exponentielle.

Observons l’illustration plus en détail :

• Le message M1 est envoyé par l’émetteur et est reçu avec succès par le récepteur, comme indiqué par le “OK” sur le côté du récepteur. En réponse, le récepteur renvoie un “ACK1” à l’émetteur, indiquant la bonne réception du message M1.
• Le message M2 est ensuite envoyé par l’émetteur et reçu correctement par le récepteur. Le récepteur tente alors de renvoyer un “ACK2” pour confirmer la bonne réception du message M2. Cependant, cet “ACK2” est corrompu pendant la transmission, comme illustré par l’éclair.
• En l’absence d’un accusé de réception valide, l’émetteur renvoie le message M2. Pour éviter une duplication inutile, le récepteur reconnaît le message grâce à son numéro de séquence et renvoie simplement un autre “ACK2” pour confirmer sa réception antérieure.

Cette illustration met en lumière la manière dont les numéros de séquence peuvent aider à surmonter non seulement les erreurs dans les messages eux-mêmes, mais aussi dans les accusés de réception, offrant une robustesse accrue au processus de communication.

Si l’on considère la perte d’un paquet

L’approche vers un protocole de transfert fiable poursuit sa progression avec une version encore plus élaborée (s’inspirant du concept RDT 3.0). L’une des limitations majeures de la version précédente est qu’elle ne prend pas en compte la possibilité que des paquets puissent être perdus pendant la transmission ; sans parler des accusés de réception (ACKs) ou des notifications d’erreur (NAKs) eux-mêmes qui pourraient également se perdre. Pour surmonter ces défis, cette version introduit le concept de “timer” ou minuterie.

Le principe est simple : lorsqu’un paquet est envoyé, un timer est déclenché côté émetteur. Si l’accusé de réception (ACK) pour ce paquet n’est pas reçu avant que le timer n’expire, le paquet est considéré comme perdu et est donc retransmis. Cette retransmission continue jusqu’à ce que l’accusé de réception soit reçu ou que le paquet soit abandonné après plusieurs tentatives.

Observons l’illustration plus en détail :

• Le message M1 est envoyé par l’émetteur et reçu avec succès par le récepteur, comme indiqué par le “OK” sur le côté du récepteur. En retour, le récepteur envoie “ACK1” à l’émetteur pour confirmer la bonne réception de M1.
• Pour le message M2, lors de sa première tentative de transmission, une erreur est survenue, symbolisée par l’icône d’explosion. En conséquence, un timer côté émetteur atteint son expiration, ce qui est indiqué par “timeout”.
• L’émetteur, ne recevant pas d’accusé de réception dans le délai imparti, tente de renvoyer le message M2. Lors de cette seconde tentative, le message M2 est correctement reçu par le récepteur, comme le montre le “OK”. Suite à cela, un deuxième accusé de réception “ACK2” est envoyé par le récepteur à l’émetteur pour confirmer la bonne réception de M2.

Observons l’illustration plus en détail :

• Le message M1 est envoyé par l’émetteur et est correctement reçu par le récepteur, comme indiqué par le “OK”. Le récepteur envoie ensuite “ACK1” pour confirmer la réception.
• Pour le message M2, la première transmission est réussie. Cependant, l’accusé de réception “ACK2” rencontre une erreur, symbolisée par l’icône d’explosion. En conséquence, l’émetteur n’en est pas informé, déclenchant un “timeout”.
• Après ce “timeout”, l’émetteur retente la transmission de M2 qui est de nouveau bien reçue, comme le montre le “OK”. Le récepteur renvoie alors un autre “ACK2” pour confirmer la réception réussie.

Cet ajout du timer permet de garantir une certaine fiabilité même dans des conditions où les paquets ou leurs accusés de réception peuvent être perdus. Cependant, cela introduit également des complexités supplémentaires, notamment la nécessité de définir une durée optimale pour le timer, afin d’éviter des retransmissions inutiles ou de longs délais d’attente.

Observons l’illustration plus en détail :

• Le message M1 est envoyé par l’émetteur et est correctement reçu par le récepteur, comme le signale le “OK”. En réponse, le récepteur envoie “ACK1” pour confirmer la réception.
• Pour le message M2, il y a eu un retard dans la transmission. Avant que le récepteur puisse accuser réception par “ACK2”, un “timeout” est déclenché du côté de l’émetteur. En réponse à ce “timeout”, l’émetteur réenvoie le message M2.
• Cependant, le récepteur finit par recevoir le premier M2 malgré le retard, et envoie “ACK2”. Peu après, le récepteur reçoit le deuxième M2 (réenvoyé à cause du “timeout”) et envoie un second “ACK2”.

La flèche orange en bas avec un point d’interrogation montre que l’émetteur a reçu deux accusés de réception “ACK2” pour le même message M2. Cela suggère que le “timeout” était peut-être trop court, car le premier “ACK2” a finalement atteint l’émetteur. Cette situation pourrait inciter l’émetteur à revoir la durée de son timer.

Il est important de noter que l’ajout de la minuterie ajoute de la complexité au protocole et nécessite une gestion attentive des délais pour s’assurer que la minuterie est bien calibrée : ni trop courte, ce qui entraînerait des retransmissions inutiles, ni trop longue, ce qui retarderait inutilement la retransmission de paquets perdus.

Les éléments indispensables pour un protocole fiable

La création d’un protocole de transfert fiable est nécessaire pour garantir l’intégrité et la fiabilité des données échangées sur un réseau. Cette fiabilité est obtenue par plusieurs mécanismes mis en œuvre progressivement pour faire face aux différentes imperfections et incertitudes du canal de transmission.

• L’un des mécanismes de base introduits est l’ACK, qui est une sorte de confirmation de réception. Lorsqu’un paquet de données est envoyé, l’émetteur attend une confirmation que le paquet a bien été reçu. Si l’émetteur ne reçoit pas cette confirmation dans un certain délai, ou que la confirmation est erronée, il considère que le paquet a été perdu et le renvoie. Cela permet de s’assurer que tous les paquets de données sont bien reçus et que la communication se déroule sans erreurs.
• Grâce aux numéros de séquence, le récepteur est capable de déterminer l’ordre dans lequel les paquets doivent être reconstitués, garantissant ainsi que les données sont reçues dans le bon ordre. De plus, ils permettent également de distinguer les paquets nouvellement transmis des paquets rediffusés, offrant une meilleure gestion des paquets dans les environnements où le risque de duplication est élevé.
• Enfin, la mise en œuvre d’un système de timer est nécessaire pour gérer les situations où les paquets sont perdus en cours de transmission. Si un paquet n’est pas accusé de réception dans un certain délai, cette minuterie expire, indiquant ainsi à l’expéditeur qu’il doit retransmettre le paquet.

En travaillant ensemble, les accusés de réception et les numéros de séquence, ainsi que l’ajout d’un timer, permettent d’améliorer considérablement la fiabilité du transfert de données. Les accusés de réception confirment que les paquets sont bien reçus, tandis que les numéros de séquence assurent que ces paquets sont dans l’ordre et intacts. Ensemble, ces éléments forment un protocole solide qui permet de livrer les données de manière fiable. Cependant, il est important de noter que cette combinaison, bien que nécessaire pour assurer la fiabilité, ne garantit pas une communication rapide. C’est une base solide pour la fiabilité, mais d’autres mécanismes et améliorations sont nécessaires pour obtenir une communication à la fois rapide et fiable.