systemes-concurrents/TP3/TP3.md

TP3: protocole de communication

On s’intéresse ici à la conception de système de télécommunications, du type protocoles téléphoniques, qui assurent la connexion et la déconnexion de session entre deux utilisateurs.

Ici on suppose que votre réseau n’a que deux utilisateurs

This is from Project Runeberg book called The key to science In swedish., Domaine public, Lien

On réutilise le “réseau FIFO” de la séance précédente. Au lieu de faire communiquer deux sites, on met en relation un processus initiateur (une instance du template initia) avec un processus repondeur (une instance du template resp).

FifoIR  := fifo(4,FIRGET,FIRPUT,PFIR,GFIR);
FifoRI  := fifo(4,FRIGET,FRIPUT,PFRI,GFRI);

repondeur := resp(FIRGET,FRIPUT,PFRI,GFIR);
initiateur := initia(FRIGET,FIRPUT,PFIR,GFRI);

system initiateur, FifoIR, FifoRI,  repondeur;

On considère deux type de message possibles, c’est-à-dire deux valeurs possibles pour les messages écrit dans le buffer des FIFO (alors que, typiquement, on ne transmettait que la valeur 5 dans le TP 2). La valeur cr correspond à un call request; dr (pour drrriiiiiing ?) correspond à un drop request , qui signale la fin ou le refus d’une session.

const int cr = 1;
const int dr = 0;

Au cours des questions du TP, le comportement de chaque service est décrit à l’aide de schémas, ou automates de services. Je donne ci-dessous une idée de la correspondance entre un automate et “l’équivalent” en UPPAAL (où on a simplifié la notion des communications).

Fig. 1: correspondance entre "automates de services" et UPPAAL

Remarque: un processus qui implante un automate de service, par exemple initiateur, doit envoyer un message (par exemple sync put!; assign vput :=cr;) lorsque le service attend de recevoir un “call request” (la transition est init(sup)? appel). Ne soyez donc pas surpris si vous pensez que les polarités sont inversées dans ces schémas.