2. Rappel du schéma client-
serveur2
Appel synchrone Requête-Réponse
Mise en œuvre
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
3. Définition
3
Appel de procédure à distance (Remote Procedure Call, ou
RPC) : un outil pour construire des applications client-serveur
dans un langage de haut niveau
L’appel et le retour ont lieu sur un site , l’exécution se déroule
sur un site distinct
L’effet de l’appel doit être identique dans les deux situations
(local et distant)
4. Avantages attendus
4
Facilité de programmation
La complexité des protocoles de communication est
cachée
Ne pas avoir à programmer des échanges au niveau
réseau
Facilité de mise au point : une application peut
être mise au point sur un site unique, puis
déployée sur plusieurs sites
Portabilité : résulte de l’usage d’un langage de
haut niveau
Indépendance par rapport au système de
communication
5. Problèmes de réalisation
5
Transmission des paramètres
conversion entre la forme interne, propre à un
langage, et une forme adaptée à la transmission
Gestion des processus
Séquentielle et parallèle
Réaction aux défaillances
Trois modes de défaillance indépendants : client,
serveur, réseau
6. Mise en œuvre
6
Par migration
Par mémoire partagée
Par messages
Par appel léger (LRPC)
1
2
3
4
7. Réalisation par migration
7
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.
1
8. Réalisation en mémoire partagée
répartie
8
L’appel distant est réalisé en utilisant une
mémoire virtuelle partagée répartie
La procédure est installée pour le client comme pour
le serveur dans la mémoire virtuelle partagée répartie.
Mais, réellement, elle est dans l’espace mémoire du
serveur.
L’appel du client se fait comme si la procédure
était locale, provoquant un premier défaut de
page sur le début du code de la procédure.
Le code et les données de la procédure distante
sont amenés page par page sur le site appelant
selon le parcours du code et des données.
Analogie avec une stratégie page à la demande.
2
9. 9
Avantages
Efficace en cas de nombreux appels
Efficace si tout le code et les données ne sont pas
visités
Résout le problème de l’utilisation des pointeurs
(références d’adresses en mémoire)
Inconvénients
Univers de systèmes homogènes
Volume de codes et de données à échanger pages
par pages
Problèmes de partage selon la cohérence de la
mémoire répartie
Réalisation en mémoire partagée
répartie
2
10. Réalisation par messages
10
Deux messages (au moins) échangés : requête et
réponse
Le premier message correspondant à la requête est
celui de l'appel de procédure, porteur des paramètres
d'appel.
Le second message correspondant à la réponse est
celui du retour de procédure porteur des paramètres
résultats.
3
11. Notion des souches (1/2)
11
Un mode de réalisation par interception
Une procédure intercepteur intercepte l’appel d’un
client vers un serveur et modifie le traitement serveur
à sa guise
Décomposition en traitements avant et après le
traitement serveur
Décomposition en intercepteur coté client,
souche client, et intercepteur coté serveur,
souche serveur
Souches (ou Stubs) =Talons = Squelettes (ou
Skeletons)…
Objectif: transformer l’appel local en un appel
3
12. Notion des souches (2/2)
12
La souche client ("client stub")
Intercepteur (procédure) coté client qui reçoit l’appel en
mode local,
Le transforme en appel distant,
Envoie message d’appel de procédure,
Reçoit le message contenant les résultats après
l’exécution,
Retourne les résultats comme dans un retour local de
procédure.
La souche serveur ("server stub")
Intercepteur (procédure) coté serveur qui reçoit le
message d’appel,
Fait réaliser l’exécution sur le site serveur par la procédure
serveur,
Récupère les résultats et retransmet les résultats par
message.
3
13. Etapes de RPC par messages
(1/2)14
Étape 1 : Le client réalise un appel procédural vers la procédure
souche client, la souche client collecte les paramètres , les emballe
dans le message d’appel
Étape 2 : La souche client demande à une entité de transport locale la
transmission du message d'appel
Étape 3 : Le message d’appel est transmis sur un réseau au site
serveur
3
Étape 4 : Le message d’appel est
délivré à la souche qui déballe les
paramètres
Étape 5 : La souche serveur
réalise l’appel effectif de la
procédure serveur
14. Etapes de RPC par messages
(2/2)15
É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 transmission du message de réponse.
3
Étape 8 : Le message de
réponse est transmis sur un
réseau au site client.
Étape 9 : Le message de
réponse est délivré à la souche
client. La souche client déballe
les paramètres résultats.
Étape 10 : La procédure
souche client transmet les
résultats au client en effectuant
un retour habituel de
procédure en mode local.
15. Diagramme de RPC par
messages16
Talon
(stub)
client
Talon
(stub)
serveur
Les talons (ou souches) client et serveur sont créés
(générés automatiquement) à partir d’une description
d’interface
3
16. Description d’interface
17
Interface = “contrat” entre client et serveur
Définition commune abstraite
Indépendante d’un langage particulier (adaptée à des
langages multiples)
Indépendante de la représentation des types
Indépendante de la machine (hétérogénéité)
Contenu minimal
Identification des procédures (nom, version)
Définition des types des paramètres, résultats
Définition du mode de passage (IN, OUT, IN-OUT)
Extensions possibles
Procédures de conversion pour types complexes
3
17. RPC par message
18
Avantages
Applicable en univers hétérogènes moyennant
des conversions
Partage d’accès sur le site serveur
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
3
18. Lightweight RPC (LRPC)
19
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
Problème: Client et Serveur (2 processus) qui se
trouvent dans deux domaines de protection différents !
Solution: la communication réseau est réalisée par
un segment de mémoire partagée entre le client et
le serveur qui contient une pile pour les paramètres
d’appel et de réponse.
LRPC: principe de RPC mais entre processus
locaux s'exécutant sur la même machine
4
19. Lightweight RPC (LRPC)
20
4
Avantages
Transmission d’appel très performant comme mode de RPC
local
Limites
Uniquement applicable dans une même machine.
20. Synthèse sur les modes de
réalisation21
RPC par messages :
Le premier modèle implémenté
Supporte l’hétérogénéité
Le plus simple à réaliser
RPC, RMI, DCE, CORBA, DCOM, SOAP
Des optimisations peuvent être obtenues par
l’usage des autres solutions
Exemple :
Chorus a développé les quatre solutions.
DCOM a développé RPC par messages + LRPC
22. Transmission par valeur
23
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
Syntaxe de transfert : une représentation lexicale des
données simples et une convention d’alignement
(emballage/déballage) des données commune au client et au
serveur
23. Transmission par valeur
dans l’appel de procédure distante
24
En appel de procédure distante :
génération automatique du code des souches à
partir de la syntaxe abstraite
les souches fabriquent la syntaxe de transfert en
réalisant l’alignement (emballage/déballage) des
paramètres dans les messages.
Définition des nouveaux langages de syntaxe
abstraite adaptés aux appels de procédure
distante :
Interface Definition Language (IDL)
24. Pourquoi les langages IDL ?
25
Être indépendant des langages évolués
utilisant le RPC
Permettre l’appel distant avec tout langage
évolué
Définition d’un langage pivot (intermédiaire) de
description de données ayant des fonctionnalités
assez riches pour les langages les plus récents.
Notion de correspondance entre les types d’IDL
et les types des langages existants
26. Exemples d’IDL
et de format de présentation en RPC
27
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
27. Autres modes de transmission :
passage par adresse
28
Le passage par adresse utilise une adresse
mémoire centrale du site de l’appelant qui n’a
aucun sens sur l’appelé (sauf cas particulier)
3 solutions :
Interdiction totale des pointeurs
La solution la plus répandu
Passage par adresse en mémoire virtuelle
partagée répartie
Simulation du passage par adresse en utilisant
une copie restauration
28. Simulation par copie restauration
29
A l’appel: copie des valeurs des paramètres de
l’appelant vers l’appelé
Au retour: copie de nouvelles valeurs pour les
paramètres de l’appelé vers l’appelant
Marche bien dans beaucoup de cas mais violation
dans certains cas de la sémantique du passage
29. Simulation par copie restauration
30
Exemple du problème de violation
procédure double_incr ( x , y ) ;
x , y : entier ;
début
x := x + 1 ;
y := y + 1 ;
fin ;
Séquence d’appel : passage par
adresse
a := 0 ;
double_incr ( a , a ) ;
Résultat attendu : a = 2
Utilisation d’une copie restauration
Résultat obtenu : a = 1
31. Désignation
32
La structuration des noms et références permet de désigner les
services distants :
Nom symbolique : une chaîne de caractères désignant la
procédure dans un annuaire ou serveur de nom
Référence : une structure de données permettant de réaliser l’appel
Référence : selon l’implantation considérée:
Désignation du protocole permettant l’accès distant (TCP ou UDP)
Désignation de l’hôte où se trouve le serveur (adresse IP)
Désignation du point d’accès de service transport (numéro de port)
Désignation de la procédure
Serveur de nom : une table qui assure la correspondance
entre nom symbolique et référence
32. Liaison
33
Moment de liaison : précoce (statique) ou tardive
(dynamique)
Statique :
localisation du serveur connue à la compilation
pas d’appel à un serveur de noms (ou appel à la compilation)
Dynamique : localisation au moment de l’exécution,
non connue à la compilation
Désignation symbolique des services (non liée à un site
d’exécution)
Liaison au premier appel : consultation du serveur de noms au
premier appel seulement
Liaison à chaque appel : consultation du serveur de noms à
chaque appel
34. Désignation & liaison
35
1, 2 : le serveur s’enregistre auprès de l’annuaire avec nom,
@serveur, #port
3, 4, 5 : le client consulte l’annuaire pour trouver @serveur,
#port à partir du nom symbolique
L’appel peut alors avoir lieu
36. Contrôle client : RPC en mode synchrone
37
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.
37. Contrôle client : RPC en mode synchrone
38
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.
38. Contrôle client : RPC en mode asynchrone
39
Le client poursuit son exécution immédiatement
après l’émission du message porteur de l’appel
La procédure distante s’exécute en parallèle avec
la poursuite du client
Le client doit récupérer les résultats quand il en a
besoin
39. Contrôle serveur : exécution séquentielle des
appels
40
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.
40. Contrôle serveur: exécution parallèle des
appels
41
le serveur créé un processus ou une activité
(« processus léger » ou « thread ») pour chaque
appel
Gestion possible de pool de processus ou d’activités
Les appels sont exécutés en parallèle.
Si les procédures manipulent des données globales
persistantes sur le site serveur, le contrôle de
concurrence doit être géré.
42. Gestion des données applicatives
sans données partagées persistantes
43
L’appel de procédure s’exécute en fonction des
paramètres d’entrée en produisant des
paramètres résultats
Données locales à la procédure
Pas de modification de données persistantes sur le
serveur
Situation très favorable, on n’a pas à gérer:
la tolérance aux pannes
le contrôle de concurrence
43. Gestion des données applicatives
partagées persistantes
44
Les exécutions successives manipulent des
données persistantes sur le serveur:
Une exécution modifie le contexte sur le serveur
Exemple: un serveur de fichier, de bases de données.
Problème de contrôle de concurrence
Problème des pannes en cours
d’exécution
44. Gestion des données protocolaires
mode avec ou sans état
45
La terminologie avec ou sans état porte sur
l’existence ou non d’un descriptif pour chaque
relation client serveur au niveau du serveur.
Notion d’état : un ensemble de données
persistantes au niveau du protocole pour
chaque relation client serveur :
Permettrait de traiter les requêtes dans l’ordre
d’émission.
Permettrait de traiter une requête en fonction des
caractéristiques de la relation client serveur
(qualité de service).
45. Mode sans état
46
Les appels successifs d’une même procédure
s’exécutent sans liens entre eux
Chaque opération du point de vue du
protocole s’effectue sans référence au passé
Exemples
NFS "Network File System" de SUN
système de fichier réparti basé sur RPC sans état
HTTP "HyperText Transfer Protocol"
protocole d’exécution de méthodes distantes sans état
46. Mode avec état
47
Les appels successifs s’exécutent en fonction
d’un état de la relation client serveur laissé par
les appels antérieurs
La gestion de l'ordre des requêtes est
indispensable
Exemple :
Opérations d’achat des produits sur Internet
(payement électronique)
48. Appel local vs Appel distant
49
En appel local
L’appelant et l’appelé s’exécutent sur la même machine : même
exécutant => mêmes performances et modes de pannes.
L’appel et le retour de procédure sont des mécanismes internes
considérés comme fiables.
Problème des erreurs abordé => exceptions chez l’appelant.
En appel distant
Appelant et appelé peuvent tomber en panne indépendamment
Le message d’appel ou celui de retour peuvent être perdus
Le temps de réponse peut-être très long en raison de surcharges
diverses (réseau, site appelé)
La prise en compte des défaillances nécessite de formuler des
hypothèses de défaillances, de détecter les défaillances, et
enfin de réagir à cette détection.
49. Hypothèses de défaillances
50
Système de communication
Congestion du réseau, messages retardés
Perte de messages
Altération de messages
Serveur
Défaillance avant l’exécution de la procédure
Défaillance pendant l’exécution de la procédure
Défaillance après l’exécution de la procédure
Défaillance définitive ou reprise possible
Client
Défaillance pendant le traitement de la requête
50. Détection de pannes – Délai de
garde51
Les mécanismes de détection de pannes reposent sur des
délais de garde.
À l'envoi d'un message,
une horloge de garde est armée, avec une valeur estimée de la
borne supérieure du délai de réception de la réponse.
Le dépassement du délai de garde déclenche une action de
reprise
Les horloges de garde sont placées côté client, à l'envoi du
message d'appel, et côté serveur, à l'envoi du message
de réponse.
Dans les deux cas, l'action de reprise consiste à renvoyer le
message.
Ilest difficile d'estimer les délais de garde : un message
d'appel peut être renvoyé alors que l'appel a déjà eu lieu, et
la procédure peut ainsi être exécutée plusieurs fois!
51. RPC : sémantique en cas de
panne52
Détection de panne = expiration de délai de garde.
On tente de ré-exécuter l’appel. Combien de fois la
procédure a-t-elle été exécutée!?
Sémantique : nombre d’exécution de la
procédure
dépend des hypothèses de pannes et du mécanisme de
reprise
Indéfini (pas d’hypothèses)
Au moins une fois (appel répété, plusieurs exécutions
possibles, au moins une réussit)
acceptable si opération idempotente (2 appels successifs ont le
même effet que 1 appel)
Au plus une fois (0 ou 1 fois)
on évite les exécutions répétées, mais on ne garantit pas le
succès
52. Traitement des défaillances
53
Congestion du réseau ou du serveur
Panne transitoire (ne nécessite pas d’action de reprise)
Détection : expiration du délai de garde coté client ou coté
serveur
Reprise (délai de garde du client)
La souche client réémet l’appel (avec le même identificateur)
sans intervention de l’application
Le service d’exécution détecte que c’est une réémission
Exécution de l’appel en cours : le nouvel appel du client n’a aucun
effet
Retour déjà effectué : réémission du résultat
Reprise (délai de garde du serveur) : réémission du
résultat
Sémantique
Si défaillance transitoire : exactement une fois
Si défaillance permanente : détection, exception vers application
53. Traitement des défaillances
54
Panne du serveur après émission de l’appel
3 cas possibles sur l’exécution de l’appel
Traitement : pas fait, partiel, total
Détection : expiration du délai de garde du client
Reprise
Le client réémet l’appel dès que le serveur redémarre
Sémantique : au moins une fois
Le client ne connaît pas l’endroit de la panne
Solution : le serveur mémorise l’identificateur de
requête et état avant exécution
54. Traitement des défaillances
55
Panne du client après émission de l’appel
L’appel est correctement traité par le serveur
Le processus exécutant courant est déclaré orphelin
Détection : expiration du délai de garde du serveur,
après n réémissions infructueuses
Action du serveur : élimination des orphelins pour libérer
ses ressources
Reprise (après redémarrage du client)
L’application cliente réémet l’appel (avec identifiant
différent)
Sémantique : au moins une fois
Le serveur ne peut pas détecter qu’il s’agit d’une répétition
Pas d ’incidence si idempotent
Sinon, le client doit informer le serveur pour qu’il revient à l’état
cohérent avant exécution de son nouvel appel
56. Avantages des RPC
57
De plus haut niveau
Les détails de communication sont cachés.
Une structure de contrôle bien connue, l’appel
de procédure
Support naturel de l’approche client-serveur
Qui s’intègre à l’univers réparti des concepts
modernes de génie logiciel: approche objets,
approches composants
Modularité, encapsulation, réutilisation par délégation.
59. Sémantique des pannes
69
La sémantique d’appel caractérise combien de fois
la procédure appelée à distance est exécutée suite
à un appel en l’absence ou en présence de
défaillances.
La sémantique est variable selon la nature du
mécanisme mis en œuvre et la nature du serveur:
Serveur avec état: le serveur conserve des informations
sur les appels des clients
Serveur sans état: gestion des pannes à la charge du
client
Remarque [Idempotence]: une procédure est
idempotente si quel que soit le nombre d’exécutions,
elle délivre le même résultat
Lecture de fichiers et une opération idempotente
L’incrémentation d’une variable est non idempotente
60. Sémantique exactement une fois
70
Une seule exécution est effectuée et celle-ci réussit
toujours.
Réémettre requêtes/réponses
Client:
Arme un délai. Après expiration du délai, le client réémet
sa requête jusqu’à réception d’une réponse
Au bout d’un nombre de tentatives, le serveur est
considéré indisponible
Serveur:
Garde en mémoire id_req, résultat (pour la perte d’une
réponse)
Pour chaque requête id_req, réémettre résultat
Reprise du serveur: la requête ne doit pas être
réexécutée: conserver un journal des requêtes traitées.
Difficile à implémenter en pratique!
61. Sémantique au plus une fois
71
Cas d'une fonction non idempotente: on ne doit pas
l'exécuter deux fois.
Solution très répandue: Identification des requêtes +
exécution effectuée une seule fois.
Exécution effectuée une seule fois:
Si tout va bien le résultat est retourné à l’utilisateur
Si un problème est détecté il est signalé à l’utilisateur.
Laisser à la charge du client.
Aucune tentative de reprise n’est effectuée. Elle est
laissée entièrement à la charge du client.
62. Sémantique au moins une fois
72
Ne convient pas aux procédures non
idempotentes
Client:
Arme un délai. Après expiration du délai, le client
réémet sa requête jusqu’à réception d’une
réponse
Au bout d’un nombre de tentatives, le serveur est
déclaré indisponible.
Hinweis der Redaktion
L’effet de l’appel doit être identique dans les deux situations (local et distant)
Mais cet objectif ne peut être atteint en toute rigueur en présence de défaillances
Ne pas avoir à programmer des échanges au niveau réseau en mode message
Ne pas utiliser pour construire une application répartie des schémas de contrôle trop simples (affectation, fork, join …)
Problèmes de partage des objets (fermeture d’objets, ...).
Réalisation de l’appel de procédure distante par messages asynchrones
Objectif de génération automatique des souches connaissant le profil d’appel de la procédure distante.
Un mode de réalisation par interception (wrapping)
Une procédure intercepteur (wrapper) intercepte l’appel d’un client vers un serveur et modifie le traitement serveur à sa guise
Stub = souche
Skeleton: squellette
J’ai remplacé procédure par intercepteur
La souche client collecte les paramètres , les aligne dans le message d’appel (“parameter marshalling”). La souche détermine l’adresse du serveur.
La souche client collecte les paramètres , les emballe dans le message d’appel. La souche détermine l’adresse du serveur.
La souche serveur réalise l’appel effectif de la procédure serveur. On a ici réalisé un rendez-vous d'activation.
La souche serveur collecte les paramètres retour, les assemble dans un message (“parameter marshalling”).
Définition des types des paramètres, résultats, exceptions
Propriétés non-fonctionnelles (qualité de service), non standard)
Avantages: Volume de code ou de données du serveur quelconque ???
Si le serveur se trouve dans le même processus (même domaine de protection) pas de problème (appel local).
Si le serveur se trouve dans un autre processus (autre domaine de protection)
Exemple : DCOM RPC par messages + RPC léger (aussi prévu en CORBA).
Si le site client et le site serveur utilisent des formats de de données différents : problème syntaxique
Conversion est nécessaire
Exemple : norme de représentation lexicale des données simples BER (‘Basic Encoding Rules’) dans le mode de communication par messages.
Exp: ASN1 ‘Abstract Syntax Notation’1 pour le mode message
codage/décodage de la syntaxe de transfert (technique de compilation, notion de compilateur de protocole).
Insuffisance des normes de syntaxe abstraite et de syntaxe de transfert en mode message asynchrone : ASN1/BER.
Définition de nouveaux langages de syntaxe abstraite adaptés aux appels de procédure distante : IDL ‘Interface Definition Language’
Pour chaque IDL en général redéfinition d’une syntaxe de transfert.
N’est pas clair, le passage de ASN1/BER vers IDL ???
Pourquoi ne pas parler directement de IDL
Motivation pour une classe de langages de syntaxes abstraites : IDL
Définition d’un langage pivot qui permette de corriger les ambiguïtés et les insuffisances des langages anciens (comme par exemple C).
Notion de correspondance entre les types retenus dans l’IDL et les types des différents langages existants ("mappings")
Archivage Entete de la procédure pour permettre de faire certaines vérifications lors de la compilation et de la génération des souches.
J’ai supprimé des parties de la figure voire figure originale
Indispensable de traiter ce problème
Y-a-t il une syntaxe qui implémente la copie restauration ?
Désignation locale de l’objet où se trouve la procédure.
une structure de données permettant de réaliser l’invocation.
Dynamique : localisation au moment de l’exécution, non connue à la compilation
Désignation symbolique des services (non liée à un site d’exécution)
Possibilité d’implémentation ou de sélection retardée
Schémas plus élaborés : attributs (critères de choix)
Condition d’exception: attente bornée
Mode centralisé: sur la même machine
Le client doit récupérer les résultats quand il en a besoin (primitive spéciale).
Exclusion mutuelle : est une primitive de synchronisation utilisée en programmation informatique pour éviter que des ressources partagées d'un système ne soient utilisées en même temps.
Exemple RPC SUN : traitement séquentiel des requêtes mais utilisation de UDP => requêtes non ordonnées (mais mode synchrone le client attend la fin du traitement).
Autres exemples : les RPC ont un mode séquentiel (exemple : CORBA)
Rémanantes= persistantes=durables
Exemple : Corba Notion d’adaptateur d’objets.
Exemple : fonction scientifique (EJB session stateless).
Données applicatives partagées (variables d’instance, fichiers, bases de données) : problème de persistance.
Sans données partagées persistantes
Solution : le couplage d’une gestion transactionnelle avec une approche RPC.
Opérations d’écriture de données persistantes, la structure de donnée manipulée par les méthodes d’un objet).
Exemple : EJB Session stateful (un seul client),
Autre aspect de la persistance des données sur le serveur
En fait une notion identique à celle du descriptif de connexion chez le serveur dans une communication en mode connecté.
Il peut y avoir modification de données globales persistantes sur le serveur mais chaque opération du point de vue du protocole s’effectue sans référence au passé (indépendamment de toutes celles qui ont précédé)
Lecture/Écriture du nième article d’un fichier dont toutes les caractéristiques utiles (nom, droit d’accès) sont passées au moment de l’appel.
Je pense que tout ça est déjà dit dans les sockets
Changer les exemples !!!
Exemple : un système de fichier en RPC : lecture d’article de fichier sur le pointeur courant.
Le message d’appel ou celui de retour peuvent être perdus (sauf si l’on emploie un protocole de transport fiable).
Système de communication
Congestion du réseau, messages retardés
Perte de messages
Altération de messages
Détection : expiration du délai de garde A ou D
Panne transitoire (ne nécessite pas d’action de reprise)
Plusieurs moments possibles
Avant B, entre C et D, entre fin traitement et D
Traitement : pas fait, partiel, total
On peut faire mieux avec un service transactionnel
Mémorise identificateur de requête et état avant exécution
Panne du client après émission de l’appel
L’appel est correctement traité
Changement d’état du serveur
Le processus exécutant courant est déclaré orphelin
Le serveur ne peut pas détecter qu’il s’agit d’une répétition
Pas d ’incidence si idempotent
On peut faire mieux, si le client a un service de transactions
De plus haut niveau que les communications en mode message.
Une structure de contrôle bien connue, l’appel de procédure (mode de communication support naturel de l’approche client-serveur).
Utilisation d’un délai de garde par le site appelant
Signalement de l’absence de réponse au client qui décide de la stratégie de reprise.
Reprise arrière automatique (si possible) : soit tentative d’exécution sur un autre site soit reprise sur le même site (si relance)
Plusieurs exécutions successives de la même procédure pour une seule demande.
Réalisation de travaux inutiles, utilisation de ressources qui ne sont plus accessibles pour des tâches utiles.
Mécanisme de traitement des pertes de message à prévoir dans la conception du RPC :
Notion d’ORB (‘Object request Broker’) temps réel en cours d’étude. Gestion de priorités au niveau réparti, gestion d’échéances intégrant les délais réseaux.
Si l'exécution se termine avant l'échéance le serveur transmet sa réponse qui retrouve ou ne retrouve pas son client
Client: Pas de réémission
Serveur : pas d’informations sauvegardées