Examen Systèmes répartis et client/serveur (SRCS) Partie

1/4
Université Pierre et Marie Curie Septembre 2004
Maîtrise Informatique
Filières Polyvalente et Systèmes/réseaux
Module : Systèmes répartis et client/serveur (SRCS)
Examen
Systèmes répartis et client/serveur (SRCS)
Partie Client/Serveur
Les parties Client/Serveur et Systèmes Répartis sont à rédiger sur des copies séparées.
Documents autorisés. 3 heures.
Le barème est donné à titre indicatif.
1 Questions de cours (3 points)
Répondre brièvement aux questions suivantes.
1.1 Définir les trois modes d'invocation de méthodes CORBA. Lequel(s) est (sont) aussi présent(s) en
Java RMI ?
1.2 Dans le cadre des protocoles de communication client/serveur, qu’est-ce qu’une souche ?
1.3 À quoi sert un serveur de noms ?
2 Serveur de consultation RMI (7 points)
On souhaite accéder par Java RMI à des données stockées dans une liste sur un serveur distant. Chaque
élément, de type java.io.Serializable , de la liste est associé à une clé unique de type
java.lang.String .
Avant d’accéder à une donnée, un client doit invoquer la méthode login du serveur. Cette méthode prend
comme paramètre un nom d’utilisateur ( String ) et retourne un entier représentant un identifiant de ses-
sion. Le serveur fournit également les méthodes suivantes :
- read : à partir d’une clé ( String ) et d’un identifiant de session (entier), retourne l’élément associé à
la clé, ou null s’il n’y en a pas.
- close : à partir d’un identifiant de session (entier), ferme la session. Cette méthode ne retourne rien.
À titre d’exemple, un serveur de consultation s peut s’utiliser de la manière suivante :
int cx = s.login("Robert");
Serializable obj1 = s.read("train",cx);
Serializable obj2 = s.read("avion",cx);
s.close(cx);

2/4
2.1 Définir l’interface Java RMI ServeurItf comprenant les méthodes login , read et close . (1 point)
2.2 Rappeler les règles que doit respecter une classe implantant une interface Java RMI. (1 point)
Le volume de données augmentant, il ne devient plus possible de les stocker sur un seul serveur. On dé-
cide de les répartir sur plusieurs serveurs. On envisage les deux architectures suivantes.
Dans la première, un frontal gère l’accès aux serveurs de consultation. Les clients ne connaissent que lui.
Le frontal se charge de déléguer la requête aux serveurs de consultation. Le frontal connaît donc tous les
serveurs de consultation.
Dans la seconde, les clients connaissent tous les serveurs de consultation et s’adressent directement au
serveur dont ils souhaitent consulter les données.
2.3 En cas d’ajout ou de retrait d’un serveur de consultation, que faut-il faire avec la première architec-
ture ? Avec la seconde ? Quelle est celle qui pose le moins de problème ? Pourquoi ? (1 point)
2.4 Lorsqu’il y a beaucoup de clients, quelle solution est la plus efficace ? Pourquoi ? (1 point)
Architecture n° 1
On se place dans le cas de la première architecture.
2.5 L’interface ServeurItf définie précédemment peut-elle être utilisée pour le frontal ? Pour les ser-
veurs de consultation ? (0,5 point)
Soit ConsultationItf l’interface des serveurs de consultations. On souhaite définir une interface Java
RMI GestionFrontalItf de gestion du frontal offrant les méthodes suivantes :
- ajouter : permet d’ajouter un serveur de consultation à la liste des serveurs gérée par le frontal.
Prend un paramètre de type ConsultationItf . Ne retourne rien.
- retirer : permet de retirer un serveur de consultation de la liste des serveurs gérée par le frontal.
Prend un paramètre de type ConsultationItf . Ne retourne rien.
2.6 Définir l’interface Java RMI GestionFrontalItf . Comment définir simplement l’interface com-
plète du frontal ? (0,5 point)
2.7 Le frontal doit être capable d’aiguiller les requêtes de consultation vers le bon serveur. Proposer un
mécanisme de répartition des données sur les serveurs qui permettent de faire cela efficacement (on
ne vous demande pas de l’implémenter). (1 point)
client frontal
serveurs de
consultation
client
serveurs de
consultation
Architecture n° 1 Architecture n° 2

3/4
Architecture n° 2
On se place dans le cas de la deuxième architecture. On souhaite interroger en parallèle deux serveurs de
consultation. On utilise pour cela des threads.
2.8 Expliquer en français comment créer et lancer un thread en Java. (0,5 point)
2.9 Donner le code Java qui permet au client d’interroger en parallèle deux serveurs de consultation s1
et s2 . (0,5 point)

4/4
Partie Systèmes Répartis
A rédiger sur une copie séparée.
3 Questions de cours (3 points)
3.1 Dans un système réparti de gestion de fichier, définir brièvement les notions de serveur de nom-
mage integré au serveur de fichier, et de serveur de nommage externe au serveur de fichier.
3.2 Quels sont les avantages et inconvénients de ces deux sortes de serveurs ?
4 MVRP (7 points)
On considère un système de mémoire virtuelle répartie partagée (MVRP). Dans ce système une applica-
tion répartie sur N machines n'a pas à s'occuper des communications, c'est le système de MVRP qui s'en
charge. Lors de l'accès à une donnée, le système de MVRP se charge de verrouiller la donnée et de la
rapatrier au processus demandeur. Une donnée en écriture n'est accessible que par un seul processus écri-
vain. Une donnée en lecture peut-être accédée par plusieurs lecteurs.
4.1 Proposez une interface de programmation avec la MVRP. Programmez cette interface en RPC.
4.2 Quels sont les avantages et les inconvénients d'un tel système de MVRP par rapport à un méca-
nisme de passage de message (RPC ou autre).
4.3 Lors de l'accès à une donnée par un processus, la MVRP doit connaître la localisation de cette don-
née et de ses éventuelles copies. Proposez un algorithme de localisation d'une donnée (sans utiliser
un message de diffusion).
4.4 Indiquez le fonctionnement de la MVRP lorsqu'une application accède principalement en lecture
(resp. en écriture) à ses données.
4.5 Est-ce qu'une application s'exécutant sur la MVRP peut-être plus performante qu'une application
équivalente écrite en RPC ? Justifiez.