Vous êtes sur la page 1sur 49

Le dveloppement de protocoles

de communication en mode
message asynchrone

G. Florin

INTRODUCTION
Le contrle rparti
Ensemble des mcanismes offerts un
programmeur pour dvelopper des applications
rparties
Utilisation de l'interface d'un systme rparti.
IPA "Interface de programmation
d'applications"
API "Application Programming Interface"
Problmes poss:
-La concurrence,
activits locales

la

synchronisation

-Les communications entre sites


(les interactions)

des

Diffrents styles d'interactions


Schma de complexit croissante:
Le mode message asynchrone
Le mode rendez-vous
Le mode appel de procdure distante
Le mode mmoire virtuelle rpartie
Les protocoles coopratifs
...
Construction d'API unifiant l'approche objet et
les interactions:
Les systmes d'objets rpartis

Premire partie
Le mode message asynchrone
Rappel de quelques points essentiels

Gnralits
- Mode de base de la communication.
- Offert par le plus grand nombre des IPA
rparties
- Le service comprend deux primitives
principales pour communiquer et se
synchroniser (couches transport).
TYPE COM_MESSAGE_ASYNCHRONE;
METHOD envoyer

(id_metteur, id_rcepteur,
complments, message);
METHOD recevoir (id_metteur, id_rcepteur,
complments, message);
METHOD ...;
END COM_MESSAGE_ASYNCHRONE.

identificateurs : ports
complments: qualits de services (selon des
smantiques multiples)
messages: zones de donnes.

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'intelligence
artificielle distribue (Act1, ...)
Exceptions : les produits orients RPC, objet,
partage de mmoire.

Variantes smantiques du mode message


asynchrone
- Proprits de synchronisation
La synchronisation locale
La synchronisation inter-sites.
- Nature des entits communicantes
point point, diffusion
mode alternat, bidirectionnel
- Proprits d'ordre.
local, global, causal
- Proprits de tolrance aux pannes.
messages, sites
- Proprits temporelles
dbits, dlai, variation de dlai
"Cours de rseaux habituels"

Les proprits de synchronisation

Le mode message asynchrone ralise un


"producteur-consommateur" rparti entre
un metteur et un rcepteur.

Envoyer

Recevoir
Site A

Prestataire du
service rseau Site B

Asynchronisme entre sites distants.


- propagation sur le rseau
Synchronisation locale sur
d'mission et de rception.
8

les

tampons

A) La synchronisation inter-sites
Aspect principal: l'asynchronisme entre
l'metteur et le rcepteur
Emettre (M1)

M1

Actif

M2

Recevoir(M)
(M=M1)

Actif
Emettre (M2)

Actif
Actif
Emettre (M3)

M3
Recevoir(M)
M=M3

Actif

Actif

Recevoir(M)
(M=M2)
Rcepteur

Emetteur

Dtails du comportement
L'metteur
. Ayant demand une mission, reprend la
main
et
continue
son
excution
"immdiatement" aprs la prise en compte de
sa demande.

. Le message est transmis (au rythme du


transport d'informations par le rseau de
communication) donc de faon asynchrone
avec le comportement metteur.
Le rcepteur

Ayant dcid de prendre en compte un nouveau


message il acquiert un message (le premier) en
instance.
-Celui qui se prsente aprs le recevoir
-Un message qui se trouve dans une file
d'attente de rception.

10

B) La synchronisation locale
Synchronisation sur l'interface de
programmation d'application.
Primitives envoyer "bloquantes" "non
bloquantes"

Le processus metteur a fourni l'adresse d'un


tampon (contenant un message) partag avec le
prestataire.
. Cas 1 :

L'metteur reste bloqu tant que le message n'a


pas t envoy => le tampon est redevenu libre.
. Cas 2 :

L'metteur reste bloqu tant que le message n'a


pas t recopi dans une file d'attente du
prestataire.
. Cas 3 :

L'metteur reprend la main alors que le


prestataire utilise le tampon. Il est averti par un
signal de la fin d'utilisation => il peut le
rutiliser.
11

Primitives recevoir "bloquantes" "non


bloquantes"

Le processus rcepteur a fourni l'adresse d'un


tampon 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 se


bloque quand il ne peut plus ne pas disposer
d'un message reu.
. Cas 3 : Recevoir non bloquant + primitive
de test de message

Le rcepteur continue mais il peut savoir si un


message reu existe.
. Cas 4 : Rception conditionnelle

Le rcepteur reprend toujours la main avec un


message reu ou avec un diagnostic.

12

L'utilisation du mode message asynchrone

En gnral deux aspects simultanment


raliss:
Invocation d'action distante

La nature de l'action est dfinie par le typage


du message.
La nature de l'action dclenche dpend du
contexte dans lequel le message est pris en
compte.
(Ide de contexte ou d'tat)
("Acte de langage")
Transport d'informations dans la partie
donnes du message

Action "d'information"
Paramtrage d'excution distante.

13

Smantique de l'activation
L'change en mode message asynchrone
permet de dfinir des structures de contrle
classiques en univers rparti

a) Activation en parallle
("fork")

D'une activit distance puisque en mode


normal l'metteur et le rcepteur continuent leur
excution aprs l'interaction envoyer recevoir.
b) Branchement inconditionnel ("goto")
Une activit distance s'excute aprs l'activit
locale si l'metteur se suspend dfinitivement
(wait) aprs l'mission.

14

Smantique d'change de donnes

- Le mode message permet une opration


d'affectation distance d'une variable M (de
type article):
mettre (M) = crire (M) (vers dest)
recevoir (M) = lire (M) ( de emet)
. Avec possibilit de vrification de cohrence
des types des variables (si type(M) achemin).
. Avec une smantique de consistance des
donnes entre l'metteur et le rcepteur trs
faible.
Reposant
sur
les
proprits
d'ordre,
temporelles, de tolrance aux pannes spcifies
par la qualit de service.

15

Proprit minimale de cohrence des


changes 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 proprits
d'ordre).

mode rendez-vous,
mode appel de procdure
mode mmoire rpartie.

16

Seconde partie
Spcification des applications utilisant le
mode message asynchrone

17

Objectifs

Dfinir des mthodes formelles de spcification


des applications rseaux en mode message
asynchrone.
(FDT "Formal Description Techniques")
=> Processus squentiels
=> Communicants par messages
Comportement squentiel des processus

=> Les mthodes de spcification utilisent des


automates d'tat fini.
=> Chaque entit communicante
reprsente par son automate d'tat.

est

Interactions communication par messages

=> Les automates sont synchroniss pour la


reprsentation des changes de messages.

18

Reprsentation des applications: automates

Une modlisation tat/transition.


tats

Chaque tat doit tre aisment interprtable


en terme d'volution locale de l'application
rpartie.
- Il reprsente un point d'avancement du contrle.
- Il est dfini par un ensemble significatif de
variables locales de chaque processus. Il peut
recevoir:
- un identifiant bien choisi
- un commentaire
- le prdicat sur les variables

En_cours

-- Mode normal de
transfert sans erreurs
connexion_ouverte

19

rejet

Identification des tats

tape
prliminaire
spcification:

importante

de

la

. Pas un niveau de dtail trop fin (illisible, trop


grand nombre d'tats).
. Pas un niveau de dtail trop gros
Tout est modlis dans les transitions.
Reprsentation graphique de l'volution au
niveau permettant l'observation de la
synchronisation.

20

Transitions.

Elles comportent deux mentions:


la condition dclenchante ,
l'action raliser.
Elles sont reprsentes par les arcs du graphe
associ l'automate conduisant d'un tat initial
un tat final.
Conditions ou gardes

Les transitions sont franchissables lorsqu'une


condition boolenne ou garde est satisfaite:
. condition boolenne portant sur les
variables locales.
. condition boolenne portant sur les
messages entrants.
. condition boolenne portant sur des
d'vnements internes (horloges)

21

Action

- C'est l'opration ralise


franchissement de la transition.

lors

du

les traitements raliser lors du passage l'tat


suivant
affectation de variables,
envoi de messages.
- Le dtail des actions ne doit pas tre trop
important sinon le modle est illisible
Sinon renvoyer des textes annexs la
spcification.

22

Reprsentation des transitions.

Prdicat
dfinissant l'tat

Etat de contrle antcdent


Etat initial

?condition: prdicat
dfinissant les conditions
de dclenchement de la
transition

Partie condition ou
garde

! action:comportement
associ la transition

Partie action de la
transition

Prdicat dfinisant les Etat de contrle consquent


connaissances aprs la
Progression de
transition
l'algorithme

23

Les commandes d'changes


- Notation des oprations envoyer, recevoir

<mission> ::= <dest> ! <message>


<rception> ::= <source> ? <message>
Dsignation

La commande d'mission doit dsigner un


destinataire (P2).
Ex : Dans le processus P1 :P2!M1
La 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 communication
point point absence d'ambigut => pas de
dsignation.

24

Utilisation de canaux

- Trs souvent la dsignation se fait au moyen


de canaux (terminologie des langages de
description de protocoles) qui sont ensuite
connects pour raliser une architecture.
Ex : mission sur canalX : canalX!M
Rception sur canalY : canalY?M
Canal X
Entit 1

Canal Y
Entit 2

La dfinition d'architecture consiste spcifier


ensuite une liaison entre canalX et canalY.

25

Typage

Il doit y avoir correspondance de type entre le


message reu (la variable de rception) et le
message 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 la
rception:
Erreur: "rception non spcifie".

26

Smantique de l'alternative constitue par


l'existence de plusieurs transitions en un tat
- valuation des gardes

. Une garde est franchissable si elle est


constitue par une expression boolenne
portant sur des variables locales valeur vrai.
. Une garde est franchissable s'il s'agit d'une
commande d'change satisfaite : en fait une
rception dont le processus source fait
parvenir un message du type attendu qui se
trouve en tte de la file d'attente.
. Une garde combinaison des deux cas
prcdents.

27

Alternative en un tat
Indterminisme de comportement

Indterminisme aspect fondamental du rseau.


- en un mme tat plusieurs messages (ou
vnements) peuvent arriver.
- l'un des messages est plac en tte de la file
de rception.
- ce sont les alas de fonctionnement des
matriels et des logiciels, les choix effectus qui
conduisent souvent l'interclassement dans la file
d'entre.

Etat_i
? message1
? message2

28

? message3

Alternative en un tat
Aspect squentiel des automates

- On choisit l'une des transitions ayant sa


condition boolenne satisfaite (sa garde
ouverte).
Indterminisme de l'valuation

- Si plusieurs conditions sont simultanment


vrifies l'une quelconque des transitions peuttre slectionne
- La liste des commandes associe la garde
est excute.
La modlisation doit tenir compte de cette
caractristique majeure.

29

Schmas persistants

Si deux messages peuvent tre reu en un tat


et que leur rception ne modifie pas les
conditions de fonctionnement ultrieures
=> leur rception doit continuer tre prvue.

Etat_i
?message1
!action1

? message2
!action2

Etat_j

Etat_k

?message2
!action2

? message1
!action1
Etat_l

30

Alternative en un tat
Smantique en cas d'attente

- Aucune garde n'est franchissable mais il existe


des gardes avec condition de rception pouvant
tre satisfaite par une mission d'un site distant.
=> Attente que l'une d'elles soit satisfaite.
- Aucune garde n'est franchissable et elles sont
toutes boolennes.
=> Fin du programme
Probable erreur d'excution.
- Aucune garde ne pourra plus jamais tre
franchie (certaines sont des attentes de
message).
=> Fin du programme
Erreur: interblocage de message.

31

Diffrents automates
Le service
Dfinit les changes entre un prestataire
(fournisseur) et un utilisateur d'un service.
. tablissement de la liste des units de
service (primitives, SDU) changs entre le
prestataire et l'utilisateur (niveau n et niveau
n+1).

. Dfinition des enchanements autoriss


de primitives sous la forme d'un automate d'tat.
=> Toutes les successions lgales qu'un
observateur de l'interface n n+1 peut observer.
=> Deux points de vue duaux:
- le prestataire du service
- l'utilisateur du service

32

Exemple de comportements autoriss dans


une entit de liaison: lments de connexion.
lments du service de connexion
avec accord confirm

Connect.request
Connect.indication
Connect.response (cas d'accord)
ou Disconnect.request (cas de rejet)
Connect.confirmation (accord)
ou Disconnect.indication (rejet)

33

Automate du service

?Disconnect_request
hors
connexion

?Connect_request
!Connect_indication
?Connect_
request
connexion
demi
ouverte
distante

! Disconnect_
indication

! Disconnect_
indication
?disconnect_
request

?disconnect_
request

! Disconnect_
indication
?Connect_response

?Connect_
request
connexion
demi
ouverte
locale

?disconnect_
request
!Connect_confirm

connexion
ouverte

34

?Connect_request

Le protocole
Dfinit les changes entre deux prestataires
de mme niveau.
. tablissement de la liste des units de
protocole (messages, PDU) changs entre deux
niveaux n.

. Dfinition des suites d'changes qu'un


observateur de la voie de communication entre
les deux niveaux n peut observer.
=> Toutes les successions lgales d'lments de
protocole observables sur la voie logique de
communication n <--> n.

35

lments du protocole de liaison en


phase de connexion

Demande d'ouverture
SABM
"Set Asynchronous Balanced Mode"
Demande de fermeture
DISC
"Disconnect"
Accus de rception non numrot
UA
"Unnumbered Acknowledge"

36

Automate du protocole de
connexion

Vision partielle
?DISC

hors
connexion

!UA
?SABM

!UA

!UA
!SABM

connexion
demi
ouverte
distante

?DISC

?DISC
!UA

connexion
demi
ouverte
locale
?UA

?DISC

!UA
connexion
ouverte

37

?SABM
!UA

Automate complet
. Runion des deux automates de service et
de protocole

Vision partielle

hors
connexion

?SABM

?Connect_request

!Connect_indication
! Disconnect_
indication
?DM

?Connect_response

!SABM

connexion
demi
ouverte

?UA

!UA

!Connect_confirm
connexion
ouverte

38

Gestion des files d'interactions

vnements systmes locaux:


signaux d'horloge

retombe

vnements distants :
arrive d'lments protocolaires
vnements requtes de service:
arrive d'lments de service

Service
Entit
prestataire

Protocole

Horloge

39

Validation des spcifications


Problmes de constructions
Rceptions non spcifies

Dans un tat un message peut se prsenter dont


le 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 fonctionnement


sur le modle automates communicants.
- assertions portant sur des variables d'tat
(boolennes)
- assertions portant sur des trajectoires
(logique temporelle)

40

Mthodes de validation systmatiques


employes
Simulation comportementale

Excution en simulation du comportement


dcrit par les automates: une partie seulement
des comportements sont couverts.
Dtection d'erreurs et correction (technique
s'apparentant au test du modle).
Difficult majeure : On ne connat pas la
couverture du test (le taux d'erreurs rsiduelles
aprs le test).

Exemple d'outil: Estelle- VEDA

41

Analyse exhaustive.

- L'application est dfinie par un ensemble


d'automates communicants
- Ralisation du produit des automates (produit
"synchronis"
tenant
compte
des
communications).
P1

P2

Ei

Ej
?cond1
P2!x
!action1

Ei+1

Ei * Ej
?cond2
P1?x
!action2

?cond1

cond2

!action1
!action2

Ej+1

Ei+1*Ej+1
Automates communicants
Produit synchronis

- Obtention du graphe d'accessibilit du


systme complet.
- Vrification d'assertions sur le graphe
complet.
Difficult majeure

Explosion combinatoire de la taille des espaces


d'tat.

42

Normes dans le domaine des rseaux


MSC ' Message State Charts ' ITU-T Z120

- Scnario d'change de messages pour dcrire


des protocoles rseaux (ordre des messages,
utilisation des temporisateurs )
Utilisateur

Hors
connexion
Appel
lanc
Traitement
en cours
Appel
dlivr
Actif

UNI User
to Network
Interface

Rseau (ATM)

SETUP

Hors
connexion

CALL PROCEEDING

Appel
lanc

ALERTING

Traitement
en cours

CONNECT

Appel
dlivr

CONNECT ACK

43

Actif

SDL ' Specification and Description


Language ' ITU-T Z100

Notation graphique (et aussi langage) pour


dcrire des entits rseaux sous la forme
d'automates synchroniss.
Un_processus_SDL
S1

M1

M2

Any

CPT:=CPT+1
C

A
S1

S2

Commentaire: Recevoir M1 ou M2, si M1


envoyer A ou B de faon indterministe. Si M2
incrmenter un compteur et envoyer C.

44

TTCN ' Testing and Test Control Notation '


ITU-T Z140

Une notation graphique langage pour dcrire


des squences de test d'une entit rseau.
Cas_test_1
!M2
?C

pass

?OTHERWISE

fail

Commentaire : Pour tester l'entit SDL


prcdente, mettre M2, la rception de C est
alors correcte (le test continue), toute autre
rception est une erreur.

45

Normes dans le domaine UML 'Unified


Modelling Language'
MSC ' Message Sequence Charts '

- Mme forme que les 'Message State Charts'.


- Utilisation trs frquente pour dcrire les
interfaces de service sous forme de cas
d'utilisations ('use cases')

46

UML : Harel Statecharts

Une modlisation tat/transition d'un systme


avec beaucoup de possibilits (complexit):
. regroupement d'tat:modlisation hirarchique
avec gestion des vnements externes.
. concurrence (oprateurs, fork, merge)
E1

C4/A4

C3/A3
C1/A1
C2/A2
C3/A3

E2

E3

C6/A6

Un modle tat transition (conditions/actions)


C4/A4

E1
C1/A1
C2/A2

C3/A3

E2

E3

C6/A6

Le mme modle en statecharts de Harel.


'UML Statecharts' : une variante de Harel.
47

UML : PSM 'Protocol State Machines'


Objectif : Modliser le comportement collectif
des mthodes d'un objet (en fait modliser le
service).

. un ensemble d'tats.
. un ensemble de transitions tiquetes avec une
expression boolenne (garde) et une invocation
de mthode.

Repos
A: ouvrir()

A: fermer()

A: fermer()

Lecture
A: lire()

A: crire()
A: lire()

Ecriture
A: crire()

Autres diagrammes UML : 'activity', 'action


semantics', SDL.
48

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 aux
utilisateurs par des changes successifs, la
construction 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 plus
complexes.
L'enrichissement du mode message en termes
de qualit de service par des couches
successives.
- Ce mode est encore le mode privilgi des
interfaces rseaux.

49