cours message

7/25/2019 Cours Message

1/49

1

Le dveloppement de protocoles

de communication en modemessage asynchrone

G. Florin


2/49

2

INTRODUCTION

Le contrle rparti

Ensemble des mcanismes offerts unprogrammeur pour dvelopper des applicationsrparties

Utilisation de l'interface d'un systme rparti.

IPA"Interface de programmation

d'applications"API"Application Programming Interface"

Problmes poss:

-La concurrence, la synchronisation desactivits locales

-Les communications entre sites

(les interactions)


3/49

3

Diffrents styles d'interactions

Schma de complexit croissante:

Le mode message asynchrone

Le mode rendez-vousLe mode appel de procdure distante

Le mode mmoire virtuelle rpartie

Les protocoles coopratifs

...Construction d'API unifiant l'approche objet etles interactions:

Les systmes d'objets rpartis


4/49


5/49

5

Gnralits

- Mode de base de la communication.

- Offert par le plus grand nombre des IPArparties

- Le service comprend deux primitivesprincipales pour communiquer et sesynchroniser (couches transport).

TYPE COM_MESSAGE_ASYNCHRONE;

METHOD envoyer (id_metteur, id_rcepteur,

complments, message);METHODrecevoir (id_metteur, id_rcepteur,

complments, message);METHOD...;

ENDCOM_MESSAGE_ASYNCHRONE.

identificateurs: portscomplments: qualits de services (selon dessmantiques multiples)messages: zones de donnes.


6/49

6

Exemples d'IPA distribues en mode

message asynchrone

Presque toutes les interfaces des architectures

"ouvertes" de rseaux(pour presque tous les niveaux)

- Internet, OSI, SNA

Presque toutes les interfaces des systmes

rpartis classiques,- Chorus , Mach, Amoeba

De nombreux langages de programmations

- Langages de spcifications de protocoles

(Estelle, ...)- Langages "acteurs" de l'intelligenceartificielle distribue (Act1, ...)Exceptions : les produits orients RPC, objet,partage de mmoire.


7/49

7

Variantes smantiques du mode messageasynchrone

- Proprits de synchronisation

La synchronisation locale

La synchronisation inter-sites.

- Nature des entitscommunicantes

point point, diffusion

mode alternat, bidirectionnel

- Proprits d'ordre.local, global, causal

- Proprits de tolrance aux pannes.

messages, sites

-Proprits temporellesdbits, dlai, variation de dlai

"Cours de rseaux habituels"


8/49

8

Les proprits de synchronisation

Le mode message asynchrone ralise un"producteur-consommateur" rpartientreun metteur et un rcepteur.

Site A Site B

Envoyer

Recevoir Prestataire duservice rseau

Asynchronisme entre sites distants.- propagation sur le rseau

Synchronisation locale sur les tampons

d'mission et de rception.


9/49

9

A) La synchronisation inter-sites

Aspect principal: l'asynchronisme entrel'metteur et le rcepteur

Emetteur Rcepteur

Emettre (M2)

Actif

Actif

Actif

Recevoir(M)

Emettre (M3)

Recevoir(M)

M1

M2

M3

M=M3

Emettre (M1)

Actif Recevoir(M)

(M=M2)

Actif

Actif

(M=M1)


10/49

10

Dtails du comportement

L'metteur

. Ayant demand une mission, reprend lamain et continue son excution" immdiatement"aprs la prise en compte desa demande.

. Le message est transmis (au rythme dutransport d'informations par le rseau decommunication) donc de faon asynchroneavec le comportement metteur.

Le rcepteurAyant dcid de prendre en compte un nouveaumessage il acquiert un message (le premier) eninstance.

-Celui qui se prsente aprs le recevoir-Un message qui se trouve dans une filed'attente de rception.


11/49

11

B)La synchronisation locale

Synchronisation sur l'interface de

programmation d'application.

Primitives envoyer "bloquantes" "nonbloquantes"

Le processus metteur a fourni l'adresse d'untampon (contenant un message) partag avec leprestataire.

. Cas 1 :

L'metteur reste bloqu tant que le message n'apas t envoy => le tampon est redevenu libre.

. Cas 2 :

L'metteur reste bloqu tant que le message n'apas t recopi dans une file d'attente du

prestataire.. Cas 3 :

L'metteur reprend la main alors que leprestataire utilise le tampon. Il est averti par unsignal de la fin d'utilisation => il peut le

rutiliser.


12/49

12

Primitives recevoir "bloquantes" "nonbloquantes"

Le processus rcepteur a fourni l'adresse d'untampon au prestataire

. Cas 1 : Recevoir bloquant

Le rcepteur reste bloqu tant qu'un message

reu n'a pas t crit.. Cas 2 : Recevoir non bloquant + attente

Le rcepteur continue son excution et sebloque quand il ne peut plus ne pas disposerd'un message reu.

. Cas 3 : Recevoir non bloquant + primitivede test de message

Le rcepteur continue mais il peut savoir si unmessage reu existe.

. Cas 4 : Rception conditionnelleLe rcepteur reprend toujours la main avec unmessage reu ou avec un diagnostic.


13/49

13

L'utilisation du mode message asynchrone

En gnral deux aspects simultanmentraliss:

Invocation d'action distante

La nature de l'action est dfinie par le typagedu message.

La nature de l'action dclenche dpend ducontexte dans lequel le message est pris encompte.

(Ide de contexte ou d'tat)

("Acte de langage")

Transport d'informations dans la partiedonnes du message

Action "d'information"

Paramtrage d'excution distante.


14/49


15/49


16/49

16

Proprit minimale de cohrence deschanges de donnes par message

asynchrone: la causalit

mettre/crire (M)->recevoir/lire(M)

t1 : metteur.crire (M)

=> t2>t1 : recepteur.lire (M)

Les messages ne remontent pas le temps

Proprits supplmentaires de cohrence

(proprits temporelles et propritsd'ordre).

mode rendez-vous,

mode appel de procdure

mode mmoire rpartie.


17/49

17

Seconde partie

Spcification des applications utilisant lemode message asynchrone


18/49


19/49


20/49


21/49


22/49


23/49

23

Reprsentation des transitions.

Etat de contrle antcdentPrdicatdfinissant l'tat

! action:comportementassoci la transition

Prdicat dfinisant lesconnaissances aprs la

transition

?condition: prdicatdfinissant les conditionsde dclenchement de la

transition

Etat initialI

F Progression del'algorithme

Etat de contrle consquent

Partie condition ougarde

Partie action de latransition


24/49

24

Les commandes d'changes

- Notation des oprations envoyer, recevoir

::= !

::= ?

Dsignation

La commande d'mission doit dsigner undestinataire (P2).

Ex : Dans le processus P1 :P2!M1La commande de rception (excute par un

processus P2) doit voquer une source P1.

Ex : Dans le processus P2 :P1?M1

Remarque: Dans le cas d'une communicationpoint point absence d'ambigut => pas dedsignation.


25/49


26/49

26

Typage

Il doit y avoir correspondance de type entre lemessage reu (la variable de rception) et lemessage mis (la valeur mise).

Donnes d'un message =

variable de type article.

Type[message_mis]=

Type [message_reu]

Si le type d'un message reu n'est pas prvu larception:

Erreur: "rception non spcifie".


27/49

27

Smantique de l'alternative constitue parl'existence de plusieurs transitions en un tat

- valuation des gardes

. Une garde est franchissable si elle estconstitue par une expression boolenne

portant sur des variables locales valeur vrai.

. Une garde est franchissables'il s'agit d'une

commande d'change satisfaite : en fait unerception dont le processus source faitparvenir un message du type attendu qui setrouve en tte de la file d'attente.

. Une garde combinaison des deux casprcdents.


28/49


29/49

29

Alternative en un tat

Aspect squentiel des automates

- On choisit l'une des transitions ayant sacondition boolenne satisfaite (sa garde

ouverte).

Indterminisme de l'valuation

- Si plusieurs conditions sont simultanment

vrifies l'une quelconque des transitions peut-tre slectionne

- La liste des commandes associe la gardeest excute.

La modlisation doit tenir compte de cettecaractristique majeure.


30/49


31/49


32/49


33/49


34/49


35/49


36/49


37/49


38/49


39/49

39

Gestion des files d'interactions

vnements systmes locaux: retombesignaux d'horloge

vnements distants :arrive d'lments protocolaires

vnements requtes de service:arrive d'lments de service

Entitprestataire

Service

Protocole

Horlo e


40/49

40

Validation des spcifications

Problmes de constructions

Rceptions non spcifies

Dans un tat un message peut se prsenter dontle cas n'a pas t prvu

Interblocages

Dans un tat un message (ou une configuration)est attendu qui ne peut jamais se prsenter.

Plus gnralement

Dfinition d'assertions de bon fonctionnementsur le modle automates communicants.

- assertions portant sur des variables d'tat(boolennes)

- assertions portant sur des trajectoires(logique temporelle)


41/49


42/49

42

Analyse exhaustive.

- L'application est dfinie par un ensembled'automates communicants

- Ralisation du produit des automates (produit"synchronis" tenant compte descommunications).

P1

P2!x

Ei

P2

P1?x

Ej

Automates communicants

Ei * Ej

Ei+1 Ej+1

?cond1?cond1

Ei+1*Ej+1

!action1 !action2

?cond2cond2

!action2!action1

Produit synchronis

- Obtention du graphe d'accessibilit dusystme complet.

- Vrification d'assertions sur le graphecomplet.

Difficult majeure

Explosion combinatoire de la taille des espacesd'tat.


43/49


44/49

44

SDL ' Specification and DescriptionLanguage ' ITU-T Z100

Notation graphique (et aussi langage) pourdcrire des entits rseaux sous la formed'automates synchroniss.

Commentaire: Recevoir M1 ou M2, si M1envoyer A ou B de faon indterministe. Si M2incrmenter un compteur et envoyer C.

M2M1

Un_processus_SDL

S1

Any CPT:=CPT+1

S1 S2

CA B


45/49


46/49


47/49


48/49


49/49

Conclusion : mode message asynchrone

- C'est le mode le plus basique

Comparable l'assembleur

Ralisation d'instructions

d'affectation, de branchement.- Le moins contraignant il permet auxutilisateurs par des changes successifs, laconstruction de tout type de protocole.

- L'utilisateur n'a pas en gnral envie d'tre

oblig de construire ses propres outils d'o:Le besoin d'autres schmas prdfinis pluscomplexes.

L'enrichissement du mode message en termes

de qualit de service par des couchessuccessives.

- Ce mode est encore le mode privilgi desinterfaces rseaux.

cours message

Documents