Systèmes et Applications Répartis

 Principes communs aux différentes versions:

Binding RPC

le binder est un programme RPC de numéro 100000

 il écoute toujours sur les ports 111 UDP et TCP

 Le portmapper offre différentes fonctions :

 publication d’un programme (décrit par son #programme et son

#version)

 suppression d’un programme

 découverte (résolution) d’un programme, c’est-à-dire obtention du

port associé à un programme

 obtention de la liste des programmes enregistrés

 appel direct d’une fonction distante

ENSI

Systèmes et applications répartis

 Le portmapper est limité à TCP et UDP.

16

RPCbind

 Remplace le portmapper.

 Principaux avantages :

 indépendant du transport

 permet un enregistrement et une résolution incluant les

informations de transport

 offre quelques nouvelles fonctions :

 horloge

 statistiques d’utilisation

 un programme peut enregistrer plusieurs instances

correspondant à différents transports (avec le portmapper,

le transport est automatique celui utilisé pour contacter le

ENSI

portmapper lui-même)

Systèmes et applications répartis

17

RPC : Gestion des paramètres

 Problèmes des paramètres

 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)

 Les paramètres sont transmis sur le réseau

Représentation sérialisée des structures

 Les machines client et serveur peuvent être

hétérogènes

Conversion de format

ENSI

Systèmes et applications répartis

18

RPC : Traitement de l’hétérogénéité

 Problème : représentation des données

 Conversion nécessaire si le site client et le site serveur :

 N’utilisent pas le même système de codage

 Utilisent des formats internes différents (pour le type de base : caractère,

entier, flottant, …)

 Solutions

 Syntaxe abstraite de transfert de données (Abstract Syntax Notation)

ASN1 : Norme OSI de définition universelle de type

 Représentation externe commune : Sun XDR (eXternal Data

Representation)

Non optimale si même représentation client et serveur

 Représentation locale pour le client et conversion par le serveur

 Choix d’une représentation parmi n (standard), conversion par le serveur

 Négociation client serveur

ENSI

Systèmes et applications répartis

19

Représentation de Données (en

mémoire)

 Client et serveur sur machines différentes

 Il faut transmettre données et résultats

 Différences de représentations en mémoire

 Codage Little-endian (x86, alpha) vs. Big-endian (ppc,

sparc, réseau) : (dépend du processeur)

 Représentation des flottants (fixe par IEEE 754)

 Alignement des données dans structure (dépend du

compilateur)

 Tailles (32 ou 64 bits ; 4 ou 8 octets pour un registre)

ENSI

Systèmes et applications répartis

20

XDR –eXternal Data Representation

 Représentation portable des données (réseau):











codage big endian avec des mots de 4 octets (complétion par des zéros)

permet de définir des types de données associés à une

représentation binaire standard

Représentation commune sur le réseau (format pivot)

orienté C (syntaxe proche du C):

 types fondamentaux classiques (int, double, etc.)

 énumération

 struct et union

 tableaux

rpcgen engendre des fonctions de traduction à partir d’un fichier .x(et des

bibliothèques de conversion de bas niveau) en XDR

ENSI

Systèmes et applications répartis

21

XDR –Types (1/2)

Type

Identificateur

taille

Entier relatif

int

Entier positif

unsigned int

Enumération

enum {id =

constante, …}

Booléen

bool

4 octets (IEEE)

4 octets (IEEE)

4 octets (IEEE)

Enum {False=0,

True=1}

Entier long

hyper

Entier positif

unsigend hyper

8 octets

8 octets

Type

Identificateur

taille

Réels simples

Réels doubles

Float

double

Réels long

quadruple

Rien

void

4 octets (IEEE)

4 octets (IEEE)

4 octets (IEEE)

0 octet

ENSI

Systèmes et applications répartis

22

XDR –Types (2/2)

 Données à taille fixe ou variable :

 [n] correspond à une taille fixe égale à n

 <> correspond à une taille variable

 <m> correspond à une taille variable inférieure à m

 exemple, int<15> : liste d’entiers de longueur au plus 15.

Cas particuliers :

Identificateur

Contenu

opaque

string

Liste d’octets

Chaîne de caractères

ENSI

Systèmes et applications répartis

23

RPC : Passage des paramètres

Plusieurs modes de passage sont possibles

Passage par valeur

 pas de problème

Passage par copie-restauration

 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

ENSI

Systèmes et applications répartis

24

RPC : Passage des paramètres

 Passage par référence (adresse)

 Impossible puisque espaces distincts

 Palliatifs possibles

 Interdire l’appel par référence

 Utiliser l’appel par copie-restauration

Équivalent le plus souvent …

 … mais pas dans tous les cas (aliasing)

 Programmer à la main les procédures d’emballage-

déballage pour les structures complexes

 Nouveaux modèles de communication (mémoire

virtuelle répartie) : revient à un espace commun

ENSI

Systèmes et applications répartis

25

Composants de RPC

IDL-- Interface Definition Language: langage de

description des données et des fonctions proche du

C;

 une méthode de représentation portable des

données;

 un protocole d’appel :

 transmission des paramètres de l’appel du client vers le

serveur;

 transmission du résultat du serveur vers le client;

 un protocole de publication et de recherche d’un

service.

ENSI

Systèmes et applications répartis

26

Langage de description

d’interface (IDL)

Interface = “contrat” entre client et serveur

 Définition commune abstraite

 Langage neutre (adapté à des langages multiples), proche du

C++

 Indépendante de la représentation des types

 Indépendante de

la machine  masquer

les divers

problèmes d’hétérogénéité

 Contenu minimal

 Identification des procédures (nom, version)

 Définition des types des paramètres, résultats, exceptions

 Définition du mode de passage (IN, OUT, IN-OUT)

 Extensions possibles

 Procédures de conversion pour types complexes

 Propriétés non fonctionnelles (qualité de service), non standard

27

Systèmes et applications répartis

ENSI

Avantages d’un IDL

 Traitement de l'hétérogénéité

 Types de données différents selon les langages

 Représentations internes différentes selon les

systèmes

 Définition des types indépendante de la

représentation

 Description d'une interface

 Description des types élémentaires

(arguments, résultats, exceptions)

 Procédures de conversion pour types complexes

(avec pointeurs)

ENSI

Systèmes et applications répartis

28

IDL

Mode opératoire

Procédure

Procédure

du client

du client

stub

stub

compilateur

compilateur

Programme

Programme

client

client

Description

d’interface

Générateur

de talons

Définitions

communes

bibliothèque

Générateur

de talons

Définitions

communes

bibliothèque

Procédure

Procédure

du serveur

du serveur

skeleton

skeleton

compilateur

compilateur

Programme

Programme

serveur

serveur

ENSI

Systèmes et applications répartis

29

Le Langage de Description RPCL

 IDL de RPC

 Les fichiers spécification d’extension ‘’.x ’’ ont la structure

suivante:

[Definition des constantes]

[Definition des types]

program NOM_PROGRAMME {

[version NOM_VERSION {

[type_resultat nom_procedure

(type_du_parametre) = numero_procedure;]

} = numero_version]

} = numero_programme;

ENSI

Systèmes et applications répartis

30

Le Langage de Description RPCL

 Les constantes :

const identificateur = valeur;

 Les structures :

struct nom_du_type {

type attribut ;

}

 Nouveau type:

typedef type nom_du_type ;



Cas particulier des tableaux et chaînes de caractères :

typedef int vecteur <1000>

typedef string chaine <255>

ENSI

Systèmes et applications répartis

31

Le Langage de Description RPCL

 Tableau

 Tableaux de taille fixe et connue : comme en C, avec [ ]

 Exemple : int data[12];

 Tableaux de taille variable

 Utilise les < > au lieu des [ ]

 Peut préciser la taille maximale du tableau entre les < >

 Exemple

– int data< >

– double valeurs<10> tableau au plus de 10 double

taille quelconque

 Traduction en C

– Définition d'un tableau de taille variable : structure de 2 éléments

» Le pointeur correspond au tableau

» La taille du tableau

struct {

u_int data_len;

int *data_val;

} data;

ENSI

Systèmes et applications répartis

32

Le Langage de Description RPCL

 Unions

 Syntaxe d'utilisation

union nom_union switch(type discrim) {

case value : ... ;

case value : ... ;

...

default : ...;

};

 Exemple

 Selon le code d'erreur d'un calcul, on veut stocker le résultat normal

(un flottant) ou le code de l'erreur (un entier)

union res_calcul switch(int errno) {

case 0:

float res;

default:

int error;

};

Traduit dans le .h en :

struct res_calcul {

int errno;

union {

float res;

int error;

} res_calcul_u;

};

typedef struct res_calcul res_calcul;

ENSI

Systèmes et applications répartis

33

Le Langage de Description RPCL

 Chaînes de caractères

 Utilise le type string

 Taille de la chaîne : quelconque ou taille maximale

 Utilise aussi la notation en < >

 Exemple

 string nom<20>; chaine de taille d'au plus 20 caractères

 string message<>; chaine de taille quelconque

 Traduit dans le .h en char* tous les deux

 char *nom;

 char *message;

 Données opaques

 Utilise le type opaque

 Exemple

– opaque id_client[128];

ENSI

Systèmes et applications répartis

34

ONC RPC (SUN)

 rfc 1831

 Solution classique, disponible sur Unix (incluse dans le système en général)

 « Open source », comparable aux DCE RPC en “gratuit”

 Il utilise le protocole XDR pour la description/échange de données (transport

des arguments et du résultat) -- (rfc 1832) ;

 Technologie utilisée par NFS--Network File System.

 Outil de base rpcgen:

génère des convertisseurs ((un)marshalling);



 génère les souches (serveurs et clients);

 propose des modèles pour le client et le serveur

 engendre un Makefile;

 Utilise un lookup service pour la publication et la découverte d’un service (rfc

1833);

 Service lookup tourne sur chaque hôte contenant des serveurs rpc.

 Les RPC ONC peuvent être implantées sur n’importe quelle couche transport

(TCP/UDP)

ENSI

Systèmes et applications répartis

35

Principe de base de SUN RPC

 Un service réseau est fourni par plusieurs programmes

 Un programme fournit plusieurs fonctions (ou procédures)

 Un client appelle une procédure d’un programme

ENSI

Systèmes et applications répartis

36

Le protocole RPC --Identification

 Une procédure est identifiée par trois entiers (positifs) :

 Hostname (IP Address)

 Le numéro de programme unique (32 bit integer)

 Sun divise les IDs en :

0x00000000 - 0x1fffffff Serveurs officiels Sun

0x20000000 - 0x3fffffff

0x40000000 - 0x5fffffff Serveurs Transitoires

0x60000000 - 0xffffffff Réservée par Sun

Publique (Admin. système)



Le numéro de procédure (32 bit integer)

 Commence toujours à partir de 1 et puis

incrémenté

séquentiellement.

 Le numéro de version du programme (pour tests et migration)

 Commence typiquement à partir de 1 et puis incrémenté

ENSI

Systèmes et applications répartis

37

RPCGEN : RPC Generator

 Utilitaire permettant de générer automatiquement

le code des talons et des fonctions XDR associées

aux données utilisées par les fonctions

 Principe d'utilisation

 On décrit dans un fichier (d'extension .x)

Les structures de données propres aux

fonctions

Les fonctions appelables à distance

 RPCGEN génère ensuite un ensemble de

fichiers

ENSI

Systèmes et applications répartis

38

RPCGEN

ENSI

Systèmes et applications répartis

39

Règles d'écriture du fichier .x

Fichier décrivant les fonctions et données

 Pour données

Décrit les structures presque comme en C (voir suite pour détails)

 Pour fonction : règle fondamentale

Une fonction ne prend qu'UN seul paramètre

On doit donc définir une structure de données dédiée à la fonction

si on veut passer plusieurs valeurs en paramètre

 Définition d'un « programme » RPC

Programme = ensemble de fonctions/services

Chaque programme possède un nom avec un numéro associé

Un programme peut exister en plusieurs versions

– Chaque version est identifiée par un nom et un numéro associé

– Chaque version définit une liste de fonctions

– Chaque fonction est identifiée par un numéro unique

ENSI

Systèmes et applications répartis

40

Exemple : geometrie.x

ENSI

Systèmes et applications répartis

41

Exemple : geometrie.x (suite)

 Nom du programme : GEOM_PROG d'identifiant 20000001 (en

hexa)

 Nom de version : GEOM_VERSION_1 de numéro 1

 Les 3 fonctions sont numérotées 1, 2 et 3

 Les structures coordonnees et param_inclus ont été créées pour les

fonctions nécessitant plus de 2 paramètres

 Par convention, on écrit les noms de fonctions, programmes et versions en

majuscule

ENSI

Systèmes et applications répartis

42

Génération des fichiers

Pour générer les fichiers avec rpcgen

 $ rpcgen geometrie.x

Fichiers générés à partir du .x

 geometrie.h

Définition de toutes les structures et des signatures des

opérations

 geometrie_xdr.c

Fonctions de codage XDR des structures de données

 geometrie_clnt.c et geometrie_svc.c

 Talons côtés client et serveur

 Avec option -a de rpcgen

Génère fichier geometrie_server.c

– Squelette pour écriture des fonctions du programme

ENSI

Systèmes et applications répartis

43

Exemple : fichier geometrie.h

ENSI

Systèmes et applications répartis

44

Exemple : fichier geometrie.h (suite)

ENSI

Systèmes et applications répartis

45

Contenu fichier .h

 Pour chaque structure définie

 Définition de la structure équivalente en C

 Définition d'un type du même nom correspondant à la structure

 Signature de la méthode XDR correspondant à ce type

 Exemple, dans .x

struct point {

int x;

int y;

};

 Devient dans le .h

struct point {

int x;

int y;

};

typedef struct point point;

bool_t xdr_point(XDR, point);

ENSI

Systèmes et applications répartis

46

Contenu fichier .h

Pour chaque méthode

 Dans .x

Pour chaque opération nommée fonction, de version numérotée x, qui

prend un type_param en paramètre et retourne un type_retour

 On aura dans le .h, signature de 2 méthodes correspondantes

type_retour fonction_x(type_param , CLIENT *)

type_retour fonction_x_svc(type_param , svc_req *)

 Dans les 2 cas

Le nom de la fonction est suffixée par la version (et svc pour la

seconde)

Un niveau de pointeur en paramètre et retour est ajouté par rapport au .x

ENSI

Systèmes et applications répartis

47

Contenu fichier .h

Pour chaque méthode (suite)

 Première version : fonction_x

 Fonction qui est implémentée par le talon client

 C'est cette fonction que la partie client appelle localement pour demander l'appel de la fonction

associée côté serveur

 Paramètre CLIENT*

– Caractéristiques de la communication avec la partie serveur

 Deuxième version fonction_x_svc

 Fonction à implémenter côté serveur

– Fonction qui est appelée par les clients

 Paramètre svc_req* : caractéristiques de la requête d'appel de service et identification du client

Exemple

 geometrie.x : int SURFACE_RECTANGLE(rectangle) = 1;

 geometrie.h

 int surface_rectangle_1(rectangle , CLIENT );

 int surface_rectangle_1_svc(rectangle , svc_req );

ENSI

Systèmes et applications répartis

48

Contenu fichier .h

 Définitions de constantes

 Numéros de programme et de versions en associant chaque

numéro au nom précisé dans .x

 Exemple

– #define GEOM_PROG 0x20000001

– #define GEOM_VERSION_1 1

 Pour chaque fonction, définition d'une constante associant son

nom à son numéro

 Exemple

– Dans .x

» rectangle CREER_RECTANGLE(coordonnees) = 2;

– Dans .h

» #define CREER_RECTANGLE 2

 Toutes ces constantes serviront à identifier le programme et les

fonctions lors des appels à distance

ENSI

Systèmes et applications répartis

49

Implémentation des fonctions

 Côté serveur, dans un fichier à part ou dans le squelette côté

serveur si on l'a généré

 Pour chacune des fonctions du programme, on

implémente le code en prenant la signature du .h

 Exemple

Dans .h

extern int surface_rectangle_1_svc(rectangle, svc_req*);

extern rectangle creer_rectangle_1_svc(coordonnees,

svc_req*);

extern bool_t inclus_1_svc(param_inclus, svc_req*);

Implémentation de ces fonctions dans fichier

geometrie_server.c

ENSI

Systèmes et applications répartis

50

Exemple : fichier geometrie_server.c

*

ENSI

Systèmes et applications répartis

51

Exemple : fichier geometrie_server.c

*

 Notes

 On n’a pas d'utilité ici à manipuler le paramètre svc_req

 Les variables result sont déclarées en static

On doit retourner un pointeur sur une donnée qui existera toujours

après l'appel de la fonction

Cette donnée sera retournée par copie au client

ENSI

Systèmes et applications répartis

52

Côté client

 Pour appel d'un service fonction sur la partie serveur

 Appelle simplement la fonction fonction_x côté client

 Cette fonction est appelée sur le talon client qui relaie la requête côté

serveur sur lequel on appellera fonction_x_svc

 Avant de pouvoir appeler une fonction sur une machine distance

 Doit identifier le programme RPC tournant sur cette machine

CLIENT *clnt_create(

char *machine,

long numero_programme,

long numero_version,

char *protocole);

nom de la machine serveur

id. du programme RPC

id. de la version du programme

« udp » ou « tcp »

 Pour identificateurs programme et version : peut utiliser les noms

associés se trouvant dans le .h

 Retourne un identificateur de communication côté client à utiliser

pour appel des fonctions ou NULL si problème

 Exemple : fichier client.c

 Programme qui appelle les fonctions distantes géométriques

ENSI

Systèmes et applications répartis

53

Exemple côté client : client.c

ENSI

Systèmes et applications répartis

54

Côté client : client.c

 Commentaires

 Pour la connexion avec le programme RPC distant

 Le programme s'exécute sur la machine scinfe222

 On utilise les constantes définies dans geometrie.h pour identifier le

programme et sa version

– GEOM_PROG et GEOM_VERSION_1

 On choisit une communication en UDP

 Fonctions creer_rectangle_1, calculer_surface_1 et inclus_1

 Vont engendrer l'appel des fonctions associés sur le serveur (sur la machine

scinfe222)

 Aucune différence avec appel d'une fonction locale

– Transparence totale de la localisation distante du code de la fonction

 Gestion des erreurs possibles lors des appels RPC

 Les fonctions retournent NULL

 clnt_perror(CLIENT,char msg) : affiche l'erreur (avec msg avant)

ENSI

Systèmes et applications répartis

55

Compilation parties client et

serveur

 Pour les 2 parties, besoin des fonctions de codage XDR

 $ gcc -c geometrie_xdr.c

 Côté client

 $ gcc -c geometrie_clnt.c

 $ gcc -c client.c

 $ gcc -o client client.o geometrie_clnt.o geometrie_xdr.o

 Côté serveur

 $ gcc -c geometrie_svc.c

 $ gcc -c geometrie_server.c

 $ gcc -o serveur geometrie_svc.o geometrie_server.o

geometrie_xdr.o

ENSI

Systèmes et applications répartis

56

Côté serveur

 Lancement du serveur

 Le talon côté serveur (geometrie_svc.c) contient un main qui enregistre

automatiquement le programme comme service RPC

 Avec l'outil système rpcinfo, on peut connaître la liste des services RPC

accessibles sur une machine

$ /usr/sbin/rpcinfo -n scinfe222

program no_version protocole no_port

tcp

100000 2

udp

100000 2

udp

100024 1

tcp

100024 1

tcp

391002 2

udp

536870913 1

tcp

536870913 1

portmapper

111

portmapper

111

32768

status

32770 status

32771 sgi_fam

32916

38950

 Notre programme est bien lancé en version 1

 Numéro programme : (536870913)10 = (20000001)16

 Il est accesible via UDP (port 32916) ou TCP (port 38950)

 Portmapper : démon système qui est interrogé pour

récupérer la référence sur un service RPC et qui enregistre les

services

ENSI

Systèmes et applications répartis

57

Liste des services RPC enregistrés sur une

machine

 Liste des services enregistrés:

 rpcinfo –p [machine]

 Appel de la procédure 0 d’un programme en

utilisant le protocole udp et tcp

 rpcinfo -u machine num_prg [num_version]

 rpcinfo -t machine num_prg [num_version]

ENSI

Systèmes et applications répartis

58

Conclusions Générales

 Limites de la programmation traditionnelle

 Tout est à la charge du programmeur

Construction des différents modules,

interconnexion

 Manque d'abstraction pour limiter la complexité

Structure de l'application et constituants

masqués

 Evolution / modification des fonctionnalités

difficiles

 Besoins importants d‘ingénierie logicielle et

ENSI

Systèmes et applications répartis

59

compétence technique

 Développement complexe  temps  fiabilité 

Conclusions sur les RPCs

 Des mécanismes plus évolués visent à remédier à ces limitations.

 C/S objet

 RMI: objets répartis de Java

 Supporte la migration de code

 CORBA

 DCOM (Microsoft): concurrent de CORBA

 XML-RPC

 Utilise des technologies normalisées:

 XML, HTTP

 Bénéficie d'un niveau de sécurité normalisé: HTTPS (SSL+X509)

 SOAP (Microsoft)

 Basé sur XML-RPC

60

Nétographie

 La majorité des transparents de ce cours sont pris de:

[Krako]

[Duvallet]

[Riveill99]

[Esnard]

http://sardes.inrialpes.fr/~krakowia/Enseignement/M

2P-GI/; Systèmes et Applications Répartis (Sacha

Krakowiak, Grenoble).

http://litis.univ-lehavre.fr/duvallet/; cours de Systèmes et

Applications Réparties, Claude Duvallet

M. Rivell, Modele client-serveur, cours ensimag, 1999. ref.

03-99-slides-client-serveur.pdf

http://www.labri.fr/~esnard; Programmation des

Applications Réparties, Aurélien Esnard, ENSEIRB

PG306-IT343

[Quinson08]

Programmation d'Applications Reparties, Martin Quinson,

cours ESIAL, 2008.

[Alons11]

Gustavo Alonso, Timothy Roscoe, Donald Kossmann,

Networks and Operating Systems, Chap. 3: Remote

Procedure Call (RPC). ETH Zurith, 2011

61