Environnement Client-Serveur

Transcription

1 Environnement Client-Serveur This work is licensed under a Creative Commons Attribution-Share Alike 2.0 France. See for details

2 Sources Le Web (sic!): Livres : Distributed Systems: Concepts and Design George F. Coulouris, Jean Dollimore, et Tim Kindberg (référencé par 'DS1' dans les slides) Sources Autres : Distributed Systems: Principles and Paradigms Andrew S. Tanenbaum et Maarten van Steen (référencé par 'DS2' dans les slides)

3 Plan (Points Importants) Origines (IPC) Critères Problèmes spécifiques à la distribution Architectures Terminologie Architecture logicielle Architecture système Plan Introduction

4 Plan (Points Importants) Plan Communications Réseau physique (Ethernet, Wi Fi, ATM) Protocoles : IP, UDP, TCP, HTTP Couches réseaux (ISO/OSI) RPC/RMI Objectif transparence Problématiques Marshalling/Serialisation Principes (Stub/proxy, diagramme de classes) Architecture classes (téléchargement de code)

5 Plan Introduction Introduction 5

6 client-serveur: origine Problématique initiale On cherche à faire communiquer des processus entre eux Introduction Inter process communication (IPC) Exemples : chat : stallman torvalds mail : stallman torvalds Logging centralisé : toutes les applications écrivent leur journaux dans /var/log Solutions?

7 client-serveur: origine IPC: solutions? On a pas précisé que les processus étaient sur des machines différentes! ; ) Les systèmes multi utilisateurs existent depuis les années 1960 Introduction CTSS puis Multics et enfin UNIX Pourquoi une bibliothèque (API) ne suffit elle pas?

8 client-serveur: origine Introduction Bibliothèque (API) : mail : écriture du message de stallman directement dans la mailbox de torvalds log : écriture du message directement dans /var/log Problème de droits un processus est lancé avec des droits d'accès qui sont liés à l'utilisateur Le code dans la lib aura les même droits que le processus stallman ne peut pas écrire dans la mailbox de torvalds

9 IPC ( Introduction fichiers process stallman écrit un fichier dans un rèpertoire process torvalds lit le contenu du fichier Attention aux droits d'accès Attention aux accès concurrents Efficace?

10 IPC ( Introduction fichiers mappés en mémoire (man mmap) Accès au fichier directement (plus de read/write) Private (COW) ou Shared mode Attention aux droits d'accès (rwx) Attention aux accès concurrents... Trés efficace.

11 IPC ( signaux (man 7 signal) limité : pas de données associées au signal efficace Introduction

12 IPC ( tube /pipe (man 7 pipe) unidirectionnel concept en flux (stream) Introduction il n'y a pas de notion de message Attention aux accès concurrents! limité : lecture/écriture entre processus de même parents

13 IPC ( Introduction tube nommés / fifo (man 7 fifo) même fonctionnement que les tubes permet à des processus sans relations filiales de communiquer Très efficace utilisé massivement par exemple sur Tera 100 (1er Europe, 6ème au Top500 en )

14 IPC ( mémoire partagée SYSV (man shmget)/posix (shm_overview) Principe: Introduction Un processus créé un segment de mémoire partagée Il diffuse la clé d'accès Les autres processus accédent à cette mémoire comme d'habitude Très efficace. Attention aux accès concurrents sémaphores (man semget/sem_overview)

15 IPC ( file de messages vieux : SYSV (msgget), récent : POSIX (msg_overview) Principe: Introduction Pas vraiment équivalent au FIFO send/receive support des priorités orienté message les priorités peuvent changer l'ordre d'arrivée Persistence niveaux OS tant que l'os n'est pas rebooté, la file existe

16 Systèmes distribués Souvent, les processus sont distants Pourquoi limite t'on la portée de cette définition aux processus? Introduction dans ce cas, on parle de système distribués quid du matériel? plusieurs ordinateurs imprimantes, scanner,...

17 Systèmes distribués Introduction Sinon, un ordinateur serait lui même un système distribué : nombreux composants CPU, RAM, Disques, Écran, Carte réseau L'OS rend le tout transparent : il donne l'illusion d'un tout cohérent C'est quoi l'os? kernel? shell? GUI? Transparence : élément très important

18 Systèmes distribués (DS1: 1.1 Introduction) On considère qu'un système est distribué s'il vérifie un certain nombre de critères Introduction

19 Systèmes distribués : critères (DS1: 1.1 Introduction) Parallélisme : les processus s'éxecutent en parallèle Attention : parallélisme!= concurrent Introduction parallélisme sur une machine multi core ou SMP concurrence sur une machine mono core même si les architectures modernes savent exécuter des instructions bas niveaux simultanément Le parallélisme devient la norme avec les architectures multi core Cela implique t'il qu'un système distribué est au moins composé de plusieurs CPUs?

20 Systèmes distribués : critères (DS1: 1.1 Introduction) Introduction Pas d'horloge globale le temps ne s'écoule pas exactement de la même manière pour chaque processus les processus ne peuvent pas se baser sur le temps pour se synchroniser : ils doivent communiquer Ce critère écarte les ordinateurs de la définition

21 Systèmes distribués : critères (DS1: 1.1 Introduction) Pannes indépendentes un processus peut ne plus répondre indépendemment des autres Introduction le réseau est tombé le processus s'est craché la machine s'est planté... Difficile de distinguer les différents cas Ce critère écarte les ordinateurs de la définition

22 Systèmes distribués (DS1: 1.1 Introduction) Quels sont les intérêts des systèmes distribués? Introduction

23 Intérêt des systèmes distribués (DS1 : 1.1 Introduction) Partage de ressources : matérielle : Introduction imprimantes (CUPS) disques (NAS, SAN), CPU (SLURM),... logicielles : fichiers (NFS, SMB, Emule,...), base de données (PostgresQL, MySQL, ) web services (google map, amazon S3,...)

24 Intérêt des systèmes distribués Performance augmenter le nombre d'utilisateurs/seconde Introduction diminuer la charge sur une ressource donnée Augmente t'on d'autant le nombre d'utilisateurs par seconde en augmentant le nombre de machines? Si le goulot d'étranglement est la base de donnée, il faut distribuer cette base Tolérance aux pannes Si une panne survient, le service est dégradé seulement Mais il fonctionne toujours

25 Examples (DS1 : 1.2 Examples) Internet est il un système distribué? Introduction

26 Examples (DS1 : 1.2 Examples) Internet est il un système distribué? Introduction Non : il n'est pas une collection de processus! Web, mail, bittorrent sont des systèmes distribués Web : firefox communique avec httpd mail : kmail communique avec sendmail BitTorrent : emule communique avec emule L'avenir : ordinateurs obsoletes (pour le grand public) ultra connectés : webphone, tv, ipad, console,...

27 Problèmes spécifiques à la distribution (DS1 : 1.4 Challenges) Communication inter processus distants Même problématique que les IPC locales C'est le cœur d'un système distribué Connaissance réseau indispensable Introduction On s'appuiera sur les couches réseaux sous jacente (modèle OSI,...) On utilisera les couches hautes pour les garanties ou les services (ex: HTTP, FTP) On utilisera les couches basses pour les performances (ex: UDP) Dans la grande majorité des cas, on s'appuie toujours au moins sur IP

28 Problèmes spécifiques à la distribution (DS1 : 1.4 Challenges) Introduction Hétérogénéité Réseaux (Ethernet, ATM, Token Ring, IB) Matériel (x86, SPARC, Power, ARM) OS (Linux, Unix, Windows) Langages (C, C++, C#, Java, Python, Ruby) Implementations (IE vs Netscape, Outlook vs...) Le middleware est une couche logicielle qui masque l'hétérogénéité CORBA, J2EE,.NET sont les plus connus

29 Problèmes spécifiques à la distribution (DS1 : 1.4 Challenges) Introduction Ouverture capacité à étendre le sytème avec de nouvelles ressources matérielles et/ou logicielles capacité à supporter une nouvelle implémentation d'une partie du système sans remettre en cause l'ensemble permet de changer de fournisseur Publication d'interface claire et concise masquant les détails sous jacent Utilisation des standards lorsqu'ils existent (RFC)

30 Problèmes spécifiques à la distribution (DS1 : 1.4 Challenges) Sécurité Les processus échangent des messages sur un réseau généralement considéré non sécurisé Introduction Identification + Chiffrement Denial of Service : un composant matériel est surchargé de requête, il ne peut plus répondre Code mobile : un code est recu dans un message, peut on l'exécuter Un pare feu est un pré requis, mais il n'est pas suffisant

31 Problèmes spécifiques à la distribution (DS1 : 1.4 Challenges) Introduction Scalabilité Capacité du système à supporter une augmentation significative des ressources et des utilisateurs Compromis coût/performance à trouver Choisir des limites acceptables dans le système Éviter les goulots d'étranglements nombres d'adresses IPv4, numéro de tél sur 8 chiffres... /etc/hosts centralisé versus DNS Réplication, cache,...

32 Problèmes spécifiques à la distribution (DS1 : 1.4 Challenges) Introduction Pannes partielles Une partie du système peut tomber en panne Détection des pannes (ex : checksum) Masquage des pannes (ex : retransmission TCP) Tolérance aux pannes (ex : timeout client web) Récupération après panne (ex : journalisation) Redondances des ressources (ex : IP, DNS, RAID) La virtualisation peut aussi offrir une solution

33 Problèmes spécifiques à la distribution (DS1 : 1.4 Challenges) Parallélisme/Concurrence Plusieurs processus s'exécutent en parallèle Introduction ex : plusieurs clients achètent le même livre sur amazon. Le système doit garantir que les clients recoivent bien leurs livres, et qu'ils payent bien (même lorsqu'il ne reste plus qu'un seul livre en stock). Programmation concurrente complexe indéterminisme rend la mise au point très difficile (ex : disparition de bug au débogage)

34 Problèmes spécifiques à la distribution (DS2 : Transparency) Transparence Leslie Lamport (LaTeX) : "A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable." Introduction Andrew Tanembaum (minix) : "A distributed system is a collection of independent components that appears to its users as a single coherent system) La transparence est une notion très importante en informatique distribuée.

35 Problèmes spécifiques à la distribution (DS2 : Transparency) Introduction Transparence Accès : ressource locale et distante s'accède de la même manière (ex : sshfs, nfs, SPARC vs x86) Localisation : masque la localisation (ex : URL) Mobilité : masque le mouvement des ressources et des utilisateurs (ex: téléphone mobile) Concurrence : masque la concurrence d'accès aux ressources (ex : database update) Réplication : masque l'utilisation de réplicas (RAID) Panne : masque les pannes et leurs récupérations (mail) Persistence : masque ressource en RAM, disque, bande, etc. (ex : HTML page)

36 Problèmes spécifiques à la distribution (DS2 : Transparency) Introduction Transparence Accès : ressource locale et distante s'accède de la même manière (ex : sshfs, nfs, SPARC vs x86) Localisation : masque la localisation (ex : URL) Mobilité : masque le mouvement des ressources et des utilisateurs (ex: téléphone mobile) Concurrence : masque la concurrence d'accès aux ressources (ex : database update) Réplication : masque l'utilisation de réplicas (RAID) Panne : masque les pannes et leurs récupérations (mail) Persistence : masque ressource en RAM, disque, bande, etc. (ex : HTML page)

37 Plan Architectures Architectures 37

38 Terminologie (DS1 : 2.2 Architectural Models) L'absence d'horloge globale dans un système distribué impose aux processus de communiquer afin de se synchroniser pourquoi? Architectures

39 Terminologie (DS1 : 2.2 Architectural Models) Les processus communique par l'envoi de messages. On distingue les serveurs : ils offrent un service ils sont passifs, attendant la réception de messages provenant de processus clients les clients : Architectures ils accèdent à des services offerts par des serveurs en envoyant des messages (requêtes) ils sont actifs

40 Terminologie (DS1 : 2.2 Architectural Models) Pourquoi parle t'on de serveur matériel? "Le serveur est tombé en panne" "Il faut augmenter la RAM du serveur" Architectures

41 Terminologie (DS1 : 2.2 Architectural Models) Pourquoi parle t'on de serveur matériel? "Le serveur est tombé en panne" Architectures Dans l'industrie, les processus serveurs sont passifs, mais pas parresseux! Ils fonctionnent en permanence Ils sont souvent critiques On place donc souvent un processus serveur sur une machine dédiée Performance : pas de partage des ressources "Il faut augmenter la RAM du serveur" Sécurité : si la machine plante, un seul serveur est indisponible C'est un abus de langage!

42 Terminologie (DS1 : 2.2 Architectural Models) Quelques exemples : client ftp serveur vsftpd client web firefox, serveur web apache client mail kmail, serveur mail sendmail quid des webmails (ex : gmail)? Un processus client peut réaliser de nombreuses requêtes à différents serveurs wget Architectures 1 requête DNS (minimum) n requêtes HTTP par lien mentionné dans la page

43 Terminologie (DS1 : 2.2 Architectural Models) Architectures Un processus serveur peut être aussi client : client web serveur web serveur base de données Un serveur peut lui aussi faire de nombreuses requêtes client webmail serveur web userdb serveur de mail serveur d'images Il peut donc être tour à tour client de différents serveurs. Un processus est un serveur s'il offre un service spécifique pour des clients potentiels Cela ne l'empêche donc pas d'être un client vis à vis d'un autre service autre que celui qu'il fournit pourquoi cette dernière précision?

44 Terminologie (DS1 : 2.2 Architectural Models) Architectures On distingue les processus qui n'ont pas de rôle particulier vis à vis du service : ils sont à la fois client et serveur du même service C'est le modèle pair à pair (peer2peer) partage de fichiers : emule, BitTorrent partage de CPU : seti@home news : USENET pour la com. inter serveur mail : Mail Transfert Agent pour la com inter serveur téléphonie : Skype Trés efficace pour certaines applications Au cœur de la problématique de la "neutralité du réseau" les FAI cherchent à filtrer

45 Architecture Logicielle (DS1 : 2.2 Architectural Models) Décrit la structure d'un logiciel en terme de module ou de couche d'abstraction. Exemple dans le cas local : Architectures

46 Architecture Logicielle (DS1 : 2.2 Architectural Models) Dans le cas distribué, on définit les éléments suivants : la plateforme Solaris/SPARC, Linux/x86, NetBSD/x86, AIX/Power le middleware CORBA, J2EE,.NET les applications distribuées Architectures

47 Architecture Logicielle (DS1 : 2.2 Architectural Models) Architectures La plateforme fournit le stack TCP/IP, le kernel, le matériel Le middleware s'appuie sur la plateforme pour fournir des abstractions de haut niveaux facilitant le développement d'applications distribuées mécanismes de communication point à point mécanismes de communication groupés mécanismes de connexions vers les bases de données mécanismes transactionnels mécanismes pour l'authentification, l'autorisation...

48 Architecture Logicielle (DS1 : 2.2 Architectural Models) Le middleware est limité: principe du bout à bout certaines applications ne peuvent s'appuyer intégralement sur les services du middleware vérification, correction, sécurité à différents niveaux requièrent l'accès à des données de l'application. Ré implémentation dans l'application Architectures Duplication de code dans le middleware Lire : "End to end arguments in system design", Saltzer et al Tendance aujourd'hui à oublier ce principe L'intelligence n'est pas dans le réseau mais dans les terminaux

49 Architecture Système (DS1 : 2.2 Architectural Models) Architectures Définition des rôles des processus serveur de page web, serveur de base de données, serveur d'authentification,... Placement des processus serveur de page web statiques lecture disque rapide serveur de base de données lecture/écriture rapide serveur d'authentification lecture disque rapide serveur de journalisation écriture disque rapide

50 Architecture Système (DS1 : 2.2 Architectural Models) Modèle client serveur classique (vieux ; )) ex : firefox apache nfsd Quelle est l'architecture logicielle? Architectures

51 Architecture Système (DS1 : 2.2 Architectural Models) Mise en œuvre d'une architecture client/serveur classique Sur un linux : mettez en place les serveurs suivants Web Configuration? Client? PostgresQL Configuration? Clients? SSH Configuration système: /etc/sshd/config user: ~/.ssh/config Clients? Architectures

52 Architecture Système (DS1 : 2.2 Architectural Models) Modèle client serveur multiples ex : DNS, NIS Architectures

53 Architecture Système (DS1 : 2.2 Architectural Models) Serveur proxy et cache Nombreux niveaux de cache en pratique Le proxy permet de partager un cache commun Le proxy permet de filtrer/surveiller (avec un firewall) Architectures

54 Architecture Système (DS1 : 2.2 Architectural Models) Architectures Ajouter un proxy au serveur web précédemment installé proxy : squid Fonction cache configuration client Fonction monitoring/limitation filtre dansguardian règles parefeu requise

55 Architecture Système (DS1 : 2.2 Architectural Models) Pair à pair (peer2peer or p2p) Coordination requise entre les processus Scalabilité? Fiabilité? Architectures

56 Architecture Système (DS1 : 2.2 Architectural Models) Network computers La gestion des applications clientes sur chaque ordinateur clients est un vrai challenge mise à jour, sécurité, bugs, configuration, déploiment, coût, Solution : l'ensemble OS + applications est téléchargé depuis un serveur. Architectures Attention aux vocabulaire : client/serveur = machine/process? Exemple : PXE est installé de base sur la plupart des PC aujourd'hui Permet de démarrer depuis le réseau Un disque dur est il requis? Intéressant?

57 Architecture Système (DS1 : 2.2 Architectural Models) Network computers La gestion des applications clientes sur chaque ordinateur clients est un vrai challenge mise à jour, sécurité, bugs, configuration, déploiment, coût, Solution : l'ensemble OS + applications est téléchargé depuis un serveur. Architectures Attention aux vocabulaire : client/serveur = machine/process? Exemple : PXE est installé de base sur la plupart des PC aujourd'hui Permet de démarrer depuis le réseau Un disque dur est il requis? Intéressant? swap, cache

58 Architecture Système (DS1 : 2.2 Architectural Models) Architectures Clients légers (thin clients): extension du network computer Le client ne comporte plus que le minimum écran, clavier, souris, audio, Les applications s'exécutent sur le serveur Seul l'affichage est réalisé sur le client Avantages Administration réduite au strict minimum Inconvénients Peu adapté à la vidéo en raison du débit requis (réseau) Coût d'acquisition très bas Application locales avec disque dur Ex : X Window (vectoriel), VNC (bitmap)

59 Architecture Système (DS1 : 2.2 Architectural Models) L'architecture X Window Le client envoie des requêtes d'affichage Architectures Le serveur exécute ces requêtes sur l'écran auquel il est connecté Client et serveur peuvent être distant Le client est l'application firefox, xterm, kmail, ex: drawline(blue, 0, 0, 640, 480), print("hello") il tourne parfois sur une machine distante Le serveur est le processus X il tourne généralement sur la machine locale Attention à la terminologie : inverse à l'intuition!

60 Architecture Système (DS1 : 2.2 Architectural Models) Exercice X Windows Connectez vous sur une autre machine Faites en sorte que l'affichage apparaisse sur votre écran en passant par SSH sans passer par SSH Faites en sorte que l'affichage de votre client apparaisse sur l'écran de votre voisin Architectures Pré requis? Danger?

61 Architecture Système (DS1 : 2.2 Architectural Models) Mettez en place un serveur de Thin client Utilisez Linux Terminal Server Project (LTSP) Serveur requis Serveur TFTP boot PXE Serveur DHCP adressage réseau Serveur NFS? applications locales Serveur NIS? Architectures identification partagée

62 Architecture Système (DS1 : 2.2 Architectural Models) Codes mobiles Le client télécharge le code à exécuter depuis un serveur (de code) Le code téléchargé peut utiliser les ressources locales du client (écran, souris, clavier, disque, réseau) interactivité, performance Le code téléchargé peut contacter à son tour d'autres serveurs Le code téléchargé peut devenir un serveur à son tour Architectures Des idées d'exemples?

63 Architecture Système (DS1 : 2.2 Architectural Models) Codes mobiles Le client télécharge le code à exécuter depuis un serveur (de code) Le code téléchargé peut utiliser les ressources locales du client (écran, souris, clavier, disque, réseau) interactivité, performance Le code téléchargé peut contacter à son tour d'autres serveurs Le code téléchargé peut devenir un serveur à son tour Architectures Des idées d'exemples? Les vers/virus et autres piraterie! ; ) Applets, javascript, flash,...

64 Architecture Système (DS1 : 2.2 Architectural Models) Architectures Quelques exemples de migration migration d'objets /pages : quand une thread référence un objet/une adresse mémoire qui n'est pas présente, on rappatrie l'objet/la page, avant de continuer migration de flux : une thread continue son exécution sur une autre machine lors d'un appel de procédure/méthode distant migrationde threads : la thread stoppe son exécution à la demande (extérieure), son contexte d'exécution est transféré sur un autre serveur, puis redémarrée par ce dernier. Problèmes de sécurité évidents

65 Migration d'objets TCP RMI o.m( ) Migration de flux (faible et proactive) Migration de threads (forte et réactive)

66 Plan Communications Communications 66

67 Topology Réseau II. History/Network (

68 Communication point à point Logiciel Logiciel Périphérique réseau Périphérique réseau Réseau

69 Communications Communication point à point? Abstraction :

70 Datagrammes Communiquer = envoyer des données Une trame : Communications Un paquet de bits Que doit contenir une trame?

71 Trame : contenance Communications Source : de qui provient la trame Destination : à qui cette trame est destinée? Données : les données à transmettre

72 Exemple : le protocole Ethernet Protocole standard très utilisé Communications Type anneau 10 Mb/s, 100 Mb/s, 1 Gb/s, 10Gb/s Bon rapport qualité prix Une carte ethernet = un numéro MAC Attribué par le constructeur /sbin/ifconfig donne le numéro MAC

73 Protocole Ethernet Une trame ethernet contient (entre autres) : Communications Le numéro MAC source Le numéro MAC destination Les données à transférer Simplicité du protocole (modèle humain) On prend la parole S'il y a collision, on recommence plus tard

74 Communications Autres protocoles Token ring ATM Infiniband PPP, SLIP (ligne téléphonique)...

75 Problèmes rencontrés Taille des données limites de taille des trames notion de datagramme Communications paquet de données = tableau d'octets découpage en trames de taille convenable Ethernet permet à une machine d'envoyer une trame à une autre machine du même réseau En faite, communication de carte réseau à carte réseau Quel intérêt pour une machine d'avoir plusieurs cartes réseau?

76 Communication inter-réseaux Communications Différence entre un internet et l'internet un internet : un réseau de réseaux Internet : le réseau des réseaux à l'échelle mondiale Intranet : réseau interne à une entreprise Extranet : exportation sécurisée d'un intranet?

77 Problèmes liés aux communications internet Hétérogénéité des réseaux Adressages différents Communications Routage numéro MAC sur Ethernet pour envoyer un paquet sur un autre réseau, quelle route prendre? Passage à l'échelle : nommage comment trouver une ressource du réseau global?

78 Solution : protocole universel Transfert de datagrammes (paquets) Adressage universel Communications Association adressage physique/logique ARP/RARP (Unix : arpwatch) Notion de passerelle (gateway) Existe sur plusieurs réseaux Elle s'occupe du découpage en trames de taille convenable Notion de routeurs S'occupe de transmettre un datagramme d'un réseaux à un autre

79 Communications Communication point à point Logiciel Logiciel Protocole Universel Protocole Universel Périphérique réseau Périphérique réseau Réseau

80 Architecture en couche ( II. History/Network On divise le système réseau en couches À l'intérieur de chaque couche une ou plusieurs entités implémentent sa fonctionnalité Chaque entité interagit directement avec la couche immédiatement en dessous et fournit des fonctionnalités à la couche immédiatement au dessus Les protocoles permettent à une entité d'une machine d'interagir avec l'entité correspondante de même niveau d'une autre machine

81 Architecture en couche ( II. History/Network Abstraction: Communication de processus à processus Implementation: Communication de couche à couche

82 Routage Communications Différencier les messages destinés : au réseau local, à l'extérieur du réseau local Algorithmique compliqué Quelle route est la plus efficace?

83 Le nommage Communications Adressage numérique Idéal pour les machines Fastidieux pour les humains Associer un nom à une adresse Statiquement Dynamiquement

84 Exemple : Le protocole Internet IP (Internet Protocol) Communications Origine Arpanet (1970!!) : Defense Advanced Research Agency : USA Adressage IPv4 : 32 bits ~ 4 Milliards de machines insuffisants aujourd'hui IPv6 : 128 bits ~ adresses! ICMP : protocole de vérification des datagrammes

85 Internet Topology ( ) Communications Asia Pacific Europe Middle East Central Asia Africa North America Latin American Caribbean RFC1918 Unknown

86 Adressage IPv4 Numéro IP : w.x.y.z Communications Associé à un périphérique réseau et non à une machine!! 0 w,x,y,z 255 Nommage dynamique : DNS Notion de domaine Notion de hiérarchie

87 Applications Communications Nslookup/host Quel nom est associé à une adresse? Quelle adresse est associée à ce nom? Ping Une adresse répond-elle? Traceroute Utilisation du TTL (Time To Live)

88 Question Pourquoi parle t'on des protocoles bas niveaux dans un cours sur les systèmes distribués? Communications La transmission de datagrammes illustre quelques uns des problèmes inhérents aux systèmes distribués Les propriétés de la transmission de datagrammes des protocoles bas niveaux affectent les protocoles de plus haut niveau Terminologie indispensable

89 Problèmes liés au protocole universel Plusieurs processus au sein d'un même système Communications Système multi tâches Qui doit recevoir les requêtes : Serveur Web? Serveur FTP? Serveur de courrier? ICMP ne possède pas ce problème Une erreur réseau s'adresse au gestionnaire de réseau et non à un processus

90 Solutions : protocole datagramme Communications Communications en mode messagerie (datagramme) Notion de ports

91 Notion de ports Le système maintient une table d'association port serveur Communications Comment un client connaît il le port d'un serveur? Certains ports doivent être standardisés UNIX : /etc/services Serveur de recherche (lookup) dilemme de la poule et de l'oeuf Ex : SUN RPC portmapper

92 Communications Communication point à point Logiciel Logiciel Protocole datagramme Protocole datagramme Protocole Universel Protocole Universel Périphérique réseau Périphérique réseau Réseau

93 Communications Exemple : UDP Utilise le protocole IP Mode datagramme (User Datagramme Protocole) Apporte la notion de port Au dessus de IP : UDP/IP

94 Les couches à l'œuvre Exemple: UDP Communications Application Layer Data Transport Layer UDP UDP Data Header Network Layer Link Layer IP Header Frame Header IP Data Frame Data Frame Trailer

95 Communications Exemple UDP : Bonjour Monde Développer en Java un programme qui envoi "Bonjour monde" à un autre programme en utilisant le protocole UDP. Le programme "receveur" doit afficher ce qu'il reçoit.

96 Remise de projets : Attendu Envoyer un fichier archive nom tpx.tar.gz le contenu doit être votre projet eclipse bin/ contient tous les *.class src/ contient tous les *.java Packaging java : tout est dans un package exo En général : exo.server et exo.client java cp bin/ exo.server et java cp bin/ exo.client doivent afficher l'usage Attention à la date limite Tester votre projet avant de l'envoyer!! Processus de test à mettre en place...

97 Bonjour Monde : remarques Qui est le serveur? Communications On considère qu'il n'y a pas de serveur : un serveur doit être capable de répondre à plusieurs requêtes en séquences! Mode de communication inter processus

98 Bonjour Monde : remarques générales Communications On vérifie que les paquets UDP transitent sur le réseau Unix : tcpdump :tout ce que reçoit la carte ethernet est affiché (mode privilégié) WindowsNT/Unix : netstat : informations réseau

99 Communications Exemple UDP : unidirectionnel Un programme lit en boucle une chaîne de caractères sur la console et la transmet à un autre programme L'autre programme reçoit en boucle une chaîne de caractères et l'affiche sur la console "clientquit" arrête le client et "serverquit" arrête le serveur

100 Unidirectionnel : remarques conceptuelles Communications Qui est le client, qui est le serveur? client : le lecteur serveur : l'afficheur sur console Quel est le type de service que le serveur implémente? Service d'affichage de chaîne de caractères sur console à distance Une chaîne transmise = une requête Pourquoi la boucle est nécessaire? pouvoir répondre à plusieurs requêtes (= serveur)

101 Unidirectionnel : remarques Java Emission/Réception dans un buffer de taille fixe Communications Attention à la réception : un tableau est toujours plein (même de zéros) Solution moche : enlever les caractères non affichable aux extrémités String.trim() Solution propre : utiliser le nombre d'octets réellement reçu DatagramPacket.getLength(). Ne pas envoyer "clientquit" au serveur

102 Unidirectionnel : observations Démarrez deux clients simultanés sur le même serveur Communications Des ports différents sont automatiquement assignés aux clients UNIX : tcpdump, netstat, fuser; ps

103 Unidirectionnel : problèmes Communications Que se passe t'il si l'on envoie une phrase qui contient plusieurs lignes? L'envoi de plusieurs paquets ne constitue pas une action atomique Des paquets de clients différents peuvent se mélanger ordonnancement des évènements

104 UDP : subtilités Communications Une opération réseau peut être bloquante : Envoyer un paquet UDP est une opération non bloquante Recevoir un paquet UDP est une opération bloquante Attention au problème d'échelle : Les opérations d'entrées/sorties peuvent être considérées comme "bloquantes" comparées aux opérations de calculs Rigoureusement, seule la réception est bloquante : celle ci pouvant ne jamais arriver!

105 UDP : interbloquage Communications Lorsque deux machines tentent de recevoir un paquet UDP l'une de l'autre en même temps! Solutions : Concevoir son système pour éviter cette situation Utiliser un dépassement de délai (time out) à la réception Utiliser les threads

106 Communications Exemple UDP : serveur echo Le client lit en boucle une chaîne de caractères sur la console et la transmet au serveur Le serveur reçoit en boucle une chaîne de caractères, l'affiche sur la console, et la renvoie au client "clientquit" arrête le client et "serverquit" arrête le serveur

107 Serveur echo : remarques Java Communications Réutilisation de l'objet DatagramPacket Chaque datagramme est "routé" séparément Réutilisation du buffer de réception en buffer d'émission (echo)

108 Serveur echo : problèmes Communications Interbloquage possible : "serverquit" arrête le serveur qui ne répond plus au client le client attend la réponse du serveur (opération bloquante)! Solution : Le serveur répond au client juste avant de s'arrêter Le client vérifie que la chaîne envoyée au serveur est "serverquit" et n'effectue pas de réception.

109 Communications Étude de cas : banque en ligne Supposons qu'il nous est demandé de concevoir un système distribué pour obtenir des soldes de comptes en banque On dispose d'un serveur qui gère les noms, les mots de passe et les soldes de comptes Principe : à un couple (nom, mot de passe) correspond un solde à afficher sur le client

110 Étude de cas : banque en ligne Communications Concevoir un système distribué, incluant le protocole pour la communication entre un client et ce serveur : Comment le serveur authentifie le client? Quelles sont les données à échanger Dans quel ordre les messages doivent être envoyés? Comment l'état est maintenu entre le client et le serveur?

111 Étude de cas : banque en ligne Communications Solution simple : Client : hello Serveur : login? Client : un nom d'utilisateur Serveur : passwd? Client : un mot de passe Serveur : le solde correspondant

112 Étude de cas : banque en ligne Communications Quels sont les problèmes liés à ce protocole? Clients multiples Recouvrement en cas d'erreur Sécurité

113 Étude de cas : banque en ligne Comment étendre ce protocole pour permettre Comptes multiples Transfert d'argent inter comptes Communications

114 Communications Problèmes avec le mode datagramme Le développeur doit s'occuper de : Datagrammes perdus Datagrammes dupliqués Datagrammes corrompus Datagrammes arrivés dans le désordre Control du flux Le client envoi les données plus rapidement que le serveur ne peut les traiter

115 Problèmes avec le mode datagramme Communications L'abstraction datagramme utilisateur n'est pas pratique à utiliser pour des petites ou des grandes tailles L'envoi de paquets de petites tailles n'est pas efficace Bufferisation L'envoi de paquets de grandes tailles peuvent être refusé Découpage en paquet plus petits Doit on résoudre chacun de ces problèmes à chaque écriture d'une application?

116 Communication en mode connecté Principes : Une connexion est établie entre deux logiciels Communications utilisation des ports Une fois la connexion établie, le protocole peut fournir certaines garanties

117 Garanties Fiabilité Communications Gestion des paquets perdus, corrompus, dupliqués, arrivés dans le désordre Flux de données La communication n'est plus en mode datagrammes On peut envoyer des données en continue Découpage des données en datagrammes Plus de problèmes de petite ou de grande tailles

118 Garanties Mode bidirectionnel Communications Sécurité On peut envoyer et recevoir des données par la même connexion Les données sont encryptés/décryptés...

119 Communications Fiabilité Solution : Les messages dupliqués sont éliminés Si les messages arrivent dans le désordre, le receveur attend l'arrivé du premier message Chaque envoi de message donne lieu à un accusé de réception Si l'accusé n'est pas reçu, le message est renvoyé Somme de contrôle pour éliminer les messages corrompus

120 Flux de données Communications Solution : Un flux de données de A à B Un flux séparé de données de B vers A Full-duplex : transmission et réception dans les deux directions simultanées Découpage en datagrammes de taille fixes Buffering : mise en file d'attente

121 Abstraction Communications Comment se situe le protocole mode connecté dans notre architecture en couche? Approche radicalement opposée au mode messagerie (datagramme) Notion de flux bi directionnel

122 Communications Architecture en couche Logiciel Logiciel Protocole Mode connecté Protocole Mode connecté Protocole Universel Protocole Universel Périphérique réseau Périphérique réseau Réseau

123 Mode connecté Deux entités établissent une connexion: Si A souhaite ouvrir une connexion vers B Communications A envoie un message Synchronize à B B répond à A par un accusé de réception et un message de synchronisation A répond à B par un accusé de réception A et B sont en accord pour communiquer Protocole similaire pour la déconnexion

124 Communications Mode connecté Deux entités seulement Les messages d'autres entités ne peuvent pas être mélangés Les protocoles en mode connecté sont moins compliqués à utiliser que ceux en mode datagramme Performance moindre!!

125 Modèle client/serveur en mode connecté Communications Le serveur ouvre une socket d'écoute sur un port Il attend une requête de clients Il créé une connexion en ouvrant une nouvelle socket sur un port libre, connectée à la machine cliente distante sur le port spécifié par le client Cette socket est utilisée pour les communications

126 Exemple : TCP Communications Utilise le protocole IP Mode connecté (TCP : Transport Connected Protocol) Garanties offertes : Fiabilité Bidirectionnel Flux de données Sécurité (checksum)

127 Exemple TCP : TimeServer Communications Développer en Java un serveur TCP qui affiche l'heure toutes les n secondes (paramétrable) Tester le serveur avec un client adéquat Client "maison" Telnet Tester le serveur avec plusieurs clients simultanés

128 TimeServer : remarques Java Java : les classes d'entrées/sorties (I/O) *Reader/*Writer vs *InputStream/*OutputStream stream Communications flux d'octets, générique : pour lire/écrire n'importe quoi reader/writer flux de caractères encodage/décodage Unicode prise en compte de la plateforme exemple : \n sous Unix = \n\r sous Windows

129 TimeServer : remarques Java Communications Le serveur doit utiliser des flux de type caractères PrintWriter : println() flush automatique après newline() gestion des erreurs réseau "à l'ancienne" BufferedWriter : Pas de println() flush manuel gestion des exceptions classiques

130 TimeServer : remarques Java Communications Arrêt du client non intégré au protocole l'arrêt brutal implique une gestion particulière de l'exception correspondante Attention à la bufferisation flush() manuel Penser au newline() à la place de "\n" Indépendance vis à vis de la plateforme notion d'encodage Sécurité : socket.shutdowninput() Le serveur ne doit pas recevoir de données

131 TimeServer : remarques générales Communications Avantages du mode connecté Mode connecté (!) Flux de données Problèmes : Gestion des clients multiples concurrents Solution(s)? threads

132 Concurrence : notion de threads Communications Concurrence!= parallèle concurrent : le processeur partage le temps d'exécution des processus parallèle : les processus s'exécutent dans la même durée de temps (multi processeur) Plusieurs processus dans le système s'exécute en concurrence : système multi tâches Plusieurs threads au sein d'une application : application multi threadée Thread utilisateurs!= threads noyaux Ordonnancement

133 Threads : pour et contre Communications Pour : Gestion rapide (comparé aux processus) Expressivité Contre : Sémantique plus compliqué que les processus Adressage partagé Alternative : nombreuse!! En pratique : évènements Lire : [von behren et al. 2003] Why Events Are A Bad Idea

134 Exemple TCP : TimeServerMultiThread Communications Développer en Java un serveur TCP multithreadé : qui affiche l'heure toutes les n secondes (paramétrable) capable de répondre à plusieurs clients simultanés. Tester le serveur avec plusieurs clients simultanés

135 Exemple TCP : talk Communications Développer en Java l'utilitaire Unix talk : Une personne A désire communiquer avec une autre personne B sur le réseau A lance un talk en précisant la machine de B Tout ce que A tape au clavier s'affiche chez B et vice-versa

136 Talk : modélisation Communications System.out System.out Socket.in Socket.in Talk Talk Socket.out Réseau System.in Socket.out System.in

137 Talk : remarques Java Un serveur et potentiellement plusieurs clients Problèmes avec System.in et System.out Communications Solutions : fenêtrage Utilisation de Swing (JFC)

138 Talk fenêtré : remarques Java Attention au problème Swing/Thread JTextArea Communications L'un en écriture Son contenu doit être envoyé sur le réseau : interface Document L'autre en lecture Son contenu doit être mise à jour en fonction des messages réseaux :thread de lecture Mise en place d'un protocole de communication Problème de la terminaison doit faire partie intégrante du protocole

139 Talk : remarques générales Communications Avantages du mode connecté Mode connecté (!) Flux de données Mode bidirectionnel Fiabilité

140 Architecture en couches Communications Logiciel Protocole Datagramme Logiciel Protocole Datagramme Protocole Connecté Protocole Connecté Protocole Universel Protocole Universel Périphérique réseau Périphérique réseau Réseau

141 Communications La norme OSI/ISO OSI : Open System Interconnexion ISO : International Standard Organization Année 70 (?) Résultant des différents types de réseaux propriétaires incompatibles entre eux Modèle d'architecture réseau décomposé en sept couches Chaque couche correspond à un service particulier et doit masquer les détails aux couches supérieures

142 Network OSI Model II. History/Network X.25 follows the OSI Model Internet (TCP/IP) does not!!

143 Les couches de la norme OSI/ISO Communications 7 Couches hautes Couches basses 3 2 1

144 Les couches basses de la norme OSI/ISO Communications couche physique : transfert de bits logique câblée exemples : modems, ADSL,... couche liaison : Gestion de la connexion entre entités du réseau Gestion des erreurs de la couche 1

145 Les couches basses de la norme OSI/ISO Communications couche réseau : Acheminer les données de la couche 4 à l'utilisateur final en passant par des passerelles ou des routeurs. adressage, routage, contrôle de flux, détection et correction d'erreurs de la couche 2 couche transport : transfert de données transparents entre entités de session. Optimiser l'utilisation des infrastructures mode connecté et non connecté

146 Les couches hautes de la norme OSI/ISO Communications couche session : fournir aux entités de la couche présentation les moyens d'organiser et de synchroniser les échanges de données Différence avec une connexion de la couche transport : plusieurs sessions peuvent être ouvertes (séquentiellement) sur une même connexion (base de données/terminal banquaire) Reprise transparente d'une session après une coupure de connexion

147 Les couches hautes de la norme OSI/ISO Communications couche présentation : syntaxe et sémantique des informations transportées représentation : BigEndian/LittleEndian, compression/cryptage couche application : fournir tous les services directement utilisables : transfert d'information, allocation de ressources, intégrité et cohérence des données reçues, synchronisation d'applications coopérante

148 Communications Différence avec l'architecture TCP/IP

149 Les protocoles de plus haut niveau Communications FTP File Transfert Protocol : transfert de fichier deux sockets TCP : commandes et données DNS Domain Name Server : résolution de noms protocole UDP WAP Wireless Application Protocol : "Web pour téléphone mobile" TCP

150 Les protocoles de plus haut niveau Communications RPC Remote Procedure Call : appel de procédure à distance UDP ou TCP (suivant implémentation) Network File System : Système de fichiers accessible à distance Utilise RPC NFS NIS Network Information System : "pages jaunes" Utilise RPC

151 Le protocole HTTP HyperText Transfert Protocol protocole de transfert d'hypertexte Origine : 1990 au CERN! Communications Protocole du WWW WWW Internet Protocole simple à base textuelle Utilisé pour transmettre des données textuelles ou binaires Page HTML (texte) ou image (binaire) le plus souvent

152 Communications Session HTTP Connection TCP/IP Browser > Serveur Web : <GET, /index.html> Serveur Web > Browser : <OK, contenu de index.html> Fin de connection TCP/IP

153 Session HTTP : Requête : GET /chemin/fichier HTTP/1.0 Communications Infos (Type de connection, browser, système,...) Type de données à recevoir Une ligne vide Réponse : HTTP/ OK Infos (Connexion, type de serveur, type de données envoyées) Une ligne vide Le contenu de la requête (fichier HTML, image, son,...)

154 Envoi de données à un serveur WEB Deux solutions : GET : l'url contient les données: Communications POST : Les données sont transmises dans l'en-tête

155 Exercice : serveur HTTP Communications Ecrire un mini-serveur HTTP en Java Le serveur ne doit comprendre que les requêtes de type GET Il renverra au client le fichier demandé Attention, les chemins devront être absolus GET /etc/wgetrc HTTP/1.0 doit renvoyer le contenu du fichier /etc/wgetrc Quels clients utiliser pour tester notre serveur? Tout client HTTP Telnet,Firefox, Chrome,......

156 serveur HTTP : remarques Java Communications Requête : Utiliser BufferedReader pour lire la requête Manipulation de texte : StringTokenizer Fin de requête == ligne vide == ligne de longueur nulle (!= "\n") Réponse : Utiliser BufferedOutputStream pour la réponse flush()

157 serveur HTTP : remarques générales Communications Attention au protocole Syntaxe Code d'erreur Trou de sécurité! Solutions?

158 Plan RPC/RMI RPC/RMI 158

159 Appel de procédure à distance Simplifie les interactions entre systèmes distribués Il n'y a plus de notion de communication RPC/RMI Ni en mode datagramme Ni en mode connecté Le développeur effectue un appel de procédure standard Le système se charge de transformer cet appel de procédure en communication réseau

160 Problèmes Gestion des erreurs Différencier celles liées au réseau Liées à l'appel lui même RPC/RMI Garanties Appel perdu Paramètres corrompus Appel dans le désordre Gestion de la concurrence

161 Problèmes : Passage des paramètres Par copie Marshalling Problème de cohérence RPC/RMI Ordre binaires Cohérence des données de type référence Modifications effectuées par le serveur non répercutées sur le client et vice versa Par référence Mémoire virtuellement partagée Matérielle Logicielle

162 Exemples : SUN RPC Utilise le protocole XDR pour le marshalling NFS, NIS : utilise les SUN RPC Portmap : nommage XML RPC RPC/RMI Utilise XML pour le marshalling Simple Object Access Protocol (SOAP) Microsoft/IBM Attention : le terme RPC est utilisé pour désigner à la fois le concept et l'implémentation

163 Invocation de méthode à distance Extension du mécanisme RPC au concept objet Beaucoup de langages sont orientés objets Un appel de méthode est conceptuellement équivalent à un envoi de message RPC/RMI Extension naturelle aux systèmes à objets distribuées Permet à des objets distribués sur tout un parc de stations de communiquer naturellement

164 Invocation de méthode à distance Abandon du mode client/serveur Les objets communiquent entre eux par passage de messages qu'ils soient locaux ou distants Localisation transparente RPC/RMI Il est inutile de connaître l'emplacement réel d'un objet

165 Localisation transparente Facilite la programmation Fiabilité si la machine qui héberge un objet tombe en panne, on déplace l'objet sur une autre machine Performance RPC/RMI si la machine qui héberge l'objet ne peut plus supporter de nouveaux clients, on réplique l'objet sur une nouvelle machine Mais tout n'est pas si simple!!

166 Principe A l'exécution, certains objets sont locaux, et d'autres sont distants RPC/RMI Si une méthode est invoquée sur un objet distant, un appel de méthode à distance est effectuée La localisation de l'objet distant détermine la destination de l'appel de méthode à distance

167 Principe RPC/RMI Utilisation des interfaces Un objet distant déclarent l'ensemble des interfaces distante qu'il implémente Chaque interface définie l'ensemble des méthodes qu'il est possible d'invoquer sur les objets qui l'implémente

168 Principe Est il possible de spécifier des champs accessible à distance? RPC/RMI

169 Est il possible de spécifier des champs accessible à distance? Raisons liées à la notion d'interface pas de champs dans les interfaces Raisons liées à la distribution modification directe d'un champ non contrôlable RPC/RMI Utilisation des objets fragmentés Stubs, Skeleton et Proxy

170 Principe : Stubs, Skeleton et Proxy Les interfaces distantes sont utilisées pour générer du code RPC/RMI Stub : partie côté client chargée de transformer les appels de méthodes en communication réseaux Skeleton : effectue l'opération inverse sur le serveur et appel la méthode correspondante de l'objet distant Proxy :partie côté cliente représentant l'objet distant et qui peut répondre à une requête localement où transmettre la requête sur le réseau. Un stub est un cas particulier de proxy dont la fonction est de transmettre toutes les requêtes sur le réseau

171 Principe : Stubs, Skeleton et Proxy F(X) Y=mar(X) send(f,y) Z=unmar(Y) Client Stub (proxy) F(Z) Serveur Skel JVM JVM

172 Nommage et recherche Comment les objets distribués se trouvent ils entre eux? Le nommage permet d'associer à un objet distant : RPC/RMI Un nom : "Printer" Des attributs : "Color, A4" La recherche permet de trouver un objet en fonction de certains paramètres (nom, attributs,...) Un serveur connu de tous est dédié à cette tache : c'est le Naming Service

173 Standards : Java RMI (Sun) Serialisation Standard Java Propriétés : rmic, rmiregistry, DGC RPC/RMI Corba (OMG) Neutre vis à vis du langage et du système Notion de services (CORBA Naming Service) Utilisé dans l'industrie? COM/DCOM (Microsoft) Standard du monde Microsoft exclusivement

174 Exemple : Java-RMI Utilise TCP/IP Peut utiliser HTTP pour passer un firewall Utilise le méchanisme de Serialisation Java pour copier les arguments RPC/RMI Passage par copie et par référence suivant la nature distante de l'objet Ramasse miettes distribués (compteur de références et leasing (bail))

175 Serialisation Les objets Java qui implémente l'interface (vide) java.io.serializable peuvent être serialisé Sauvegarde sur disque Tolérance aux pannes RPC/RMI Sauvegarde dans une base de données Persistance Envoi sur le réseau Migration d'objets

176 Exemple Serialisation : PersonsManager Ecrire en Java une application capable d'enregistrer dans un fichier des personnes RPC/RMI Une personne est définie par les champs : firstname (prénom) lastname (nom de famille) birthdate (date de naissance) L'application doit pouvoir retrouver ces informations après un arrêt. (persistance)

177 PersonsManager : remarques Java Création d'un objet de type Person Doit implémenter java.io.serializable Utiliser ObjectOutputStream pour écrire et ObjectInputStream pour lire Attention : stream = flux RPC/RMI Pas d'accès direct Pas d'ajout en fin Faire le travail en mémoire Lire le fichier à l'initialisation Sauvegarder à la terminaison

178 PersonsManager : subtilités problèmes avec les classes internes (inner classe) Pas toujours Serializable Efficacité en temps et en espace sauvegarde de la classe mère Serialisation de la classe Date inefficace Serialisation spécialisée RPC/RMI

179 Java-RMI : Passage par copie Les objets qui implémentent l'interface (vide) java.rmi.remote sont distants Ces objets sont passés par références lors d'invocation de méthode à distance RPC/RMI Les autres objets sont passés par copie En réalité, tous les objets sont passés par serialization Les objets distants redéfinissent leur serialisation pour passer leur Stub à leur place!

180 Exemple Java-RMI : Bonjour Monde RPC/RMI Écrire en Java RMI : Un objet distant qui possède une méthode retournant la chaîne de caractère "Bonjour Monde" Un client qui appelle cette méthode à distance et l'affiche

181 Java-RMI : Bonjour Monde Schéma HelloWorldImpl exportobject() RPC/RMI JVM HW_Stub Client rmiregistry JVM JVM

182 Java-RMI : Bonjour Monde Schéma HelloWorldImpl Client rebind() JVM RPC/RMI foo HW_Stub rmiregistry JVM JVM

183 Java-RMI : Bonjour Monde Schéma HelloWorldImpl Client JVM foo RPC/RMI HW_Stub rmiregistry JVM JVM

184 Java-RMI : Bonjour Monde Schéma HelloWorldImpl Client JVM lookup() RPC/RMI foo HW_Stub rmiregistry JVM JVM

185 Java-RMI : Bonjour Monde Schéma HelloWorldImpl Client JVM RPC/RMI foo getstring() HW_Stub rmiregistry JVM HW_Stub JVM

186 Java-RMI : Bonjour Monde RPC/RMI Où est le stub? depuis le jdk 1.5, le stub est automatiquement généré : il est retourné par l'appel UnicastRemoteObject.exportObject(r, 0); il fallait le générer auparavant à l'aide d'un compilateur spécial : 'rmic' On peut observer son code à l'aide de la commande : 'rmic keep'

187 Exemple Java-RMI : Gestionnaire d'utilisateurs Écrire en Java RMI Un objet distant capable de gérer des informations sur des utilisateurs (nom, prénom, date de naissance,...). Un client peut enregistrer une nouvelle personne RPC/RMI il récupère un identifiant unique Récupération de la liste complète des personnes enregistrées Un client peut récupérer une personne donnée pour un identifiant précis et la mettre à jour

188 RMI : Gestionnaire d'utilisateurs : architecture Le client et le serveur doivent partager du code! Interface RMI Implémentée par le stub pour le client Implémentée par le serveur La classe personne RPC/RMI Pour le client et le serveur Le client n'a pas besoin de la classe serveur Le serveur n'a pas besoin de la classe client Séparation des CLASSPATH Génération de jar files (fichier jar ~ fichier zip)

189 Gestion des classpath : jar jar : même syntaxe que la commande 'tar' UNIX RPC/RMI jar cvf /tmp/client.jar client jar cvf /tmp/server.jar server jar cvf /tmp/common.jar common Au lancement, on précise le classpath java classpath /tmp/common.jar:/tmp/client.jar client.main Commande serveur : attention au rmiregistry java.rmi.server.codebase requis! Security Manager requis! java.security.policy requis!

190 RMI : Gestionnaire d'utilisateurs : Serveur Problématique : génération d'id unique? UUID simple mais peu lisible int lisible, mais unicité? accès concurrents? RPC/RMI retourner une liste à un client? utiliser des verrous copie requise? Passage par copie (serialisation) update vérifier que l'id donné existe! sécurité!

191 Gestionnaire d'utilisateurs : remarques Problématique de mise à jour ajout d'une méthode au serveur RPC/RMI Recompilation, re génération du 'jar', déploiment sur les clients du common.jar Regénération du stub (plus requis jdk >= 1.5) Rebinding requis ajout d'un champ à la classe Person Le client doit avoir accès à la nouvelle classe. recompilation, re génération du 'jar' et déploiment sur les clients. Interruption du serveur requise? Pas toujours (compatibilité ascendante Person)

192 Gestionnaire d'utilisateurs : remarques Protocole sous jacent : TCP Gestion des exceptions réseaux Gestion des clients simultanés RPC/RMI Tolérance aux pannes Threads et RMI : pas de garanties données par RMI sémantique des appels RMI? sémantique at most once (cf DS1: 5.2.4) un appel est exécuté au plus une fois. Attention, CORBA et Sun RPC propose d'autres sémantiques.

193 Gestionnaire d'utilisateurs : remarques Comment implémenter la persistence des données? pour un très grand nombre de personnes? Comment assurer la sécurité? RPC/RMI un client devrait s'authentifier pour pouvoir faire un update() (accès en écriture) avec une base de données gestionnaire d'authentification/identification Comment assurer l'intégrité des données? un update() ne devrait jamais être fait à moitié utilisation des transactions

194 Exemple Java-RMI : ChatServer RPC/RMI Écrire en Java RMI un serveur de 'chat' et son client Chaque client attend qu'un utilisateur tape une ligne au clavier Lorsque la ligne est entrée, le client en informe le serveur Le serveur en informe alors tous les autres clients qui affiche la ligne.

195 ChatServer : remarques Différence conceptuelle entre client/serveur classique client/serveur liée à la notion de service RPC/RMI Callbacks : "appelle moi quand c'est prêt!" le client est en réalité à la fois client et serveur Le serveur est à la fois serveur et client

196 ChatServer Architecture Logicielle Conception des interfaces distantes RPC/RMI Diagramme de classes Définir une interface Message dont l'implémentation n'est pas connue du serveur (téléchargement de code requis). Séparation des classpath Que doivent contenir les jar common, client et server? Attention à la spécification du java.rmi.server.codebase. Security Manager indispensable.

197 Plan EJB EJB :: introduction introduction Basé sur le cours de M. Buffa composants_distribu%c3%a9s_pour_l%27entreprise_%2f %2F_EJB_

198 EJB : introduction Motivation Les RPC/RMI facilitent le développement d'applications distribuées Mais ce n'est pas suffisant Seul la communication entre composants est assurée Autres problématiques gestion de la charge (concurrence), gestion des pannes, persistence, transaction, monitoring, sécurité, C'est l'objet d'un middleware

199 Motivation EJB : introduction Dans le passé, la plupart des entreprises programmaient leur propre middleware. Adressaient rarement tous les problèmes, Gros risque : ça revient cher (maintenance, développement) Orthogonal au secteur d'activité de l'entreprise (banque, commerce ) Pourquoi ne pas acheter un produit? Oracle, IBM, BEA proposent depuis plusieurs années des middleware Aussi appelés serveurs d'application.

200 Motivation Explosion du nombre de middlewares Propriétaires et Inter opérabilité limitée EJB : introduction À l'encontre du crédo Java : "Write Once, Run Anywhere" EJB : Enterprise Java Beans Attention : Rien à voir avec les Java Beans!! Standard qui définit une architecture de composants serveur écrits en Java EJB = une spécification + un ensemble d'api Alternatives : ruby on rails, spring, python turbo gears,...

201 Caractéristiques EJB EJB : introduction Attention, les EJB ne fournissent pas de GUI C'est plutôt le rôle des Java Beans Le GUI est côté client Application classique (Applets) Servlets/JSP (dans le standard J2EE) Approche Modèle/View/Controller (MVC)

202 EJB : introduction J2EE