Techniques de dialogue client-serveur

C
CH HA AP PI IT TR RE E I II I : : T TE EC CH HN NI IQ QU UE ES S D DE E D DI IA AL LO OG GU UE E
Introduction
Le client-serveur est avant tout un mode de dialogue entre deux processus. Le premier
appelé client demande l'exécution de services au second appelé serveur. Le serveur accomplit
les services et envoie en retour des réponses. En général, un serveur est capable de traiter les
requêtes de plusieurs clients. Un serveur permet donc de partager des ressources entre
plusieurs clients qui s'adressent à lui par des requêtes envoyées sous forme de messages.
Dans ce chapitre, nous présentons le mode de dialogue client-serveur, indépendamment
des fonctions accomplies et des matériels ou logiciels supports.
Nous allons dans cette section étudier plus en détail ce mode de dialogue.
1) Notions de base
Le modèle de communication client-serveur est orienté vers la fourniture de services par
un processus serveur à un processus client. Un échange consiste donc en la transmission d'une
requête à un serveur, qui exécute l'opération demandée et envoie en retour la réponse. Nous
définissons ci-dessous plus précisément ces concepts de base.
Client : Processus demandant l'exécution d'une opération à un autre processus par envoi d'un
message contenant le descriptif de l'opération à exécuter et attendant la réponse à cette
opération par un message en retour.
Serveur : Processus accomplissant une opération sur demande d'un client et transmettant la
réponse à ce client.
Requête (Request) : Message transmis par un client à un serveur décrivant l'opération à
exécuter pour le compte du client.
Réponse (Reply) : Message transmis par un serveur à un client suite à l'exécution d'une
opération contenant les paramètres de retour de l'opération.
En résumé, la figure 1 ci-dessous illustre ces notions: un client exécute une application et
demande l'exécution d'une opération à un serveur par le biais d'une requête (Request). Il
reçoit une réponse (Reply), lui indiquant par exemple que l'opération a été bien exécutée. Les
appels au service de transport mis en jeu sont au nombre de quatre: SendRequest() permet au
client d'émettre le message décrivant la requête à une adresse correspondant à la porte
d'écoute du serveur, ReceiveReply() permet au client de recevoir la réponse en provenance du

serveur ; ReceiveRequest() permet au serveur de recevoir la requête sur sa porte d'écoute,
SendReply() permet au serveur d'envoyer la réponse sur la porte d'écoute du client.
Figure 1- Le dialogue client-serveur.
2.2) Protocoles de type question-réponse
Comme vu ci-dessus, le dialogue client-serveur s'appuie sur l'envoi de requêtes et de
réponses en sens inverse. Des opérations de transport permettant d'envoyer (Send) et de
recevoir (Receive) des messages sont typiquement utilisées à cette fin. Les protocoles de
question-réponse peuvent s'implémenter au-dessus d'une couche session. Celle-ci doit alors
être établie entre le client et le serveur par des primitives de connexion (Connect), puis de
déconnexion (Disconnect) en fin de session. Ils peuvent aussi être implémentés directement
au-dessus d'un service de datagrammes, qui permet d'envoyer des messages à des portes
associées aux clients et au serveur, ce que nous avions implicitement supposé ci-dessus.
L'identification des clients et des serveurs dans un réseau est un problème d'adressage
réseau. Une ou plusieurs adresses de porte sont généralement associées à un serveur. Cette
adresse peut être dépendante du site ou indépendante, ce qui permet un changement de
localisation des serveurs sans changement d'adresse.
Nous avons vu ci-dessus que quatre appels au service de transport (deux Send et deux
Receive) sont généralement nécessaires pour effectuer un dialogue client-serveur.
3) Assemblage-désassemblage des paramètres
En général, client et serveur s'exécutent sur des machines hétérogènes qui communiquent
par un réseau. Les données sont souvent codées de manières différentes sur des machines
distinctes. Il est donc nécessaire de définir un format d'échange standard, afin de convertir les

noms de fonctions et paramètres dans ce format lors de l'émission, et de les convertir en sens
inverse lors de la réception.
Lors de l'émission d'une requête, les paramètres doivent être arrangés et codés sous forme
de message: c'est l'assemblage. A l'arrivée, ils doivent être remis en format interne de
manière symétrique à partir du message reçu: c'est le désassemblage.
Assemblage (Marshalling)
Procédé consistant à prendre une collection de paramètres et à les arranger et coder en
format externe pour constituer un message à émettre.
Désassemblage (Unmarshallîng)
Procédé consistant à prendre un message en format externe et à reconstituer la collection
de paramètres qu'il représente en format interne.
4) Les protocoles de communication
4-1/ Appel de procédure à distance (Remote Procedure CalI : RPC)
Dans un système centralisé, l'appel d'opération (fonction ou procédure) s'effectue
directement par un débranchement depuis l'appelant vers l'appelé (cf. figure 7). Ceci n'est plus
possible dans un environnement distribué. Afin de rendre transparent le dialogue client-
serveur, la technique d'appel de procédure à distance (RPC) a été introduite.
Cette technique permettant d'appeler une procédure distante comme une procédure locale,
en rendant transparents les messages échangés et les assemblages / désassemblages de
paramètres.
Le RPC offre les fonctions de l'appelé à l'appelant sur le site de ce dernier. Il est réalisé par
introduction d'une souche de procédure (en anglais, stub) pour transformer l'appel de
procédure en un envoi de message depuis le site de l'appelant au site de l'appelé. Là, une
souche de procédure symétrique reçoit le message et réalise l'appel effectif de l'appelé par
débranchement. Les paramètres de retour transitent par un chemin inverse via le réseau
d'interconnexion.
La Souche (Stub) est représentant d'une procédure sur un site client ou serveur capable de
recevoir un appel de procédure du client et de le transmettre en format adapté à
l'implémentation ou à son représentant.

Figure 2 - Illustration du RPC.
De manière plus détaillée, la figure 3 ci-après représente les flots de données entre client et
serveur. La souche client reçoit l'appel de procédure de l'application. Elle assemble les
paramètres et envoie la requête par la commande SendRequest() sur le réseau. La souche
serveur reçoit la requête par la commande ReceiveRequest(), recherche le code de la
procédure à exécuter, désassemble les paramètres, et lance l'exécution de la procédure. La
réponse est transmise en fin d'exécution à la souche serveur qui l'assemble et l'envoie à la
souche client par la commande SendReply(). La souche client reçoit la réponse par la
commande ReceiveReply(), la désassemble, et la transmet à l'application. Tout est donc
transparent pour l'application.

Figure 3 -Fonctionnement du RPC.
Les souches peuvent être générées automatiquement à partir d'un langage de description
d'interface, permettant de spécifier les noms des procédures appelées, les noms, positions, et
types des paramètres d'entrée et de sortie. Ce langage peut être défini comme une extension
d'un langage existant (par exemple C), ou comme un langage indépendant de tout langage de
programmation (par exemple IDL Interface Definition Language).
4-2/ Transfert control protocol (TCP)
5) Dialogue synchrone et asynchrone
Le dialogue client-serveur nécessite l'émission d'une requête et la réception d'une réponse.
Le RPC permet de cacher ces mécanismes de bas niveau pour l'application.
Lors de l'émission d'une requête par une commande SendRequest(), celle-ci peut être émise
immédiatement ou mise en file d'attente pour émission ultérieure. Dans ce dernier cas, la
commande SendRequest() n'est généralement pas bloquante, et l'utilisateur peut effectuer une
autre tâche avant de venir attendre la réponse par une commande
ReceiveRequest. Cette dernière commande peut de même être bloquante en attente de la
réponse, ou non bloquante avec un code retour signalant que la réponse n'est pas arrivée. Ceci
conduit à distinguer les notions de dialogue synchrone et de dialogue asynchrone.
Dialogue synchrone (Synchronous dialog)
Type de dialogue géré sans file d'attente, où les commandes d'émission et de réception sont
bloquantes.
Typiquement, dans le cas synchrone, le client attend le serveur pendant que celui-ci exé-
cute une opération pour lui.
Dialogue asynchrone (Asynchronous dialog)
Type de dialogue géré avec file d'attente, où l'une au moins des commandes d'émission ou
de réception est non bloquante.