Systèmes Répartis
Chapitre III :
Communication dans les
systèmes distribuées
RPC et Socket
Amine DHRAIEF
1ère année Master Pro Data Science
Contexte
●
Les systèmes distribués modernes consistent
souvent en des milliers voire des millions de
processus dispersés sur des réseaux peu
fiables.
→ Comment peuvent-ils communiquer ?
13/10/2019 Systèmes Répartis 2
Contexte
●
Une solution = Les RPCs (Remote Procedure
Call)
– Un modèle très répondu de communication entre des
processus d’un système distribué
●
Objectif : Un processus appel localement une
procédure qui est réellement implémentée sur
une machine distante
13/10/2019 Systèmes Répartis 3
Middelware protocols
Applications
●
Par exemple : DNS
●
Des protocoles à usage générale
(general-purpose)
Middelware protocols
●
Des protocoles utilisés par les
applications
OS Pile protocolaire TCP/IP
hardware
13/10/2019 Systèmes Répartis 4
Les RPCs ????
Client Serveur
res=[Link]() ; method(){...}
RPC Middelware RPC Middelware
Requête
Réponse
13/10/2019 Systèmes Répartis 5
Les RPCs en bref :
●
1) Couplage fort
– Le client doit « connaître » le serveur (Référence)
●
2) Dépendance temporelle
– Le client et le serveur doivent être simultanément
connectés et disponibles
●
3) Communication bloquante
– Le client est bloqué entre l’envoi de la requête et
l’arrivée de la réponse
13/10/2019 Systèmes Répartis 6
Analysons tout ça …. !
13/10/2019 Systèmes Répartis 7
Les types de
communication des middelwares
Persistante/Transitoire
Les communications
Synchrone/Asynchrone
13/10/2019 Systèmes Répartis 8
Communication Persistante
PAS DE DÉPENDANCE TEMPORELLE
l’émetteur et le récepteur
ne sont pas obligés d’être présents en même temps
13/10/2019 Systèmes Répartis 9
Communication Persistante
●
Un message qui a été soumis pour transmission
est stocké aussi longtemps que nécessaire pour
le transmettre au destinataire.
– Il n'est pas nécessaire que l'application
d'envoi continue son exécution après l'envoi
du message.
– De même, l'application réceptrice n’a pas
besoin d’être en cours d’exécution lorsque
le message est envoyé.
– Exemple type : l’émail.
13/10/2019 Systèmes Répartis 10
Communication Transitoire
DÉPENDANCE TEMPORELLE
l’émetteur et le récepteur
doivent être présents tout au long de l’échange
13/10/2019 Systèmes Répartis 11
Communication Transitoire
●
Si le middelware n’arrive pas à délivrer le
message au destinataire, le message sera
purement est simplement effacer.
– Les routeurs offrent une communication transitoire
– Si le routeur n’arrive pas à délivrer le message au
prochain saut, le message sera effacer.
13/10/2019 Systèmes Répartis 12
Communication Asynchrone (non
bloquante) / Synchrone (bloquante)
●
Communication asynchrone : L’émetteur
n’est pas bloqué par la transmission en cours, il
peut continuer à s’exécuter après avoir soumis
le message pour transmission
13/10/2019 Systèmes Répartis 13
Communication Asynchrone (non
bloquante) / Synchrone (bloquante)
●
Communication synchrone : L’émetteur est
bloqué jusqu’à ce que :
– le middelware le notifie qu’il va prendre en charge
la transmission de la requête
– la requête est délivré au récepteur
– le requête complètement traitée par le récepteur
(envoie d’un ack)
13/10/2019 Systèmes Répartis 14
RPC Communication Synchrone
Transitoire
13/10/2019 Systèmes Répartis 15
Les RPCs en bref
●
Objectif : permettre aux programmes d’appeler des
procédures situées sur d'autres machines.
●
Lorsqu'un processus sur la machine A appelle une
procédure sur le machine B, le processus d'appel sur A
est suspendu et l'exécution de la procédure a lieu sur
B.
●
Les informations sont acheminées dans les
paramètres et les résultats de la procédure.
– Aucune transmission de message n’est visible au programmeur.
13/10/2019 Systèmes Répartis 16
Les RPCs en bref
●
Quelques problèmes posés par l’utilisation
des RPC :
1)L’appelant et l’appelé tournent sur deux
machines différentes, ils ont deux espaces
d’adressage disjoints.
2)Les paramètres et les résultats doivent être
échangés entre l’appelant et l’appelé via un
réseau non fiable.
3)L’appelant ou l’appelé peuvent crasher.
13/10/2019 Systèmes Répartis 17
Les opérations RPC de bases
●
L'idée principale des RPC est de faire en
sorte qu'un appel de procédure à distance
ressemble autant que possible à un appel
local.
– En d'autres termes, nous voulons que les RPCs
soient transparents
– la procédure appelante ne doit pas savoir que la
procédure appelée s'exécute sur une machine
différente ou inversement.
13/10/2019 Systèmes Répartis 18
Les opérations RPC de bases
●
Supposons qu'un programme ait accès à une
base de données lui permettant d'ajouter des
données à une liste stockée, après quoi il
renvoie une référence à la liste modifiée.
●
L’opération est mise à la disposition d’un
programme au moyen d’une procédure append:
newlist = append(data, dbList)
13/10/2019 Systèmes Répartis 19
Les opérations RPC de bases
●
Dans un système traditionnel (à un seul processeur),
append est extrait d'une bibliothèque par l'éditeur
de liens et inséré dans le programme objet.
● Même si append ne réalise finalement que quelques
opérations de fichier de base, il est appelé de la
manière habituelle.
– Le programmeur ne connaît pas les détails d’implémentation
de append
13/10/2019 Systèmes Répartis 20
Les opérations RPC de bases
Appels de procédure conventionnels
● Soit l’appel local : newlist = append(data, dbList)
●
Nous supposons que le but de cet appel est d’ajouter à un
objet liste dbList , un élément de données simple,
représenté par la variable data.
● Dans divers langages de programmation tels que C, dbList est
implémenté en tant que référence à un objet de liste (c.-à-
d.,un pointeur), alors que les données peuvent être
représentées directement par leur valeur (ce qui est supposé
être le cas ici).
13/10/2019 Systèmes Répartis 21
Les opérations RPC de bases
Appels de procédure conventionnels
● Lors de l'appel de append, data et dbList sont placées
dans la pile, ce qui rend ces représentations accessibles
à l'implémentation de append.
– Pour data, cela signifie que la variable suit une stratégie copie
par valeur, la stratégie pour dbList étant copie par référence.
13/10/2019 Systèmes Répartis 22
Les opérations RPC de bases
Appels de procédure conventionnels
●
Le choix du mécanisme de passage de paramètre
à utiliser est normalement pris par les concepteurs
de langage et est une propriété fixe du langage.
●
Parfois, cela dépend du type de données transmis.
– En C, par exemple, les entiers et autres types scalaires
sont toujours passés par valeur, alors que les tableaux
sont toujours passés par référence
13/10/2019 Systèmes Répartis 23
Les opérations RPC de bases
appels distants ?
● append est en réalité une procédure distante,
une version différente de append, appelée
client stub, est proposée au client appelant.
●
Comme l'original, le client stub est appelé à
l'aide d'une séquence d'appels normale.
Cependant, contrairement à l'original, il ne
réalise pas d'opération d'ajout.
13/10/2019 Systèmes Répartis 24
Les opérations RPC de bases
appels distants ?
●
le client stub regroupe les paramètres dans
un message et demande que ce message
soit envoyé au serveur.
●
Après l'appel à send, le client stub appel
receive et se bloque jusqu'à ce que la réponse
revienne.
13/10/2019 Systèmes Répartis 25
Les opérations RPC de bases
appels distants ?
13/10/2019 Systèmes Répartis 26
Les opérations RPC de bases
appels distants ?
●
Lorsque le message arrive au serveur, le système
d’exploitation du serveur le transmet à un server
stub.
– Un server stub est l'équivalent côté serveur d'un client
stub.
– c'est un code qui transforme les demandes arrivant
sur le réseau en appels de procédure locaux.
●
En règle générale, le server stub appel receive et
se bloque dans l'attente des messages entrants.
13/10/2019 Systèmes Répartis 27
Les opérations RPC de bases
appels distants ?
●
À la réception du message, le server stub décompresse les
paramètres inclus dans le message, puis appelle la
procédure serveur de la manière habituelle.
●
Du point de vue du serveur, c’est comme si la procédure
était appelé localement: les paramètres et l’adresse de
retour se trouvaient tous sur la pile rien ne semblait inhabituel.
●
Le serveur effectue son travail et renvoie ensuite le résultat à
l'appelant (dans ce cas le server stub).
13/10/2019 Systèmes Répartis 28
Les opérations RPC de bases
appels distants ?
●
Lorsque le server stub reprend le contrôle une
fois l'appel terminé, il encapsule le résultat
dans un message et appelle send pour le
renvoyer au client.
●
Après cela, le server stub appel receive à
nouveau, afin d'attendre la demande
entrante suivante.
13/10/2019 Systèmes Répartis 29
Les opérations RPC de bases
appels distants ?
●
Lorsque le message encapsulant le résultat arrive au client, le
système d’exploitation le transmet au client stub via l’opération de
receive précédemment appelée.
→ Le processus client est ensuite débloqué.
●
Le client stub inspecte le message, décompresse le résultat, le
copie et le renvoie de la manière habituelle à la procédure
appelante.
●
Lorsque l'appelant prend le contrôle à la suite de l'appel à
append, tout ce qu'il sait, c'est qu'il a ajouté des données à une
liste.
– Il n'a aucune idée que le travail a été effectué à distance sur une autre
machine.
13/10/2019 Systèmes Répartis 30
Les opérations RPC de bases
appels distants ?
13/10/2019 Systèmes Répartis 31
RPC & Passage de paramètre
La fonction du client stub consiste à encapsuler des
paramètres dans un message, puis à les envoyer au server
stub.
●
Bien que cela semble simple, ce n'est pas aussi évident qu'il y
paraît à première vue.
●
La procédure d’encapsulation des paramètres dans un message
est appelé parameter marshaling.
– « Marshalling is the process of transforming the memory
representation of an object into another format, which is suitable for
storage or transmission to other software applications. » wikipedia
13/10/2019 Systèmes Répartis 32
RPC & Passage de paramètre
● Pour l’opération append, nous devons donc nous assurer que ses
deux paramètres (data et dbList) sont envoyés sur le réseau et
correctement interprétés par le serveur.
●
Ce qu’il faut comprendre, c’est qu’au bout du compte, le serveur ne
verra qu’une série d’octets qui constitueront le message original
envoyé par le client.
●
Cependant, aucune information supplémentaire sur la signification
de ces octets n'est normalement fournie avec le message
→ comment les méta-informations doivent-elles être reconnues
comme telles par le serveur?
13/10/2019 Systèmes Répartis 33
RPC & Passage de paramètre
●
Outre ce problème d'interprétation, nous devons
également traiter le cas où l'emplacement des octets en
mémoire peut différer selon les architectures de machine.
– En particulier, nous devons tenir compte du fait que certaines
machines, telles que les processeurs Intel Pentium,
numérotent leurs octets de droite à gauche, tandis que d’autres,
telles que les anciens processeurs ARM, les numérotent
dans l’autre sens (ARM prend désormais en charge les deux).
– Le format Intel s’appelle little endian et l’ancien format ARM
s’appelle big endian.
13/10/2019 Systèmes Répartis 34
RPC & Passage de paramètre
●
L'ordre des octets est également important
pour la mise en réseau
– Les machines utilisent un ordre différent pour
transmettre (et donc recevoir) des bits et des
octets.
– Big endian est ce qui est normalement utilisé
pour transférer des octets sur un réseau.
13/10/2019 Systèmes Répartis 35
RPC & Passage de paramètre
●
La solution à ce problème consiste à
transformer les données à envoyer en un
format indépendant de la machine et du
réseau
– On peut utiliser des routines dépendant de la
machine qui transforment les données vers et
depuis des formats indépendants de la machine et
du réseau.
13/10/2019 Systèmes Répartis 36
RPC & Passage de paramètre
●
Le Marshaling and unmarshaling permettent
de transformer en formats neutres et
constitue une partie essentielle des appels
de procédure à distance.
13/10/2019 Systèmes Répartis 37
RPC & Passage de paramètre
●
Nous arrivons maintenant à un problème
difficile: comment les pointeurs, ou en
général, les références sont-elles passées?
– La réponse est: avec la plus grande difficulté,
voir pas du tout.
– Un pointeur n'a de sens que dans l'espace
d'adressage du processus dans lequel il est utilisé.
13/10/2019 Systèmes Répartis 38
RPC & Passage de paramètre
● Pour revenir à notre exemple avec append, nous avons indiqué
que le deuxième paramètre, dbList, est implémenté au moyen
d'une référence à une liste stockée dans une base de données.
●
Si cette référence est simplement un pointeur sur une
structure de données locale située quelque part dans la mémoire
principale de l'appelant, nous ne pouvons pas simplement la
transmettre au serveur.
●
La valeur du pointeur transféré fera probablement référence à
quelque chose de complètement différent.
13/10/2019 Systèmes Répartis 39
RPC & Passage de paramètre
●
Une solution consiste simplement à interdire les pointeurs et
les paramètres de référence en général.
– Cette solution est hautement indésirable.
●
Les paramètres de référence sont souvent utilisés avec
– des types de données de taille fixe, tels que des tableaux statiques,
– ou avec des types de données dynamiques pour lesquels il est facile de
calculer leur taille au moment de l'exécution, tels que des chaînes ou
des tableaux dynamiques.
●
Dans de tels cas, nous pouvons simplement copier
l'intégralité de la structure de données à laquelle le
paramètre fait référence, en remplaçant efficacement le
mécanisme de copie par référence par copie par valeur.
13/10/2019 Systèmes Répartis 40
Communications orientées messages :
Les Sockets
13/10/2019 Systèmes Répartis 41
Les inconvénients des RPC
●
Les appels de procédures distantes contribuent à masquer la communication
dans les systèmes distribués, c'est-à-dire qu'ils améliorent la transparence des
accès.
●
Toutefois, avec les RPC on n’est pas toujours sûr que le destinataire est en
train de s'exécuter au moment où une demande est émise, pour assurer cela
d'autres services de communication sont nécessaires.
●
De même, la nature intrinsèque synchrone des RPC, par laquelle un client
est bloqué jusqu'à ce que sa demande ait été traitée, peut être perçu
comme un inconvénient majeur.
→ Une alternative : les communications orientées messages
13/10/2019 Systèmes Répartis 42
Communication transitoire orientée
messages avec les sockets
●
De nombreux systèmes et applications
distribués sont construits directement sur le
modèle simple orienté message proposé par la
couche de transport.
●
Pour mieux comprendre et apprécier les
systèmes orientés message dans les solutions
middleware, nous abordons la communications
via des sockets de niveau transport.
13/10/2019 Systèmes Répartis 43
Communication transitoire orientée
messages avec les sockets
●
Une attention particulière a été accordée à la normalisation de
l'interface de la couche de transport afin de permettre aux
programmeurs d'utiliser toute sa suite de protocoles par le biais
d'un simple ensemble d'opérations.
●
De plus, les interfaces standard facilitent le portage d'une
application sur une autre machine.
●
A titre d’exemple, l'interface socket introduite dans les années
1970 dans Unix de Berkeley et qui a été adoptée comme
standard POSIX (avec très peu d'adaptations).
13/10/2019 Systèmes Répartis 44
Communication transitoire orientée
messages avec les sockets
●
Conceptuellement, une socket est un point de
communication sur lequel une application peut écrire
des données à envoyer sur le réseau sous-jacent et
à partir desquelles des données entrantes peuvent
être lues.
●
Une socket forme une abstraction sur le port réel
utilisé par le système d’exploitation local pour un
transport spécifique.
13/10/2019 Systèmes Répartis 45
Les opérations des sockets TCP/IP
13/10/2019 Systèmes Répartis 46
Les opérations des sockets TCP/IP
Le serveur
●
Les serveurs exécutent généralement les quatre
premières opérations, normalement dans l'ordre indiqué.
– socket / bind / listen / accept
● Lorsqu'il appelle socket, l'appelant crée un nouveau point
de communication pour un protocole de transport
spécifique.
– En interne, la création d’un point de communication signifie que le
système d’exploitation local réserve des ressources pour l’envoi et
la réception de messages pour le protocole spécifié.
13/10/2019 Systèmes Répartis 47
Les opérations des sockets TCP/IP
Le serveur
● L'opération de bind associe une adresse locale au socket
nouvellement créé.
● Par exemple, un serveur doit faire un bind entre l’adresse IP de sa
machine avec un numéro de port (éventuellement bien connu) à
un socket.
● Le bind indique au système d'exploitation que le serveur souhaite
recevoir des messages uniquement à l'adresse et au port
spécifiés.
– Dans le cas d'une communication en mode connexion, l'adresse est utilisée
pour recevoir les demandes de connexion entrantes.
13/10/2019 Systèmes Répartis 48
Les opérations des sockets TCP/IP
Le serveur
● L'opération listen n'est appelée que dans le
cas d'une communication en mode connexion.
●
Il s'agit d'un appel non bloquant qui permet au
système d'exploitation local de réserver
suffisamment de mémoires tampons pour un
nombre maximal spécifié de demandes de
connexion en attente que l'appelant est disposé à
accepter.
13/10/2019 Systèmes Répartis 49
Les opérations des sockets TCP/IP
Le serveur
● Un appel à accept bloque l'appelant jusqu'à ce qu'une
demande de connexion soit reçue.
●
Lorsqu'une demande arrive, le système d'exploitation local crée
un nouveau socket avec les mêmes propriétés que celui
d'origine et le renvoie à l'appelant.
– Cette approche permettra par exemple au serveur de déclencher un
processus qui gérera ensuite la communication réelle via la nouvelle
connexion.
●
Le serveur peut revenir en arrière et attendre une autre
demande de connexion sur le socket d'origine.
13/10/2019 Systèmes Répartis 50
Les opérations des sockets TCP/IP
Le client
● Le côté client aussi,doit d'abord être créé à l'aide de l'opération socket un
point de communication
– Liée explicitement le socket à une adresse locale n'est pas nécessaire, car le système
d'exploitation peut allouer de manière dynamique un port lors de l'établissement de la
connexion.
● L'opération de connect nécessite que l'appelant spécifie l'adresse de niveau de
transport à laquelle une demande de connexion doit être envoyée.
●
Le client est bloqué jusqu'à ce qu'une connexion soit établie avec succès, après
quoi les deux parties peuvent commencer à échanger des informations via les
opérations send et receive.
●
Enfin, la fermeture d'une connexion est symétrique lors de l'utilisation de sockets et
est établie en faisant en sorte que le client et le serveur appellent l'opération close.
13/10/2019 Systèmes Répartis 51
Schéma générale de communication
avec les sockets
13/10/2019 Systèmes Répartis 52
Exemple
[Link]
13/10/2019 Systèmes Répartis 53
Exemple
[Link]
13/10/2019 Systèmes Répartis 54
Exemple
[Link]
13/10/2019 Systèmes Répartis 55
The End !
13/10/2019 Systèmes Répartis 56
