Réseaux et systèmes répartis C3camos.buniet.free.fr/LB/Distribue4.pdf · CAMOS CNAM 12 mars 2005 Informatique, réseaux, systèmes, multimédia / Réseaux et systèmes répartis

CAMOS CNAM 12 mars 2005

Informatique, réseaux, systèmes, multimédia / Réseaux et systèmes répartis C3 1

Réseaux et systèmes répartis C3

Distribué 4 : Java client/serveur avec RMI

12 mars 2005


2

Plan du jour

RappelsIntroduction RPCRMI : Remote Method invocation



12 mars 2005


3

Rappels et introduction

Nous avons vu le principe de fonctionnement d’un serveur Web– Utilisation du protocole HTTP pour demander un

document– Récupération et analyse du document pour retrouver

de l’information complémentaireLa récupération d’un document (statique) peut être assimilée à un appel d’une fonction distante effectuant une lecture de fichier

12 mars 2005


4

Récupération d'un fichier statique sur un serveur web

DNS : Domain Name ServerFait le lien entre le nom du serveur

et son adresse IPserveur.net => 158.167.34.11

client.net serveur.netRecherche du documenthttp://serveur.net/repertoire/index.html

http://serveur.net/repertoire/index.html



12 mars 2005


5

Récupération d'un fichier statique sur un serveur web (suite)

client.netserveur.net

http://serveur.net/repertoire/index.html

Et ensuite:

12 mars 2005


6

Récupération d'un fichier statique sur un serveur web (fin)

Le processus de récupération se traduit par deux appels distants– Appel au DNS pour récupérer l'adresse IP du serveur

à partir de son nom (si le client ne la connaît pas déjà, i.e. il ne l'a pas stockée dans un cache)

– Appel au serveur web pour obtenir le contenu du document à partir de sa place dans le système de gestion de fichiers (généralement hiérarchique) du serveur web. Le serveur web exécute une fonction simple : une lecture de fichier à partir du nom (la place) de celui-ci



12 mars 2005


7

Rappels et introduction (2)

Il est possible de demander des documents qui sont en fait produits dynamiquement par un serveur– Scripts et gateways– De véritables fonctions sont alors exécutées

Pages dynamiques avec Java– CGI et Java à la place de PERL (au début)– Servlets (même sur Microsoft IIS, Internet

Information Server)– JSP (Java Server Pages)

12 mars 2005


8


Le client et le serveur sont cependant spécifiques pour les documents hypertextes– La présentation graphique de certaines informations

n'est pas facileIl est possible d’envisager la possibilité où le client et le serveur seraient tous les deux aptes à comprendre Java pour effectuer des traitements– Java devient la "Lingua Franca" de l’échange



12 mars 2005


9


Cette situation imposerait cependant que les deux parties comprennent Java mais également les objets et méthodes partagés par les deux parties– Dans le cas de le navigation Internet, le client et le

serveur comprennent HTML et HTTP– Pour Java, un même objet devrait avoir la même

définition et le même comportement aux deux extrémités

Il faudrait donc distribuer des objets Java– Et le plus simple est de créer des composants

12 mars 2005


10


Les premiers ordinateurs ("centraux", "host") donnaient à la fois accès aux données et aux traitementsLes postes client n'étaient que des terminaux avec écrans et claviers, sans puissance de calcul (pas de processeur)– Ces terminaux n'affichaient que des caractères

Le host devait être puissant, très puissant– Invention du moniteur transactionnel pour garantir la

continuité d'un certain niveau de service



12 mars 2005


11


Informatique Mainframe

12 mars 2005


12


Avec l'arrivée de PC est apparu un poste client bon marché avec une puissance de calcul et des capacités graphiques (client lourd)Les logiciels ont été développés pour être distribués sur ces machines– Le même logiciel doit être partout pour respecter

uniformément les règles de gestion ou détenir la dernière version du schéma de la base de données : problème de distribution correcte du logiciel

Pour garantir la cohérence, les données continuent à être centralisées !



12 mars 2005


13


InformatiqueClient/Serveur

12 mars 2005


14


Pour résoudre le problème de distribution du logiciel, on partitionne l'application du poste client en deux :– La partie graphique de l'application reste sur le client– La partie règles de gestion et accès aux données de

l'application est rapatriée sur le serveur– Il faut cependant que la partie graphique possède un

lien vers les règles de gestionRéduction du besoin de distribution des applications sur le poste client lourd



12 mars 2005


15


InformatiqueDistribuée

12 mars 2005


16


Ce dernier type d'architecture correspond àl'architecture distribuée, faisant suite aux modèles "centralisé" et "client/serveur"

– Dans l'architecture distribuée, il est encore question de clients et de serveurs

Il faut définir une couche application (modèle ISO, couche 7) qui s'occupe de tous les aspects élémentaires de l'informatique distribuéeIl faut définir une couche présentation (modèle ISO, couche 6) qui garantit l'uniformité du codage entre les différentes plates-formes utilisées dans l'architecture



12 mars 2005


17


Les sockets, c’est bien :– Efficace, bien compris – Indépendant de la plate-forme et du langage– Facile à modifier pour rajouter de la sécurité, de la

compression, etc.Mais...– Pas vraiment abstrait– Les "streams" n’ont rien d’orienté objet– Il faut définir et implémenter tout le protocole

applicatif qui permettra de réaliser les fonctions distribuées

12 mars 2005


18


Première grande utilisation des sockets pour standardiser la programmation distribuée : DCE, Distributed Computing Environment– Très difficile à mettre en œuvre car nécessite de tout

gérer « à la main »– Encore très utilisé aujourd’hui : couche de base de

Microsoft DCOM !

Début du RPC : Remote Procedure Call



12 mars 2005


19


Comme dans le cas de HTML et de HTTP :– Le client doit retrouver le serveur par son adresse

binaire ou son adresse texte– Le serveur doit s'assurer de l'existence de la

ressource recherchée (chemin jusqu'à un fichier dans le système de gestion de fichiers)

– Le serveur doit s'assurer que le client a le droit d'accéder à la ressource

– Le serveur doit garantir la bonne prise en compte des paramètres passés (GET ou POST avec HTTP)

12 mars 2005


20

RMI :Remote Method Invocation



12 mars 2005


21

L’idée de base

Si le code se trouvant sur le client et le serveur est en Java, les données envoyées sur le fil devraient également être en Java pour économiser du temps de filtrage (ISO couche 6)Il devient possible d’envoyer des messages (au sens orienté objet) à des objets Java quelque soit leur localisationAttention : plus le fil sera long (distance à parcourir avec de plus en plus de relais) et fin (bande passante) et plus cela prendra du temps, quoique l’on fasse (pour RMI comme pour les autres protocoles…)

12 mars 2005


22

RMI ?

Remote Method InvocationUne manière d’envoyer des messages à des objets Java sur le réseau– Utilise les sockets (...)– Facile à utiliser lorsque l’on connaît Java

RMI est un véritable framework pour construire des applications distribuéesInfrastructure bien faite– Sun avait déjà une bonne expérience avec DCE/RPC



12 mars 2005


23

Place de RMI dans Java

java.net

RMI

Jini

JavaSpaces

Servlets

EJB JSP

12 mars 2005


24

L'apparence d'un appel distribué

traitementsdonnées

affichages*

* : Les affichages sont aussi des traitements.Mais il ne s’agit pas de règles de gestion



12 mars 2005


25

La réalité d'un appel distribué

traitements données

affichages

distribution

12 mars 2005


26

Mise en place de la distribution

Entre les objets "graphiques", qui appellent un objet se trouvant à distance, et l’objet lui-même, il faut mettre en place une batterie de mécanismes qui vont établir le lienLes mécanismes inclus dans RMI sont très proches de ceux disponibles dans les versions Sun de C++ intégrant le RPC– Ne me dites pas que vous pensiez que l’on inventait

des choses en informatique !!!



12 mars 2005


27

Vocabulaire...

Les stubs et les skeletons de RMI suivent la nomenclature définie pour CORBA (que nous verrons au prochain cours)Cette nomenclature diffère de celle de Microsoft

Bus applicatif

stubproxy

client

skeletonstub

serveur

MicrosoftAutres

12 mars 2005


28

Déroulement d’un appel

client stub du client skeleton du serveur serveur

fooforward de l’appel

foo

Le client croit parler directementà l’objet

Tous les arguments, ainsique le nom de la méthode,sont empaquetés et envoyés sur le réseau

Le skeleton dépaquette tout et appelle la méthode présente sur le serveur



12 mars 2005


29

Avant l’appel...

Pour effectuer l’appel à distance présentéavant, il faut cependant disposer d’un mécanisme d’appel valable du côté du client– Il faut donc le mettre en place

En appelant un document avec HTTP, il faut disposer d’un chemin correct (un nom de fichier complet) vers un fichier sur le serveurAvec RMI, il faut disposer d’un nom d’objet correct sur le serveur...

12 mars 2005


30

Avant l’appel... (suite)

Le fichier que l’on cherche à obtenir avec HTTP possède un nom défini dans le système de gestion de fichiers du serveur– Le système de gestion de fichiers fait cette gestion

de noms, permettant le déplacement dans l’arborescence

Pour RMI, il faut également disposer d’un mécanisme de nommage pour les objets– Il faut donc disposer d’un serveur de nom spécialisé



12 mars 2005


31

Généralité sur le nommage

Un objet c’est :– Un Identifiant +– Un état +– Un comportement

Pour les applications non réparties, le nommage est géré par le langage (référence) ou le système d’exploitation (adressage)Pour une application répartie, le nommage peut être explicite ou dynamiqueExemples de systèmes de nommage : URL, DNS, X500, LDAP ...

12 mars 2005


32

Séquence de développement

Définition des objets sérialisables– Ceux qui pourront être envoyés sur le fil

Définition des interfacesChoix de l’identité de l’objetImplémentation du serveurImplémentation du clientGénération des stubs et skeletonsTest et débogage...



12 mars 2005


33

Séquence de développement : précision des classes Java

Déclarer les objets pouvant être appelés de manière distante : – Sous-classe de java.rmi.RemoteObject

Déclarer les méthodes pouvant être appelées de manière distante : – déclaration d’une interface pour les appels distant.

Toutes les méthodes distantes peuvent générer des exceptions– java.rmi.RemoteException

12 mars 2005


34

Une vue du Java en UML

Remote

RemoteObject

UnicastRemoteObject Dispatcher SrvObj

DispatcherImpl SrvObjImpl

Serializable

RemoteServer

Param2Param1 Param3



12 mars 2005


35

Serializable, Primitive, Remote

Les seuls types de valeurs exploitables dans les interfaces sont :– Les objets Serializable (ils implémentent l’interface)– Les instances d’une classe qui implémente l’interface

Remote– Les valeurs de type primitif (byte, int, ...)

Il est toujours possible d’avoir des objets non serializable et non remote dans une application mais il ne sera pas possible de les utiliser dans les parties du code en relation avec RMI

12 mars 2005


36

Objets sérialisés

Ils sont utilisés comme paramètres lors des appels de méthodeIls sont envoyés par valeur (donc copie...)– Les mécanismes de RMI utilisent une sous-classe de

ObjectOutputStream pour sérialiser une instance et l’envoyer sur le fil

– La JVM qui réceptionne l’appel crée un objet dupliqué (un clone)

Une ObjectOutputStream est utilisée pour chaque appel de méthode



12 mars 2005


37

Objets Remote

L’interface Remote est un marqueurLes objets qui implémentent Remote sont “passés par référence”Typiquement :– On l’étend avec une autre

interface déclarant lesméthodes disponibles surle serveur

– On l’implémente alors en créant une sous-classe de UnicastRemoteObject

Remote

RemoteMethodDeclarations

LocalImpl

UnicastRemoteObject

12 mars 2005


38

Passage par référence ?

Comment passer un pointeur vers un objet dans un autre espace d’exécution ?– Cela ne se fait pas... Les objets Remote ont des

stubs et des skeletonsRMI sérialise les objets Remote– RMI utilise une sous-classe de ObjectOutputStream

et surcharge la méthode replaceObject pour “sérialiser” le stub et l’envoyer (les valeurs de l’appel dans la signature du stub sont sérialisées...)



12 mars 2005


39

Identité des objets

Que se passe-t-il dans l’objet serveur si plusieurs appels à une même méthode sont effectués en même temps ?

– Plusieurs instances des paramètres sont créésIls pourraient même contenir les mêmes valeurs

– Ce sont cependant des objets différentsIls doivent pouvoir être distingués

Une bonne manière de faire ceci est de surcharger les méthodes equals et hashcode dans les objets paramètres

– On donne la manière de créer une carte d’identité

12 mars 2005


40

Deux types de serveurs

Serveurs nommés, accessibles “universellement”– Implémentent Remote et étendent

UnicastRemoteObject– Définis dans un registre quelque part

La définition sera faite au démarrage de l’application, par exemple

Les serveurs qui doivent être signalés au client– Implémentent Remote et étendent

UnicastRemoteObject– Ne sont pas définis dans un registre



12 mars 2005


41

Nommage

Interface simple vers un registre Implémenté au travers de cinq méthodes statiques :

public static String[] list( String name ) public static Remote lookup( String name ) public static void bind( String name, Remote obj ) public static void rebind( String name, Remote obj ) public static void unbind( String name )

12 mars 2005


42

Qu’est-ce qu’un nom ?

Tous les appels au service de nommage utilisent le même format : //host:port/name

– host par défaut : localhost– port par défaut : 1099– name doit normalement être humainement compréhensible

“Trouve un registre RMI au [port] de la machine [host]. Enregistre moi en tant que [name].”

– Un bind : une déclaration (définition) de référence d’objetOU “Trouve un registre RMI au [port] de la machine [host]. Trouve moi l’objet connu sous le nom [name].”

– Un lookup : la recherche d’une référence d’un objet d’un certain nom



12 mars 2005


43

Enregistrement d’un objet

serveur SrvObj registry SrvObjImplNaming

lookup( SrvObj )

create

ajout d’une référence

12 mars 2005


44

Appel de méthode

client Naming SrvObj SrvObjImpl

lookup

appel

appel effectif

retour



12 mars 2005


45

Génération des stubs et skeletons

RMIC : RMI Compiler– Génère automatiquement les stubs et les skeletons à

partir de fichiers .class des implémentations serveur

rmic -d répertoiredesortie chemin.complet.vers.classe

12 mars 2005


46

Exécution du programme

Démarrage du registre– rmiregistry

Démarrage du dispatcher– java -Djava.security.policy=java.policy Dispatcher

Démarrage du serveur– java -Djava.security.policy=java.policy

ProgrammeServeurExécution du client– java -Djava.security.policy=java.policy

ProgrammeClient



12 mars 2005


47

Exemple : Copier un fichier

Copier un fichier d ’une machine à une autre– Lire un fichier sur la machine expéditrice et le mettre

dans un tampon en mémoire– Appeler une méthode d’un objet receveur distant en

passant le tampon en paramètre, – L’objet receveur écrit ce paramètre dans un fichier

sur son système de gestion de fichiers...Dans ce cas, c’est le client qui fournit le fichier– Equivalent d’un file upload HTTP

12 mars 2005


48

Diagramme de classes

RemoteReceiver

RemoteReceiver()setDirectory(directory : String) : voidreceiveFile(packet : FilePacket) : voidmain(args[] : String) : void

FilePacket

data[] : byte

FilePacket(name : String)getName() : StringreadIn() : voidwriteTo(out : OutputStream) : void

FileSender

FileSender(hostname : String)actionPerformed(event : ActionEvent) : voidmain(args[] : String) : void

FilePacket : une variable intermédiaireFileSender : l’émetteurRemoteReceiver : le receveur...



12 mars 2005


49

Diagramme de séquence

1FileSender : FileSender

1File : FilePacket

1RemoteRec : RemoteReceiver

FilePacket(String)

readIn( )

receiveFile(FilePacket)

writeTo(OutputStream)

Sur le ClientSur le Serveur...

12 mars 2005


50

FilePacketdata[] : byte

FilePacket(name : String)getName() : StringreadIn() : voidwriteTo(out : OutputStream) : void

FileSender

FileSender(hostname : String)actionPerformed(event : ActionEvent) : voidmain(args[] : String) : void

FileReceiver

setDirectory(directory : String) : voidreceiveFile(packet : FilePacket) : void

<<Interface>>

RemoteReceiver

RemoteReceiver()setDirectory(directory : String) : voidreceiveFile(packet : FilePacket) : voidmain(args[] : String) : void

UnicastRemoteObject

UnicastRemoteObject()readObject(in : java.io.ObjectInputStream) : voidclone() : ObjectexportObject(obj : Remote) : RemoteStub

(from server)

RemoteServer

RemoteServer()RemoteServer(ref : RemoteRef)getClientHost() : StringsetLog(out : java.io.OutputStream) : voidgetLog() : java.io.PrintStream

(from server)

RemoteObject

RemoteObject()RemoteObject(newref : RemoteRef)hashCode() : intequals(obj : Object) : booleantoString() : StringwriteObject(out : java.io.ObjectOutputStream) : voidreadObject(in : java.io.ObjectInputStream) : void

(from server)

Diagramme de classes remis en contexte



12 mars 2005


51

Problèmes...

1RR : RemoteReceiver

1FS : FileSender 1FP : FilePacket

FilePacket(String)

readIn( )

receiveFile(FilePacket)


Comment avoir une ref sur 1RR ?? Impossible de manière classique...

12 mars 2005


52

Accéder à un objet distant ...

Le créateur et détenteur de l’objet (serveur) doit d’abord externaliser (au moins) un objet en lui donnant un nom : – static void Naming.rebind( String, Remote )

L ’utilisateur (client) doit récupérer un référence en utilisant ce nom : – static Object Naming.lookup( String )



12 mars 2005


53

Nommage...

Qu’est qu’un nom ? En RMI, une URL …– rmi://java.sun.com:1099/root/foo

RMI : le protocole de haut niveau– En dessous : JRMP, Java Remote Method Protocol

java.sun.com:1099 : le nom ou le remoteReceiver tourne…– 1099 : le port par défaut de la RMI registry

root/foo : une chaîne de caractères pour déterminer l ’objet...

12 mars 2005


54

: Naming 1FP : FilePacket : FileSender: srvr


RemoteReceiver( )

rebind("rmi://localhost:1099/receiver", 1RR)

FilePacket("c:\fic.txt")

readIn( )

lookup("rmi://localhost:1099/receiver")

receiveFile(1FP)

JVM serveur RMI Registry JVM client

Action...



12 mars 2005


55

Remarque

: Naming 1FP : FilePacket : FileSender: srvr


RemoteReceiver( )



readIn( )


receiveFile(1FP)

JVM serveur RMI Registry JVM client

ATTENTION ! Passage par copie !

12 mars 2005


56

Objet Remote et non Remote...

Paramètre et valeur de retour des méthodes :Sous-classe de RemoteObject -> passage par référenceAutrement -> passage par copie !



12 mars 2005


57

1FP' : FilePacket 1FP : FilePacket : FileSender: srvr


: Naming

RemoteReceiver( )



readIn( )


receiveFile(1FP)


Objet crééimplicitement !

Si je change qq chose dans 1FP', pas de chagmenent sur1FP ! passage par copie !

12 mars 2005


58

Nommage : RMIRegistry…

Attention ! Un processus à part est chargé de maintenir la table gérant l’association entre un nom et une RemoteReference– Comme pour HTTP ou un client a besoin du DNS

(Domain Name Serveur) pour retrouver l’adresse binaire du serbeur dont il connaissait l’adresse texte

C ’est le RMIRegistry ! – 1: on lance le RMIRegistry– 2 : on lance le RemoteReceiver– 3 : on lance le FileSender



12 mars 2005


59

Attention aux problèmes de typage

Attention : ici 1FP est d’une certaine manière présent sur deux JVM ! Il faut être sûr que les deux JVM ont bien le même FilePacket.class !Vérifié par Java à l ’exécution avec des VID (version ID)Problème de déploiement– Source d’erreur classique pour toutes les

applications distribuées

12 mars 2005


60

Class loader ...

Les fichier .class utilisés par le client peuvent être téléchargés à partir du serveur si elles n’existent pas localement sur le client par le RMIClassLoader…– Utilisé pour les paramètres et les valeurs de retour

de méthodes distantes.– Aucune raison pour que cela ne marche pas : tout

est en Java !Facilite le déploiement, mais crée des problèmes de sécurité...



12 mars 2005


61

RMI et Security Manager

Si des classes doivent être téléchargées àtravers le réseau, elles doivent obéir aux politiques de sécurité– Par exemple : pas d’actions sensibles (accès

systèmes) ou de téléchargement à partir de sources de confiance

Une politique pré-définie existe en RMI : le RMISecurityManager...– Sécurité de base (pas très poussée)– Il est possible de faire le sien !

12 mars 2005


62

1FP : FilePacket : FileSender : System: System

: srvr


: Naming


readIn( )

RemoteReceiver( )

receiveFile(1FP)



CRSM : RMISecurityManager

RSM : RMISecurityManager

RMISecurityManager( )

setSecurityManager(RSM)

RMISecurityManager( )

setSecurityManager(CRSM)

RMI et Security Manager (suite)



12 mars 2005


63

RMI et Security Manager (suite)

Si aucun Security Manager n ’est installé, tous les chargement de fichiers .class doivent se faire à partir du CLASSPATH local.– La seule source de confiance qui reste...

Mais il s’agit d’une mauvaise solution pour le déploiement d ’applications distribuées– problème fondamental…

12 mars 2005


64

Politique de sécurité : policies

Un fichier de policies doit être fourni :grant signedBy "signer_names", codeBase "URL" { permission permission_class_name "target_name",

"action", signedBy "signer_names"; .... permission permission_class_name "target_name",

"action", signedBy "signer_names"; }; UTILISATION : java -Djava.security.policy=policy …



12 mars 2005


65

Policies…

grant signedBy "Duke" { permission java.io.FilePermission "/tmp/*", "read,write";

};

grant {

permission java.security.AllPermission;

};

grant signedBy "sysadmin", codeBase "file:/home/sysadmin/*" {

permission java.security.SecurityPermission "Security.insertProvider.*";

permission java.security.SecurityPermission "Security.removeProvider.*";

permission java.security.SecurityPermission "Security.setProperty.*"; };

12 mars 2005


66

Class Loader et Déploiement

java -Djava.rmi.server.codebase=http://host/rmiclasses/LoadClient

import java.rmi.RMISecurityManager;import java.rmi.server.RMIClassLoader;public class LoadClient {

public static void main() {System.setSecurityManager( new RMISecurityManager() );try {

Class cl = RMIClassLoader.loadClass( "myclient" );Runnable client = (Runnable) cl.newInstance();client.run();

} catch ( Exception e ) {System.out.println( "Exception: " + e.getMessage() );e.printStackTrace();

}}

}



12 mars 2005


67

Stub et Skeleton

Comment ça marche en fait ?Pour chaque objet remote, il est nécessaire de disposer de deux objets : l ’objet stub et l ’objet skeleton.Le stub représente l ’objet remote sur le client, une sorte de fantôme de l ’objet remote.Le skeleton est là pour réceptionner les appels de méthodes distants du client et les propager àl ’implémentation de l ’objet remote sur le serveur.

12 mars 2005


68

Stub et Skeleton

Transport Layer

Remote Reference Layer

Stub Skeleton

Client Serveur

Lien vers lesystème denommage



12 mars 2005


69

Stub et skeleton

Bonne nouvelle : ils sont générés automatiquementMauvaise nouvelle : il faut quand même appeler un compilateurAppel de rmic sur une classe sous-classes de remoteObject– RemoteReceiver dans notre cas

Génère RemoteReceiver_Skel.classRemoteReceiver_Stub.class

12 mars 2005


70

Le code du serveur

public class RemoteReceiver extends UnicastRemoteObject implements FileReceiver {

private String directory;public RemoteReceiver() throws RemoteException {

super();}public void receiveFile( FilePacket packet )

throws RemoteException {try{

packet.writeTo( new FileOutputStream( packet.getName() + ".snt" ) );

}catch( IOException e ){e.printStackTrace();

}}

...



12 mars 2005


71

Le code du serveur (suite)

public static void main( String args[] ) {String usage =

"Usage: java rmi.RemoteReceiver <directory> <hostname>";try {

System.setSecurityManager( new RMISecurityManager() );RemoteReceiver remote = new RemoteReceiver();Naming.rebind( "//" + args[ 1 ] + "/receiver", remote );System.out.println( "Object is bound" );

} catch( Exception e ) {e.printStackTrace();System.out.println( usage );

}}

}

12 mars 2005


72

L’interface de définition du Remote...

public interface FileReceiverextends Remote

{public void receiveFile( FilePacket packet )

throws RemoteException;}



12 mars 2005


73

Le code du client

public class FileSender implements ActionListener {private Frame frame;FileReceiver receiver;public FileSender( String hostname ) throws Exception {

receiver = (FileReceiver) Naming.lookup( "//" + hostname + "/receiver" );

frame = new Frame( "File Sender" );frame.setBounds( 100, 100, 80, 80 );Button b = new Button( "Send File" );b.addActionListener( this );frame.add( "Center", b );frame.setVisible( true );

}...

12 mars 2005


74

Le code du client (suite)

public void actionPerformed( ActionEvent event ){try{

FileDialog dialog = new FileDialog( frame, "Upload a file", FileDialog.LOAD );

dialog.setVisible( true );String filename = dialog.getDirectory() + dialog.getFile();FilePacket packet = new FilePacket( filename );packet.readIn();receiver.receiveFile( packet );

} catch( Exception e ) {e.printStackTrace();

}}...



12 mars 2005


75

Le code du client (suite)

public static void main( String args[] )throws Exception

{String usage = "Usage: java rmi.FileSender <remotehost>";try{

System.setSecurityManager( new RMISecurityManager() );FileSender sender = new FileSender( args[ 0 ] );

} catch( Exception e ) {e.printStackTrace();System.out.println( usage );

}}

}

12 mars 2005


76

L’objet intermédiaire

public class FilePacket implements Serializable {private String name;private byte[] data;public FilePacket( String name ) {

this.name = name; }public String getName() {

return name; }public void readIn() {

try {File file = new File( name );data = new byte[ (int) (file.length()) ];(new FileInputStream( file )).read( data );

} catch( Exception e ) {e.printStackTrace();}

}



12 mars 2005


77

L’objet intermédiaire (suite)

public void writeTo( OutputStream out ){

try{

out.write( data );}catch( Exception e ){

e.printStackTrace();}

}}

12 mars 2005


78

Déploiement de FileSender...

javac *.javarmic rmi.RemoteReceivercopier les fichiers .class vers le client (à moins de bootstrapper ou de faire une applet)démarrer rmiregistry sur le serveurdémarrer le serveur : java RemoteReceiverdémarrer le client (normalement sur une autre machine) java FileSender



12 mars 2005


79

Distributed Garbage Collector

Comment libérer les objets référencés dans le serveur par des remote-références ?Problème : – Le client ne les utilise plus– Le client se crashe (pour une longue période)– Le client se crashe et réapparaît (arghhhh)

12 mars 2005


80

Distributed Garbage Collector

Le serveur maintient une liste de références remoteCette référence remote est prêtée par le serveur au client pour un temps prédéfini – 10 minutes par défaut

Le client peut renouveler sa période de prêt de référence en appelant la méthode dirty() sur le serveur



12 mars 2005


81

RMI et appels concurrents...

Attention : a priori un objet remote peut-être accédé par plusieurs client en même temps !Dans ce cas, la JVM du serveur démarre un thread par client (distant)– Est-ce que cela vous rappelle quelque chose ?– Les servlets peut-être ?

Attention aux synchronized– Comme pour le Single Thread Model des servlets

12 mars 2005


82

Conclusion

RMI est une extension distribué du langage Java. Ça a l’avantage d’être simple et de préserver les qualités intrinsèques du langage (type safety, Garbage Collection, threads)Problèmes :– Ça marche de Java à Java (pas d ’interopérabilité

avec des applications dans d’autres langages)À moins de réécrire tout le code RMI en C++...

– C’est peu performant et cela supporte assez mal pas le passage à l’échelle (i.e. un grand nombre de clients)

Mais certains en ont fait de grandes choses avec J2EE



12 mars 2005


83

Questions / Remarques

Documents

Réseaux et systèmes répartis C3camos.buniet.free.fr/LB/Distribue4.pdf · CAMOS CNAM 12 mars 2005 Informatique, réseaux, systèmes, multimédia / Réseaux et systèmes répartis