Systèmes d Exploitation

Transcription

1 Systèmes d Exploitation chapitre 12 Introduction aux systèmes répartis Plan Introduction Modélisation F. Moal 2012/2013 Source : cours E-mi@ge, G.M. Cochard 2 1

2 Introduction Un système informatique = ensemble de composants matériels et logiciels communicants Réalisation suivant deux techniques : Introduction un système réparti = un ensemble d ordinateurs ( de toutes tailles, marques,...) répartis géographiquement dans des lieux différents et reliés entre eux par un réseau de communication les systèmes à parallélisme fortement couplé Une tâche est décomposée en sous-tâches élémentaires synchronisées au sein d une même machine : pipe line, SIMD, MIMD les systèmes à parallélisme faiblement couplé Les tâches sont distribuées à des unités spécialisées avec une coordination assurée à un niveau supérieur : systèmes répartis ou distribués, réseaux de machines 3 Les systèmes distribués d actualité : demande de systèmes OUVERTS, INTERCONNECTABLES, DISTRIBUES La création de l OSF (Open Software Foundation), en 1988 (Bull, DEC, Hitachi, HP, IBM, Philips, Siemens,...) 4 2

3 Introduction Introduction les systèmes répartis posent un nombre non négligeable de problèmes : synchronisation des processus incertitudes spatiales et temporelles accès cohérents aux ressources ordonnancement d évènements terminaison d un travail fiabilité gestion des processus fichiers, bases de données, transactions objets raisonnement et intelligence artificielle protocoles et appels de procédures... 5 Synchronisation de processus Exemple d un parking de N places (ressources) destinées à accueillir des automobiles (processus) en compétition pour se garer. synchronisation nécessaire : une voiture ne peut se garer que si il existe une place. Simple si centralisé : sémaphore / un compteur dans un moniteur Si réparti (plusieurs entrées et sorties dans le parking)?? 6 3

4 Introduction Incertitudes spatiales et temporelles Les délais de transmission d un message entre deux ordinateurs d un réseau sont non négligeables. Les conséquences immédiates sont : Introduction l événement e1 intervient de manière absolue avant e2. ces événements sont perçus différemment par les sites : le site 1 voit e2 se produire avant e1 tandis que le site 4 voit e1 se produire avant e2 à un instant donné, sur un site donné, on ne connaît que de façon approchée l état d un système 2 événements du système réparti peuvent être perçus dans un ordre différent par deux sites distincts 7 8 4

5 Introduction Accès cohérent à une ressource Introduction Ordonnancement d événements exemple du parking à N places comportant plusieurs accès 1, 2,..., n La solution précédente engendre des problèmes nouveaux : l ordre d arrivée des automobiles aux accès ne correspond pas à l ordre d entrée dans le parking ( le premier arrivé n est pas nécessairement le premier à entrer à cause de l attente du message) il se peut que le compteur = 0 chaque fois que le message passe à l accès n i ; il s ensuit donc une attente indéfinie pour les automobiles qui veulent entrer

6 Introduction Introduction Pour un système centralisé, la solution au premier problème est la file d attente unique et u ordre défini sur la base d une horloge unique locale Pour un système réparti, il existe des files d attente multiples en général ; il n y a pas d horloge unique, mais au contraire plusieurs horloges non synchrones. On est donc confronté au problème de la construction d un ordre global strict Terminaison Comment peut-on être sûr qu un système réparti a terminé son travail? Il ne suffit pas de constater que les processus sont inactifs car des messages en transit peuvent les réactiver à tout moment!

7 Introduction Introduction Exemple : Algorithme de la casquette (Dijkstra 1983) : Des employés de bureau travaillent dans les bureaux dans un immeuble qu un gardien est chargé de fermer après le travail. Les règles sont les suivantes : il n y a qu un employé par bureau quand un employé entre dans un bureau il allume la lumière un employé quitte un bureau soit pour rentrer chez lui, soit pour aller dans un autre bureau. un employé qui quitte un bureau pour aller dans un autre bureau laisse le premier bureau allumé et allume la lumière dans le second (si ce n est déjà fait) un employé qui quitte un bureau pour rentrer chez lui éteint la lumière le travail est terminé quand tous les employés sont rentrés chez eux 13 L algorithme fonctionne comme suit : 1) Chaque bureau est numéroté de 1 à n et le gardien visite les bureaux toujours dans l ordre 1,...n. Le gardien est muni d une casquette et il commence toujours sa ronde avec la casquette sur la tête. 2) Si le gardien visite un bureau occupé, il reste dans ce bureau jusqu à ce que l agent sorte. 3) Chaque fois que le gardien quitte un bureau allumé, il l éteint et met sa casquette sous son bras. 4) Si le contrôleur revient à son point de départ avec sa casquette sur la tête, il peut fermer l immeuble : le travail est terminé. 14 7

8 Les motivations qui ont conduit au développement des systèmes répartis sont : assurer la communication entre applications existantes adapter la structure des systèmes à celle des applications fournir des services interactifs à coût raisonnable augmenter la disponibilité des systèmes réduire les temps de traitement partager des ressources entre plusieurs utilisateurs Un système réparti possède de manière générale les caractéristiques suivantes : ensemble d éléments de traitement (UC) reliés par un réseau de communication permettant l échange d information un élément en panne ne met pas en panne les autres éléments plusieurs éléments ont une connaissance commune et partielle de l état du système faciliter l évolutivité

9 une situation " simple " : l accès à un fichier distant Solution 1 : transfert par FTP principe : construction sur la machine A d une copie locale du fichier. Nécessité de connaître le nom du fichier distant et l identité de la machine B critique : création de deux versions du fichier ; après manipulation, on aura deux versions incohérentes. Pour prendre en compte les modifications apportées par A, il faut recopier le fichier sur B. procédé très lourd si on veut modifier seulement un octet difficulté de maintien de la cohérence en cas d utilisation simultanée par plusieurs usagers formule intéressante pour la distribution de logiciels

10 Solution 2 : Accès à distance, désignation explicite : UU principe : Unix United permet l accès à des fichiers distants sur des systèmes sous Unix en réseau local. Adjonction d une super racine /../ exemple :copie de prog dans gedeon de machin : cp prog /../machine2/gedeon réalisation : Ajout d une couche de connexion entre le noyau Unix résident et le " reste " (programmes utilisateurs + système non résident) : Newcastle Connexion

11 critique : accès direct au fichier l utilisateur doit connaître explicitement la localisation du fichier gestion complexe des droits d accès (sur chaque machine) Solution 3 : Accès à distance, désignation transparente principe : Emploi de NFS (Network File System) : création de lien entre un " point de montage " sur une machine i et un catalogue situé sur une machine j :

12 réalisation : emploi de v-nodes pour désigner les fichiers : critique : client en panne : pas grave ; serveur en panne : grave emploi de caches client et serveur pour réduire les temps d accès. Plusieurs clients entraînent des risques d incohérence (mais solutions par divers algorithmes). important : le serveur ne garde aucune indication sur les accès aux fichiers (c est à la charge du client)

13 Ces trois solutions permettent de mettre en évidence les problèmes suivants : désignation des entités, transparence pour l utilisateur synchronisation des activités, ordre des événements gestion de l information répartie, cohérence tolérance aux pannes Synchronisation Le problème de base est l ordonnancement des événements : quand peut -on dire qu un événement s est produit avant un autre? Précédence causale Les conditions de précédence causale évoquées précédemment peuvent se reformuler de la manière suivante : Un événement a précède directement un événement b si et seulement si C1) a et b ont lieu sur le même site et a est antérieur à b C2) a est l émission d un message et b est la réception de ce message

14 Avec la fermeture transitive, on obtient la relation " précède ", notée ci-dessous " ". Si a précède b et si b précède c alors a précède c. Deux événements a et b sont dits concurrents si on n a ni a b, ni b a. On notera donc que la relation " précède " est un ordre partiel puisqu elle ne permet pas de classer deux événements quelconques. Ordonnancement par estampillage Cet ordonnancement utilise des horloges logiques. Chaque site Si est muni d un compteur Hi à valeurs entières initialisé à 0. Ce compteur est une horloge logique. Lorsqu un événement a se produit sur le site Si, on incrémente Hi et la date de a est la valeur du compteur Hi(a) Tout message m émis par le site Si porte une estampille E(m) qui est la date d émission au sens précédent. Tout message m reçu par le site Sj correspond à un événement qui modifie l horloge logique Hj de la manière suivante : Hj=Max(Hj, E(m))

15 Cette méthode permet de dater les événements mais ne procure pas un ordre strict car des événements se produisant sur des sites distincts peuvent avoir la même date. On peut cependant, d une manière artificielle, définir un ordre strict en numérotant de manière unique les sites. La date d un événement sera alors le couple (numéro de site, date Hi). On notera cette relation d ordre par " Þ " : a Þ b ssi [Hi(a)<Hj(b) ou (Hi(a)=Hj(b) et i<j)]

16 Horloges vectorielles Avec la méthode précédente, a Þ b implique en fait que soit a b (précédence causale), soit a et b sont concurrents. L inconvénient est que l ordre Þ masque la précédence causale. Une solution à ce problème a été donnée en 1988 : les horloges vectorielles Une horloge vectorielle Vi[1...n] est un vecteur défini pour chaque site Si. Ce vecteur est initialisé à 0. Quand un événement se produit sur le site Si, alors Vi[i] = Vi[i] + 1. A l émission d un message sur le site Si, celui-ci est estampillé par l horloge vectorielle Vi, date de l émission du message sur le site de départ (horloge vectorielle). La réception du message m par un site Sj est un événement qui est daté par : Vj[k] = Max(Vj[k],Vi[k]) k=1,...,n où Vi est l estampille du message

17 Le passé d un événement a est l ensemble des événements qui précèdent causalement a et a lui-même a étant daté par l horloge vectorielle Va, Va[j] est le nombre d événements du passé de a sur le site Sj. Σj Va[j] est le nombre total d événements du passé de a Entre les dates définies par les horloges vectorielles, on peut définir un ordre partiel : (,, ) V W ssi pour tout j V[j] W[j] V W ssi pour tout j V[j] W[j] V W ssi (V W) et (V W) dont on déduit la propriété fondamentale : a b Û Va < Vb a,b concurrents Û Va ê ê Vb

18 Aperçus sur les algorithmes distribués de base. Aperçus sur les algorithmes distribués de base. Les algorithmes distribués oscillent entre deux catégories très distinctes : la centralisation totale Un noeud C du réseau est désigné comme noeud de contrôle unique. Si un noeud quelconque X veut accéder à un objet partagé, X envoie un message REQUEST à C. Quand l objet est disponible, le noeud C envoie un message REPLY au noeud X. Seul, le noeud C prend les décisions et toute l information disponible est concentrée en C la décentralisation totale Tous les noeuds du réseau ont le même " volume " d information ; tous les noeuds prennent des décisions basées sur l information connue localement ; tous les noeuds portent une responsabilité égale ; tous les noeuds dépensent la même " quantité " d efforts pour aboutir à une décision intéressant la communauté des noeuds ; la défaillance d un noeud n implique pas la paralysie totale du système

19 Bien entendu, ces deux catégories sont extrêmes et les algorithmes distribués se placent dans des catégories intermédiaires. A partir de 1978, de nombreuses propositions d algorithmes ont été publiées (Lamport 1978, Thomas 1979, Gifford 1979, Ricart et Agrawala 1981, Maekawa 1985,...) Les points communs (hypothèses)à tous ces algorithmes sont principalement les suivants : un système distribué est considéré comme un ensemble de N noeuds numérotés de 1 à N. Chaque noeud héberge un processus qui demande l accès exclusif à une ressource du réseau. Cette requête est communiquée à d autres processus. les messages envoyés par un processus à un autre arrivent dans l ordre de leur envoi (propriété pipeline) chaque message arrive à destination après un intervalle de temps fini ; le réseau est supposé maillé complètement (logiquement) : chaque processus peut envoyer directement un message à n importe lequel des processus

20 Autres algorithmes distribués élection Dans certains systèmes, un processus est " élu " pour effectuer certaines tâches, par exemple régénérer un jeton dans un anneau à jeton. cet exemple peut être généralisé l anneau physique devient alors un anneau logique : les différents noeuds numérotés de 1 à N => anneau Exemple : un algorithme d élection dû à Chang (1979) qui est basé sur une technique de filtrage sur un anneau ( on laisse passer ou on ne laisse pas passer) En cas d élection chaque processus transmet sur l anneau un message de candidature portant son numéro. A la réception du message k par le processus Pi, si k<i, le message est stoppé, si k>i, le message est retransmis au noeud suivant

21 procédures du site i : terminaison détection de la perte du jeton : candidat := true; envoyer_suivant(élection,i); réception du message (élection,k) select k > i : envoyer_suivant(élection,k); k < i : if candidat:=false then candidat :=true; envoyer_suivant(élection,i); end; k = i : régénérer_jeton /* le site i a été élu */ end; Un algorithme de terminaison permet de détecter la fin d un travail réparti, c est à dire quand tous les processus sont terminés aucun message n est en transit

22 Tjrs en anneau virtuel. Sur cet anneau les messages ne peuvent se doubler et un message peut successivement visiter tous les sites. Un message spécial appelé jeton circulant sur cet anneau et passant deux fois au même site est considéré comme ayant fait le tour de tous les sites. Si chaque site a été visité deux fois par le jeton et qu il est resté passif entre deux passages, la terminaison est alors détectée. L algorithme de Misra (1983) : un jeton est utilisé qui n est autre qu un compteur augmentant de 1 à chaque passage de noeud

23 Modélisation des systèmes répartis procédures d un site : début d un traitement (réception de message) état := actif; couleur := noir; /* couleur de l activité d un site */ fin d un traitement état:= passif; if jeton_present then couleur := blanc /* couleur de l inactivité d un site */ envoyer_jeton(1); jeton_present:=false; end; réception du jeton(j) if état :=actif then /* site actif */ jeton_present :=true; else if j=n and couleur=blanc then /* site non actif */ terminaison_détectée; else if couleur=blanc then envoyer_jeton(j+1); else couleur:=blanc; envoyer_jeton(1); end; end; end; 45 Modèle client serveur Le client est le noeud A qui demande un service, le serveur est le noeud B qui réalise le service. Généralement A et B sont des noeuds (machines) différentes mais évidemment reliés par un réseau de communication En général, les serveurs sont dédiés à un groupe de tâches à fonctionnalités voisines: serveur de noms, serveur de fichiers, serveur d impression,

24 Modélisation des systèmes répartis Du côté serveur, le message de requête de procédure peut être accueilli par un processus serveur cyclique : processus serveur : répéter indéfiniment recevoir(client, message); extraire(message, service_id, paramètres); selon service_id... id : début effectuer_service[id](parametres,resultats); envoyer(client, resultats); fin;... fin; fin; 47 Modélisation des systèmes répartis La solution précédente ne permet de servir qu un client à la fois. Pour servir simultanément plusieurs clients, il faut une famille de processus serveurs fonctionnant suivant le schéma suivant : un processus veilleur reçoit une demande et active un processus exécutant. Ce dernier peut être choisi dans un pool fixe ou créé dynamiquement

25 Modélisation des systèmes répartis Implémentations La solution précédente ne permet de servir qu un client à la fois. Pour servir simultanément plusieurs clients, il faut une famille de processus serveurs fonctionnant suivant le schéma suivant : un processus veilleur reçoit une demande et active un processus exécutant. Ce dernier peut être choisi dans un pool fixe ou créé dynamiquement. Plusieurs niveaux : - Sockets - RPC - RMI - Architecture implicitement réparties (JEE)

26 Implémentations: sockets Implémentations: sockets Socket en Java, rappels! public class Serveur { public static final int PORT = 4567; - Un serveur qui écoute et lance des threads - Un Service par client connecté (thread) - Plusieurs clients public static void main(string[] args) throws IOException{ ServerSocket socketserveur = new ServerSocket(PORT); // boucle infinie d'attente de connection while (true) { // accepte une connection d'un client et retourne un socket sur ce client. Socket traitesocket = socketserveur.accept(); System.out.println("Connection au serveur depuis : " + traitesocket.getinetaddress().gethostaddress()); // démarre un nouveau thread pour s'occuper du client Service traitement = new Service(traiteSocket); new Thread(traitement).start(); // fermeture du socket socketserveur.close();

27 Implémentations: sockets Implémentations: sockets public class Service implements java.lang.runnable { // le socket connecté au client private Socket traitesocket; // le constructeur qui reçoit comme argument un socket connecté au client. public Service( Socket clisock ) { traitesocket = clisock; public void run() { try { // les flux d'entrée-sortie sur le socket BufferedReader entreedepuisclient = new BufferedReader(new InputStreamReader(traiteSocket.getInputStream())); PrintWriter sortieversclient = new PrintWriter(traiteSocket.getOutputStream(),true); // tant qu'il y à qqch à lire du socket connecté au client, traiter String demande, reponse; do { demande = entreedepuisclient.readline(); reponse = traiter(demande); sortieversclient.println(reponse); while (!demande.equals("quit")); // fermer les flux et le socket sortieversclient.close(); entreedepuisclient.close(); traitesocket.close(); catch (IOException e) { 53 public class Client { public static void main(string[] args) throws IOException { // création du socket sur le port 4567 de localhost Socket socket = new Socket(« ", 4567); PrintWriter sortieversserveur = new PrintWriter(socket.getOutputStream(),true); BufferedReader entreedepuisserveur = new BufferedReader(new InputStreamReader(socket.getInputStream())); //tant que data les écrire vers le serveur String message,reponse; do { message = ; // envoi du message au serveur sortieversserveur.println(message); reponse = entreedepuisserveur.readline(); while (!message.equals("quit")); // Fermeture des ressources sortieversserveur.close(); entreedepuisserveur.close(); socket.close(); 54 27

28 Modélisation des systèmes répartis Modélisation des systèmes répartis Appel de procédure à distance - RPC Le client envoie sa requête et reste bloqué ; la requête active le serveur qui exécute la procédure et renvoie les résultats. L arrivée de ceux-ci réactivent le client. Les problèmes généraux posés par le RPC (Remote Procedure Call) sont : la gestion de la création et de l exécution du processus serveur ( modèle client serveur) la transmission des paramètres et des résultats : communication par message mécanismes de conversion : les codes client et serveurs peuvent être de natures différentes (machines différentes) attitude à adopter en cas de défaillance du client, du serveur, du système de communication

29 Modélisation des systèmes répartis Modélisation des systèmes répartis organisation du client et du serveur pour une RPC : On constate que deux procédures locales sont utilisées : les talons (stubs). Le talon client effectue les tâches suivantes : mise en forme, pour le transport, des paramètres d appel (emballage ou marshalling) envoi d un message (identité de la procédure appelée + paramètres) blocage du processus client déblocage à l arrivée des résultats extraction des résultats et transposition ( déballage ou unmarshalling) exécution du retour de procédure

30 Modélisation des systèmes répartis Modélisation des systèmes répartis Le talon serveur effectue les tâches suivantes : Stub + skeletton : réception du message client, détermination de la procédure appelée, déballage des paramètres exécution de la procédure appelée préparation du message de retour (emballage) envoi du message de retour fin d exécution (mort du processus ou blocage d attente) 59 Méthode utilisée par RMI Ressources : Cours AAR Matthieu Exbrayat

31 RMI Petit détour historique... Pour être précis, parler de «Java RMI» Invocation distante Deux objets dialoguent naturellement, par invocation de méthode Un peu de code et des composants externes pour masquer la distance Approche proposée Des exemples de complexité croissante RMI découle de l'approche RPC RPC = Remote procedure call Accès aux services distants par un mécanismes de fonctions Interfaces développées grâce à une IDL (Interface Definition Language) Format externe de représentation des données (marshalling)

32 Suivez le guide (RPC)... Bilan historique des RPC... Standardisation, Simplicité, Portabilité, A apporté le marshalling et l IDL mais : Client Stub Skeleton Serveur Constituait un point central (risque d engorgement, de délai, de bloquage) Précompilation Nécessitait l introduction du multithreading... IDL Chez le client (pour cacher l attente) Chez le serveur (pour supporter les clients multiples) Ce qui complexifiait les applis (partage de ressources, etc.)

33 (Java) RMI Un seul langage Moins hétérogène, IDL = java, pas de marshalling... Localisation transparente On passe par un annuaire Ne se place pas tout à fait au même niveau que les RPC! Offre l'appel de méthodes, de manière (assez) transparente, vers des objets de localisation quelconque... Niveau 0 : dialogue local package hello; public class Hello { public void hello(){ System.out.println("hello"); package hello; public class Call { public static void main(string[] args){ Hello h=new Hello(); h.hello(); 65 Et maintenant, en route! 66 33

34 Niveau 1 : RMI en local Niveau 1 Schématiquement Recherche Call RMI registry 3. Référence 4. Invocation 1. Enregistrement Hello Vu de plus près... L'appelant ne connaît pas la classe appelée Il connaît une interface (c'est à dire un type de service) et une adresse (un nom associé à ce service) Il connait l'adresse du RMI registry L'appelé est invocable à distance : il implémente l'interface on lui associe un proxy (stub : client + skeletton : serveur) il se déclare auprès du RMI registry (sous le nom connu par l'appelant)

35 Niveau 1 Niveau 1 : Mise en oeuvre Vu de près Recherche Hello RMI registry 3. Référence + stub 1. Enregistrement Hello Ecrire l'interface + les deux classes (<java5) Compiler le stub : rmic classe Lancer le registry (pour l'instant, à partir de la racine des classes serveur) Lancer la classe serveur (enregistrement) Lancer la classe client Call 4.1. Invoc. locale HelloStub 4. Invocation distante *HelloSkel* HelloImpl 4.3. Invoc. locale

36 Interface + serveur (<=java5) Lanceur (<java5) 71 package hello; public interface Hello extends java.rmi.remote { public String hello() throws java.rmi.remoteexception; package helloserveur; import hello.hello; public class HelloImpl extends java.rmi.server.unicastremoteobject implements Hello{ public HelloImpl() throws java.rmi.remoteexception { public String hello() { return "hello"; // constructeur vide package helloserveur; import java.net.malformedurlexception; import java.rmi.remoteexception; public class HelloLaunch { public static void main(string[] args) { try { HelloImpl h=new HelloImpl(); java.rmi.naming.rebind("//localhost/monservice",h); System.out.println("service hello enregistre"); catch (RemoteException e) { e.printstacktrace(); catch (MalformedURLException e) { e.printstacktrace(); 72 36

37 Client (<java5) Mise en oeuvre (<java5) package helloclient; import hello.hello; public class Call { public static void main(string[] args){ try { Hello h=(hello) java.rmi.naming.lookup("//localhost/monservice"); String result=h.hello(); System.out.println(result); catch (java.rmi.remoteexception re) { // pb accès distant re.printstacktrace(); catch (java.net.malformedurlexception e) { // URL mal écrite e.printstacktrace(); catch (java.rmi.notboundexception e) { // pas de service correspondant e.printstacktrace(); ~> cd demo/bin/ bin> rmic helloserveur.helloimpl bin> ls helloserveur HelloImpl.class HelloImpl_Stub.class HelloLaunch.class bin> rmiregistry& [1] 6385 bin> java helloserveur.hellolaunch service hello enregistre ~> cd demo/bin/ bin> java helloclient.call hello bin>

38 Interface + serveur (>=java5) Lanceur (>=java5) 75 package hello; public interface Hello extends java.rmi.remote { public String hello() throws java.rmi.remoteexception; package helloserveur; import hello.hello; public class HelloImpl implements Hello { public HelloImpl() { public String hello() { return "hello"; // constructeur vide package helloserveur; import java.rmi... import hello.hello; public class HelloLaunch { public static void main(string[] args) { try { HelloImpl h=new HelloImpl(); Hello stub = (Hello) UnicastRemoteObject.exportObject(h, 0); // ^^^ étape inutile si HelloImpl étend UnicastRemoteObject Registry registry = LocateRegistry.getRegistry("localhost"); // ou getregistry(); registry.bind("monservice", stub); System.out.println("service hello enregistre"); catch (RemoteException e) { e.printstacktrace(); catch (AlreadyBoundException e) { e.printstacktrace(); 76 AAR Matthieu EXBRAYAT Master 2 MIAGE / IRAD Orléans 38

39 Client (>=java5) Mise en oeuvre (>=java5) package helloclient; import java.rmi.registry.*; import hello.hello; public class Call { public static void main(string[] args){ try { Registry registry = LocateRegistry.getRegistry("localhost"); // ou getregistry(); Hello h=(hello) registry.lookup("monservice"); String result=h.hello(); System.out.println(result); catch (java.rmi.remoteexception re) { // pb accès distant re.printstacktrace(); catch (java.rmi.notboundexception e) { // pas de service correspondant e.printstacktrace(); ~> cd demo2/bin bin> rmiregistry& [1] 6841 bin> java helloserveur/hellolaunch service hello enregistre ~> cd demo2/bin/ bin> java helloclient.call hello bin>

40 Niveau 2 : RMI distant RMI security server Schématiquement Recherche Call Contrôle RMI registry (site?) 3. Référence 4. Invocation 1. Enregistrement Hello RMI permet le chargement dynamique de classes inconnues Utilisation d interfaces Implémentation après coup Un peu risqué Risque d incohérences Risque de piratage Java fournit un mécanisme de protection RMISecurityServer (basique) Similaire au bac à sable des applets

41 Sécurité dans JDK 1.2 (et +) SecurityManager Les droits sont organisés par domaine (que les objets soient locaux ou distants) Une classe appartient à un domaine Politique de sécurité D1 D2 D3 Accès complet Bac à sable SecurityManager Ressources système Classe abstraite Un seul par JVM, non redéclarable Déclare des accès par ressource On peut utiliser des fichiers de définition Affine le fonctionnement du SM java -Djava.security.policy=mage.policy Policytool : gestion «graphique» des droits

42 Policytool Un fichier policy très simple... grant { permission java.net.socketpermission "*: ", "connect,accept"; ;

43 Mise en oeuvre du SM Mise en oeuvre dans l'exemple Avant l instanciation de l objet remote (début de main) Avant l appel à un objet remote (client) If (System.getSecurityManager()==null) { System.setSecurityManager( new RMISecurityManager()); De quel côté? Client : accède à des données distante : ok Serveur : ne reçoit rien de suspect : pas nécessaire utilisation d'un fichier «java.policy» grant { permission java.net.socketpermission "*: ", "connect,accept,resolve"; ; java -Djava.security.policy=java.policy helloclient.call

44 Client package helloclient; import java.rmi.registry.*; import java.rmi.*; import hello.hello; public class Call { public static void main(string[] args){ if (System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager()); try { Registry registry = LocateRegistry.getRegistry("localhost"); // ou getregistry(); Hello h=(hello) registry.lookup("monservice"); String result=h.hello(); System.out.println(result); catch (java.rmi.remoteexception re) { // pb accès distant re.printstacktrace(); catch (java.rmi.notboundexception e) { // pas de service correspondant e.printstacktrace(); AAR Matthieu EXBRAYAT Master 2 87 MIAGE / IRAD Orléans 88 Niveau 3 : chargement dynamique de classes Intérêt des interfaces? le service importe plus que le code le codage peut évoluer Se limiter au seul service? On peut faire transiter des objets (paramètres) entre client et serveur Quelle caractéristique doivent-ils posséder? Plutôt que des objets, les signatures peuvent contenir des interfaces... 44

45 Accès à des classes distantes Exemple L'interface est connu de C & S L'implémentation n'est définie que d'un côté, mais Elle doit être accessible de l'autre côté Utilisation d'un serveur de classe (codebase) plusieurs protocoles possibles (ftp, http...) Le méthode hello prend en paramètre la «carte de visite» du client dispose d'une méthode «contenutexte» (équivalent à un tostring personnalisé) l'implémentation est laissée libre au client

46 Niveau 3 : vue d'ensemble Mise en oeuvre serveur HTTP 0. mise en place des classes dans le serveur Call Implémentation de la CV RMI registry Hello package hello; public interface Hello extends java.rmi.remote { public String hello(cartevisite cv) throws java.rmi.remoteexception; package hello; public interface CarteVisite { public String contenutexte(); 91 Certaines classes intermédiaires ne sont pas représentées ici

47 Côté client... Côté client... package helloclient; package helloclient; import hello.cartevisite; import java.io.*; public class CarteVisiteClient implements CarteVisite,Serializable { private String nom; private String prenom; public CarteVisiteClient(String nom,string prenom) { this.nom=nom; this.prenom=prenom; public String contenutexte () { return prenom+ +nom; 93 import java.rmi.registry.*; import hello.*; public class Call { public static void main(string[] args){ if (System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager()); try { Registry registry = LocateRegistry.getRegistry("localhost"); // ou getregistry(); Hello h=(hello) registry.lookup("monservice"); CarteVisite cv=new CarteVisiteClient(«Dupont», «Jean»); String result=h.hello(cv); System.out.println(result); catch (java.rmi.remoteexception re) { // pb accès distant re.printstacktrace(); catch (java.rmi.notboundexception e) { // pas de service correspondant e.printstacktrace(); 94 AAR Matthieu EXBRAYAT Master 2 MIAGE / IRAD Orléans 47

48 Côté serveur... Côté serveur package helloserveur; import hello.*; public class HelloImpl implements Hello { public HelloImpl() { public String hello(cartevisite cv) { return "hello"+cv.contenutexte; // constructeur vide package helloserveur; import java.rmi... import hello.hello; public class HelloLaunch { public static void main(string[] args) { if (System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager()); try { HelloImpl h=new HelloImpl(); Hello stub = (Hello) UnicastRemoteObject.exportObject(h, 0); Registry registry = LocateRegistry.getRegistry("localhost"); // ou getregistry(); registry.bind("monservice", stub); System.out.println("service hello enregistre"); catch (RemoteException e) { e.printstacktrace(); catch (AlreadyBoundException e) { e.printstacktrace(); 96 AAR Matthieu EXBRAYAT Master 2 MIAGE / IRAD Orléans 48

49 Mise en oeuvre Détails pratiques Lancer un serveur http sur la machine client (ou un autre site) Placer la classe CarteVisiteClient sur ce serveur Lancement du client : java -Djava.rmi.server.codebase= -Djava.security.policy=java.policy helloclient.call Ici, les classes sont à la racine du serveur (modulo leur package) Côté serveur Il faut un java.policy!!! serveur HTTP on trouve un petit serveur de test chez sun disponible dans les ressources pédagogiques policy côté serveur idem à client

50 Question Modélisation des systèmes répartis Le serveur est un serveur de calcul Le client lui adresse une classe implémentant le calcul demandé Il envoie aussi les paramètres nécessaires Le client n'attend pas la réponse Le serveur le prévient à la fin des calculs Comment s'y prendre?... FIN :)