Plans du cours

Troisième partie III 3 RPC : Appel de procédure à distance

Principe
RPC : Appel de procédure à distance Désignation et liaison
Gestion des paramètres
Passage de paramètres
Traitement des défaillances
Génération des talons

Damien Pellier (MASTER I Info.) Applications Distribuées 67 / 430 Damien Pellier (MASTER I Info.) Applications Distribuées 68 / 430

Appel de procédure à distance Appel de procédure à distance

Remote Procedure Call (RPC)

Outil de haut niveau pour la réalisation du schéma client-serveur Avantages attendus

! Forme et effet identiques à ceux d’un appel local
Principe
" Applications non modifiées lors du passage à l’appel distant
" Mise au point locale avant répartition
processus p Site A Site B
" Simplicité d utilisation
procédure P(x,y,...) procédure P(x,y,...) ! Abstraction
" Indépendance par rapport aux protocoles de communication
procédure P(x,y,...) réseau procédure P(x,y,...) " Réutilisation, y compris en environnement hétérogène
Problèmes
! Sémantique complexe en cas de panne
" Les processus client et serveur peuvent tomber en panne indépendamment
" Le réseau introduit une incertitude
Remarque ! Restrictions sur les paramètres
L’effet doit être identique dans les deux cas, vu de p Dans la pratique, ce n’est pas " Passage de structures complexes, possible mais compliqué
vrai en toute rigueur

Damien Pellier (MASTER I Info.) Applications Distribuées 69 / 430 Damien Pellier (MASTER I Info.) Applications Distribuées 70 / 430
Appel de procédure à distance Fonctions des talons (stubs)
Principe de réalisation

Talon client Talon serveur

! Représente le serveur sur le ! Représente le client sur le site
Client Talon client Talon serveur Serveur
site client serveur
appel
emballer déballer ! Reçoit l’appel local ! Reçoit l appel sous forme de
paramètres paramètres
! Emballe les paramètres message et déballe les
! Crée un identificateur unique paramètres
attente création
exécution !
processus
de P(x,y) pour l’appel Crée ou sélectionne un
réveil ! Exécute l’appel distant processus (ou thread) et lui
! Met le processus client en fait exécuter la procédure
déballer emballer attente ! Emballe les résultats et les
résultats résultat
retour ! Reçoit et déballe les résultats transmet à l appelant
! Exécute le retour vers
envoi réception
paramètres
l’appelant (comme retour
paramètres
réception envoi
local de procédure)
résultats résultats
logiciel de communication (sockets)
Remarque
Les talons doivent détecter et traiter les erreurs (délais de garde)

Damien Pellier (MASTER I Info.) Applications Distribuées 71 / 430 Damien Pellier (MASTER I Info.) Applications Distribuées 72 / 430

Appel de procédure à distance Désignation et liaison

Problèmes de mise en œuvre

Comment le client connaı̂t-il l’adresse du serveur ?

Comment fonctionne la transmission des paramètres et résultats Objets à désigner
! ! Procédure appelée, site serveur
Modes de passage (valeur, référence ?)
! Propriétés souhaitées : désignation indépendante de la localisation
! Structures complexes
! " possibilité de reconfiguration (pannes,régulation de charge)
Représentation, emballage/déballage
! Traitement de l’hétérogénéité Moment de liaison
Comment sont traitées les erreurs ? ! Liaison précoce (statique) ou tardive (dynamique)
! ! Statique : localisation du serveur connue à la compilation
Hypothèses sur les erreurs, mode de détection
! Dynamique : localisation non connue à la compilation
! « Sémantique » de l’appel en cas d’erreur
" Désignation symbolique des services (non liée à un site d’exécution)
Construction des talons " Possibilité d’implémentation ou de sélection retardée
! Génération automatique
Gestion à l’exécution
! Lancement et arrêt du serveur, etc.

Damien Pellier (MASTER I Info.) Applications Distribuées 73 / 430 Damien Pellier (MASTER I Info.) Applications Distribuées 74 / 430
Désignation et liaison Désignation et liaison
Urilisation d’un annuaire

Liaison statique : pas d’appel à un serveur de noms (ou appel à la compilation

Programme
Programme appelé
Liaison au premier appel : consultation du serveur de noms au premier appel appelant
seulement 3
4
1

2
Liaison à chaque appel : consultation du serveur de noms à chaque appel Talon client annuaire Talon serveur
5

communication
Communication Communication
Programme logique
Programme appelé client serveur
appelant

Service de
Talon client Talon serveur
désignation 1, 2 : le serveur s’enregistre auprès de l annuaire avec
< nom, adr .serveur , numport >
Communication Communication 3, 4, 5 : le client consulte l’annuaire pour trouver < adr .serveur , numport >
client logiciel de serveur
communication à partir de nom
(sockets)
L’appel peut alors avoir lieu
Schémas plus élaborés : attributs (critères de choix)

Damien Pellier (MASTER I Info.) Applications Distribuées 75 / 430 Damien Pellier (MASTER I Info.) Applications Distribuées 76 / 430

Désignation et liaison et le portmapper Gestion des paramètres

Si le serveur est connu (cas fréquent) : on peut utiliser un service de
nommage local au serveur, le portmapper
Un service enregistre le n˚ de port de son veilleur auprès du portmapper et le
veilleur se met en attente sur ce port Problèmes des paramètres
Le portmapper a un n˚ de port fixé par convention (111) ! Les espaces d’adressage de l’appelant et de l’appelé sont distincts
" Pas de passage par référence
" Les pointeurs perdent leur signification (difficulté pour passer des structures
complexes)
2. recherher Serveur ! Les paramètres sont transmis sur le réseau
(prog,version)
111 " Représentation sérialisée des structures
portmapper ! Les machines client et serveur peuvent être hétérogènes
Client
3. 4543 " Conversion de format
1. enregistrer
(prog,version,4543)

Service Serveur
(prog, version)
4543
4. appel

Damien Pellier (MASTER I Info.) Applications Distribuées 77 / 430 Damien Pellier (MASTER I Info.) Applications Distribuées 78 / 430
Problèmes de représentation des paramètres représentation des paramètres

Conventions différentes sur client et serveur

! Exemple : little endian vs big endian Solution normalisée (ASN.1)
! Syntaxe abstraite (Abstract Syntax Notation) pour représenter des structure
" Sens des octets d’une chaı̂ne de caractères
de données
t o t o ←→ o t o t ! Codage indépendant des machines
! Outils de génération disponibles pour des machines spécifiques
" Poids fort des nombres à gauche ou à droite
Autres solutions
O 43 1 21 ←→ 21 1 43 0 ! Représentation externe commune. Exemple : Sun XDR (External Data
Representation) utilisée dans NFS
" Alignement des données sur les frontières de mots " ... conversions inutiles si client et serveur de même type
! Conventions de représentation des nombres flottants ! Conversion explicite (par le serveur) à partir d une représentation locale au
! Conventions de représentation des structures complexes
client
Limitations de taille ! Négociation entre client et serveur
! Exemple : entiers sur 64 bits vs 32 bits

Damien Pellier (MASTER I Info.) Applications Distribuées 79 / 430 Damien Pellier (MASTER I Info.) Applications Distribuées 80 / 430

Un exemple de convention de représentation de paramètres XDR : exemples de routines de conversion

XDR
Paramètres : pointeurs vers zones contenant les variables sous forme interne
et sous forme « réseau » (transmissible). La même routine sert dans les deux
sens (un paramètre spécifie le sens).
XDR : External Data Representation (Sun)
! Format de transmission sur réseau bool t xdr int(xdrs, ip) ip xdrs
!
forme
Bibliothèque de programmes de conversion XDR *xdrs interne sens
...
Ensemble de routines disponibles pour les types de base (de C) int *ip forme réseau

! Données élémentaires
! Structures simples (tableaux, chaı̂nes, unions)
!
bool t xdr array (xdrs, arrp, sizep, maxsize, elsize, elproc)
Traitement de pointeurs, gestion de mémoire
XDR *xdrs
Utilisation : programmes d emballage/déballage char **arrp
! Courante : par les générateurs automatiques de talons, dans tous les cas usuels u int *sizep, maxsize, elsize
!
xdrproc t elproc ;
Avancée : directement par le programmeur, pour le traitement de structures de
données complexes *arrp : pointeur vers tableau
*sizep : nombre d éléments de taille elsize
maxsize : nombre max d éléments
elproc : filtre xdr pour convertir l élément (exemple : xdr int pour tableau d’entiers)

Damien Pellier (MASTER I Info.) Applications Distribuées 81 / 430 Damien Pellier (MASTER I Info.) Applications Distribuées 82 / 430
Passage des paramètres Passage des paramètres

Plusieurs modes de passage sont possibles :

1 Passage par valeur Passage par référence (adresse)
" pas de problème ! Impossible puisque espaces distincts
2 Passage par copie-restauration Palliatifs possibles
" À l’appel, copie des valeurs des paramètres de l’appelant vers l’appelé ! Interdire l’appel par référence
" Au retour, copie de nouvelles valeurs pour les paramètres de l’appelé vers ! Utiliser l’appel par copie-restauration
l’appelant
" Équivalent le plus souvent ...
" ... mais pas dans tous les cas (aliasing)
! Programmer à la main les procédures d emballage/déballage pour les
Avant V0 Copie de l'état V0 V0
structures complexes
traitement
! Nouveaux modèles de communication (mémoire virtuelle répartie) : revient à
Après V1 Restauration de l'état V1 V1 un espace commun

Damien Pellier (MASTER I Info.) Applications Distribuées 83 / 430 Damien Pellier (MASTER I Info.) Applications Distribuées 84 / 430

Passage par copie-restauration et passage par référence « Sémantique » en cas de panne

Procédure Question
void double incr(x, y) Quel est l’effet qu’aura la séquence Principe de la détection de panne
x = x+1 d’opérations suivante : ! Détection de panne = expiration de délai de garde
y = y+1 a := 0 ; ! On tente de réexecuter l’appel
double incr(a, a) ! Problème : combien de fois la procédure a-t-elle été exécutée ?
La sémantique dépend des hypothèses de pannes et du mécanisme de reprise
copie ! Indéfini (pas d hypothèses)
+1 +1 ! Au moins une fois (appel répété, plusieurs exécutions possibles, au moins une
x x 0 0 réussit)
+1 +1
y y 0 0 " acceptable si opération idempotente (2 appels successifs ont le même effet que
1 appel)
a 0 initial
référence initial traitement ! Au plus une fois (0 ou 1 fois)
a 0
" on évite les exécutions répétées, mais on ne garantit pas le succès
a 2 final 1 1
! Exactement une fois (c est l idéal, difficile à atteindre)
1 1

a 1 final restauration

Damien Pellier (MASTER I Info.) Applications Distribuées 85 / 430 Damien Pellier (MASTER I Info.) Applications Distribuées 86 / 430
Traitement des défaillances Traitement des défaillances A B C

E D

Congestion du réseau ou du serveur

Hypothèses de défaillances
! Panne transitoire (ne nécessite pas d’action)
! Système de communication
! Détection : expiration du délai de garde A ou D
" Congestion du réseau, messages retardés ! Reprise (délai de garde A)
" Perte de messages
" Le talon client (A) réémet l’appel (même identificateur) sans intervention de
" Altération de messages
!
l’application
Serveur " Le service d’exécution (C) détecte que c est une réémission
" Défaillance avant l’exécution de la procédure → Appel en cours : aucun effet
" Défaillance pendant l’exécution de la procédure → Retour déjà effectué : réémission du résultat
" Défaillance après l’exécution de la procédure
! Reprise (délai de garde D) : réémission du résultat
" Défaillance définitive ou reprise possible
! Sémantique
! Client " Si défaillance transitoire : exactement une fois
" Défaillance pendant le traitement de la requête " Si défaillance permanente : détection, exception vers application

Damien Pellier (MASTER I Info.) Applications Distribuées 87 / 430 Damien Pellier (MASTER I Info.) Applications Distribuées 88 / 430

Traitement des défaillances A B C Traitement des défaillances A B C

E D E D

Panne du client après émission de l’appel

Panne du serveur après émission de l’appel ! L’appel est correctement traité
! Plusieurs moments possibles " Changement d’état du serveur
" Avant B, entre C et D, entre fin traitement et D " Le processus exécutant courant est déclaré « orphelin »
" Traitement : pas fait, partiel, total ! Détection : expiration du délai de garde D, n réémissions infructueuses
! Détection : expiration du délai de garde A " Action du serveur : élimination des orphelins
! Reprise → Consomment des ressources
" Le client réémet l’appel dès que le serveur redémarre ! Reprise (après redémarrage du client)
" Sémantique : au moins une fois " L’application cliente réémet l’appel (id. différent)
→ Le client ne connaı̂t pas l’endroit de la panne → Sémantique : au moins une fois
" On peut faire mieux avec un service transactionnel → Le serveur ne peut pas détecter qu’il s’agit d une répétition (Pas d’incidence
→ Mémorise identificateur de requête et état avant exécution si idempotent)
→ On peut faire mieux, si le client a un service de transactions

Damien Pellier (MASTER I Info.) Applications Distribuées 89 / 430 Damien Pellier (MASTER I Info.) Applications Distribuées 90 / 430
Génération des talons Génération des talons

application gcc
Principe client
proc_client.c
exécutable
client
talon client
! La structure des talons est bien définie et ils peuvent être créés proc_cInt.c

automatiquement
! Renseignements nécessaires
description
" Dépendants de l environnement local : procédures de conversion, protocole de conversion définition bibliothèque
d'interface rpcgen
proc_xdr.c proc.h
communication proc.x

" Dépendants de l’application : formats des paramètres et résultats (pour

emballage-déballage) ; c’est l’interface de la procédure
talon serveur
Mise en œuvre application proc_svc.c
serveur exécutable
! Les informations nécessaires dépendantes de l’application sont décrites dans proc_server.c serveur
gcc
un langage de définition d interfaces (IDL)

fourni par le programmeur généré automatiquement outils et services

Damien Pellier (MASTER I Info.) Applications Distribuées 91 / 430 Damien Pellier (MASTER I Info.) Applications Distribuées 92 / 430

Description d’interfaces Exemple de description d’interfaces

Client Serveur
Fichier annuaire.x
Interface /∗ constantes et types ∗/
const max nom = 20 ;
Interface = « contrat » entre client et serveur const max adr = 50 ;
! Définition commune abstraite const max numero = 16 ;
" Indépendante d’un langage particulier (adaptée à des langages multiples) typedef s t r i n g typenom<max nom>
"
typedef s t r i n g typeadr<max adr>
Indépendante de la représentation des types typedef s t r i n g
" Indépendante de la machine (hétérogénéité) typenumero<max numero>
! Contenu minimal s t r u c t personne {
typenumero numero ;
" Identification des procédures (nom, version) typenom nom ;
" Définition des types des paramètres, résultats, exceptions typeadr adresse ;
" Définition du mode de passage (IN, OUT, IN-OUT) };
!
typedef s t r u c t personne personne ;
Extensions possibles
/∗ d e s c r i p t i o n de l ’ i n t e r f a c e ∗/
" Procédures de conversion pour types complexes program ANNUAIRE {
" Propriétés non-fonctifonctionnelles (qualité de service), non standard) v e r s i o n V1 {
void INIT ( void ) = 1 ;
i n t AJOUTER( personne p ) = 2 ;
i n t SUPPRIMER ( personne p ) = 3 ;
personne CONSULTER ( typenom nom ) = 4 ;
} = 1 ;
} = 0 x23456789 ;

Damien Pellier (MASTER I Info.) Applications Distribuées 93 / 430 Damien Pellier (MASTER I Info.) Applications Distribuées 94 / 430
Utilisation de rpcgen Utilisation de rpcgen
modèle de programme client : annuaire client.c

Fichiers nécessaires à rpcgen Fichiers générés

main ( argc , argv )
annuaire client.c programme client annuaire.h include i n t argc ; char ∗ argv ;
{
annuaire server.c programme serveur annuaire clnt.c talon client
CLIENT∗ c l n t ;
makefile.annuaire modele de makefile annuaire svc.c talon serveur char ∗ host ;
annuaire xdr.c proc. de conversion ...
i f ( argc <2) {
p r i n t f ( ”usage : %s s e r v e r h o s t \n” , argv [ 0 ] ) ;
Illustration annuaire xdr.c b o o l t xdr personne ( xdrs , objp )
}
exit (1)
r e g i s t e r XDR ∗ xdrs ;
b o o l t xdr typeadr ( xdrs , objp ) typeadr ∗ objp ; host = argv [ 1 ] ;
r e g i s t e r XDR ∗ xdrs ; { c l n t = c l n t c r e a t e ( host , ANNUAIRE, V1 , ”netpath” ) ; /∗ accès au serveur ∗/
typeadr ∗ objp ; r e g i s t e r long ∗ buf ; i f ( c l n t == ( CLIENT ∗) NULL {
{ i f ( ! xdr typenumero ( xdrs , c l n t p c r e a t e e r r o r ( host ) ;
r e g i s t e r long ∗ buf ; &objp−>numero ) ) exit (1);
i f ( ! x d r s t r i n g ( xdrs , objp , return ( FALSE ) ; }
max numero ) ) i f ( ! xdr typenom ( xdrs , ...
return ( FALSE ) ; &objp−>nom ) ) r e s u l t 2 = a j o u t e r 1 (& ajouter 1 arg , c l n t ) ; /∗ s a i s i r paramètres ∗/
return (TRUE) ; return ( FALSE ) ; i f ( r e s u l t 2 == ( i n t ∗) NULL) {
} i f ( ! xdr typeadr ( xdrs , c l n t p e r r o r ( clnt , ” c a l l f a i l e d ” ) ;
b o o l t xdr typenom ( xdrs , objp ) &objp−>adresse ) ) }
... return ( FALSE ) ; ...
b o o l t xdr typenumero ( xdrs , objp ) return (TRUE ) ; }
... }

Damien Pellier (MASTER I Info.) Applications Distribuées 95 / 430 Damien Pellier (MASTER I Info.) Applications Distribuées 96 / 430