Un cap pour ce chapitre
Ce que vous saurez faire
- Dérouler une transmission avec accusés de réception.
- Expliquer le rôle du délai et du bit alterné.
- Distinguer perte de données et perte d’un accusé.
Les bases utiles pour commencer
Attendre une confirmation
Nous étudions un émetteur qui envoie un seul message à la fois. Après l’envoi, il attend un accusé de réception, abrégé ACK. Si la confirmation attendue arrive, il peut passer au message suivant. Si un délai expire, il retransmet le même message. C’est une stratégie d’arrêt et d’attente : plusieurs messages différents ne sont pas simultanément en cours de confirmation.
Le délai ne prouve pas que le message a été perdu. Un réseau lent ou un ACK disparu produit la même observation du côté de l’émetteur. La retransmission doit donc être compatible avec le fait que les données ont peut-être déjà été livrées.
On distingue trois événements : émettre des données, les livrer à l’application du récepteur et confirmer leur réception à l’émetteur. Ces événements peuvent être séparés par une attente ou une perte. Une trace correcte doit pouvoir répondre à deux questions différentes : combien de données l’application possède-t-elle déjà, et combien de messages l’émetteur sait-il confirmés ? Après la perte d’un accusé, ces nombres diffèrent.
Une ambiguïté dangereuse
Supposons que le message demande d’ajouter une ligne dans un document. Le récepteur l’applique puis envoie un ACK, qui se perd. L’émetteur renvoie alors les mêmes données. Si le récepteur les traite comme nouvelles, la ligne apparaît deux fois. Un protocole fiable doit détecter cette répétition.
Nous joignons donc un bit de numéro, 0 ou 1, au message. Le récepteur mémorise le bit qu’il attend. Quand ce bit arrive, il livre les données et change son attente. Quand l’ancien bit revient, il reconnaît un doublon et renvoie une confirmation sans livrer à nouveau les données.
Pourquoi un seul bit ? Dans ce modèle, le récepteur doit distinguer le message courant de la répétition du précédent, puisque l’émetteur attend une confirmation avant d’avancer. Deux valeurs suffisent pour cette distinction locale. Ce raisonnement repose sur l’absence d’anciens messages réapparaissant après plusieurs échanges : avec des retards arbitraires, un numéro réutilisé pourrait redevenir ambigu.
Annoncer la convention des accusés
Dans ce cours, ACK 0 confirme un message numéroté 0, et ACK 1 confirme un message numéroté 1. D’autres présentations utilisent un ACK indiquant le prochain numéro attendu. Elles sont possibles, mais mélanger les deux conventions rend une trace incohérente. Commencez toujours par lire celle de l’énoncé.
L’émetteur alterne le bit seulement après réception de la confirmation correcte. Une retransmission conserve donc les données et leur bit. Le récepteur alterne son attente après acceptation de nouvelles données, même si l’ACK envoyé ensuite disparaît. Ces deux changements ne se produisent pas nécessairement au même instant.
Lire une trace sans perdre les états
Pour chaque échange, notez le message envoyé, son bit, ce que le récepteur attendait, ce qu’il livre et ce que devient l’ACK. Une perte de données ne modifie pas l’état du récepteur. Une perte d’ACK peut laisser le récepteur en avance sur l’émetteur : il a déjà accepté le message.
L’atelier propose une perte au premier envoi ou une perte des données suivie de celle du premier accusé ; il suppose les autres échanges corrects, sans anciens messages retardés au-delà d’un cycle. C’est le modèle pédagogique étudié ici. Les véritables protocoles traitent des situations plus riches ; il ne faut pas conclure qu’un unique bit suffit sans hypothèses pour tous les réseaux.
Exemple suivi : données perdues, puis accusé perdu
Au départ, l’émetteur prépare A avec 0 et le récepteur attend 0. Première tentative : A disparaît ; aucune livraison, aucun changement d’attente. Deuxième tentative : A avec 0 arrive ; A est livré, le récepteur attend 1, mais ACK 0 disparaît. Troisième tentative : A avec 0 arrive encore ; le récepteur détecte le doublon, conserve son attente de 1 et envoie ACK 0. Cette fois, l’émetteur le reçoit et passe à B avec 1.
Il y a trois émissions de A, deux réceptions de A au niveau du protocole, une livraison de A à l’application et une confirmation reçue. Ces compteurs ne mesurent pas la même chose. Pour reconstruire une trace, maintenez deux colonnes d’état séparées : bit du message courant chez l’émetteur et prochain bit accepté chez le récepteur. Ne modifiez une colonne que lorsque l’événement correspondant a effectivement lieu.
Vérifier une réalisation avec des propriétés locales
Une réalisation doit conserver les données et le bit tant que la confirmation correcte manque. Du côté du récepteur, accepter un nouveau message entraîne une livraison puis l’inversion du bit attendu. Recevoir un doublon entraîne seulement l’émission d’un nouvel accusé. Ces règles se vérifient sur chaque ligne, même lorsque toute la trace n’est pas encore terminée.
Supposons maintenant que B contient exactement le même texte que A. Après la confirmation de A, B porte 1 et sera livré : comparer les textes aurait supprimé à tort ce nouvel événement. Inversement, incrémenter un compteur applicatif à chaque réception aurait compté deux fois A dans l’exemple précédent. Le numéro du protocole et le contenu applicatif remplissent donc deux fonctions distinctes. Dans l’atelier, arrêtez-vous après la première tentative pour prédire l’état avant de faire apparaître la retransmission.
À vous de faire varier les choses
Faites disparaître un échange
Choisissez une perte puis avancez le nombre de tentatives. Comparez les transmissions aux messages réellement livrés.
Lire le résultat de l’expérience initiale
Messages livrés : A, B
ACK b confirme le message portant b. Une retransmission garde son bit ; un doublon provoque un ACK sans nouvelle livraison.
| Tentative | Envoi | Réception | Confirmation | Bit émetteur après | Bit attendu après |
|---|---|---|---|---|---|
| 1 | A / bit 0 | Nouveau message livré | ACK 0 perdu | 0 | 1 |
| 2 | A / bit 0 | Doublon non livré | ACK 0 reçu | 1 | 1 |
| 3 | B / bit 1 | Nouveau message livré | ACK 1 reçu | 0 | 0 |
La perte d’un ACK entraîne une retransmission, mais le bit évite une seconde livraison.
De la compréhension à l’autonomie
À vous de résoudre
Cherchez d’abord par vous-même. Vérifiez les résultats demandés, utilisez les indices si nécessaire, puis comparez votre méthode à la correction.
Premier message perdu
L’émetteur envoie A avec le bit 0. Le message est perdu. Quel message envoie-t-il après expiration du délai ?
Indice 1
Aucune confirmation n’est arrivée.
Indice 2
Le changement de bit exige une confirmation correcte.
Comprendre la correction
Il renvoie A avec le bit 0. Le récepteur attend toujours 0 puisqu’il n’a rien reçu. Après réception correcte, il livre A une fois, passe à l’attente de 1 et renvoie ACK 0. L’émetteur pourra alors préparer le message suivant avec 1.
Accusé perdu
A avec 0 est accepté, mais ACK 0 se perd. Le récepteur reçoit ensuite de nouveau A avec 0. Que livre-t-il et que renvoie-t-il ?
Indice 1
Le récepteur attend maintenant 1.
Indice 2
Confirmer de nouveau ne signifie pas livrer de nouveau.
Comprendre la correction
Il ne livre aucune nouvelle donnée : le bit 0 est celui du message déjà accepté. Il renvoie ACK 0 afin que l’émetteur puisse sortir de son attente. Son prochain bit attendu reste 1. A apparaît donc une seule fois dans les données livrées.
Une alternance trop rapide
Un programme inverse le bit après chaque envoi, même après une retransmission. Expliquez pourquoi il peut perdre une donnée.
Indice 1
Imaginez que le premier envoi numéroté 0 disparaisse.
Indice 2
Quel numéro le récepteur attend-il encore ?
Comprendre la correction
Après la perte de A avec 0, le récepteur attend toujours 0. Si A revient avec 1, son numéro ne correspond pas à l’attente : le récepteur peut le prendre pour un ancien message. L’émetteur doit conserver son bit jusqu’à la confirmation du message courant, et non jusqu’à sa simple émission.
Deux messages identiques
Une application souhaite envoyer deux messages distincts contenant tous les deux « OK ». Comment éviter de confondre le second avec une retransmission ?
Indice 1
L’identité du contenu ne suffit pas à identifier l’échange.
Indice 2
Suivez les bits de deux messages successivement confirmés.
Comprendre la correction
Le premier « OK » porte par exemple 0, le second 1. Après la confirmation du premier, le récepteur attend 1 et accepte donc le second, même si son texte est identique. Une retransmission du premier garderait 0. La numérotation décrit l’avancement du protocole, pas la différence entre les textes.
Deux pertes dans une même histoire
A avec 0 se perd. Sa première retransmission arrive, mais son accusé se perd. La seconde retransmission et son accusé arrivent. B est ensuite envoyé sans incident. Donnez les bits des quatre émissions, les livraisons et le bit attendu à la fin.
Indice 1
Une retransmission conserve le bit initial.
Indice 2
Le récepteur change d’attente seulement lors d’une nouvelle livraison.
Comprendre la correction
Les émissions portent 0, 0, 0, 1. A est livré à la deuxième émission seulement ; sa répétition à la troisième n’est pas livrée. B est livré à la quatrième. Les données applicatives sont A puis B et le prochain bit attendu est 0. Les quatre émissions n’ont produit que deux livraisons.
Auditer un récepteur
Un récepteur attend 1. Il reçoit A avec 0, déjà livré précédemment, puis B avec 1. Le programme proposé ignore totalement A et attend la suite sans envoyer d’ACK. Expliquez le défaut. Décrivez le traitement correct des deux réceptions et comptez les nouvelles livraisons.
Indice 1
Le récepteur connaît la réception passée, mais l’émetteur attend peut-être toujours sa confirmation.
Indice 2
Pour le doublon, dissociez la livraison et l’envoi d’ACK.
Comprendre la correction
Ignorer A sans renvoyer ACK 0 peut maintenir l’émetteur dans ses retransmissions. Le traitement correct confirme 0 sans nouvelle livraison ni changement d’attente. B avec 1 est ensuite accepté, livré et confirmé par ACK 1 ; l’attente passe à 0. Il y a une nouvelle livraison. Cette réponse suppose que B est effectivement envoyé après confirmation de A.
Le délai ne révèle pas la panne
Après l’envoi de A avec 0, aucun ACK n’arrive avant le délai. Construisez deux histoires compatibles avec cette observation : perte des données, puis perte de l’accusé. Donnez dans chacune le nombre de livraisons avant retransmission. Quelle action commune permet de poursuivre ?
Indice 1
L’émetteur ne voit pas directement ce qui est arrivé au récepteur.
Indice 2
Considérez ce que le récepteur a pu changer dans chaque histoire.
Comprendre la correction
Si A est perdu, le récepteur attend 0 et aucune livraison n’a eu lieu. Si seul ACK 0 est perdu, A a été livré une fois et l’attente vaut 1. L’émetteur doit retransmettre A avec 0 dans les deux cas. Le récepteur l’accepte dans le premier et le reconnaît comme doublon dans le second. Un nouvel ACK permet ensuite de poursuivre.
Les erreurs qui méritent un détour
- Changer le bit lors d’une retransmission.
- Une retransmission concerne encore le même message. Le bit de l’émetteur change après un ACK correct.
- Ignorer entièrement un doublon.
- Les données ne sont pas livrées deux fois, mais un nouvel ACK est nécessaire pour débloquer l’émetteur.
La fiche à garder
L’essentiel à retenir
- Une absence d’ACK ne permet pas de localiser la perte.
- Le récepteur mémorise le prochain bit attendu.
- Données et accusés n’entraînent pas les mêmes changements d’état.
Le prochain pas
Retrouver le catalogue de Première
Ce chapitre s’appuie sur le programme officiel de Première (PDF, nouvel onglet). Les explications et exercices sont proposés pour l’apprentissage.