Création d’un protocole de transfert fiable

La conception d’une communication fiable sur des réseaux n’est pas une tâche aisée. En réalité, les couches sous-jacentes de la communication ne garantissent pas l’intégrité et la livraison des données. Bien que les couches physiques et liaison de données jouent un rôle essentiel dans la transmission des informations, elles ne garantissent pas que les données parviendront intactes à leur destination, ni même qu’elles y parviendront du tout. Des erreurs peuvent survenir à cause de divers facteurs tels que le bruit, l’atténuation du signal ou les collisions. Par conséquent, la responsabilité de garantir une transmission fiable des données repose en grande partie sur la couche transport.

Ainsi, pour assurer la fiabilité, les ingénieurs ont dû imaginer des mécanismes capables de détecter les erreurs, de confirmer la réception des paquets et, si nécessaire, de renvoyer les données perdues ou erronées. L’approche pédagogique utilisée dans cette section illustre la progression logique des idées qui ont été développées pour adresser ces défis. Elle présente une série d’étapes évolutives pour la conception d’un protocole de transfert fiable, en commençant par une hypothèse simple où le canal est considéré comme étant parfaitement fiable, et en y ajoutant progressivement des mécanismes pour gérer différents types d’erreurs et de problèmes.

Il est essentiel de comprendre cette progression, car elle met en lumière les défis fondamentaux de la communication fiable en réseau et les solutions élaborées pour y faire face. 

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

La fiabilité dans les transmissions de données est cruciale pour garantir la qualité des communications. Alors que l’approche initiale s’était concentrée sur la détection d’erreurs dans les messages à l’aide de signaux d’accusé de réception (ACK) et de non-accusé de réception (NAK), un autre défi se posait. Si des erreurs peuvent survenir lors de la transmission du message lui-même, elles peuvent également survenir lors de la transmission de l’ACK. Comment alors distinguer un ACK corrompu d’un ACK valable ?

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 élémentaires pour un protocole fiable

La création d’un protocole de transfert fiable est essentielle 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 fondamentaux introduits est l’ACK. Les accusés de réceptio jouent un rôle pivot dans la confirmation de la réception correcte des paquets de données. Si l’émetteur n’acquiert pas cet ACK dans un délai spécifique, ou que l’ACK est invalidé, l’émetteur considère que le paquet a été perdu en chemin et le renvoie.
• 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 s’est avérée cruciale 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.

Le mécanisme de timer, par lui-même, est une innovation cruciale pour garantir la fiabilité du transfert de données. En parfaite harmonie avec les accusés de réception et les numéros de séquence, il veille à la rigueur du processus de transmission. Les accusés de réception confirment la bonne réception des paquets, tandis que les numéros de séquence assurent l’ordre et l’intégrité de ces paquets. Ensemble, ces éléments créent un protocole robuste capable de délivrer les données de manière fiable.

Cependant, il est important de noter que cette combinaison, bien qu’essentielle à la fiabilité, ne garantit pas nécessairement une communication rapide. Elle constitue le strict minimum pour la fiabilité, mais d’autres mécanismes et optimisations sont nécessaires pour assurer à la fois rapidité et fiabilité.