Fabrice Huet fhuet@sophia.inria.fr Systèmes Distribués Fabrice Huet fhuet@sophia.inria.fr.

Présentation au sujet: "Fabrice Huet fhuet@sophia.inria.fr Systèmes Distribués Fabrice Huet fhuet@sophia.inria.fr."— Transcription de la présentation:

1 Fabrice Huet fhuet@sophia.inria.fr
Systèmes Distribués Fabrice Huet

2 Thèmes, Évaluation Thèmes: Introduction aux systèmes distribués
Matériel, Logiciel Communications Synchronisation Outils pour la programmation Sockets RPC Java-RMI Introduction aux systèmes Pair-à-Pair Évaluation Un mini projet à rendre en binomes Examen

3 1- Introduction aux Systèmes Distribués
“… no man is an island, entire of itself; every man is a piece of the continent, a part of the main.” John Donne ( ). “The network is the computer” Sun Microsystems, 1985.

4 Petites définitions Pleins de définitions possibles pour un SD:
Un système distribué est une collection d’ordinateurs indépendants qui apparaissent à l’utilisateur comme un unique système cohérent Un système distribué est un ensemble de programmes, s’exécutant sur des ordinateurs différents, reliés par un réseau, et s’échangeant des informations pour exécuter une tache. Élément d’un SD Un élément physique d’un SD (par exemple un processeur) est appelé hôte ou noeud

5 Identifier un système distribué
Comment déterminer si un système est un SD ? est-ce que c’est….. La distance géographique entre les nœuds ? Le nombre de nœuds disponibles ? Le système d’exploitation, les protocoles, l’api utilisés ?

6 La taille ? Non Il y en a de toutes les tailles
Les sondes contrôlées depuis la terre Millions de kms Seulement quelques noeuds (Mars Pathfinder, 1997) Internet Milliers de kms, Millions de noeuds

7 La taille ? Non Tailles intermédiaires
Ordinateurs reliés à une imprimante ~ 10 mètres ~ 10 nœuds Caisse enregistreuse dans un supermarché ~ 100 mètres ~ 100 nœuds

8 La taille ? Non Très petits Home Cinéma
~ 1 mètre 3-5 noeuds (TV, Stéreo, DVD,…) Voitures (GPS, ABS, alarme, ...) Quelques mètres Plein de noeuds 40% du coût d’une voiture moderne est lié à l’électronique Personal Area Networks ~ 1 mètre 3-5 noeuds (montre, portable, PDA, lunettes…)

9 SD vs. Systèmes centralisés
Quelle sont les différences entre un SD et un système centralisé (ou mono-processeur) Un système centralisé est un système qui fonctionne toujours si la connexion réseau est coupée Exemples: Compilateur Traitements de texte Certains jeux Systèmes d’exploitation pour ordinateurs familiaux (mais de moins en moins vrai)

10 SD vs. Systèmes centralisés
Différences principales Plus un unique espace d’adressage Un programme sur un nœud ne peut pas accéder directement aux données d’un autre programme sur un autre nœud. Les programmes s’exécutent indépendamment Vraie parallélisme (et concurrence) entre les programmes Pas d’horloge globale, chaque exécution est différente Les communications se font en envoyant des informations sur le réseau La latence à un impact important Les pannes sont courantes

11 SD vs. Systèmes centralisés
Objectifs: Transparence Masquer la distribution Dégradation progressive Un système devrait continuer à fonctionner aussi correctement que possible si une de ses parties tombe en panne. Les systèmes centralisés tombent en panne complètement. Passage à l’échelle Un SD devrait être capable de gérer un grand nombre de noeuds. Hétérogénéité Les nœuds peuvent être d’architecture différente, avoir des OS différents…

12 Transparence Le concept de transparence peut-être appliqué à plusieurs aspects Localisation : où se trouve la ressource Migration : déplacement de la ressource Réplication : plusieurs ressources Concurrence : plusieurs utilisateurs Panne : panne ou réparation Persistance : sauvegarde de la ressource

13 Passage à l’échelle La centralisation limite le passage à l’échelle
Service centralisé : un unique serveur Données centralisées : unique point d’accès pour les données Algorithmes centralisés : nécessite une connaissance globale du système La latence est aussi un facteur limitant Mais il existe de nombreuses techniques pour contourner ces problèmes Serveurs multiples (ex: CDN - DNS) Bases de données réparties (ex: DNS) Algorithmes utilisant des informations partielles (ex: P2P)

14 Exemple: Nom de domaine
Il est plus facile de se rappeler d’un mot/phrase que d’une série de chiffres… Les noms de domaine sont des suites alphanumériques de caractères séparées par des points Chaque segment a une taille/valeur arbitraire (mais limitée) Le segment le plus significatif (le plus à droite) est normalisé com, edu, gov, info, org, net, biz… La transformation du nom de domaine en adresse IP se fait en contactant un serveur de domaine (DNS) Les serveurs DNS sont organisés hiérarchiquement Au sommet se trouvent les serveurs racine Chaque organisation peut mettre en place son serveur

15 Nom de domaine - 2 Serveur Web
Serveurs DNS Serveur Web IP? XXX.XXX.XXX.XXX http get Client Pour communiquer, un client doit connaître l’IP d’un serveur et un numéro de port Cette adresse s’obtient auprès d’un serveur DNS (lookup)

16 Serveurs DNS . com org gov biz fr amazon unice free inria Une requête DNS est envoyée au serveur du domaine dont dépend la machine Si le serveur n’a pas autorité il demande à son parent… Les réponses parcourent le chemin inverse et sont mises en cache

17 Exemple: CDN Content Delivery Network
Un (très) gros serveur peut supporter plusieurs centaines de milliers de connexions par secondes MAIS: Rien pour la latence Le réseau peut être un goulot d’étranglement (cf. 9/11) Solutions: Avoir le même contenu sur plusieurs serveurs Diriger un client vers un serveur « proche » Approcher physiquement le contenu du client Problèmes: Diriger le client Assurer la synchronisations des miroirs

18 Routage de contenu Donner au client le contenu disponible à l’endroit le plus approprié Plusieurs métriques Proximité au sens réseau Proximité géographique Temps de réponse Type d’utilisateur (payant…) Routage global par redirection DNS Sous un même nom sont regroupés plusieurs serveurs Le serveur DNS retourne au client la « bonne » IP Mais Risque de latence élevée pour le lookup La requête DNS ne contient pas d’information sur le contenu demandé Routage par port TCP La requête est redirigée par un serveur vers d’autres serveurs suivant le numéro de port Routage de niveau 7 Analyse du contenu de la requête Une requête peut générer plusieurs sous requêtes transparentes Web Cache Communication Protocol Un routeur intercepte les demandes des clients et les envoient à des caches Les caches indiquent aux routeurs (avec WCPP) quels protocoles ils servent

19 Conclusion Les systèmes distribués viennent dans toutes les tailles
Caractéristiques: Multiples espaces d’adressage Parallélisme, concurrence et absence d’horloge globale. Latences et pannes

20 2- Matériel pour les systèmes distribués

21 Introduction En pratique tous les systèmes distribués sont composés de plusieurs processeurs Mais l’organisation varie Mémoire Interconnexion Homogénéité/Hétérogénéité Influence La façon de programmer La façon de les utiliser Les performances

22 Organisation Mémoire privée (multicalculateurs)
Chaque processeur à sa propre mémoire Mémoire partagée (multiprocesseurs) L’ensemble des processeurs partagent la mémoire Interconnexion à bus Tous les processeurs utilisent un seul médium pour communiquer Interconnexion par commutation Les processeurs communiquent par un ensemble de câbles Les messages se déplacent sur ces câbles et des décisions de routage sont prises à chaque nœud d’interconnexion Homogénéité La même technologie est utilisée partout Hétérogénéité Des ordinateurs différents sont connectés par des réseaux différents Ex: Internet (ATM, IP, Fibre, Ethernet…)

23 Multiprocesseurs à bus
Tous les processeurs ont accès à la même mémoire à travers un bus Exemples: Bi-Processeurs Processeurs multi-cores Cohérence Si le CPU A écrit un mot en mémoire et que le CPU b y accède ensuite, il aura la bonne valeur Implémentation naïve peu performante 4 ou 5 CPUs saturent le bus Solution: ajouter du cache au niveau de chaque processeur Tous les accès mémoire passent pas le cache Si hit rate élevé, moins de messages sur le bus Mais problème de la cohérence des caches UC Cache Mémoire

24 Multiprocesseurs à commutation
Les systèmes à bus ne passent pas à l’échelle Pour des systèmes de plus de 256 processeurs, on utilise d’autres techniques Réseau d’interconnexion La mémoire est divisée en modules Les processeurs y sont reliés par une matrice de commutation (crossbar switch) A chaque intersection, le nœud de commutation (crosspoint switch) peut-être ouvert ou fermé L’accès à un module mémoire est synchronisé Les demandes sont mises dans une file d’attente Inconvénient Nécessite beaucoup de nœuds d’interconnexion (n*m) C M Mémoires UC

25 Multiprocesseurs à commutation
Alternatives à la matrice Réseau oméga NUMA Des commutateurs à 2 entrées et 2 sorties Nécessite de passer par plusieurs pour atteindre la mémoire A besoin d’être extrêmement rapide, donc coûteux NonUniform Memory Access Accès hiérarchique à la mémoire Les processeurs ont une mémoire locale accessibles rapidement L’accès à la mémoire d’un autre processeur est plus lent En général plus rapide que l’oméga Mais plus difficile à programmer Bien placer les données est non trivial C M

26 Multicalculateurs Beaucoup plus facile à construire qu’un système multiprocesseurs Mémoire privée donc communications CPU à CPU (volume plus faible que CPU vers mémoire) Multicalculateurs homogènes à bus Les nœuds sont dans des racks Et reliés par un réseau rapide (Fast Ethernet) Passage à l’échelle problématique (100 nœuds max)

27 Multicalculateurs Multicalculateurs homogènes commutés
Les messages sont routés à travers un réseau d’interconnexion Plusieurs topologies possibles Grille à 2 dimensions Câblage simple Le chemin le plus long est en

28 Multicalculateurs Tore Extension de la grille
Les processeurs frontières sont reliés à leurs homologues Nécessite un câblage plus long

29 Multicalculateurs Hypercube Cube à n dimensions
4 dimensions: 2 cubes à 3 dimensions reliés par les sommets homologues Complexité du câblage en log(n) Chemin le plus long en log(n)

30 IBM BlueGene/L 1er au classement mondial
processeurs et Go de mémoire Interconnexion par tore 3D (chaque processeur a 6 voisins)

31 Cray XT3 2000 à 30 000 processeurs Opterons Reliés par un tore 3D
Actuellement 6eme au classement mondial avec processeurs

32 Multicalculateurs Les multicalculateurs commutés sont très variés
Modèles à plusieurs milliers de CPUs coûtant plusieurs millions d’euros Clusters: PCs reliés par du matériel « grand public » Ce qui les différencie souvent est le matériel pour l’interconnexion Faible latence et haut débit sont coûteux

33 Grid’5000 32x2 PowerPC 216x2 Opterons 64x2 Xeons 64x2 Opterons
103x2 Itaniums 56x2 Opterons 32x2 Xeons 32x2 Opterons 105x2 Opterons

34 3- Logiciels pour les systèmes distribués

35 Systèmes d’exploitations
Le matériel est important, mais c’est le logiciel qui détermine le système distribué Ressemblent beaucoup à des systèmes d’exploitation classiques Gèrent l’accès au matériel Permet le partage de ressources (mémoire, CPU…) Masquent l’hétérogénéité Système fortement couplé L’OS fournit une unique vue des ressources Souvent appelé Distributed Operation System Systèmes multiprocesseurs Systèmes multicalculateurs Système faiblement couplé Chaque ordinateur a son propre OS Appelé Network Operating System

36 Systèmes multiprocesseurs
Dans le cas de plusieurs processeurs accédant à la même mémoire, les accès doivent être protégés Très similaire à un OS monoprocesseur Difficile de porter un OS mono en multi Nécessite souvent des changements profonds Les OS modernes sont pensés multiprocesseurs dés le début Rend le nombre de processeurs transparents pour l’application Protection de la mémoire grâce à des primitives de synchronisation Sémaphores et moniteurs

37 Systèmes multicalculateurs
Très différent d’un OS monoprocesseur Les données nécessaires au fonctionnement global du système ne sont plus dans une zone de mémoire partagée Chaque nœud a son propre noyau (kernel) responsable de la gestion des ressources locales (mémoire, CPU, disque…) Un module pour gérer les communications inter processeurs Une couche commune au dessus des noyaux implémente un OS supportant l’exécution parallèle et concurrente de taches Services parfois fournis: Mémoire partagée! Affectation des taches à certains processeurs Gestion des pannes Applications distribuées Services distribués noyau

38 Communications par messages
Si pas de mémoire partagée, communication par messages Différences Buffers ou non Blocage ou non Bufferisation possible à 2 endroits Du côté de l’appelant Du côté de l’appelé Bloquage Dépend de la bufferisation

39 Communications par messages
Appelant Receveur S1 S2 S3 S4 Blocage de l’appelant S1 : mise en buffer, seulement si plein S2 : envoie du message S3 : réception du message S4 : transmission du message a l’appelé Si blocage en S2 , S3 ou S4 alors buffer appelant inutile Blocage de l’appelé Possible seulement en S3 : buffer vide ou pas de buffer L’appelé peut décider de vérifier périodiquement si des messages sont disponibles (polling) mais Fréquence trop rapide signifie gâchis de CPU Fréquence trop lente, risque de pertes de messages (buffer plein)

40 Fiabilité des communications
L’émetteur a-t-il une garantie que son message a bien été reçu ? Si fiabilité les messages sont garantis d’arriver en S3 Si blocage en S1 ou S2 fiabilité non obligatoire Si blocage en S3 ou S4, fiabilité obligatoire!

41 Systèmes distribués à mémoire partagée
Les multiprocesseurs sont plus simples à programmer que les multicalculateurs Accéder à des variables partagées est plus simple que communiquer par messages Il est possible d’émuler une mémoire partagée sur les multicalculateurs Page-Based Distributed Shared Memory Unique espace d’adressage virtuel Les pages physiques sont reparties sur les différentes machines Quand un processeur demande une page non locale, le système d’exploitation la copie localement

42 Systèmes distribués à mémoire partagée
Pour améliorer les performances, on peut répliquer les pages en lecture seule Permet à plusieurs processeurs d’avoir localement la même page Limite les chargements Réplication de toutes les pages Possibles lorsqu’elles ne sont que lues Si modifications, alors il faut prendre des mesures (avant ou après ?) Inconsistance Il est possible d’abandonner la stricte consistence Mais rend la programmation beaucoup plus compliqué Taille des pages Quelle est la bonne taille? D’où vient le coût d’un transfert?

43 Network Operating Systems
Ne suppose pas que le système est homogène et qu’une vue globale doit être fournie Les machines et leurs OS peuvent être différents, mais elles sont toutes reliées par un réseau Un NOS fournit des mécanismes pour utiliser les services disponibles sur certaines machines Exemples: rlogin, ssh… Applications distribuées Services réseau Services réseau Services réseau noyau noyau noyau

44 Applications distribuées
Middleware Un DOS ne gère pas des machines indépendantes Un NOS ne donne pas une vue cohérente de machines Comment avoir le meilleur des 2 ? On ajoute une couche au dessus d’un NOS pour masquer l’hétérogénéité, le middleware Applications distribuées Middleware Services réseau Services réseau Services réseau noyau noyau noyau

45 4- Outils pour la programmation

46 Outil de base: Sockets Introduit dans Berkeley Unix 4.2 (BSD) en 1981
Représentation point à point d’un flux de données Un programme peut Écrire des données Lire des données B A Application Socket write read Lorsque l’on veut passer de la programmation classique (le programme tourne dans une seule machine virtuelle et ne communique pas avec d’autres machines virtuelles) à la programmation distribuée, l’outil de base à notre disposition est les sockets. Cependant; l’utilisation des sockets nécessitede définir à la fois un format d’échange de données et un protocole de communication puis de les implémenter en termes identiques à chaque extrémité de la connexion. Qui plus est, utiliser des sockets oblige à raisonner en termes de flux d’octets (streams) et non plus en termes d’objets, ce qui éloigne la programmation distribuée de la programmation classique et oblige le programmeur à faire sans cesse l’aller-retour entre les deux modes de pensée. L’avantage des sockets est que tous les systèmes d’exploitation les supportent de manière standardisée, ce qui permet à des applications Java de parler à des applications autres. HTTP : la popularité du Web a amené de plus en plus d’applications à utiliser le protocole HTTP pour communiquer. L’avantage étant que l’infrastructure est déjà en partie disponible (serveurs Webs pouvant accueillir des scripts CGI, ASP ou JSP) et que Java permet de programmer facilement en termes de requêtes GET, POST, PUT, etc... Les inconvénients sont à peu près les mêmes que pour les sockets, même si cette solution se situe une couche réseau au dessus des sockets.

47 Primitives Les sockets fournissent un ensemble d’opérations de base (les primitives) Socket: création d’une socket Bind: Attachement de la socket à une adresse locale Listen: Annonce l’acceptation des connexions Accept: Bloque jusqu’à l’arrivée d’une demande de connexion Connect: Demande de connexion Send: Envoie de données Receive: Lecture de données Close: Fermeture Lorsque l’on veut passer de la programmation classique (le programme tourne dans une seule machine virtuelle et ne communique pas avec d’autres machines virtuelles) à la programmation distribuée, l’outil de base à notre disposition est les sockets. Cependant; l’utilisation des sockets nécessitede définir à la fois un format d’échange de données et un protocole de communication puis de les implémenter en termes identiques à chaque extrémité de la connexion. Qui plus est, utiliser des sockets oblige à raisonner en termes de flux d’octets (streams) et non plus en termes d’objets, ce qui éloigne la programmation distribuée de la programmation classique et oblige le programmeur à faire sans cesse l’aller-retour entre les deux modes de pensée. L’avantage des sockets est que tous les systèmes d’exploitation les supportent de manière standardisée, ce qui permet à des applications Java de parler à des applications autres. HTTP : la popularité du Web a amené de plus en plus d’applications à utiliser le protocole HTTP pour communiquer. L’avantage étant que l’infrastructure est déjà en partie disponible (serveurs Webs pouvant accueillir des scripts CGI, ASP ou JSP) et que Java permet de programmer facilement en termes de requêtes GET, POST, PUT, etc... Les inconvénients sont à peu près les mêmes que pour les sockets, même si cette solution se situe une couche réseau au dessus des sockets.

48 Sockets en Java Jusqu’à JDK 1.4 : I/Os bloquantes
Deux classes : java.net.Socket et java.net.ServerSocket Beaucoup de classes pour la gestion des streams Toutes les opérations (lecture ou écriture) sont bloquantes 1 ou 2 threads nécessaires pour chaque socket Surcoût mémoire et changement de contexte available() permet de savoir si des données sont disponibles mais utilisation du CPU

49 Nouvelle API pour les Sockest
Nouveauté dans JDK 1.4: I/Os non bloquantes 2 nouvelles abstractions de haut niveau Buffers: conteneur à données linéaire Channels: Tube de communication bidirectionnel supportant des opérations bloquantes et non bloquantes Une classe Selector pour multiplexer les événements : base du passage à l’échelle ServerSocketChannel et SocketChannel Support d’opérations bas-niveau de gather/scatter Fichier mappés en mémoire, gestion des buffers… Package java.nio.*

50 Limitations des sockets
Description des données (ce qui sera lu et écrit) Chaque application doit le définir L’implémentation doit être identique sur chaque nœud Problèmes: ordre des bits, symboles spéciaux… Protocole de communication (comment lire et écrire) L’implémentation doit être consistante sur tous les noeuds Problèmes: taille de buffer, synchronisation, timeouts, ... Conséquences Beaucoup de temps est passé à récrire le même code Des erreurs sont faciles à faire, mais difficiles à trouver

51 Sockets vs. Procédures Probleme: 2 abstractions différentes dans la même application Local: structures de données et procédures Distant: Flux de données et lecture/écriture dans des sockest Idée: Pourquoi ne pas tout programmer sous forme de procédures? Le programmeur n’a plus à se soucier de détails bas-niveau, il peut se concentrer sur son application. Première implémentation avec RPC (Remote Procedure Calls) Fonctionnement : Un outil génère du code Code pour convertir des appels de procédure en données écrite ou lues sur des sockets Code pour convertir les structures de données en données compatibles avec les sockets (marshalling / unmarshalling ou Serialization/Deserialization)

52 Remote Procedure Calls (RPC)
Permet de donner l’impression d’un appel local pour un appel distant Code généré Du côté appelant: stubs Du côté appelé: skeletons Passage de paramètre par valeur RPC est fait pour le langage C Toujours utilisé aujourd’hui, par exemple pour NFS B A Stub Skeleton Application RPC

53 Remote Procedure Calls
Le rôle du Stub est de: Transformer les structures de données passées en paramètres de la procédure en flux d’octets (marshalling) Écrire ces données dans la socket Attendre jusqu’à ce que des données soient disponibles en lecture Lis les données et les converties en structure (unmarshalling) Retourne le résultat à l’appelant comme résultat de son appel de méthode A Stub

54 Remote Procedure Calls
Le Skeleton doit Attendre que des données soient disponibles en lecture Lire un flux d’octets et construire la structure correspondante Appeler la méthode correspondante sur B avec les paramètres Transformer le résultat en flux d’octets Envoyer ce résultat à l’appelant B Skeleton

55 Remote Procedure Calls
Limitations de RPC Peu de transparence Les machines distantes sont trouvées avec leur adresse IP et le numéro de port Pas de nommage symbolique Impossible de trouver un service suivant son nom ou son type Pas de chargement de code dynamique Le stub doit être pré installé chez l’appelant, le skeleton chez l’appelé Le code pour le marshalling/unmarshalling est spécifique et doit être présent des 2 côtés Aucun mécanisme de tolérance aux pannes ou de gestion des erreurs

56 Java-RMI RMI signifie Remote Method Invocation Introduit dés JDK 1.1
Partie intégrante du cœur de Java RMI = RPC en Java + chargement dynamique de code Même notions de stubs et skeletons Fonctionne avec l’API de sérialization (utilisée également pour la persistance) Possibilité de faire interagir RMI avec CORBA et DCOM

57 RMI: Fonctionnalités Masque pratiquement tout le réseau à l’application Très similaire à RPC Utilisation de l’interface Remote Java Appels distants bloquants L’appelant est bloqué jusqu’à ce que le résultat soit disponible Les références vers des objets « normaux »sont passées par copie profonde (deep copy) grâce à la sérialisation Les références vers des objets distants sont passées par référence

58 Implémenter un objet distant
Un objet qui à des méthodes appelables à distance est appelé objet distant Les seules méthodes accessibles à distance seront celles spécifiées dans l’interface Remote Écriture d’un interface spécifique à l’objet, étendant l’interface java.rmi.Remote Chaque méthode distante doit annoncer lever l’exception java.rmi.RemoteException Sert à indiquer les problèmes liés à la distribution L’objet devra fournir une implémentation de ces méthodes

59 Implémenter un objet distant
import java.rmi.Remote; import java.rmi.RemoteException; public interface MonInterfaceDistante extends Remote { public void echo() throws RemoteException; } Cette interface indique que l’objet qui l’implémentera aura la méthode echo() appelable à distance

60 Implémenter un objet distant
import java.rmi.Remote; import java.rmi.RemoteException; import java.rmi.server.UnicastRemoteObject; public class MonObjetDistant extends UnicastRemoteObject { implements MonInterfaceDistante public MonObjetDistant() throws RemoteException {} public void echo() throws RemoteException{ System.out.println(« Echo »); } L’objet distant doit finalement implémenter les méthodes de l’interface Hériter de java.rmi.server.UnicastRemoteObject Et avoir un constructeur sans paramètre levant aussi l’exception

61 Utiliser un objet distant
Pour utiliser un objet distant il faut Connaître sont interface Le trouver! L’utiliser RMI fournit un service de nommage permettant de localiser un objet par son nom : le registry L’objet s’enregistre sous un nom « bien connu » Les clients demandent une référence vers cet objet

62 Utiliser un objet distant
import java.rmi.RemoteException; public class Client { public static void main(String args) { MonInterfaceDistante mod = ….. // du code pour trouver l’objet try { mod.echo(); } catch (RemoteException e) { e.printStackTrace(); } Une fois la référence obtenue, il suffit d’appeler la méthode dessus, en prenant garde aux éventuelles exceptions

63 Trouver un objet distant
L’objet doit s’enregistrer dans le registry Programme lancé auparavant sur la même machine que l’objet distant : rmiregistry Utilise le port 1090 par defaut Possibilité de le démarrer depuis l’application (LocateRegistry) Il agit comme un service d’annuaire Les noms ressemblent à des URLs protocole://machine:port/nom Protocole, machine et port sont optionnels Objet toto sur la machine locale: ///toto Les méthodes de gestion sont regroupées dans la classe Naming L’objet distant appel Naming.bind Le client appel Naming.lookup

64 Générer les stubs et skeletons
Une fois l’objet distant écrit, il est possible de générer les stubs et les skeletons Outils fournit dans Java: rmic Prends le nom complet de la classe distante (package+nom) Génère 2 fichiers ( _Stub et _Skel) Ne met dans le stub que les méthodes spécifiées dans l’interface distante Possibilité de voir le code source avec l’option –keep

65 RMI: en résumé Écrire l’interface distante
Écrire le code de l’objet distant Implémenter l’interface Ajouter le code pour le registry (en général dans le main ou le constructeur) Compiler Générer les stub et skeleton Écrire le client Obtenir une référence vers l’objet distant Appeler les méthodes Exécuter Démarrer le serveur Démarrer le client Debugger 