Lappel de procdure distante RPC Remote Procedure Call

Grard Florin - CNAM - Laboratoire CEDRIC -

Plan
Introduction Mise en oeuvre de lappel de procdure distante Gestion du contrle Gestion des donnes Transmission des arguments (prsentation) Dsignation/liaison Tolrance aux pannes Conclusion Bibliographie

Introduction

Lapproche client-serveur en appel de procdure distante

Mode de ralisation dune interaction client serveur
ou l'opration raliser est prsente sous la forme d'une procdure que le client peut 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);

Avantage majeur de lapproche clientserveur en appel de procdure distante

Saffranchir du cot basique des communications en mode message.
Ne pas avoir programmer des changes au niveau rseau en mode message 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.
5

Les implantations de lappel de 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: procdures stockes.

Les implantations de lappel de 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

Les implantations de lappel de 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

Mise en oeuvre de lappel de procdure distante

A) Par migration. B) Par mmoire partage. C) Par messages. D) Par appel lger.
9

A) Ralisation de lappel de procdure distante par migration

Stratgie de migration: Le code et les donnes de la procdure distante sont amens sur le site appelant pour y tre excuts par un appel local habituel. Analogie : stratgie de pr-chargement en 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, ).
10

B) Ralisation de lappel de procdure distante 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 page sur 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 du code et des donnes. 11 Analogie avec une stratgie page la demande.

Ralisation de lappel de procdure distante 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 (rfrences dadresses 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.
12

C) Ralisation de lappel de procdure distante par messages asynchrones

Deux messages (au moins) changs: requte et rponse.
n_proc(p_in, p_out); Appel(p_in) Retour(p_out) procedure n_proc (p_in,p_out) Debut Fin

CLIENT

SERVEUR

Rponses Requtes Client Slection serveur Serveur1 Rponses Serveur2

13

File dattente requtes

Notion de souches
Un mode de ralisation par interception ( wrapping )
Une procdure intercepteur ( wrapper) intercepte lappel dun client vers 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 appel distant. Objectif de gnration automatique des souches connaissant le profil d appel de la procdure distante. Trs nombreuse terminologie dans ce cas : Souches ("Stubs"), Talons, Squelettes ("Skeletons")...
14

Les souches: diagramme global dinteraction

Site client
rf

Site serveur
tat Proc_1

appel

Souche client

Client

Souche serveur

. Proc_2 .

Rfrence distante + mthode + paramtres Paramtres rsultats / exception

15

Souches 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.
16

Les tapes dun appel de procdure distante par messages

client 1 10 6

serveur 5

souche client 2 9 3 transport client 8

souche serveur 7 4

transport serveur

17

Avantages/inconvnients de lappel distant 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 au transactionnel. Inconvnients Pas dusage des pointeurs dans les paramtres. change de donnes complexes/de grande taille dlicat. Peu efficace pour de trs nombreux appels.
18

D) Ralisation de lappel de procdure distante lger (lightweight RPC) (lightweight

Problme de performances : quand on invoque un serveur qui se trouve sur la mme machine la traverse des couches rseaux 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 un segment de mmoire partage entre le client et le serveur qui contient un tas pour les paramtres d'appel et de rponse.

19

Schma gnral de lappel de procdure distante lger

Domaine client call s Domaine serveur method s Segment

partag Souche client Souche serveur

Noyau du systme Contrle Donne

20

Avantages Inconvnients: RPC lger

Avantages Transmission dappel trs performant comme mode de RPC local. Inconvnients Uniquement applicable aux RPC du mme site.

21

Conclusion ralisation de lappel de procdure 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 obtenues par l'usage opportun des autres solutions.
Exemple: Chorus a dvelopp les quatre solutions. Exemple: DCOM RPC par messages + RPC lger (aussi prvu en CORBA).
22

Gestion du contrle
I) Paralllisme chez le client II) Paralllisme chez le serveur III) Structures de contrle rparti par composition dappels distants

23

I) Paralllisme chez le client : Appel de procdure 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'exception n'a pas entran un traitement spcifique.
proc(...) client bloqu Appel Retour procedure proc Debut serveur SERVEUR actif Fin

CLIENT

Avantage: le flot de contrle est le mme que dans l'appel en mode centralis Inconvnient: le client reste inactif.
24

Une solution au problme de linactivit du client: utilisation des activits

Cration de (au moins) deux activits ( threads ) sur le site client L'une occupe le site appelant par un travail faire. L'autre gre lappel en mode synchrone en restant bloque: Le fonctionnement est exactement celui d'un appel habituel.
CLIENT
Appel Activit 1 Activit 2 proc(...) Activit 2 bloque

SERVEUR
procedure proc Debut serveur actif Fin

Retour

25

Appel de procdure distante en mode asynchrone

Le client poursuit son excution immdiatement aprs l'mission du message porteur de l'appel. La procdure distante s'excute en parallle avec la poursuite du client. Le client doit rcuprer les rsultats quand il en a besoin (primitive spciale).
CLIENT proc(...) client actif Rcupration des rsultats
26

Appel Retour

procedure proc Debut serveur SERVEUR actif Fin

Rcupration des rsultats en mode asynchrone: notion de futurs explicites

Un futur : une structure de donne (un objet) permettant de rcuprer 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()

27

Rcupration des rsultats en mode asynchrone: notion de futurs implicites

Invocation asynchrone futur implicite Les structures de donnes de communication pour les rponses (ex boite lettre) sont implicitement crs par le prestataire du service d'APD asynchrone. Approche gnrale: dfaut d'information (analogie dfaut de 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 pas parvenue. Lusager ne saperoit de rien (si le rsultat est parvenu ou s il nest pas parvenu).
28

Cas particulier du mode asynchrone: invocation asynchrone sens unique

Invocation asynchrone sans rponse (autre terminologie, "peut-tre", "oneway" , "maybe") Invocation asynchrone utilis pour dclencher une procdure qui 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 retour de rsultat, pas d'informations sur la terminaison du travail demand. Exemples: CORBA oneway.
29

II) Paralllisme chez le serveur : Excution squentielle des appels

Les requtes dexcution sont traites lune aprs lautre par le serveur: exclusion mutuelle entre les traitements. Si la couche transport assure la livraison en squence et que lon gre une file dattente premier arriv premier servi, on a un traitement ordonn des suites dappels.
Requtes Client File dattente requtes Rponses Serveur File dattente rponses

Exemple RPC SUN : traitement squentiel des requtes mais utilisation de UDP => requtes non ordonnes (mais mode synchrone le client attend la fin du traitement). Autres exemples: les RPC ont un mode squentiel (ex CORBA)
30

Excution parallle des appels

Dans ce mode le serveur cr un processus ou une activit (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 globales rmanentes sur le site serveur, le contrle de concurrence doit tre gr. Exemple : Corba Notion dadaptateur dobjets.
Requtes Client Client Serveur2
31

Serveur1 Gestion des serveurs Rponses

III) Schmas de contrle: composition dappels distants en squence A) Schma appel en cascade synchrone
Appel synchrone du destinataire et asynchrone des intermdiaires Code appel1 Code appel 2

Client

Site1

Site 2

Dduit immdiatement de lappel de procdure distante synchrone 32

B) Schma de continuation asynchrone: appels en cascade asynchrone

Appel asynchrone destinataire1 puis destinataire n Client Destinataire1 Destinataire2

Code destinataire1

Code destinataire n

Baptis schma continuation en mode asynchrone. Lmetteur prpare une liste de procdures destinataires invoquer en mode asynchrone. Le message dappel visite successivement les destinataires. Analogie avec le routage par la source en mode message Implantation: protocole SOAP en mode message. 33

C) Schma de continuation asynchrone avec appel synchrone pour le client

Appel synchrone du destinataire et asynchrone des intermdiaires Client

Code intermdiaire1

Code destinataire

Intermdiaire1

Destinataire

Le premier schma continuation propos. Une liste dintermdiaires en mode asynchrone et un destinataire final : le tout en mode synchrone pour le client. Implantation: protocole SOAP en mode RPC. 34

D) Schma de continuation asynchrone en appel et en rponse

Appel synchrone du destinataire et Code asynchrone des intermdiaire intermdiaires Retour Client

Code intermdiaire appel

Code destinataire

Destinataire

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.
35

Schmas de contrle par composition parallle dappels distants (1)

Notion de RPC asynchrone sur groupe

Appel asynchrone en parallle de n destinataires

Code destinataire 1

Code destinataire 2

Code destinataire N

Client

Destinataire 1 Destinataire 2

Destinataire N 36

Schmas de contrle par composition parallle dappels distants (2)

Notion de RPC synchrone sur groupe (autre nom RPC diffus, RPC parallle) Code destinataire 1 Appel synchrone en parallle de n destinataires

Code destinataire 2

Code destinataire N

Client

Destinataire 1 Destinataire 2

Destinataire N 37

Proprits dordre dans les communications par RPC

L'appel de procdure distante peut comporter des spcifications 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 ralises dans le mme ordre sur tous les destinataires (cas des communications de groupe). Ordre causal: Les excutions sont effectues en respectant la 38 relation de causalit qui existe entre les requtes.

Gestion des donnes

I) Gestion des donnes applicatives persistantes. II) Gestion des donnes protocolaires persistantes.

39

Gestion des donnes applicatives sans 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 en fonction uniquement des paramtres dentre: en produisant uniquement des paramtres rsultats. Exemple: fonction scientifique (EJB session stateless). Il ny a pas de modification de donnes rmanentes sur le site serveur. Pas de problme pour la tolrance aux pannes et pour le 40 contrle de concurrence

Gestion des donnes applicatives partages persistantes

Les excutions successives manipulent des donnes persistantes sur 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), EJB 41 Entity (plusieurs clients)

Gestion des donnes protocolaires: notion de mode avec ou sans tat

Autre aspect de la rmanence des donnes sur le serveur. La terminologie avec ou sans tat porte sur l'existence ou non dun descriptif pour chaque relation client serveur au niveau du serveur. Notion dtat : un ensemble de donnes rmanentes au niveau du protocole pour chaque relation client serveur.
Permettrait de traiter les requtes dans lordre dmission. Permettrait de traiter une requte en fonction des caractristiques de la relation client serveur (qualit de service).

En fait une notion identique celle du descriptif de connexion chez le serveur dans une communication en mode connect. 42

Mode sans tat

Les appels successifs dune mme procdure s'excutent sans liens entre eux. Il peut y avoir modification de donnes globales rmanentes sur le site serveur mais chaque opration du point de vue du protocole seffectue sans rfrence au pass (indpendamment de toutes celles qui ont prcd). Ex: NFS Network File System de SUN systme de fichier rparti bas sur RPC sans tat. Lecture/criture du nime article dun fichier dont toutes les caractristiques utiles (nom, droit daccs) sont passes au moment de lappel. Ex: HTTP HyperText Transfer Protocol dexcution de mthodes distantes sans tat. protocole
43

Mode avec tat

Les appels successifs s'excutent en fonction dun tat de la relation client serveur laiss par les appels antrieurs. Exemple dutilisation : la gestion de l'ordre de traitement des requtes, la gestion de caractristiques du client. Exemple systme de fichier en RPC: Lecture darticle de fichier sur le pointeur courant.

44

Mode avec ou sans connexion

Rappel gestion des connexions: Dlimitation temporelle des requtes et des excutions de procdure entre des oprations douverture et de fermeture. Maintien dun descriptif de connexion sur le client et sur le serveur pour la gestion de paramtres caractristiques de la connexion : qualit de service, traitement des pannes, proprits d'ordre, ... ) Dfinition dune rfrence (dune dsignation) de connexion
45

Appel de procdure distante sans connexion

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 la relation client serveur : absence de mmoire entre appels successifs. 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 de connexions est juge trop coteuse.

Exemple : tous les RPC

46

Appel de procdure distante avec connexion

Dans ce mode le client doit ouvrir une connexion avec le serveur pour 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.

47

Transmission des arguments

I) La transmission par valeur II) Les autres modes de passage

48

Transmission par valeur: rappels (1)

Le seul mode de transmission des donnes dans les messages en rseau. Si le site client et le site serveur utilisent des formats de donnes diffrents : problme syntaxique => une conversion est ncessaire. La solution: notion de prsentation des donnes au moyen dune syntaxe de transfert => une reprsentation lexicale des donnes simples et une convention dalignement des 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 ).
49

Transmission par valeur: rappels (2)

Dfinir une syntaxe abstraite de donnes pivot: analogue des langages de description de donnes des langages volus, facile gnrer pour un dveloppeur dapplication (en mode message ASN1 Abstract Syntax Notation 1). A partir de la syntaxe abstraite: codage/dcodage de la syntaxe de transfert (technique de compilation, notion de compilateur de protocole).

50

Transmission par valeur dans lappel de procdure distante

En appel de procdure distante : gnration automatique du code des souches partir de la syntaxe abstraite, les souches fabriquent la syntaxe de transfert en ralisant lalignement des paramtres dans les messages ( marshalling ). Insuffisance des normes de syntaxe abstraite et de syntaxe 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 redfinition dune syntaxe de transfert . 51

Motivation pour une classe de langages de 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 des fonctionnalits 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")

52

Motivation pour une classe de langages de syntaxes abstraites : IDL

Permettre aux utilisateurs de dfinir un identifiant unique pour chaque 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.

53

Un 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 }; }
54

Un exemple en IDL Corba

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 ); }; };

55

Gnration des souches

Source code client Dfinition de linterface en IDL Compilateur IDL Souche client Compilateur (C, java, ..) Binaire client Compilateur (C, java,..) Binaire souche client Entte Souche serveur Compilateur (C, java, ..) Binaire serveur 56 Source code serveur

Compilateur (C, java, ..) Binaire souche serveur

Quelques exemples dIDL et de format 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
57

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

Le passage par adresse (par pointeur) utilise une adresse 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 des paramtres par adresse ou de structures de donnes contenant des pointeurs. Introduit une diffrence dans le dveloppement de procdures locales et celles destines un usage distant.
58

B) Simulation du passage par adresse en utilisant une copie restauration.

Marche bien dans beaucoup de cas mais violation assez inacceptable dans certains cas de la smantique du passage. Exemple de problme
procdure double_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

59

C) Passage par adresse en mmoire virtuelle partage rpartie

Faire raliser des accs mmoire inter-sites : mmoire virtuelle partage rpartie Solution trs coteuse. satisfaisante mais galement trs

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

Ncessit d'un systme rparti autorisant la mmoire virtuelle rpartie (Chorus, Mach). Ne se conoit que dans un systme rparti de calculateurs de mme type.
60

Passage par nom (rfrences ou pointeurs d'objets)

En approche objets rpartis utilisation des rfrences d'objets. Le passage d'un argument se fait en transmettant une rfrence sur l'objet en univers rparti (en CORBA IOR). L'accs s'effectue au moyen des mthodes implantes par l'objet. Par exemple accs un attribut en lecture ou en criture. Avantages inconvnients Mcanisme universel. Coteux pour des accs frquents.
61

Dsignation et liaison

62

Dsignation
Comment sont structurs les noms et rfrences permettant de 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 Dsignation Dsignation Dsignation Dsignation du protocole permettant laccs distant (TCP) de lhte ou se trouve le serveur (adresse IP). du point d accs de service transport (numro de port) locale de lobjet ou se trouve la procdure. de la procdure.

63

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
64

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).

65

Enregistrement dun serveur

Site Serveur Export(nom) Site Serveur de nom Export(nom) Service de nom (dannuaire) Retour Enregistrer_local (nom) Enregistrer_global (nom) Retour Souche serveur Serveur

Ajouter_service(nom)

Adaptateur (gestion locale des noms)

66

Liaison client serveur

Site Client Ref=import(nom) Code Retour ref Ref=import(nom) Souche Retour ref Service de nom (dannuaire) Recherche (nom) Recherche (nom) Retour ref
67

Site Serveur

Requte_annuaire (nom) Vrifier (nom) Adaptateur client

Tolrance aux pannes

68

Comparaison appel local appel 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 de surcharges diverses (rseau, site appel).
69

Les diffrents modes de pannes : les pannes franches du serveur

1 - Attente indfinie par le client d'une rponse qui ne viendra jamais => 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.
70

Les diffrents modes de pannes : 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 de distinguer les requtes utiles des vieilles requtes. Problme des pannes franches Ltat du client ou du serveur peuvent devenir inconsistants => Analyse des modifications de ltat du client et du serveur.
71

Les diffrents modes de pannes : les pertes de messages

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 de traitement 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 lancer plusieurs excutions de la mme requte.
72

Les diffrents modes de pannes : les pannes temporelles

Cas dun appel de procdure utilis sous contraintes de qualit 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 date limite dfinie par une chance. Variation du temps de rponse: La variation du temps de traitement doit tre borne. Notion dORB ( Object request Broker ) temps rel en cours dtude. Gestion de priorits au niveau rparti, gestion dchances intgrant les dlais rseaux.
73

Les diffrents modes de pannes : les pannes quelconques

Cas dun appel de procdure utilis sous contraintes de criticit (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.

74

Formalisation des techniques de reprise sur panne franche

Procdure F appele distance: F (C_avant, S_avant) ----> (C_aprs, S_aprs) tat des donnes tat des donnes client 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 modifient aussi ltat du client. (C_avant) -----> (C_aprs) Techniques de reprise sur erreur : en cas de problmes rxcution: F(0) , F(1),...., F(n) les tentatives successives 75

A) Reprise arrire complte

Les excutions successives du serveur peuvent laisser ltat du serveur indtermin (panne en cours d'excution). Le client peut tre dans un tat incertain (panne au moment de la modification en retour des variables persistantes du client). Solution maximale => Pour chaque tentative ltat du client et celui du serveur doivent tre restaurs aux valeurs avant le premier appel: F(n) (C_avant, S_avant) --> (C_aprs(n), S_aprs(n))
76

Validit de la reprise arrire complte

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 des rsultats identiques (la procdure produit un rsultat dterministe). Cas d'une procdure indterministe Les tats aprs sont potentiellement diffrents puisque les excutions rptes donnent des rsultats qui dpendent du contexte d'excution. La reprise est correcte si les alas conduisant l'indterminisme du fonctionnement sont accepts. 77

B) Reprise arrire du serveur seul

Hypothse: Les rxcutions du serveur sont toujours compltes ou quivalent une excution complte correcte.
Par exemple retransmission dappel sur dlai de garde pour un mode d'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 variables globales rmanentes laisses incohrentes). Fonctionnement de la reprise Pas de sauvegarde de l'tat client: on peut s'en passer le client 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 rsulte de la dernire tentative n-1.
78

Reprise arrire du serveur seul: condition lidempotence

Condition respecter Les tats aprs sont conservs si des excutions rptes du code du serveur sur les donnes rsultant de l'excution prcdente produisent des rsultats identiques: F est idempotente F (F (x) )=F (x). Exemples relatifs l'idempotence F est idempotente si l'excution de la procdure ne modifie pas 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 idempotente.
79

Rsum des techniques de reprise arrire

Les trois attitudes concernant les reprises en RPC A) Reprise arrire complte : mise uvre de techniques de type gestion transactionnelle. B) Reprise arrire du serveur seul : uniquement valable si le serveur est une fonction idempotente sur son tat. C) Tentatives de reprise hors des deux cas prcdents: interdiction totale.

80

Smantique du RPC du point de vue des pannes serveurs Smantique exactement une fois
Dfinition thorique: Une seule excution est effectue et celle-ci russit toujours. Impossible au sens strict: des lors quune hypothse de panne est formule. Comportement souhait: le plus voisin possible de celui de l'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
81

Smantique : Au plus une fois

Cas d'une fonction quelconque (non idempotente): on ne doit pas l'excuter deux fois. Solution trs rpandue: garantir quon n excute pas deux fois une mme procdure.
Identification des requtes + excution effectue une seule fois. . Si tout va bien le rsultat est retourn lutilisateur. La requte ne sera plus excute (modulo le dlai de garde de l'historique). . Si un problme est dtect Il est signal lutilisateur pour qu il puisse ventuellement statuer).

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

Smantique : Au moins une fois

On se place dans le cas ou chaque excution du serveur est ralise sans sauvegarde de l'tat du serveur. L'excution est lance plusieurs fois si ncessaire (dans une certaine 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 numrots et traits squentiellement. On est capable d'attribuer la russite de l'excution la 83 dernire de toutes les tentatives.

Smantique du RPC du point de vue des pannes client (1)

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 en mmoire stable tous les appels en cours. Lorsqu'un site client est relanc: il doit examiner l'historique des appels en cours non termins et demande la destruction de tous les serveurs orphelins encore actifs.
84

Smantique du RPC du point de vue des pannes client (2)

Rincarnation Une technique de numros de squence:en fait un numro d'poque correspondant aux priodes d'activit successives du client. Il doit tre enregistr en mmoire stable et doit marquer toutes les requtes. Lorsqu'un client est relanc il change d'poque et diffuse sa nouvelle poque ses serveurs qui dtruisent les appels anciens.

85

Smantique du RPC du point de vue des pannes client (3)

Expiration Une technique de dlais de garde : L'excution d'un serveur est toujours associe une surveillance priodique du client : le serveur arme des dlais de garde. Si le quantum s'achve, le serveur demande a son client 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 du client par le serveur et celle du serveur par le client.
86

Conclusion

87

Les avantages de lappel de procdure distante

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.

88

Les impressions trompeuses de lappel de procdure distante

Une application en appel distant est une application rpartie qui risque de prsenter un moment ou un autre pratiquement toutes les difficults systmes/rseaux: de conception. de dsignation et de liaison. de prsentation des donnes changes. de synchronisation. de contrle de concurrence. de tolrance aux pannes et de scurit. de performances. de disponibilit d'outils conviviaux. 89

Lappel de procdure distante

Pour: Le mode appel de procdure distante est en dveloppement important pour la conception et la ralisation de tous les types dapplications rparties. Restriction: Le dveloppement de protocoles RPC intgrs aux approches langages, objets ou composants devrait encore mobiliser longtemps les nergies des chercheurs et des dveloppeurs.

90

Bibliographie
- A.D. Birell and B.J. Nelson, Implementing remote procedure calls ACM Trans 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 distributed environment 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
91