cours_apd.pdf

7/25/2019 Cours_APD.pdf

1/91

1

Lappel de procdure distante

RPC Remote Procedure Call

Grard Florin- CNAM -- Laboratoire CEDRIC -


2/91

2

PlanIntroduction

Mise en oeuvre de lappel de procdure distanteGestion du contrle

Gestion des donnes

Transmission des arguments (prsentation)Dsignation/liaison

Tolrance aux pannes

Conclusion

Bibliographie


3/91

3

Introduction


4/91

4

Lapproche client-serveur en appelLapproche client-serveur en appelLapproche client-serveur en appelLapproche client-serveur en appel

de procdure distantede procdure distantede procdure distantede procdure distante Mode de ralisation duneinteraction client serveur

ou l'opration raliser est prsente sous la forme d'une procdure

que le clientpeut faire excuter distance par le serveur.

Service basique (API dappel de procdure distante)

/* Cot client : invoque gnre lappel distant et rcupre le rsultat*/invoque (id_client, id_serveur, nom_procedure, paramtres);

/* Cot serveur : reoit, traite un appel et rpond */traite (id_client, id_serveur, nom_procedure, paramtres);

Service intgr objet/* Cot client : on invoque une procdure localise distance*/

ref_objet_serveur.nom_procedure (paramtres);

/* Cot serveur : on dploie lobjet qui implante la procdure*/method nom_procedure (paramtres);


5/91

5

Avantage majeur de lapproche client-Avantage majeur de lapproche client-Avantage majeur de lapproche client-Avantage majeur de lapproche client-

serveur en appel de procdure distanteserveur en appel de procdure distanteserveur en appel de procdure distanteserveur en appel de procdure distante Saffranchir du cot basique des communications en

mode message.

Ne pas avoir programmer des changes au niveau rseau en modemessage

Ne pas utiliser pour construire une application rpartie des schmas de

contrle trop simples (affectation dans cohrence, fork)

Utiliser une structure familire: lappel de procdure.

Problme: ne pas ignorer les diffrences centralis/rparti.

Disposer de mcanismes modernes de programmation.

Vision modulaire des applications rparties (en approche objets rpartis

ou par composants sur tagres). Rutilisation par dlgation en univers rparti.


6/91

6

Les implantations de lappel deLes implantations de lappel deLes implantations de lappel deLes implantations de lappel de

procdure distante (1)procdure distante (1)procdure distante (1)procdure distante (1)

Les approches RPC traditionnelles

SUN ONC/RPC Open Network Computing / Remote Procedure Call

OSF DCE

Open Software Foundation - Distributed Computing Environnment

Systmes de gestion de bases de donnes: procduresstockes.


7/91

7


procdure distante (2)procdure distante (2)procdure distante (2)procdure distante (2)Approches RPC intgres dans les

systmes dobjets rpartis

OMG CORBA Object Management Group - Common Object Request Broker

Architecture

SUN Java RMI

Remote Method Invocation Microsoft - DCOM

Distributed Component Object Model


8/91

8


procdure distante (3)procdure distante (3)procdure distante (3)procdure distante (3)

Approches RPC intgres dans les

systmes de composants

SUN J2EE EJB Java 2 (Platform) Enterprise Edition - Enterprise Java Beans

OMG CCM Object Management Group - Corba Component Model

WS-SOAP Web Services - Simple Object Access Protocol


9/91

9

Mise en oeuvre delappel de procdure

distante

A) Par migration.B) Par mmoire partage.

C) Par messages.

D) Par appel lger.


10/91

10

A) RalisationA) RalisationA) RalisationA) Ralisation de lappel dede lappel dede lappel dede lappel de

procdure distante par migrationprocdure distante par migrationprocdure distante par migrationprocdure distante par migration

Stratgie de migration:Le code et les donnes de la

procdure distante sont amens sur le site appelant pour ytre excuts par un appel local habituel.

Analogie : stratgie de pr-chargementen mmoire.

Avantages

Trs efficace pour de nombreux appels.

Inconvnients

Univers dexcutions homognes (ex machine virtuelle).

Performances selon le volume de codes et de donnes.

Problmes de partage des objets (fermeture dobjets, ).


11/91

11

B) RalisationB) RalisationB) RalisationB) Ralisation de lappel de procdurede lappel de procdurede lappel de procdurede lappel de procdure

distante en mmoire partage rpartiedistante en mmoire partage rpartiedistante en mmoire partage rpartiedistante en mmoire partage rpartie

L'appel distant est ralis en utilisant une mmoire virtuelle

partage rpartie. La procdure est installe pour le client comme pour le

serveur dans la mmoire partage rpartie.

Elle est en fait dans lespace rel du serveur. L'appel du client se fait comme si la procdure tait locale,

provoquant un premier dfaut de pagesur le dbut du code

de la procdure. Le code et les donnes de la procdure distante sont amens

page par page sur le site appelant selon le parcours ducode et des donnes.

Analogie avec une stratgie page la demande.


12/91

12

RalisationRalisationRalisationRalisation de lappel de procdurede lappel de procdurede lappel de procdurede lappel de procdure

distante en mmoire partage rpartiedistante en mmoire partage rpartiedistante en mmoire partage rpartiedistante en mmoire partage rpartie

Avantages

Efficace en cas de nombreux appels. Efficace si tout le code et les donnes ne sont pas visits.

Rsout le problme de lutilisation des pointeurs (rfrencesdadresses en mmoire).

Inconvnients

Univers de systmes homognes.

Volume de codes et de donnes changer pages par pages.

Problmes de partage selon cohrence de la mmoire rpartie.


13/91

13

C) RalisationC) RalisationC) RalisationC) Ralisation de lappel de procdurede lappel de procdurede lappel de procdurede lappel de procdure

distante par messages asynchronesdistante par messages asynchronesdistante par messages asynchronesdistante par messages asynchrones

Deux messages (au moins) changs: requte et rponse.

CLIENT SERVEUR

Debut

Fin

n_proc(p_in,p_out);

procedure n_proc(p_in,p_out)

Appel(p_in)

Retour(p_out)

Client

Requtes

File dattente requtes

Slection serveur

Serveur1

Rponses

Serveur2

Rponses


14/91

14

Notion deNotion deNotion deNotion de souchessouchessouchessouches

Un mode de ralisation par interception ( wrapping )

Une procdure intercepteur ( wrapper) intercepte lappel dun clientvers un serveur et modifie le traitement serveur sa guise.

Dcomposition en intercepteur cot client et intercepteur cot serveur.

Dcomposition en traitements avant et aprs le traitement serveur.

Souches: transformation dun appel local en appeldistant.

Objectif de gnration automatique des souchesconnaissant le profil d appel de la procdure distante.

Trs nombreuse terminologie dans ce cas :Souches("Stubs"), Talons, Squelettes ("Skeletons")...


15/91

15

LesLesLesLes souches: diagramme globalsouches: diagramme globalsouches: diagramme globalsouches: diagramme global

dinteractiondinteractiondinteractiondinteraction

Proc_1

Proc_2

tatSite serveurSite client

.

.appelSouche

serveur

Souche

client

rf

Rfrence distante + mthode + paramtres

Paramtres rsultats / exception

Client


16/91

16

Souches client et serveurSouches client et serveurSouches client et serveurSouches client et serveur

La souche client (client stub)

Procdure cot client qui reoit lappel en mode local

Le transforme en appel distant

En envoyant un message

Reoit le message contenant les rsultats aprs l'excution Retourne les rsultats comme dans un retour de procdure.

La souche serveur (server stub)

Procdure cot serveur qui reoit le message d appel,

Fait raliser lexcution sur le site serveur par la procdure serveur

Rcupre les rsultats et retransmet les rsultats par message.


17/91

17

LLLLes tapes dun appel de procdurees tapes dun appel de procdurees tapes dun appel de procdurees tapes dun appel de procdure

distante par messagesdistante par messagesdistante par messagesdistante par messages

transport client

souche client

client

transport serveur

souche serveur

serveur

1

2

10

9

3

8

6 5

7 4


18/91

18

Avantages/inconvnients de lappelAvantages/inconvnients de lappelAvantages/inconvnients de lappelAvantages/inconvnients de lappel

distant ralis par messagesdistant ralis par messagesdistant ralis par messagesdistant ralis par messages

Avantages

Volume de code ou de donnes serveur quelconque. Applicable en univers htrognes moyennant des

conversions.

Partage daccs sur le site serveur analogue autransactionnel.

Inconvnients Pas dusage des pointeurs dans les paramtres. change de donnes complexes/de grande taille dlicat.

Peu efficace pour de trs nombreux appels.


19/91

19

D) RalisationD) RalisationD) RalisationD) Ralisation de lappel de procdurede lappel de procdurede lappel de procdurede lappel de procdure

distante lger (distante lger (

distante lger (

distante lger (

lightweightlightweightlightweightlightweight RPC)RPC

)RPC

)RPC)

Problme de performances: quand on invoque un serveurqui se trouve sur la mme machine la traverse des couchesrseaux est inutile et coteuse.

Si le serveur se trouve dans le mme processus(mme

domaine de protection) pas de problme (appel local). Si le serveur se trouve dans un autre processus(autre

domaine de protection)

Solution propose: la communication rseau est ralise par unsegment de mmoire partage entre le client et le serveur qui contientun tas pour les paramtres d'appel et de rponse.


20/91

20

Schma gnralSchma gnralSchma gnralSchma gnral de lappel dede lappel dede lappel dede lappel de

procdure distante lgerprocdure distante lgerprocdure distante lgerprocdure distante lger

Domaine client

Souche client

Domaine serveur

Souche serveur

Segment

partag

call s

Noyau du systme

method s

Contrle Donne


21/91

21

Avantages Inconvnients: RPC lgerAvantages Inconvnients: RPC lgerAvantages Inconvnients: RPC lgerAvantages Inconvnients: RPC lger

Avantages

Transmission dappel trs performant comme modede RPC local.

Inconvnients

Uniquement applicable aux RPC du mme site.

C C


22/91

22

Conclusion ralisation de lappel deConclusion ralisation de lappel deConclusion ralisation de lappel deConclusion ralisation de lappel de

procdure distanteprocdure distanteprocdure distanteprocdure distante

Lappel est dabord dvelopp en

invocation distante par messages. Supporte l'htrognit

Finalement le plus simple raliser.

RPC, DCE, CORBA, RMI, DCOM, SOAP

Des optimisations peuvent tre obtenuespar l'usage opportun des autres solutions.

Exemple: Chorus a dvelopp les quatre solutions.

Exemple: DCOM RPC par messages + RPC lger(aussi prvu en CORBA).


23/91

23

Gestion du contrle

I) Paralllisme chez le client

II) Paralllisme chez le serveur

III) Structures de contrle rparti parcomposition dappels distants

I) P llli h l li t A l d


24/91

24

I) Paralllisme chez le client :Appel deprocdure distante en mode synchrone

L'excution du client est suspendue tant que la rponse du

serveur n'est pas revenue ou qu'une condition d'exceptionn'a pas entran un traitement spcifique.

Avantage: le flot de contrle est le mme que dansl'appel en mode centralis

Inconvnient: le client reste inactif.

CLIENT SERVEUR

Appel

Retour

Debut

Fin

proc(...)procedure proc

client

bloqu

serveur

actif

Une solution au problme de linactivitUne solution au problme de linactivitUne solution au problme de linactivitUne solution au problme de linactivit


25/91

25

Une solution au problme de linactivitUne solution au problme de linactivitUne solution au problme de linactivitUne solution au problme de linactivit

du client: utilisation des activitsdu client: utilisation des activitsdu client: utilisation des activitsdu client: utilisation des activits

Cration de (au moins) deux activits ( threads ) surle site client

L'une occupe le site appelantpar un travail faire. L'autre gre lappel en mode synchroneen restant

bloque: Le fonctionnement est exactement celui d'unappel habituel.

CLIENT SERVEUR

Appel

Retour

Debut

Fin

proc(...)

procedure proc

Activit 2

bloque

serveur actif

Activit 2Activit 1

A l d d di t t dA l d d di t t dA l d d di t t dA l d d di t t d


26/91

26

Appel de procdure distante en modeAppel de procdure distante en modeAppel de procdure distante en modeAppel de procdure distante en mode

asynchroneasynchroneasynchroneasynchrone

Le client poursuit son excution immdiatement aprsl'mission du message porteur de l'appel.

La procdure distante s'excute en parallleavec lapoursuite du client.

Le client doit rcuprer les rsultats quand il en abesoin (primitive spciale).

CLIENT SERVEUR

Appel

Retour

Debut

Fin

proc(...)

procedure proc

client

actif

serveur

actif

Rcupration

des rsultats

Rcupration des rsultats en modeRc pration des rs ltats en modeRc pration des rs ltats en modeRcupration des rsultats en mode


27/91

27

Rcupration des rsultats en modeRcupration des rsultats en modeRcupration des rsultats en modeRcupration des rsultats en mode

asynchrone: notion de futurs explicitesasynchrone: notion de futurs explicitesasynchrone: notion de futurs explicitesasynchrone: notion de futurs explicites

Un futur : une structure de donne (un objet) permettant dercuprer des rsultats.

Notion de futur explicite

Les structures de donnes sont dfinies par le client avant

lappel (le serveur les connat et y dpose les rsultats). Exemple: En ACT++ une boite lettre dfinie par le client sert

de moyen de communication pour les paramtres rsultats.

BAL := factorielle.calculfact(n) resultat := BAL.prlever()



28/91

28


asynchrone: notion de futurs implicitesasynchrone: notion de futurs implicitesasynchrone: notion de futurs implicitesasynchrone: notion de futurs implicites

Invocation asynchrone futur implicite

Les structures de donnes de communication pour lesrponses (ex boite lettre) sont implicitement crspar leprestataire du service d'APD asynchrone.

Approche gnrale: dfaut d'information (analogie dfautde page en mmoire virtuelle).

La lecture de la structure de donne rsultat bloque le

client s'il accde la rponse et que celle-ci n'est pasparvenue.

Lusager ne saperoit de rien (si le rsultat est parvenu ou

s il nest pas parvenu).

Cas particulier du mode asynchrone:Cas particulier du mode asynchrone:Cas particulier du mode asynchrone:Cas particulier du mode asynchrone:


29/91

29

Cas particulier du mode asynchrone:Cas particulier du mode asynchrone:Cas particulier du mode asynchrone:Cas particulier du mode asynchrone:

invocation asynchrone sens uniqueinvocation asynchrone sens uniqueinvocation asynchrone sens uniqueinvocation asynchrone sens unique

Invocation asynchrone sans rponse (autreterminologie, "peut-tre", "oneway" , "maybe")

Invocation asynchrone utilis pour dclencher une procdurequi ne retourne pas de rsultats. Pour obtenir un dialogue il

faut prvoir dautres procdures en sens inverse. Avantage: Utilisation d'un mode appel de procdure pour

des communications sont en fait de mode message.

Inconvnients : Uniquement possible en l'absence de retourde rsultat, pas d'informations sur la terminaison du travaildemand.

Exemples: CORBA oneway.

II) Paralllisme chez le serveur :II) Paralllisme chez le serveur :II) Paralllisme chez le serveur :II) Paralllisme chez le serveur :


30/91

30

II) Paralllisme chez le serveur :II) Paralllisme chez le serveur :II) Paralllisme chez le serveur :II) Paralllisme chez le serveur :

Excution squentielle des appelsExcution squentielle des appelsExcution squentielle des appelsExcution squentielle des appels

Les requtes dexcution sont traites lune aprs lautre par leserveur: exclusion mutuelle entre les traitements.

Si la couche transport assure la livraison en squence et quelon gre une file dattente premier arriv premier servi, on aun traitement ordonndes suites dappels.

Exemple RPC SUN: traitement squentiel des requtes maisutilisation de UDP => requtes non ordonnes (mais mode

synchrone le client attend la fin du traitement). Autres exem les: les RPC ont un mode s uentiel ex CORBA

Client

Requtes

File dattente requtes

Serveur

Rponses

File dattente rponses


31/91

31

Excution parallle des appelsExcution parallle des appelsExcution parallle des appelsExcution parallle des appels

Dans ce mode le serveur cr un processusou uneactivit(un processus lger ou thread) par appel

(gestion possible de pool de processus ou d activits). Les appels sont excuts concurremment.

Si les procdures manipulent des donnes globalesrmanentes sur le site serveur, le contrle deconcurrence doit tre gr.

Exemple : Corba Notion dadaptateur dobjets.Client

Requtes

Gestion des serveurs

Serveur1

Serveur2

Rponses

Client

III) Schmas de contrle: compositionIII) Schmas de contrle: compositionIII) Schmas de contrle: compositionIII) Schmas de contrle: composition


32/91

32

III) Schmas de contrle: compositionIII) Schmas de contrle: compositionIII) Schmas de contrle: compositionIII) Schmas de contrle: composition

dappels distants en squencedappels distants en squencedappels distants en squencedappels distants en squence

A) Schma appel en cascade synchroneA) Schma appel en cascade synchroneA) Schma appel en cascade synchroneA) Schma appel en cascade synchrone

Dduit immdiatement de lappel de procdure distante synchrone

Code appel1

Client Site1 Site 2

Appel

synchrone du

destinataire etasynchrone des

intermdiaires

Code appel 2

B) Schma de continuation asynchrone:B) Schma de continuation asynchrone:B) Schma de continuation asynchrone:B) Schma de continuation asynchrone:


33/91

33

B) Schma de continuation asynchrone:B) Schma de continuation asynchrone:B) Schma de continuation asynchrone:B) Schma de continuation asynchrone:

appels en cascade asynchroneappels en cascade asynchroneappels en cascade asynchroneappels en cascade asynchrone

Codedestinataire1

Client Destinataire1 Destinataire2

Appel

asynchrone

destinataire1

puis

destinataire n

Code

destinataire n

Baptis schma continuation en mode asynchrone. Lmetteur prpare uneliste de procdures destinataires invoquer en mode asynchrone. Lemessage dappel visite successivement les destinataires.

Analogie avec le routage par la source en mode messageImplantation: protocole SOAP en mode message.

C) Schma de continuation asynchroneC) Schma de continuation asynchroneC) Schma de continuation asynchroneC) Schma de continuation asynchrone


34/91

34

C) Schma de continuation asynchroneC) Schma de continuation asynchroneC) Schma de continuation asynchroneC) Schma de continuation asynchrone

avec appel synchrone pour le clientavec appel synchrone pour le clientavec appel synchrone pour le clientavec appel synchrone pour le client

Codeintermdiaire1

Client Intermdiaire1 Destinataire

Appelsynchrone du

destinataire et

asynchrone desintermdiaires

Code

destinataire

Le premier schma continuation propos. Une liste dintermdiaires enmode asynchrone et un destinataire final : le tout en mode synchrone

pour le client.Implantation: protocole SOAP en mode RPC.

D) Schma de continuation asynchroneD) Schma de continuation asynchroneD) Schma de continuation asynchroneD) Schma de continuation asynchrone


35/91

35

D) Schma de continuation asynchroneD) Schma de continuation asynchroneD) Schma de continuation asynchroneD) Schma de continuation asynchrone

en appel et en rponseen appel et en rponseen appel et en rponseen appel et en rponse

Une liste dintermdiaires en mode asynchrone est possible lappel comme

la rponse : le tout en mode synchrone pour le client.Implantation: protocole SOAP en mode RPC.

Codeintermdiaire

appel

Client

Destinataire

Appelsynchrone du

destinataire et

asynchrone desintermdiaires

Codedestinataire

Code

intermdiaire

Retour

Schmas de contrle par compositionSchmas de contrle par compositionSchmas de contrle par compositionSchmas de contrle par composition


36/91

36


parallle dappels distants (1)parallle dappels distants (1)parallle dappels distants (1)parallle dappels distants (1)

Notion de RPC asynchrone sur groupe

Code

destinataire 2

Client Destinataire N

Appel

asynchrone

en parallle

de n

destinataires

Code

destinataire N

Destinataire 1

Code

destinataire 1

Destinataire 2



37/91

37


parallle dappels distants (2)parallle dappels distants (2)parallle dappels distants (2)parallle dappels distants (2)

Notion de RPC synchrone sur groupe

(autre nom RPC diffus, RPC parallle)

Codedestinataire 2

Client Destinataire N

Appel

synchrone en

parallle de ndestinataires

Code

destinataire N

Destinataire 1

Code

destinataire 1

Destinataire 2

Proprits dordre dans lesProprits dordre dans lesProprits dordre dans lesProprits dordre dans les


38/91

38

Proprits d ordre dans lesProprits d ordre dans lesProprits d ordre dans lesProprits d ordre dans les

communications par RPCcommunications par RPCcommunications par RPCcommunications par RPC

L'appel de procdure distante peut comporter desspcifications de proprits d'ordre.

Le respect d'une proprit d'ordre peut porter:

sur le lancement de la procdure (peut utilisable)

sur la totalit de son excution. Ordre local: Les excutions pour un client sont ralises dans

l'ordre d'mission.

Ordre global: Les excutions pour un client sont ralisesdans le mme ordre sur tous les destinataires (cas descommunications de groupe).

Ordre causal: Les excutions sont effectues en respectant larelation de causalit qui existe entre les requtes.


39/91

39

Gestion des donnesGestion des donnesGestion des donnesGestion des donnes

I) Gestion des donnes applicativespersistantes.

II) Gestion des donnes protocolairespersistantes.

Gestion des donnesGestion des donnesGestion des donnesGestion des donnes applicativesapplicativesapplicativesapplicatives


40/91

40

pppppppp

sans donnes partages persistantessans donnes partages persistantessans donnes partages persistantessans donnes partages persistantes

Donnes locales la procdure : pas de problme.

Donnes applicatives partages (variables dinstance, fichiers,bases de donnes) : problme de persistance.

Sans donnes partages persistantes

Situation idale du cas ou lappel de procdure s'excute enfonction uniquement des paramtres dentre: en produisantuniquement des paramtres rsultats.

Exemple: fonction scientifique (EJB session stateless). Il ny a pas de modification de donnes rmanentessur

le site serveur.

Pas de problmepour la tolrance aux pannes etpour lecontrle de concurrence

Gestion des donnesGestion des donnesGestion des donnesGestion des donnes applicativesapplicativesapplicativesapplicatives


41/91

41

pppppppp

partages persistantes

Les excutions successivesmanipulent des donnespersistantessur le site serveur.

Une excution modifie le contexte sur le site distant(un serveur de fichier rparti, de bases de donnes.Oprations d'criture de donnes persistantes, la structure

de donne manipule par les mthodes d'un objet).=> Problme de contrle de concurrence.

=> Problme des pannes en cours d'excution. Solution: le couplage d'une gestion transactionnelle avec

une approche RPC (ou systme d'objets rpartis).

Exemple: EJB Session stateful (un seul client), EJBEntity (plusieurs clients)

Gestion des donnes protocolaires:Gestion des donnes protocolaires:Gestion des donnes protocolaires:Gestion des donnes protocolaires:


42/91

42

pppp

notion de mode avec ou sans tatnotion de mode avec ou sans tatnotion de mode avec ou sans tatnotion de mode avec ou sans tat

Autre aspect de larmanencedes donnes sur le serveur.

La terminologie avec ou sans tat porte sur l'existence ounon dun descriptifpour chaque relation client serveur auniveau du serveur.

Notion dtat: un ensemble de donnes rmanentes auniveau du protocole pour chaque relation client serveur.

Permettrait de traiter les requtes dans lordre dmission.

Permettrait de traiter une requte en fonction des caractristiques dela relation client serveur (qualit de service).

En fait une notion identique celle du descriptif de

connexionchez le serveur dans une communication enmode connect.


43/91

43

Mode sans tatMode sans tatMode sans tatMode sans tat

Les appels successifs dune mme procdure s'excutentsans liensentre eux.

Il peut y avoir modification de donnes globalesrmanentes sur le site serveur mais chaque oprationdupoint de vue du protocole seffectue sans rfrence aupass (indpendamment de toutes celles qui ont prcd).

Ex:NFS Network File System de SUN systme de fichierrparti bas sur RPC sans tat. Lecture/criture du nimearticle dun fichier dont toutes les caractristiques utiles(nom, droit daccs) sont passes au moment de lappel.

Ex: HTTP HyperText Transfer Protocol protocoledexcution de mthodes distantes sans tat.


44/91

44

Mode avec tatMode avec tatMode avec tatMode avec tat

Les appels successifs s'excutent en fonction dun tat dela relation client serveurlaiss par les appels antrieurs.

Exemple dutilisation : la gestion de l'ordre de traitementdes requtes, la gestion de caractristiques du client.

Exemple systme de fichier en RPC: Lecture darticle defichier sur le pointeur courant.


45/91

45

Mode avec ou sans connexionMode avec ou sans connexionMode avec ou sans connexionMode avec ou sans connexion

Rappel gestion des connexions:

Dlimitation temporelle des requtes et desexcutions de procdure entre des oprationsdouverture et de fermeture.

Maintien dun descriptif de connexion sur le clientet sur le serveur pour la gestion de paramtrescaractristiques de la connexion : qualit de

service, traitement des pannes, proprits d'ordre,... )

Dfinition dune rfrence (dune dsignation) de

connexion

Appel de procdure distante sansAppel de procdure distante sansAppel de procdure distante sansAppel de procdure distante sans


46/91

46

connexionconnexionconnexionconnexion

Dans ce mode le client peut envoyer des appels au serveur nimporte quel moment.

Le client comme le serveur ne grent pas de descriptif de larelation client serveur : absence de mmoireentre appelssuccessifs.

Le mode sans connexion est donc un mode orient Vers un traitement sans gestion de qualit de service des

appel.

Vers le traitement dun grand nombre de clients: la gestion deconnexions est juge trop coteuse.

Exemple : tous les RPC

Appel de procdure distante avecAppel de procdure distante avecAppel de procdure distante avecAppel de procdure distante avec


47/91

47

connexionconnexionconnexionconnexion

Dans ce mode le client doit ouvrir une connexion avec leserveurpour effectuer des appels puis il doit fermer.

Exemple : prototypes recherche, pas dexemple industriel

connu. Si lon souhaite grer des RPC en mode connect il faut

construire cette gestion dans le cadre dune application

donne.


48/91

48

Transmission desTransmission desTransmission desTransmission des

argumentsargumentsargumentsarguments

I) La transmission par valeurII) Les autres modes de passage


49/91

49

Transmission par valeur: rappels (1)Transmission par valeur: rappels (1)Transmission par valeur: rappels (1)Transmission par valeur: rappels (1)

Le seul mode de transmission des donnes dans les messagesen rseau.

Si le site client et le site serveur utilisent des formatsde donnes diffrents: problme syntaxique => uneconversion est ncessaire.

La solution: notion de prsentation des donnes aumoyen dune syntaxe de transfert => une reprsentationlexicaledes donnes simples et une convention

dalignementdes donnes commune au client et au serveur. Dans le domaine des communications en mode message:

norme de reprsentation lexicale des donnes simples

BER ( Basic Encoding Rules ).


50/91

50

Transmission par valeur: rappels (2)Transmission par valeur: rappels (2)Transmission par valeur: rappels (2)Transmission par valeur: rappels (2)

Dfinir une syntaxe abstraite de donnes pivot:analogue des langages de description de donnes deslangages volus, facile gnrer pour un dveloppeurdapplication (en mode message ASN1 Abstract SyntaxNotation 1).

A partir de la syntaxe abstraite: codage/dcodagede lasyntaxe de transfert (technique de compilation, notionde compilateur de protocole).

Transmission par valeur dans lappel deTransmission par valeur dans lappel deTransmission par valeur dans lappel deTransmission par valeur dans lappel de

d di t td di t td di t td di t t


51/91

51

procdure distanteprocdure distanteprocdure distanteprocdure distante

En appel de procdure distante : gnration automatiquedu code des souches partir de la syntaxe abstraite,

les souches fabriquent la syntaxe de transferten ralisantlalignement des paramtres dans les messages( marshalling ).

Insuffisance des normes de syntaxe abstraite et desyntaxe de transfert en mode message asynchrone: ASN1/BER

Dfinition de nouveaux langages de syntaxe abstraite

adapts aux appels de procdure distante:IDL Interface Dfinition Language

Pour chaque IDL en gnral redfinitiondune syntaxe detransfert .

Motivation pour une classe de langagesMotivation pour une classe de langagesMotivation pour une classe de langagesMotivation pour une classe de langages

d t b t it IDLd t b t it IDLd t b t it IDLd t b t it IDL


52/91

52

de syntaxes abstraites : IDLde syntaxes abstraites : IDLde syntaxes abstraites : IDLde syntaxes abstraites : IDL

tre indpendant des langages volus utilisant le RPC

Permettre linvocation distante avec tout langage volu

Dfinition dun langage pivot de description de donnes ayant desfonctionnalits assez riches pour les langages les plus rcents.

Dfinition d un langage pivot qui permette de corriger les ambiguts

et les insuffisances des langages anciens (comme par exemple C). Notion de correspondance entre les types retenus dans l'IDL et les

types des diffrents langages existants ("mappings")

Motivation pour une classe de langagesMotivation pour une classe de langagesMotivation pour une classe de langagesMotivation pour une classe de langages

d t b t it IDLd t b t it IDLd t b t it IDLd t b t it IDL


53/91

53

de syntaxes abstraites : IDLde syntaxes abstraites : IDLde syntaxes abstraites : IDLde syntaxes abstraites : IDL

Permettre aux utilisateurs de dfinir un identifiant unique pourchaque interface afin de l'utiliser .

Supporter les caractristiques particulires des langages objets Exemple : permettre de dfinir des relations d'hritage entre dfinitions

d'interfaces.

ventuellement structurer les interfaces en modules.

U l IDL DCEU l IDL DCEU l IDL DCEU l IDL DCE


54/91

54

Un exemple en IDL DCEUn exemple en IDL DCEUn exemple en IDL DCEUn exemple en IDL DCE

/* Exemple documentation OSF Open Software Foundation */

[uuid (f9f8be80-2ba7-11c9-89fd-08002b13d58d), version(0),

endpoint("ncadg_ip_udp:[6677]", "dds:[19] )]interface bin_op

{

[idempotent] void bin_add{ [in] handle_t h,

[in] long a,

[in] long b,

[out] long *c

};

}

Un e emple en IDLU l IDLU l IDLUn e emple en IDL CorbaC bC bCorba


55/91

55

Un exemple en IDLUn exemple en IDLUn exemple en IDLUn exemple en IDL CorbaCorbaCorbaCorba

module StockObjects { struct Quote {

string symbol; long at_time; double price; long volume;}; exception Unknown{}; interface Stock { Quote get_quote() raises(Unknown); // lit la cotation. void set_quote(in Quote stock_quote); // crit la cotation};

interface StockFactory { Stock create_stock( in string symbol, in string description

);};};

G ti d h


56/91

56

Gnration des souches

Source code

client

Source code

serveur

Dfinition de

linterface en IDL

Compilateur IDL

Souche client Entte Souche serveur

Compilateur(C, java, ..)

Compilateur(C, java,..)


Binaireclient

Binairesouche client

Binaireserveur

Binaire soucheserveur


Quelques exemples dIDL et deQuelques exemples dIDL et deQuelques exemples dIDL et deQuelques exemples dIDL et de

format de prsentation en RPCformat de prsentation en RPCformat de prsentation en RPCformat de prsentation en RPC


57/91

57

format de prsentation en RPCformat de prsentation en RPCformat de prsentation en RPCformat de prsentation en RPC

SUN ONC/RPC XDR eXternal Data Representation

OSF DCE

IDL DCE - Format NDR Network Data Representation

OMG CORBA IDL Corba - Format CDR Common Data Representation, Protocole IIOP

SUN Java RMI

Langage Java - Protocole JRMP Java Remote Method Protocol Microsoft - DCOM

MIDL Microsoft IDL - DCOM Protocole ORPC Object RPC Format NDR

WS-SOAP WSDL Web Services Definition Language - XML

II) Autres modes de transmission :le passage par adresse (pointeurs)


58/91

58

le passage par adresse (pointeurs)

Le passage par adresse (par pointeur) utilise uneadresse mmoire centrale du site de l'appelant qui n'a

aucun sens sur l'appel (sauf cas particulier). Indispensable de traiter ce problme.

A) Interdiction totale des pointeurs

Dans la plupart des RPC, pas de passage desparamtres par adresse ou de structures de donnescontenant des pointeurs.

Introduit une diffrence dans le dveloppement deprocdures locales et celles destines un usage distant.

B) Simulation du passage par adresseB) Simulation du passage par adresseB) Simulation du passage par adresseB) Simulation du passage par adresse

en utilisant une copie restaurationcopie restaurationcopie restaurationcopie restauration


59/91

59

en utilisant une copie restauration.copie restauration.copie restauration.copie restauration.

Marche bien dans beaucoup de cas mais violation asseinacceptable dans certains cas de la smantique du passage.

Exemplede problme procduredouble_incr ( x , y ) ; x , y : entier; dbut

x := x + 1 ; y := y + 1 ; fin ;

Squence d'appel: passage par adresse

a := 0 ; double_incr ( a , a ) ; Rsultat attendu : a = 2

Utilisation d'une copie restauration Rsultat obtenu : a = 1

C) Passage par adresseC) Passage par adresseC) Passage par adresseC) Passage par adresse en mmoire

virtuelle partage rpartie


60/91

60

virtuelle partage rpartie

Faire raliser des accs mmoire inter-sites : mmoirevirtuelle partage rpartie

Solution trs satisfaisante mais galement trscoteuse.

Appel: Dfauts d'information mmoire serveur -> mmoire client

Retour: Dfauts d'information mmoire client -> mmoire serveur

Ncessit d'un systme rparti autorisant la mmoirevirtuelle rpartie (Chorus, Mach).

Ne se conoit que dans un systme rparti decalculateursde mme type.

Passage par nom (rfrences ouPassage par nom (rfrences ouPassage par nom (rfrences ouPassage par nom (rfrences ou

pointeurs d'objets)pointeurs d'objets)pointeurs d'objets)pointeurs d'objets)


61/91

61

pointeurs d objets)pointeurs d objets)pointeurs d objets)pointeurs d objets)

En approche objets rpartis utilisation des rfrencesd'objets.

Le passage d'un argument se fait en transmettant unerfrencesur l'objet en univers rparti (en CORBA IOR).

L'accs s'effectue au moyen des mthodes implantespar l'objet. Par exemple accs un attribut en lecture ouen criture.

Avantages inconvnients

Mcanisme universel.

Coteux pour des accs frquents.


62/91

62

Dsignation et liaisonDsignation et liaisonDsignation et liaisonDsignation et liaison

Dsignation


63/91

63

Dsignation

Comment sont structurs les noms et rfrences permettantde dsigner les services distants: Non symbolique : utilisable au moyen dun serveur dannuaire. Rfrence : une structure de donnes permettant de raliser

linvocation.

Rfrence : selon limplantation considre. Dsignation du protocole permettant laccs distant (TCP) Dsignation de lhte ou se trouve le serveur (adresse IP). Dsignation du point d accs de service transport (numro de port) Dsignation locale de lobjet ou se trouve la procdure. Dsignation de la procdure.

Liaison


64/91

64

Liaison

Comment localiser une procdure distante? Au moyen dun service de gestion de noms (serveur dannuaire)

A quel moment effectuer la liaison Le plus tard plus possible -> plus souple, moins performant Le plus tt possible -> plus performant

Ralisation de la liaison la compilation Vision trs statique, le serveur ne doit pas bouger.

Ralisation de la liaison en excution Au chargement du client Au moment de la premire invocation Localiser la procdure (rfrence), mettre en cache

Relocaliser chaque fois quil est ncessaire

Problmes de la Liaison


65/91

65

Problmes de la Liaison

Le serveur est-il disponible? Solution - fabrique de serveurs

Est ce que la version de linterface utilise est consistante? Solution - gestion d identificateurs uniques dinterface

(comportant des numros de version).

Existence de serveurs multiples Gestion d une technique dquilibrage de charge. Gestion de redondances (temporelles, massives).

Enregistrement dun serveur


66/91

66

Enregistrement d un serveur

Serveur

Souche

serveur

Adaptateu

(gestion

locale des

noms)

Export(nom)

Export(nom)

Enregistrer_local (nom)

Enregistrer_global (nom)

Site Serveur de nom

Ajouter_service(nom)

Retour

Retour

Site Serveur

Service de nom

(dannuaire)

Liaison client serveur


67/91

67

Liaison client serveur

Ref=import(nom)

Ref=import(nom)

Requte_annuaire (nom)

Vrifier (nom)

Recherche (nom)

Retour ref

Retour ref

Site Client

Service de nom

(dannuaire)

Site Serveur

Recherche

(nom)

Retour ref

Code

Souche

Adaptateur client


68/91

68

Tolrance auxTolrance auxTolrance auxTolrance aux

pannespannespannespannes

Comparaison appel local appel

distant


69/91

69

distant

En appel local

L'appelant et l'appel s'excutent sur la mme machine: mme

excutant => mmes performances et modes de pannes. L'appel et le retour de procdure sont des mcanismes internes

considrs comme fiables (sauf systmes scuritaires).

Problme abord les erreurs => exceptions chez l'appelant. En appel distant Appelant et appel peuvent tomber en panne

indpendamment. Le message d'appel ou celui de retour peuvent tre perdus(sauf si l'on emploie un protocole de transport fiable).

Le temps de rponse peut-tre trs long en raison desurcharges diverses (rseau, site appel).

Les diffrents modes de pannes :

les pannes franches du serveur


70/91

70

les pannes franches du serveur

1 - Attente indfinie par le client d'une rponse qui ne viendrajamais => Abandon du programme sur temps limite

2 - Utilisation d'un dlai de garde par le site appelant

=> Signalement de l'absence de rponse au client qui dcide de

la stratgie de reprise.=> Reprise arrire automatique (si possible)

soit tentative d'excution sur un autre site

soit reprise sur le mme site (si relance)

=> Plusieurs excutions successives de la mme

procdure pour une seule demande.


les pannes franches du client


71/91

71

les pannes franches du client

Le serveur est dit orphelin (orphan).

Ralisation de travaux inutiles, utilisation de ressources

qui ne sont plus accessibles pour des tches utiles. Confusion aprs relance du client entre les nouvelles

rponses attendues et les rponses d'anciennes requtes.

=> Ncessit de dtruire les tches serveurs orphelines et dedistinguer les requtes utiles des vieilles requtes.

Problmedes pannes franches Ltat du client ou du serveur peuvent devenir inconsistants

=> Analyse des modifications de ltat du client et duserveur.


les pertes de messages


72/91

72

es pe tes de essages

Cas facile: pertes traites par une couche transport fiable.

Cas difficile: il existe des RPC implants pour des raisons

d'efficacit au dessus dune communication non fiable(couche rseau sans connexion type UDP) => Mcanisme detraitement des pertes de message prvoir dans la

conception du RPC Ex : La rponse acquitte la demande

La prochaine requte acquitte la rponse.

Pour tolrer les pertes de messages on peut lancerplusieurs excutions de la mme requte.


les pannes temporelles


73/91

73

p p

Cas dun appel de procdure utilis sous contraintes dequalit de service temporelle

contraintes dune application temps rel (contrle de procd industriel) contraintes dune application multimdia.

Temps de rponse: La rponse doit parvenir avant une datelimite dfinie par une chance.

Variation du temps de rponse: La variation du temps detraitement doit tre borne.

Notion dORB ( Object request Broker ) temps rel en coursdtude. Gestion de priorits au niveau rparti, gestion

dchances intgrant les dlais rseaux.


les pannes quelconques


74/91

74

p q q

Cas dun appel de procdure utilis sous contraintes decriticit (systme critique)

Pas de spcificit particulire des protocoles de RPC

Application des techniques habituelles de redondances

massives: pour tolrer les dfaillances dun (ou de plusieurs)des serveurs redondants.

Formalisation des techniques de

reprise sur panne franche


75/91

75

p p

Procdure F appele distance: F

(C_avant, S_avant) ----> (C_aprs, S_aprs)tat des donnes tat des donnesclient serveur avant client serveur aprs

F dans son traitement modifie ltat du serveur.

(S_avant) -----> (S_aprs)

Les rsultats de lexcution de F en retour modifientaussi ltat du client.

(C_avant) -----> (C_aprs)

Techniques de reprise sur erreur : en cas de problmesrxcution: F(0), F(1),...., F(n)les tentatives successives

A) Reprise arrire complte


76/91

76

) p p

Les excutions successives du serveur peuvent laisser ltat duserveur indtermin (panne en cours d'excution).

Le client peut tre dans un tat incertain (panne au moment dela modification en retour des variables persistantes du client).

Solution maximale => Pour chaque tentative ltat du clientet celui du serveur doivent tre restaurs aux valeursavant le premier appel:

F(n)

(C_avant, S_avant) --> (C_aprs(n), S_aprs(n))

Validit de la reprise arrireValidit de la reprise arrireValidit de la reprise arrireValidit de la reprise arrire

compltecompltecompltecomplte


77/91

77

Cas d'une procdure dterministe

La reprise complte est correcte quelles que soient les pannes. Les tats aprs sont identiques puisque les excutions rptes

du code du serveur sur la mme donne produisent desrsultats identiques (la procdure produit un rsultat

dterministe).Cas d'une procdure indterministe

Les tats aprs sont potentiellement diffrentspuisque lesexcutions rptes donnent des rsultats qui dpendent ducontexte d'excution.

La reprise est correcte si les alas conduisant l'indterminisme du fonctionnement sont accepts.

B) Reprise arrire du serveur seulB) Reprise arrire du serveur seulB) Reprise arrire du serveur seulB) Reprise arrire du serveur seul


78/91

78

Hypothse: Les rxcutions du serveur sont toujourscompltesou quivalent une excution complte correcte.

Par exemple retransmission dappel sur dlai de garde pour un moded'excution squentiel des appels distants

Il n'y a pas de perte de cohrence de l'tat du serveur(pas d'excutions partielles interrompues avec des variablesglobales rmanentes laisses incohrentes).

Fonctionnement de la reprise

Pas de sauvegarde de l'tat client: on peut s'en passer leclient ralise seulement l'criture des paramtres rsultats. Pas de sauvegarde de l'tat du serveur: Au moment

d'une tentative n l'tat du serveur est donc celui qui rsultede la dernire tentative n-1.

Reprise arrire du serveur seul:Reprise arrire du serveur seul:Reprise arrire du serveur seul:Reprise arrire du serveur seul:

condition lidempotencecondition lidempotencecondition lidempotencecondition lidempotence


79/91

79

Condition respecter

Les tats aprs sont conservs si des excutions rptes du

code du serveur sur les donnes rsultant de l'excutionprcdente produisent des rsultats identiques: F estidempotente F (F (x) )=F (x).

Exemples relatifs l'idempotence

F est idempotente si l'excution de la procdure ne modifiepas ltat du serveur (Ex :lecture du kime article dun fichier)

F est idempotente si ltat du serveur est modifi seulement la premire excution de F (Ex l'criture du kime article).

Lcriture en fin de fichier est une opration non idempotente. L'incrmentation d'une variable est non idem otente.

Rsum des techniques deRsum des techniques deRsum des techniques deRsum des techniques de

reprise arrirereprise arrirereprise arrirereprise arrire


80/91

80

Les trois attitudes concernant les reprises en RPC

A) Reprise arrire complte: mise uvre de techniques detype gestion transactionnelle.

B) Reprise arrire du serveur seul: uniquement valable sile serveur est une fonction idempotente sur son tat.

C) Tentatives de reprise hors des deux cas prcdents:interdiction totale.

Smantique du RPC du point de vue desSmantique du RPC du point de vue desSmantique du RPC du point de vue desSmantique du RPC du point de vue des

pannes serveurspannes serveurspannes serveurspannes serveurs


81/91

81

Smantique exactement une foisSmantique exactement une foisSmantique exactement une foisSmantique exactement une fois

Dfinition thorique:Une seule excution est effectue etcelle-ci russit toujours.

Impossible au sens strict: des lors quune hypothse depanne est formule.

Comportement souhait:le plus voisin possible de celui del'appel de procdure en mode centralis.

Une suite de n tentatives est effectue

Avec sauvegarde tat du client et du serveur avant chaque tentative.

Pour une procdure dterministe

Smantique : Au plus une foisSmantique : Au plus une foisSmantique : Au plus une foisSmantique : Au plus une fois


82/91

82

Cas d'une fonction quelconque (non idempotente): onne doit pas l'excuter deux fois.

Solution trs rpandue: garantir quon n excute pas deuxfois une mme procdure.

Identification des requtes + excution effectue une seule fois. . Si tout va bienle rsultat est retourn lutilisateur.

La requte ne sera plus excute (modulo le dlai de garde de

l'historique). . Si un problme est dtectIl est signal lutilisateur pour qu il

puisse ventuellement statuer).

Aucune tentative de reprise nest effectue automatiquement.Elle est laisse entirement la charge du client.

Smantique : Au moins une foisSmantique : Au moins une foisSmantique : Au moins une foisSmantique : Au moins une fois


83/91

83

On se place dans le cas ou chaque excution du serveur estralise sans sauvegarde de l'tat du serveur.

L'excution est lance plusieurs fois si ncessaire (dans unecertaine limite) pour obtenir une rponse correcte .

=> La procdure doit tre idempotente.

Variante: La dernire de toutes

On fait de plus l'hypothse que les appels sont numrotset traits squentiellement.

On est capable d'attribuer la russite de l'excution ladernire de toutes les tentatives.

Smantique du RPC du point de vueSmantique du RPC du point de vueSmantique du RPC du point de vueSmantique du RPC du point de vue

des pannes client (1)des pannes client (1)des pannes client (1)des pannes client (1)


84/91

84

Problme des serveurs en cas de panne du client

Abandonner le plus vite possible lexcution en cours. En laissant un tat cohrent sur le site serveur.

Extermination

Une approche de journalisation: La souche client note enmmoire stable tous les appels en cours.

Lorsqu'un site client est relanc: il doit examinerl'historique des appels en cours non termins et demande ladestruction de tous les serveurs orphelins encore actifs.




85/91

85

Rincarnation

Une technique de numros de squence:en fait unnumro d'poque correspondant aux priodes d'activitsuccessives du client.

Il doit tre enregistr en mmoire stable et doit marquertoutes les requtes.

Lorsqu'un client est relanc il change d'poque et diffuse sa

nouvelle poque ses serveurs qui dtruisent les appelsanciens.




86/91

86

Expiration

Une technique de dlais de garde : L'excution d'unserveur est toujours associe une surveillancepriodiquedu client : le serveur arme des dlais de garde.

Si le quantum s'achve, le serveur demande a sonclient s'il est encore oprationnel:

si le client rpond: armement d'un nouveau dlai et poursuite.

si le client est en panne: abandon cohrent d'excution.

Remarque : Cette technique permet la fois la surveillance duclient par le serveur et celle du serveur par le client.


87/91

87

Conclusion

Les avantages de lappel de procdureLes avantages de lappel de procdureLes avantages de lappel de procdureLes avantages de lappel de procdure

distantedistantedistantedistante


88/91

88

De plus haut niveau que les communications en mode

message. Une structure de contrle bien connue, lappel de

procdure (mode de communication support naturel de

lapproche client-serveur). Qui sintgre lunivers rparti des concepts

modernes de gnie logiciel: approche objets,

approches composants Modularit, encapsulation, rutilisation par dlgation.

Les impressions trompeuses de lappelLes impressions trompeuses de lappelLes impressions trompeuses de lappelLes impressions trompeuses de lappel

de procdure distantede procdure distantede procdure distantede procdure distante


89/91

89

Une application en appel distant est une application

rpartie qui risque de prsenter un moment ou un autrepratiquement toutes les difficults systmes/rseaux: de conception.

de dsignationet de liaison.

de prsentationdes donnes changes. de synchronisation.

de contrle de concurrence. de tolrance aux pannes et de scurit.

de performances.

de disponibilit d'outils conviviaux.

Lappel de procdure distanteLappel de procdure distanteLappel de procdure distanteLappel de procdure distante


90/91

90

Pour:Le mode appel de procdure distante est en

dveloppement important pour la conception et laralisation de tous les types dapplicationsrparties.

Restriction:Le dveloppement de protocoles RPCintgrs aux approches langages, objets oucomposants devrait encore mobiliser longtemps lesnergies des chercheurs et des dveloppeurs.

BibliographieBibliographieBibliographieBibliographie


91/91

91

- A.D. Birell and B.J. Nelson, Implementing remote procedure calls ACMTrans on Comp Syst, vol. 2(1), pp 39-59, feb 84

- M. D. Schroeder and M. Burrows Performance of Firelly RPC ACM Trans.On Comp. Syst., vol. 8(1), pp 1-17, jan 90- B. Liskov and L. Shira Promises: linguistic Support for efficient

Asynchronous Procedure Calls in Distributed Systems Proc of SIGPLAN,

pp 260-267, 88- B.N. Bershad, T.E. Anderson, E.D. Lazowska and H.M. Levy Lightweight

remote procedure call ACM Trans. On Comp. Syst., vol. 8(1) pp 37-55,jan 90

- Satyanarayanan, H. Siegel Parallel communication in a large distributedenvironment ACM Trans. On Comp, vol 39(3), pp 328-348, mar 90

- A.S. Tannenbaum "Distributed Operating Systems" Prentice Hall

- W Rosenberry, D Kenney, G Fisher, Comprendre DCE, Addison Wesley

cours_apd.pdf

Documents