Exam on Distributed Systems and Applications

Exercice 1 : Questions diverses

Question 1 - Signification des acronymes

Voici la signification des acronymes demandés :

• CORBA : Common Object Request Broker Architecture
• IOR : Interoperable Object Reference
• IIOP : Internet Inter-ORB Protocol
• JMS : Java Message Service
• MOM : Message-Oriented Middleware (ou Middleware Oriented Message)
• POA : Portable Object Adapter

Question 2 - Différences fondamentales

1. RMI, CORBA et MOM : RMI est une technologie d'invocation de méthodes à distance spécifique à Java (orientée objet et synchrone). CORBA est également orienté objet et synchrone, mais se distingue par son interopérabilité entre différents langages de programmation (C++, Java, etc.). MOM est un intergiciel orienté messages, basé sur une communication asynchrone par files d'attente, sans couplage direct entre l'émetteur et le récepteur.
2. Communication synchrone et asynchrone : Dans une communication synchrone, l'envoi est bloquant (l'émetteur attend la réponse avant de continuer), par exemple avec RMI ou CORBA. Dans une communication asynchrone, l'envoi est non bloquant (l'émetteur continue son exécution immédiatement), par exemple avec un MOM.
3. Message Queue et Topic dans MOM : Une "Message Queue" correspond au modèle Point-à-Point (un seul producteur envoie un message à un seul consommateur spécifique). Un "Topic" correspond au modèle Publication/Souscription (un producteur publie un message qui est distribué à plusieurs consommateurs abonnés).
4. JMS et JXTA : JMS est une API Java standardisée pour interagir avec les systèmes de messagerie (MOM). JXTA est un ensemble de protocoles et une plateforme ouverte pour le développement d'applications distribuées de type Peer-to-Peer (P2P).
5. Un système P2P décentralisé et un P2P structuré : Un P2P décentralisé (ou "pur") ne possède aucun index global ou serveur central ; le réseau se construit par des interactions locales (exemples : Gnutella, Freenet). Un P2P structuré organise les nœuds et les données selon une topologie précise, souvent hybride ou utilisant des tables de hachage distribuées (DHT), pour optimiser la recherche (exemple : Kazaa).

Question 3 - Correspondance MOM et Email

Voici le tableau complété pour établir le parallèle entre une architecture MOM et le courrier électronique :

MOM	email
Message MOM	SMTP message
Message queue (ou File d'attente)	Mail box
Producer (ou Producteur)	SMTP client
Publish/subscribe (ou Topic)	Mailing list

Exercice 2 : Java-RMI

Remarque de l'assistant : Le corrigé source de cet exercice emploie des noms de méthodes différents (calculSurface et decalerRectangle) de ceux exigés dans le texte de l'énoncé (surfaceRectangle et DecalerRectangle). Conformément aux bonnes pratiques de conception, les codes Java ci-dessous utilisent rigoureusement les signatures exactes de l'énoncé. De plus, les imports nécessaires à la compilation (absents du texte original) ont été ajoutés pour garantir un code fonctionnel.

Question 1 - Interface IRectangle

Pour que les opérations soient accessibles à distance via RMI, l'interface doit hériter de java.rmi.Remote et chaque méthode doit déclarer lever une java.rmi.RemoteException.

import java.rmi.Remote;
import java.rmi.RemoteException;

public interface IRectangle extends Remote {
    int surfaceRectangle(Rectangle rect) throws RemoteException;
    Rectangle DecalerRectangle(Rectangle rect, int x, int y) throws RemoteException;
}

Question 2 - Classe Rectangle

Pour être transmis via le réseau par RMI (que ce soit en tant que paramètre ou en tant que valeur de retour), les objets doivent être sérialisables. La classe doit donc implémenter l'interface java.io.Serializable.

import java.io.Serializable;

public class Rectangle implements Serializable {
    public int x1, y1, x2, y2;

    public Rectangle(int x1, int y1, int x2, int y2) {
        this.x1 = x1;
        this.y1 = y1;
        this.x2 = x2;
        this.y2 = y2;
    }

    @Override
    public String toString() {
        return "(" + x1 + "," + y1 + ")(" + x2 + "," + y2 + ")";
    }
}

Question 3 - Implémentation de IRectangle

La classe qui implémente l'interface doit étendre UnicastRemoteObject (ou être exportée manuellement) pour écouter les appels réseau entrants.

import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;

public class IRectangleImpl extends UnicastRemoteObject implements IRectangle {

    public IRectangleImpl() throws RemoteException {
        super(); // Exporte l'objet RMI
    }

    @Override
    public int surfaceRectangle(Rectangle rect) throws RemoteException {
        // La surface est la valeur absolue de la différence des coordonnées
        return Math.abs((rect.x2 - rect.x1) * (rect.y2 - rect.y1));
    }

    @Override
    public Rectangle DecalerRectangle(Rectangle rect, int x, int y) throws RemoteException {
        return new Rectangle(rect.x1 + x, rect.y1 + y, rect.x2 + x, rect.y2 + y);
    }
}

Question 4 - Génération des stubs

Pour les versions de Java nécessitant la génération manuelle des stubs (avant Java 5.0), la commande à exécuter sur la classe compilée est la suivante :

rmic -v1.2 IRectangleImpl

Question 5 - Récupération de la référence via le registry

Pour récupérer la référence distante de l'objet enregistré sous le nom opRect sur la machine ensi, le client utilise la méthode lookup de la classe Naming.

IRectangle opRectangle = (IRectangle) java.rmi.Naming.lookup("rmi://ensi/opRect");

Question 6 - Invocation de la méthode distante

Une fois la référence opRectangle obtenue, l'appel se fait de manière transparente comme s'il s'agissait d'un objet local, bien qu'il faille gérer l'exception distante.

// Supposons qu'un objet Rectangle r1 a été instancié au préalable :
// Rectangle r1 = new Rectangle(0, 0, 5, 5);
int surface = opRectangle.surfaceRectangle(r1);

Exercice 3 : OMG-CORBA

Question 1 - Fichier et extension

Le code fourni correspond à un fichier de spécification d'interface CORBA. Son extension standard est .idl (Interface Definition Language).

Question 2 - Erreurs de syntaxe IDL

Le fichier IDL fourni contient trois erreurs de syntaxe enfreignant les règles du langage.

1. Erreur 1 : string description(); est déclarée directement dans le module clientserveur. Règle non respectée : La déclaration d'une méthode (opération) doit obligatoirement se trouver à l'intérieur d'une entité de type interface.
2. Erreur 2 : string date(long seance ); dans l'interface Cours. Règle non respectée : En IDL CORBA, tout paramètre de méthode doit obligatoirement être précédé par son mode de passage : in (entrée), out (sortie), ou inout (entrée/sortie). Il faudrait écrire par exemple : string date(in long seance);.
3. Erreur 3 : Le bloc de l'interface Cours n'est pas fermé avant l'ouverture de l'interface TP (il manque une accolade fermante };). Règle non respectée : La syntaxe exige la fermeture stricte des blocs. On ne peut pas déclarer une interface à l'intérieur d'une autre interface dans ce contexte. De plus, il est de bonne pratique de définir les types complexes (comme sequence<float>) via un typedef avant leur utilisation dans l'interface.

Question 3 - Commande idlj et fichiers générés

En supposant que le fichier s'appelle Specif.idl, la commande pour générer le code (incluant le stub client) est :

idlj -fall Specif.idl

Dans le répertoire généré (ou dans un sous-répertoire correspondant au nom du module, ici clientserveur), le compilateur va créer cinq types de fichiers pour chaque interface définie (donc un ensemble pour Cours et un ensemble pour TP) :

1. _CoursStub.java (Le proxy pour le client)
2. CoursHelper.java (Méthodes utilitaires de lecture/écriture sur les flux réseau et conversion)
3. CoursOperations.java (Interface Java contenant les méthodes distantes)
4. CoursHolder.java (Classe gérant le passage des paramètres out et inout)
5. CoursPOA.java (Le squelette pour le serveur) (La même série de cinq fichiers sera générée pour l'interface TP).

Exercice 4 : Système de fichiers répartis

Question 1 - Accès concurrent et sémantique "une-copie"

1. Sur une même machine (Unix local) : Unix gère directement les états des fichiers via le noyau du système d'exploitation. Si un utilisateur ouvre un fichier avec des droits de lecture/écriture, le système peut appliquer un mécanisme de verrouillage empêchant les autres processus de l'ouvrir dans un mode modifiant, garantissant ainsi que tout le monde voit immédiatement la dernière mise à jour.
2. Sur deux machines différentes (AFS) : L'Andrew File System assure la cohérence des caches distants via un mécanisme de notifications ("callbacks"). Lorsqu'un processus modifie un fichier sur son client et le renvoie au serveur, le serveur envoie immédiatement une notification d'invalidation à tous les autres clients possédant une copie en cache de ce fichier. Ces clients savent ainsi qu'ils devront télécharger la nouvelle version complète depuis le serveur lors de leur prochain accès.

Question 2 - Fonctionnement de Google FS (GFS)

Remarque : L'énoncé d'origine fait référence à une figure qui est corrompue dans l'extraction PDF (balise illisible data:image/x-emf...). Les réponses ci-dessous sont basées sur le fonctionnement avéré de l'architecture GFS correspondant aux questions posées.

1. A quoi sert le chunk handle dans le GFS ? Le chunk handle sert d'identifiant global unique (souvent sur 64 bits) assigné par le serveur principal (le Master). Il fait office de descripteur permettant de repérer une portion spécifique de fichier (un "chunk") et d'y associer ses métadonnées, comme la liste des emplacements réseau où ce fragment est répliqué.
2. Où sont sauvegardés les fichiers et comment ? Chaque fichier stocké dans le GFS est d'abord découpé en morceaux de taille fixe (les "chunks", typiquement de 64 Mo). Ces chunks sont ensuite sauvegardés sous forme de fichiers Linux standard directement sur les disques des serveurs de stockage appelés "Chunkservers". Pour assurer la tolérance aux pannes, chaque chunk est répliqué sur plusieurs serveurs (généralement 3 fois), et c'est le serveur Master qui supervise la répartition et le contrôle de ces réplicats.
3. Décrivez une opération de lecture. Lorsqu'un client souhaite lire des données :
   • Il utilise l'index du fichier et la position (l'offset) de la donnée voulue pour demander au serveur Master quel fragment est concerné.
   • Le Master répond en fournissant le chunk handle correspondant et la liste des emplacements réseau (Chunkservers) possédant un réplicat de ce chunk.
   • Le client contacte alors directement l'un des Chunkservers (généralement le plus proche sur le réseau) en lui communiquant le chunk handle et une plage d'octets à lire. Les données transitent directement du Chunkserver au client sans repasser par le Master.

Méthode

Face à une épreuve de systèmes répartis comme celle-ci, la réussite repose sur la séparation claire des responsabilités entre chaque composant de l'architecture.

• Concepts et définitions (Exercice 1) : Assurez-vous de bien différencier les paradigmes (objets distribués vs messages, appels bloquants vs asynchrones). Ces notions sont la clé de voûte du reste du cours.
• Développement pratique (Exercices 2 et 3) : Le code attendu est souvent squelettique mais exige une syntaxe parfaite sur les éléments réseau. Pour RMI, n'oubliez jamais les exceptions (RemoteException) et les interfaces mères (Remote, Serializable). Pour CORBA (IDL), rappelez-vous que le langage IDL est déclaratif et indépendant, ses règles de syntaxe (mot-clé in, structure des modules, absence de types natifs complexes non définis) doivent être respectées à la lettre, indépendamment du langage cible.
• Protocoles (Exercice 4) : Lorsque vous expliquez un système distribué (NFS, AFS, GFS), focalisez-vous toujours sur le cycle de vie de la donnée : Qui stocke ? Qui indexe ? Comment les clients sont-ils prévenus si la donnée change ? La clarté de ces trois points garantira la totalité des points de la question.