Chapitre 3
Chapitre 3
Chapitre 3
LES APPELS DE
PROCÉDURE
DISTANTS
Contexte
Les systèmes distribues modernes consistent souvent en des milliers voire des
millions de processus disperses sur des réseaux peu fiables.
! Mise en oeuvre
Bas niveau : utilisation directe du transport : sockets (construit sur
!
TCP ou UDP)
" Exemple : utilisation des sockets en C
!Haut niveau : intégration dans un langage de programmation : RPC
(construit sur sockets)
" Exemple : RPC en C
Définition
distinct
L’effet de l’appel doit être identique dans les deux situations (local et
distant)
Les RPCs
Objectif :
permettre aux programmes d’appeler des procedures situees sur d'autres machines.
● Les informations sont acheminees dans les parametres et les resultats de la procedure.
– Aucune transmission de message n’est visible au programmeur.
Les approches à RPC
SUN ONC/RPC
Open Network Computing / Remote Procedure Call
OSF DCE
Open Software Foundation - Distributed Computing Environnment
!Facilité de programmation
! La complexité des protocoles de communication est cachée
! Ne pas avoir à programmer des échanges au niveau réseau
1. Par migration
2. Par mémoire partagée
3. Par messages
4. Par appel léger (LRPC)
Réalisation par migration
Stratégie de migration
! Le code et les données de la procédure distante sont amenés sur le
site appelant pour y être exécutés par un appel local habituel.
! Analogie
! Stratégie de pré-chargement en mémoire.
! Avantages
! Très efficace pour de nombreux appels
! Inconvénients
! Univers d’exécutions homogènes (ex machine virtuelle).
! Performances selon le volume de codes et de données.
! Problèmes de partage des objets.
Réalisation en mémoire partagée répartie
Étape 6 La procédure serveur ayant terminé son exécution transmet à la souche serveur
dans son retour de procédure les paramètres résultats. La souche serveur collecte les
paramètres retour, les emballe dans un message.
! Étape 7 La procédure souche serveur demande à l ’entité de transport serveur la
Les talons (ou souches) client et serveur sont créés (générés automatiquement) à partir d’une
description d’interface
Description d’interface
! Avantages
! Inconvénients
! Pas d’usage des pointeurs dans les paramètres
! Échange de données complexes/de grande taille
délicat
! Peu efficace pour de très nombreux appels
Lightweight RPC (LRPC)
Quand on appelle un serveur qui se trouve sur la même machine, la traversée des
couches réseaux est inutile et coûteuse
# Optimisation de la communication
! LRPC: principe de RPC mais entre processus locaux s'exécutant sur la même
machine
Lightweight RPC (LRPC)
! Avantages
! Transmission d’appel très performant comme mode de RPC local.
! Limites
! Uniquement applicable dans une même machine.
Synthèse sur les modes de réalisation
!Le seul mode de transmission des données dans les messages en réseau
! Si le client et le serveur utilisent des formats de de données
différents $ Conversion
! Définition du couple syntaxe abstraite/syntaxe de transfert des
données échangées:
! Syntaxe abstraite
! analogue à celles des langages évolués,
! facile à générer pour un développeur d’application
! À partir de la syntaxe abstraite : codage/décodage de la syntaxe de
Transfert
! SUN RPC
! RPCL - 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
! Java - Protocole JRMP Java Remote Method Protocol
! Microsoft DCOM
! MIDL Microsoft IDL - DCOM Protocole ORPC Object RPC Format NDR
! Services Web
! Web Services Definition Language (WSDL) – SOAP
Autres modes de transmission :
passage par adresse
! 3 solutions :
Marche bien dans beaucoup de cas mais violation dans certains cas de la
sémantique du passage
Simulation par copie restauration
”
Désignation
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
Le portmapper a un n° de port fixé par convention (111)
Solution proposée par les RPC ONC, un programme de binding (RFC 1823) :
le portmapper (version 2) : spécifique à TCP/UDP: le portmapper est lui-même un
serveur rpc.
rpcbind (versions 3 et 4) : indépendant du transport
“
Gestion du contrôle
”
Contrôle client : RPC en mode
synchrone
L’exécution du client est suspendue tant que la réponse du serveur n’est pas revenue
ou qu’une condition d’exception n’a pas entraîné un traitement spécifique
Avantage : le flot de contrôle est le même que dans l’appel en mode centralisé.
Inconvénient : le client reste inactif.
Solution au problème de l’inactivité du client : création des activités concurrentes
Création de (au moins) deux activités (« processus léger » ou « threads ») sur le site
client:
L’une occupe le site appelant par un travail à faire.
L’autre gère l’appel en mode synchrone en restant bloquée :
Le fonctionnement est exactement celui d’un appel habituel.
Contrôle client : RPC en mode
asynchrone
Les requêtes d’exécution sont traitées l’une après l’autre par le serveur exclusion
mutuelle entre les traitements.
Si la couche transport assure la livraison en séquence et que l’on gère une file
d’attente « FIFO : premier arrivé premier servi », on a un traitement ordonné des
suites d’appels.
Contrôle serveur: exécution parallèle
des appels