Mis à jour le 18/10/2017
  • 10 heures
  • Facile

Ce cours est visible gratuitement en ligne.

Ce cours est en vidéo.

Vous pouvez obtenir un certificat de réussite à l'issue de ce cours.

J'ai tout compris !

Une activité débranchée pour comprendre la notion de protocole

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Dessin de Pétillon. Une délicate question de protocole :)
Dessin de Pétillon. Une délicate question de protocole :)

Mais comment apprendre cela à des jeunes ? En jouant !

  • Objectif : Cette activité permet de montrer comment transite l'information et d'expliquer
    le concept de « protocole ». Dans cette activité, on explique essentiellement les grandes lignes de TCP.

  • Prérequis : Savoir ce qu'est un « algorithme » (le mot sera utilisé de nombreuses fois
    dans l'activité)

  • Matériel : Des fiches de trois types (ou couleurs) différentes :
    - quelques destinations (4 suffisent) : Brest, Rennes, Pékin, Prétoria par exemple
    - des messages (~16) qui seront numérotés à la phase 4
    - des accusés de réception (~16) numérotés et correspondant à chaque message

  • Disposition : Les jeunes sont assis à leur place habituelle et se font passer les messages ou accusés de réception de proche en proche comme quand on se passe des petits mots pendant les cours.

Phase 1 : explication de l’objectif

Quand une source envoie un fichier à un destinataire, la source doit être certaine que le fichier est bien reçu. Or il peut y avoir des erreurs dans le réseau, qui peut perdre des informations.

  • Distribuer des localisations (source = Brest) et des destinations possibles (dont Rennes, Pékin et Prétoria par exemple) en essayant de mettre Pékin et Prétoria loin dans la salle et Rennes et Brest proches.

  • Donner à Brest un paquet bleu.

  • Lui demander de le faire parvenir à Rennes.

  • Comment Brest peut être certaine que Rennes a bien reçu le paquet ? On peut guider les élèves : parler de lettre recommandée avec accusé de réception

  • Donner un accusé de réception au récepteur

Phase 2 : la notion d’accusé de réception

Mais quelqu’un peut voler un paquet ou un accusé de réception, ou l’accusé de réception peut se perdre !

Que peut faire la source pour décider si le paquet doit être retransmis ?

  • Laisser les élèves s’exprimer. Peut-être que l’un ou l’une va penser à un temps limite d’attente ! Sinon, leur parler d’un minuteur.

  • Donner le rôle de minuteur à un élève. Le faire se placer derrière la source ou à côté (son voisin par exemple). Faire compter lentement jusqu’à 5.

  • Faire fonctionner le système entre source et destination proches avec un faible délai. Cela peut se faire avec plusieurs paquets bleus non numérotés et plusieurs accusés de réception non numérotés.

  • Déplacer la destination beaucoup plus loin : 5 ne suffit plus ! Montrer que le minuteur doit tenir compte du temps d’aller-retour entre Brest et la destination.

Phase 3 : formalisation du protocole de transport

Nous devons maintenant concevoir un algorithme pour ce protocole de transport en mode
assuré.

Quel algorithme pour la destination ? Et pour la source ?

Les élèves doivent proposer sous forme d’algorithme la solution construite en situation de recherche.

Algorithme pour la destination :

Le récepteur envoie un accusé de réception quand il reçoit un paquet.

Algorithme pour la source :

  1. Quand la source envoie un paquet, elle lance son minuteur.

  2. Si la source reçoit l’accusé de réception avant l’expiration du minuteur, c’est terminé, le paquet peut être effacé par la source.

  3. Si le minuteur expire avant réception de l’accusé de réception, la source recommence à l’étape "renvoi du paquet et relance du minuteur".

Que se passe-t-il si la source reçoit l’accusé de réception de la première émission après avoir retransmis le paquet ?

Si la source respecte son algorithme elle réalise le n°2 : elle jette le paquet et considère que tout s’est bien passé. Mais elle risque de recevoir, plus tard, un accusé de réception sur un paquet qu’elle n’a pas gardé en mémoire.

Phase 4 : une transmission efficace

Un fichier peut être tout petit ou très gros ! Le réseau n’accepte pas de transporter en une fois un gros fichier. Un gros fichier est donc découpé en de multiples paquets qui sont numérotés et doivent être tous reçus pour reconstruire le fichier.

Donnez les paquets numérotés à la source, les accusés numérotés à la destination qui doit rester lointaine.

Commencer par utiliser la règle suivante :

  • Le récepteur envoie le N-ème accusé de réception s’il a reçu le N-ème paquet.

  • La source envoie les paquets 1 à 1 et ne jette le N-ème paquet que s’il a reçu le N-ème accusé de réception, il peut seulement alors envoyer le paquet suivant.

C’est très lent ! Que peut-on faire pour accélérer le transfert ?

Ce n’est pas si simple, car il faut gérer en parallèle ces paquets, qui peuvent arriver en désordre. On va vite se rendre compte que si on envoie plusieurs paquets, il faut autant de minuteurs que de paquets en cours d’envoi.

On va proposer de travailler avec cet algorithme pour la destination :
À chaque réception de paquet, le récepteur envoie l’accusé de réception numéro N s’il a reçu tous les paquets jusqu’au paquet numéro N, même si il a aussi reçu - par exemple - le N+2ème paquet.

La source, elle, dispose d’une fenêtre : elle peut prendre de l’avance par rapport aux accusés de réception. Considérons une fenêtre de 2, avec deux minuteurs (donc deux jeunes qui décomptent le temps).

La source envoie les paquets un à un à chaque fois qu’un minuteur est disponible.

Si la source reçoit le Nième accusé de réception à temps (avant l’expiration du minuteur numéro N), tous les paquets de numéro N et inférieurs peuvent être effacés par la source, et les minuteurs rendus disponibles.

Si le minuteur d’un paquet expire avant réception de l’accusé de réception de ce paquet, la source renvoie le paquet et relance le minuteur de ce paquet.

La source ignore les autres accusés de réception.

Voici quelques derniers conseils :

  • Prendre le temps que chacun·e s’approprie le protocole, puis le faire tourner.

  • On pourra aussi laisser le groupe tâtonner en essayant à la recherche de solutions.

  • Si un bug se produit (il y en aura :)) on regardera si le protocole a une faille (quelque chose de mal défini, ou un cas imprévu) ou si il a été mal exécuté.

  • On mettra en avant le fait que ce n’est plus un algorithme séquentiel exécuté par une machine, mais un algorithme distribué qui interagit avec un environnement incertain : un protocole.

Exemple de certificat de réussite
Exemple de certificat de réussite