Td corrigé Question 2. Protocole Producteur ? Consommateur pdf

Question 2. Protocole Producteur ? Consommateur

M1 Info (TD du cours RdP ENSEEIHT). Travaux Dirigés n°1 ... On demande de modéliser l'ensemble du système par un réseau de Petri global.




part of the document



, et qu’il y a un ordre en attente d’exécution , alors elle l’exécute, sinon elle attend l’arrivée d’un ordre
L’exécution d’un ordre de travail consiste en
D’une part une phase d’exécution
D’autre part une action d’envoi du produit fabriqué
Ces deux phases peuvent être faites en même temps (pour deux ordres de travail différents)
La machine ne peut exécuter qu’un seul ordre à la fois.

On demande de modéliser le fonctionnement d’une telle machine à l’aide d’un RdP.
Question 1.2. Modélisation d’un atelier de fabrication
On considère maintenant un atelier de fabrication composé de trois machines M1, M2 et M3 répondant chacune au cahier des charges ci-dessus. Cet atelier est géré par deux opérateurs F1 et F2 tels que F1 est habilité à faire fonctionner les machines M1 et M2, tandis que F2 est habilité à faire fonctionner M1 et M3.

Les ordres de fabrication arrivant dans l’atelier nécessitent deux étapes de fabrication.
D’une part une étape par la machine M1
D’autre part une étape par l’une quelconque des deux machines M2 ou M3
Ces étapes de fabrication peuvent être gérées par l’un quelconque des deux opérateurs. Il n’est pas nécessaire que les deux étapes de fabrication soient gérées par le même opérateur.

Comme précédemment, une machine ne peut répondre qu’à un seul ordre à la fois. De même, un opérateur ne peut faire fonctionner qu’une seule machine à la fois.

On demande de modéliser l’ensemble du système par un réseau de Petri global.
Question 2. Protocole Producteur – Consommateur
On considère deux tâches « producteur » et « consommateur », la première produisant des données pour la seconde. Ces deux tâches correspondent à des processus indépendants qui sont activés indépendamment. Elles communiquent via un médium du type « buffer ». On supposera que ce médium est fiable, c’est-à-dire qu’il ne perd aucun message (ce point sera étudié à la question 3).

Le producteur suit schématiquement le scénario suivant :
Activation par un opérateur externe
Phase d’initialisation
Emission de N données dans le médium à destination du consommateur
Fin des émissions.

On notera que le rythme de production du producteur ne doit pas conduire à un débordement du médium. En particulier, si le médium est plein, le producteur devra attendre que celui-ci se libère avant de produire une nouvelle donnée.

De son coté, le consommateur suit schématiquement le scénario suivant :
Activation par un opérateur externe
Phase d’initialisation
Consommation des données envoyées par le producteur dans le médium
Déconnexion lorsque toutes les données ont été consommées.

On notera en particulier qu’à aucun moment le producteur n’a informé le consommateur du nombre N de données à produire.
Question 2.1. Médium = buffer à une case
On demande de modéliser ces deux tâches producteurs et consommateur en RdP dans le cas particulier d’un médium constitué d’un buffer à une seule case.
Question 2.2. Médium = buffer à K case
On demande de modéliser ces deux tâches producteurs et consommateur en RdP dans le cas particulier d’un médium constitué d’un buffer à K cases.
Question 3. Un service d’établissement de connexion
Le système de producteur consommateur ci-dessus s’appuie sur un service de connexion et d’échange de données comme indiqué par la figure 1.


figure 1. Modèles en couches

On demande de modéliser le protocole de niveau N (Protocole (N)) entre les deux (N)Entités des sites du producteur et du consommateur dans les cas suivants ;
Question 3.1.
Hypothèse : service N-1 parfait (pas de perte de (N)PDU)
Hypothèse : demande de connexion par le (N)E du site du producteur.

Sous ces hypothèses, le protocole que l’on demande de modéliser consiste en l’envoi d’un (N)PDU : Connection Request (CR) et d’un (N)PDU Deconnection Request (DR). L’entité appelante se considère connectée dès qu’elle a envoyé CR ; l’entité appelée est connectée dès qu’elle a reçue CR. De même, l’entité appelante se considère déconnectée dès qu’elle a envoyé DR ; l’entité appelée est connectée dès qu’elle a reçue DR.
Question 3.2.
Hypothèse : service N-1 parfait (pas de perte de (N)PDU)
Hypothèse : demande de connexion possible par les deux (N)E.

Dans ce cas, les deux N(E) peuvent être initiateurs de la demande de connexion. Comme précédemment, le protocole que l’on demande de modéliser consiste en l’envoi d’un (N)PDU : Connection Request (CR) et d’un (N)PDU Deconnection Request (DR).

Dans un premier temps on généralisera simplement le protocole proposé à la question 3.1. Cette généralisation est-elle satisfaisante ?

Dans un deuxième temps, on mettra en œuvre un schéma d’échange du type « poignée de main » : l’entité initiateur attend une réponse avant de se considérer comme connectée ; l’entité appelée se considère comme connectée dès qu’elle a envoyé une réponse. Par contre, en ce qui concerne la phase de déconnexion, le protocole reste identique à celui de la question 3.1. : l’entité appelante se considère déconnectée dès qu’elle a envoyé DR ; l’entité appelée est connectée dès qu’elle a reçue DR.

M1 Info (TD du cours RdP ENSEEIHT)

PAGE 



Page  PAGE 3 sur  NUMPAGES 3 2008-2009

M1 Info. (TD du Cours RdP ENSEEIHT)

Page  PAGE 1 sur  NUMPAGES 3 2008-2009