Les protocoles peuvent dans certains cas être relativement complexes. Afin de pouvoir raisonner plus facilement sur ceux-ci, il est nécessaire de les modéliser.

Quelles sont les qualités que l’on attend d’un modèle ? Il doit permettre de représenter certaines caractéristiques des protocoles de manière simple, synthétique et non ambigüe.

A quoi cela sert il ? Cela peut servir pour ceux qui les utilisent à raisonner plus facilement sur les protocoles. Ces modèles peuvent également être utilisés par des programmes d’analyse pour vérifier certaines propriétés protocolaires comme le fait que le protocole se termine ou que tel ou tel type d’unité de donnée est utilisé.

Ils peuvent aussi être utilisés afin de créer de manière automatique une partie des programmes implantant les protocoles.

Parmi les modèles existants nous allons étudier les automates. Ceux-ci sont utilisés dans de nombreux domaines parfois différents des réseaux de données. Nous nous intéressons par exemple ici à la modélisation du protocole d’utilisation d’un distributeur de café.

Un automate à nombre fini d’états se défini au travers de deux éléments principaux :

• Un ensemble d’états souvent représentés graphiquement par un cercle;
• Et un ensemble de transitions représentées par des flèches.

A chaque transition est associé un évènement: réception d’une pièce d’un euro, expiration d’un minuteur, appui sur une touche de la machine pour choisir une boisson, etc.

Cet évènement permet de passer d’un état à l’autre. On peut également attacher aux transitions les actions qui sont associées à chaque évènement comme par exemple, l’affichage d’un message, l’armement d’un minuteur, la préparation de la boisson choisie: ceux-ci sont notés après l’évènement.

Parmi les états on distingue par ailleurs l’état initial qui correspond à l’état dans lequel se trouve le système avant exécution du protocole et un ou plusieurs états finaux correspondant aux états dans lesquels le système peut se trouver en fin d’exécution.

Nous avons vu précédemment le protocole du bit alterné. Essayons de modéliser celui-ci en utilisant ce formalisme. Les deux entités peuvent échanger quatre unités de données, une unité contenant des données et associée à un compteur valant ‘0’ ou ‘1’ et une unité contenant un acquittement et associée à un compteur valant lui aussi ‘0’ ou ‘1’. Pour simplifier nous appellerons ces unités de données D0, D1, et ACK0, ACK1.

L’émetteur peut être soumis à plusieurs évènements:

• La réception d’une unité de donnée D de la couche supérieure;
• La réception d’un ACK0;
• la réception d’un ACK1;
• enfin l’expiration du minuteur.

Il peut par ailleurs lui-même initier des évènements en armant un minuteur, en envoyant D0 et en envoyant D1.

Il est possible de représenter le protocole de bit alterné du coté de l’émetteur en utilisant 4 états.

Comme on le voit sur notre schéma, dans l’état initial 1, l’entité attend des données de la couche supérieure. Lorsqu’elle en reçoit au travers l’évènement « Lire D », elle envoie D0 au récepteur, arme le minuteur et passe dans l’état 2.

Dans cet état deux évènements peuvent se produire, soit le minuteur expire auquel cas l’entité estime que D0 s’est perdue. D0 est donc retransmise et le minuteur réarmé. L’entité reste alors dans l’état 2 et cette situation peut se reproduire indéfiniment.

La deuxième possibilité est qu’un ACK 0 soit reçu signifiant que D0 a été reçu par son destinataire. Le minuteur est alors désarmé et le compteur passé à 1.

L’entité passe ensuite dans l’état 3. Dans cet état la situation est similaire à celle rencontrée dans l’état 1 à l’exception du fait que nous utilisons une valeur de compteur de 1.

De manière similaire l’état 4 est semblable à l’état 2 et permet lors de la réception de ACK 1 de revenir à l’état 1.

Les états 1 et 3 peuvent représenter une fin de communication si aucune autre information complémentaire n’est reçue depuis la couche supérieure.

Utilisons maintenant cet automate pour voir comment celui-ci fonctionne.

Dans l’état initial 1, une SDU est reçue de la couche supérieure. Elle permet de passer à l’état 2 en provoquant l’envoie de D0 et l’armement du minuteur.

Lors de la réception du ACK0, l’automate passe de l’état 2 à l’état 3 et provoque le désarmement du minuteur.

Lorsqu’une nouvelle SDU est reçue depuis la couche supérieure, l’automate passe de l’état 3 à l’état 4 ce qui provoque l’envoi de D1 et l’armement du minuteur.

Aucun acquittement n’ayant été reçu, le minuteur se déclenche ce qui provoque la retransmission de D1 et le réarmement du minuteur. L’automate reste ainsi dans l’état 4.

En supposant que l’utilisateur veuille envoyer une SDU D alors que l’automate est dans l’état 4 pour le protocole du bit alterné.

Dans quel état va passer l’automate selon vous ?

• L’état 4;
• L’état 2;
• L’état 1.

La réponse est l’état 4. En effet aucune transition ne permet de sortir de 4 au travers de l’évènement « Lire D ». D ne sera donc lu que lorsque l’automate sera revenu dans l’état 1.

Nous avons abordé comment modéliser au travers d'un automate certains aspects d'un protocole. Nous nous sommes intéressés, pour le cas du bit alterné, au comportement de l'émetteur.

Les automates ne représentent qu'une partie du fonctionnement du protocole qu'ils décrivent. Ainsi : le format des unités de données, le détail des opérations réalisées ou l'interface utilisée pour accéder au service ne sont pas décrits. c'est cette absence de détails qui paradoxalement les rend utiles.

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