SYSTÈMES RÉPARTIS
heithem.abbes@gmail.com2015-16
Introduction au systèmes
répartis
Système centralisé
4
 Tout est localisé sur la même machine
 1 processeur : une horloge commune
 1 mémoire centrale : u...
Emergence du réparti
 Evolution technologique
 machines
 de plus en plus performantes avec une baisse des
prix
 Équipe...
Systèmes répartis (1/3)
 "Un ensemble de machines connectées par un
réseau, et équipées d’un logiciel dédié à la
coordina...
Systèmes répartis (2/3)
7
 Types de ressources
 Calcul
 Stockage
 Electronique
 capteur, satellites, scanneurs, …
 A...
Systèmes répartis (3/3)
 Fonctionnement collaboratif: des traitements
coopérants sur des données réparties pour
réaliser ...
Caractéristiques (1/2)
9
 Absence d’état global
 Pas de référence spatiale commune à cause de
l’absence (dans la majorit...
Caractéristiques (2/2)
10
 Architecture matérielle
 Multi-processeurs à mémoire
partagée
 Clusters (grappes) d’ordinate...
Exemples
 Commerce électronique
 Partage de fichiers (P2P)
 Réseaux sociaux
11
 Grilles informatiques
 Ensemble de re...
Tolérance aux pannes
 Un système réparti doit tolérer la panne des machines :
 Une machine tombe en panne
 Une machine ...
Sécurité
 Confidentialité, Intégrité : Droits d’accès, Pare-Feu
 Non-répudiation (s'assurer qu’un contrat signé via
inte...
Passage à l’échelle (scalability) :
 paramètre primordial pour la durabilité du
système et sa capacité d’évolution en fon...
Nommage et accès
 Comment identifier les ressources distantes et les
retrouver?
 Système centralisé: nommage géré par le...
Déploiement des applications
 Comment installer tous les composants logiciels
de l’application sur les différentes machin...
Applications réparties19
Système vs application
20
 Système : gestion des ressources communes et de
l’infrastructure, lié de manière étroite au ma...
Modèles de répartition
21
 Modèle Client/Serveur
 Modèle de communication par messages
 Modèle de communication par évé...
Modèle Client/Serveur
22
 Client : processus demandant l’exécution d’une
opération à un autre processus
 Serveur : proce...
Modèle de communication par messages
(1/2)
23
 Une application produit des messages (producteur)
et une application les c...
Modèle de communication par messages
(2/2)
24
 Adapté à un système réparti dont les éléments
en interaction sont faibleme...
Modèle de communication par événements
25
 Mode de communication asynchrone et anonyme
 indépendance entre le producteur...
Modèles à mémoire partagée
26
 Objectif:
 Replacer le programmeur dans les conditions d’un
système centralisé :
 utilis...
Modèle à base de composants
27
 Composant : module logiciel autonome et
réutilisable
 possède des entrées/sorties déclar...
Modèle à base d’agents mobiles
28
 Code mobile : programme se déplaçant d’un
site à un autre sur le réseau
 Exemple : un...
Modèle orienté service
29
 Un modèle d'interaction basé sur la notion de
service
 Un service est un composant logiciel e...
Middleware30
Motivations
31
 L’interface fournie par les systèmes
d’exploitation et de communication est encore
trop complexe pour êtr...
Middleware
33
 Un middleware (ou intergiciel) permet le
dialogue entre les différentes entités d'une
application répartie...
Middleware - Fonctions
34
 Masquer l’hétérogénéité (machines,
systèmes, protocoles de communication)
 Fournir une API (A...
Services du middleware
35
 Communication
 permet la communication entre machines mettant
en œuvre des formats différents...
Middleware
36
 Nommage
 permet d'identifier la machine serveur sur laquelle
est localisé le service demandé afin d'en dé...
Types de middleware
37
 Middleware RPC (Remote Proceedure Call)
 RPC de SUN
 Middlewares orientés objets distribués
 J...
Communications38
Présentation
39
 Elément fondamental d’un système réparti
 Plusieurs systèmes séparés physiquement
 Reliés par un résea...
Outils de communication
40
 Problématique
 Réaliser un service réparti en utilisant l’interface de
transport (TCP, UDP)
...
le réseau vu de l’utilisateur
41
 Schéma Client/Serveur
 Machines différentes : client demande un service
fournit par un...
le réseau vu de l’utilisateur
42
 Le serveur (machine physique) peut comporter différents services:
 L’adresse IP du ser...
Prochain SlideShare
Chargement dans…5
×

Introduction aux systèmes répartis

360 vues

Publié le

Ce cours introduit les systèmes répartis. Il met l'accent sur les propriétés, les problèmes et les modèles de répartition.

Publié dans : Formation
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
360
Sur SlideShare
0
Issues des intégrations
0
Intégrations
10
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • et accessible par le programme
  • L’évolution des technologies informatiques au cours des dernières années a entraîné des modifications radicales dans la conception des applications.
  • Une application répartie est une application dont les éléments s’exécutent dans des processus différents ou sur des machines différentes mais surtout sur des machines différentes. 
  • La coopération entre les processus correspond à la communication entre eux et la synchronisation de leurs évolutions. Ceci nécessite:
    la conception d’un modèle d’exécution permettant l’identification des éléments/entités communicants et de leur mode de communication,
    une interface de programmation et des outils de développement pour l’implémentation du modèle conçu et sa mise en place.
    La répartition/la distribution peut concerner les données comme les traitements (tâches).
  • Les réseaux sociaux,
    Video streaming
  • Problèmes liés aux applications réparties
  • Combien de personnes utilisent l’application, qui sont-ils ?
    Nécessité de se protéger contre les intrusions
    Nécessité de stocker les accès des clients dans des fichiers journaux

    Transparence ; L'ISO définit plusieurs transparences
    accès, localisation, concurrence, réplication, mobilité, panne, performance, échelle

    Abstraction
    Séparation interface/réalisation : accès à un service via une interface d’accès en faisant abstraction à son implémentation.
  • Ce qui marche pour un objet, marchera-t-il pour des millions ?
  • Un objet = un identifiant + un état + un comportement.

    Système centralisé: nommage géré par le langage (référence) ou par le système d’exploitation (adressage).
    (Java Naming and Directory Interface), LDAP :

    Nommage explicite ou dynamique
    explicite : l’administrateur se charge de l’ajout d’une nouvelle machine au système
    dynamique : le système réparti permet un ajout dynamique des machines sans passer par l’administrateur
    Exemples : DNS, URL, JNDI, LDAP, ...
  • Intégration de l’existant (Legacy)
  • La distinction n’est pas toujours évidente, car certaines applications peuvent directement travailler à bas niveau (au contact du matériel).
    Exemple : systèmes embarqués
  • Le modèle client-serveur de base met en jeu un processus client, qui demande l’exécution d’un service, et un processus serveur, qui réalise ce service. Client et serveur sont localisés sur deux machines reliées par un réseau de communication. Ce modèle a été introduit pour mettre en œuvre les premières applications réparties (transfert de fichiers, connexion à une machine distante, courrier électronique, etc.), réalisées chacune par un protocole applicatif spécifique. Dans une seconde étape, une construction commune, l’appel de procédure à distance, a été introduite pour fournir un outil général pour la programmation d’applications client-serveur.

  • MOM, ou Message-Oriented Middleware
    Les systèmes de communication asynchrones, fondés sur l'envoi de messages, connaissent aujourd'hui un regain d'intérêt dans le contexte des applications réparties sur Internet. En effet, on s'accorde à penser que les modèles de communication asynchrones sont mieux adaptés que les modèles synchrones (de type client-serveur) pour gérer les interactions entre systèmes faiblement couplés. Le couplage faible résulte de plusieurs facteurs de nature spatiale ou temporelle : l'éloignement géographique des entités communicantes, la possibilité de déconnexion temporaire d'un partenaire en raison d'une panne ou d'une interruption de la communication (pour les usages mobiles par exemple). Les modèles de communication asynchrones prennent en compte l'indépendance entre entités communicantes et sont donc mieux armés pour traiter ces problèmes. Aujourd'hui les systèmes de communication asynchrones, appelés MOM (Message Oriented Middleware), sont très largement répandus dans la mesure où ils constituent la base technologique pour la réalisation des classes d'applications suivantes :Intégration de données et intégration d'applications (EAI, B2B, ESB, etc.)
Systèmes ubiquitaires et usages de la mobilité.
Surveillance et contrôle d'équipements en réseau.
  • Mieux expliquer la communication Publish/subscribe, je pense qu’il faut la déplacer dans le modèle de communication par évènement !


    Publish Subscribe (par abonnement) : les applications consommatrices des messages s'abonnent à un topic (sujet, catégorie de messages). Les messages envoyés à ce topic restent dans la file d'attente jusqu'à ce que toutes les applications abonnées aient lu le message.

    Les environnements :
    JMS (Java Messenging Service), JORAM (Java Open Reliable Asynchronous Messaging)
    MOM (Middleware orientés messages ou Message-Oriented Middleware)


    JORAM: Java Open Reliable Asynchronous Messaging

    Les différents éléments administrés émettent des
    messages :
    changements d'état et de configuration
    alertes, statistiques

    Implémentations existantes: TIBCO Rendezvous…


    Principe d’attachement
    Association dynamique entre un type d’évènement et une réaction.


    « Pull » – réception explicite Les clients viennent prendre périodiquement leurs messages sur le serveur.
    « Push » – délivrance implicite Une méthode prédéfinie (réaction) est attachée à chaque type de message (événement) ;
    la réception d'un événement entraîne l'exécution de la réaction associée.

    Exemple : surveillance des systèmes (changement d’états de configuration, alertes, statistiques)
  • Objectifs :
    Replacer le programmeur dans les conditions d’un système centralisé :
    utiliser un espace mémoire commun pour les communications
    synchronisation des applications par variables partagées

    Problématique :
    Mise en œuvre efficace d’une mémoire partagée distribuée
    Cohérence des données, localité des codes

    Exemples d’implémentations :
    Modèles à espace de tuples (une base de données relationnelle partagée).
    Modèles à objets dupliqués (un espace d’objets répartis partagés).

  • Ajouter 1 ou 2 phrases ici.

    Exemples d’implémentations
    Beans, EJB (Enterprise JavaBeans), CORBA Component, DCOM (Distributed Component Object Model)

    EJB: Enterprise Java Bean: Un environnement pour la répartition des objets répartis: un serveur qui gère tous les problèmes de répartitions
    DCOM: Distributed Component Object Model
  • permet l’extension des fonctions des serveurs pour des besoins spécifiques

    Avantages de la mobilité :
    privilégie les interactions locales
    minimiser les communications effectuées pour les échanges
    amener le code aux données plutôt que le contraire


    Agent mobile : entité logicielle permettant de construire des applications distribuées
    peut se déplacer d'une machine à une autre sur réseau.
    s'exécute sur une machine et peut, à tout moment, arrêter son exécution, se déplacer sur une autre machine et reprendre son exécution (à partir de son dernier état)



    Paradigme:
    L’activité démarre sur un site (une machine)
    Migration du code et des données sur un site distant
    Reprise de l’exécution
  • Ajouter 1 ou 2 phrases ici
  • Nécessité de gérer (et de masquer, au moins partiellement) la répartition

    Le middleware joue un rôle analogue à celui d’un “super-système d’exploitation” pour un système réparti
  • Ce dialogue se base sur un protocole applicatif commun, défini par l'API du middleware.
  • Un middleware ou « intergiciel » ou « élément du milieu » est l'ensemble des couches réseau et services logiciel qui permettent le dialogue entre les différents composants d'une application répartie.

    Positionnement du middleware (couche du milieu)
  • Objectif
    Unifier, pour les applications, l'accès et la manipulation de l'ensemble des services disponibles sur le réseau, afin de rendre l'utilisation de ces derniers transparente
  • J’ai remplacé : Conversion par Communication

    Conversion
    permet la communication entre machines mettant en œuvre des formats différents de données
    prise en charge par la FAP (Format And Protocol)
  • permet la transmission des données entre les deux systèmes sans altération.
    doit gérer la connexion au serveur, la préparation de l'exécution des requêtes, la récupération des résultats et la déconnexion de l'utilisateur.


    Communication
    permet la transmission des données entre les deux systèmes
  • J’ai modifié l’emplacement de Corba de l’orienté objet vers orientés composants
  • Services offerts par les couches TCP et UDP d’un réseau
    Couche réseau et couche transport
  • Même machine : client et serveur sur la même machine
  • Introduction aux systèmes répartis

    1. 1. SYSTÈMES RÉPARTIS heithem.abbes@gmail.com2015-16
    2. 2. Introduction au systèmes répartis
    3. 3. Système centralisé 4  Tout est localisé sur la même machine  1 processeur : une horloge commune  1 mémoire centrale : un espace d’adressage commun  1 système d’exploitation  Gestion centralisée des ressources  Etat global du système facilement reconstiuable  Accès local aux ressources
    4. 4. Emergence du réparti  Evolution technologique  machines  de plus en plus performantes avec une baisse des prix  Équipement réseau  de plus en plus rapides 5  Regroupement des machines  Puissance de calcul et de stockage  Moins de centralisation : accès multiples + partage de ressources  Flexibilité : facilité d’extension du système (matériels, logiciels)
    5. 5. Systèmes répartis (1/3)  "Un ensemble de machines connectées par un réseau, et équipées d’un logiciel dédié à la coordination des activités du système ainsi qu’au partage de ses ressources." 6  "Un système réparti est un système qui s’exécute sur un ensemble de machines sans mémoire partagée, mais que pourtant l’utilisateur voit comme une seule et unique machine." « Coulouris et al. » « Tanenbaum »
    6. 6. Systèmes répartis (2/3) 7  Types de ressources  Calcul  Stockage  Electronique  capteur, satellites, scanneurs, …  Architecture  Plusieurs processeurs  plusieurs horloges  Plusieurs mémoires  pas de mémoire partagée  Réseau d’interconnexion et de communication
    7. 7. Systèmes répartis (3/3)  Fonctionnement collaboratif: des traitements coopérants sur des données réparties pour réaliser une tâche commune  La coopération entre les processus correspond à la communication entre eux et la synchronisation de leurs évolutions.  La répartition peut concerner les données comme les traitements (tâches). 8
    8. 8. Caractéristiques (1/2) 9  Absence d’état global  Pas de référence spatiale commune à cause de l’absence (dans la majorité des cas) d’une mémoire partagée  Pas de référence temporelle commune à cause de l’existence de plusieurs processeurs ayant chacun sa propre horloge  Existence d’un réseau  non géré par le système d’exploitation  le comportement du système réparti dépend de l’état du réseau
    9. 9. Caractéristiques (2/2) 10  Architecture matérielle  Multi-processeurs à mémoire partagée  Clusters (grappes) d’ordinateurs  Ordinateurs puissants (serveurs dédiés) et indépendants  Ordinateurs PC en réseau  Architecture logicielle (système)  Entités logicielles séparées s’exécutant en parallèle
    10. 10. Exemples  Commerce électronique  Partage de fichiers (P2P)  Réseaux sociaux 11  Grilles informatiques  Ensemble de ressources hétérogènes et dé-localisées  Cloud Computing (Informatique en nuage) :  Accès via le réseau, à la demande et en libre-service, à des ressources virtualisées et mutualisées
    11. 11. Tolérance aux pannes  Un système réparti doit tolérer la panne des machines :  Une machine tombe en panne  Une machine envoie des informations erronées  Une machine n’est plus atteignable (problème réseau) Hétérogénéité  Comment s’affranchir des différences matérielles et logicielles des ressources du système ?  Sources d’hétérogénéité  machines (architecture matérielle)  systèmes d'exploitation  langages de programmation  protocoles de communications Propriétés 12
    12. 12. Sécurité  Confidentialité, Intégrité : Droits d’accès, Pare-Feu  Non-répudiation (s'assurer qu’un contrat signé via internet, ne peut être remis en cause par l’une des parties)  Authentification  Identification des applications partenaires  Messages authentifiés Disponibilité  Prêt à l’utilisation et toujours disponible Transparence  Propriété fondamentale : Tout cacher à l’utilisateur  La répartition doit être non perceptible : une ressource distante est accédée comme une ressource locale  Cacher l'architecture et le fonctionnement du système Propriétés 13
    13. 13. Passage à l’échelle (scalability) :  paramètre primordial pour la durabilité du système et sa capacité d’évolution en fonction des besoins  un système réparti doit montrer une capacité acceptable de passer à l’échelle:  Ce qui marche pour un utilisateur, marchera-t-il pour des milliers (voir des millions) ?  Ce qui marche pour un site, marchera-t-il pour des milliers ?  Ce qui marche pour un objet, marchera-t-il pour des millions ? Problèmes 16
    14. 14. Nommage et accès  Comment identifier les ressources distantes et les retrouver?  Système centralisé: nommage géré par le système d’exploitation (adressage).  Système réparti: utilisation d’annuaires et de services de nommage Intégration de l’existant  Connexion sur toutes les ressources d’une entreprise  Interopérabilité des applications Problèmes 17
    15. 15. Déploiement des applications  Comment installer tous les composants logiciels de l’application sur les différentes machines?  La modification d’un service ou l’ajout d’un autre, nécessite la recompilation, et/ou redéploiement de l’application?  Est il possible de reconfigurer automatiquement le redéploiement ? Problèmes 18
    16. 16. Applications réparties19
    17. 17. Système vs application 20  Système : gestion des ressources communes et de l’infrastructure, lié de manière étroite au matériel sous- jacent  Système d’exploitation : gestion de chaque élément  Système de communication : échange d’information entre les éléments  Caractéristiques communes : cachent la complexité du matériel et des communications, fournissent des services communs de plus haut niveau d’abstraction  Application : réponse à un problème spécifique, fourniture de services à ses utilisateurs (qui peuvent être d’autres applications).
    18. 18. Modèles de répartition 21  Modèle Client/Serveur  Modèle de communication par messages  Modèle de communication par événements  Modèle à mémoire partagée  Modèle à base de composants  Modèle à base d’agents mobiles  Modèle orienté service
    19. 19. Modèle Client/Serveur 22  Client : processus demandant l’exécution d’une opération à un autre processus  Serveur : processus accomplissant une opération sur demande d’un client, et lui transmettant le résultat  Modèle Requête/Réponse :  Requête : message transmis par un client à un serveur décrivant l’opération à exécuter  Réponse : message transmis par un serveur à un client suite à l’exécution d’une opération, contenant le résultat de l’opération  Mode de communication synchrone  Le client envoie la requête et attend la réponse.  Emission bloquante
    20. 20. Modèle de communication par messages (1/2) 23  Une application produit des messages (producteur) et une application les consomme (consommateur)  Le producteur (l’émetteur) et le consommateur (récepteur) ne communiquent pas directement entre eux mais utilisent un objet de communication intermédiaire (boîte aux lettres ou file d’attente)  Communication asynchrone :  Les deux composants n'ont pas besoin d'être connectés en même temps grâce au système de file d'attente  Emission non bloquante: l’entité émettrice émet son message, et continue son traitement sans attendre que le récepteur confirme l'arrivée du message  Le récepteur récupère les messages quand il le souhaite
    21. 21. Modèle de communication par messages (2/2) 24  Adapté à un système réparti dont les éléments en interaction sont faiblement couplés :  éloignement géographique des entités communicantes  possibilité de déconnexion temporaire d’un élément  Deux modèles de communication :  Point à point: le message n’est lu que par un seul consommateur. Une fois lu, il est retiré de la file d'attente  Multi-points : le message est diffusé à tous les éléments d’une liste de destinataires
    22. 22. Modèle de communication par événements 25  Mode de communication asynchrone et anonyme  indépendance entre le producteur et les (consommateurs d’un événement  Concepts de base  Evénement = changement d'état survenant de manière asynchrone (par rapport aux clients)  Réaction = exécution d’une opération prédéfinie liée à l’événement  Modèle Publish/Subscribe (par abonnement) :  les applications consommatrices des messages s'abonnent à un topic (sujet)  Les messages envoyés à ce topic restent dans la file d'attente jusqu'à ce que tous les abonnées aient lu le message  Deux modes de consommation :  « Mode Pull » - réception explicite : les consommateurs viennent prendre régulièrement leurs messages  « Mode Push » - délivrance implicite : une méthode prédéfinie est attachée à chaque type de message et elle est appelée automatiquement à chaque occurrence de l’évènement. La réception d'un événement entraîne l'exécution de la réaction associée  Exemple : surveillance des systèmes
    23. 23. Modèles à mémoire partagée 26  Objectif:  Replacer le programmeur dans les conditions d’un système centralisé :  utiliser un espace mémoire commun pour les communications  Avantages:  transparence de la distribution pour le développeur  efficacité de développement (utilisation des paradigmes usuels de la programmation concurrente)  Inconvénient:  Complexité de mise en œuvre efficace d’une mémoire partagée distribuée
    24. 24. Modèle à base de composants 27  Composant : module logiciel autonome et réutilisable  possède des entrées/sorties déclarées pour permettre les connexions entre plusieurs composants  possède des propriétés déclarées permettant de configurer le composant  Objectif: Simplifier la conception et le développement des applications :  Réutilisabilité  Indépendance  autonomie
    25. 25. Modèle à base d’agents mobiles 28  Code mobile : programme se déplaçant d’un site à un autre sur le réseau  Exemple : une applet incluse dans une page HTML et qui s’exécute sur la machine qui télécharge la page.  Avantages de la mobilité :  minimiser les communications effectuées pour les échanges  amener le code aux données plutôt que le contraire  Agent mobile : entité logicielle  peut se déplacer d'une machine à une autre sur réseau  s'exécute sur une machine et peut arrêter son
    26. 26. Modèle orienté service 29  Un modèle d'interaction basé sur la notion de service  Un service est un composant logiciel exécuté par un producteur à l'attention d'un consommateur  Une nouvelle vision dans la conception des applications réparties
    27. 27. Middleware30
    28. 28. Motivations 31  L’interface fournie par les systèmes d’exploitation et de communication est encore trop complexe pour être utilisée directement par les applications:  Hétérogénéité (matérielle et logicielle)  Complexité des mécanismes (bas niveau)  Nécessité de gérer la répartition  Solution  Introduire une couche logicielle intermédiaire (répartie) entre les niveaux bas (systèmes et communication) et le niveau haut (applications) : c’est l’intergiciel ou Middleware
    29. 29. Middleware 33  Un middleware (ou intergiciel) permet le dialogue entre les différentes entités d'une application répartie  Représente l’élément le plus important de tout système réparti Site 1 Site 2
    30. 30. Middleware - Fonctions 34  Masquer l’hétérogénéité (machines, systèmes, protocoles de communication)  Fournir une API (Application Programming Interface) de haut niveau  Permet de masquer la complexité des échanges  Facilite le développement d'une application répartie  Rendre la répartition aussi invisible (transparente) que possible  Fournir des services répartis d’usage courant
    31. 31. Services du middleware 35  Communication  permet la communication entre machines mettant en œuvre des formats différents de données  prise en charge par la FAP (Format And Protocol)  FAP : pilote les échanges à travers le réseau :  synchronisation des échanges selon un protocole de communication  mise en forme des données échangées selon un format connu de part et d'autre
    32. 32. Middleware 36  Nommage  permet d'identifier la machine serveur sur laquelle est localisé le service demandé afin d'en déduire le chemin d'accès.  fait, souvent, appel aux services d'un annuaire.  Sécurité  permet de garantir la confidentialité et la sécurité des données à l'aide de mécanismes d'authentification et de cryptage des informations
    33. 33. Types de middleware 37  Middleware RPC (Remote Proceedure Call)  RPC de SUN  Middlewares orientés objets distribués  Java RMI, Corba  Middlewares orientés composants distribués  EJB, Corba, DCOM  Middlewares orientés messages  JMS de Sun, MSMQ de Microsoft, MQSeries de IBM  Middlewares orientés sevices  Web Services (XML-RPC, SOAP)  Middlewares orientés SGBD  ODBC (Open DataBase Connectivity), JDBC de Sun  Middlewares transactionnels  JTS de Sun, MTS de Microsoft
    34. 34. Communications38
    35. 35. Présentation 39  Elément fondamental d’un système réparti  Plusieurs systèmes séparés physiquement  Reliés par un réseau  Définit leur interconnexion  Leur permet de communiquer entre eux
    36. 36. Outils de communication 40  Problématique  Réaliser un service réparti en utilisant l’interface de transport (TCP, UDP)  Mise en œuvre  Bas niveau  Utilisation directe de la couche transport  Sockets : mécanisme universel de bas niveau, utilisable depuis tout langage (exemple : C, Java)  Haut niveau  Utiliser les services offerts par les middlewares (Services plus complexes  Appel de procédure à distance (RPC), dans un langage particulier ; exemple : C  Appel de méthode à distance, dans les langages à objets ; exemple : Java RMI
    37. 37. le réseau vu de l’utilisateur 41  Schéma Client/Serveur  Machines différentes : client demande un service fournit par un serveur sur une autre machine  Un service est souvent désigné par un nom symbolique (email, http://..., telnet, etc.).  Ce nom doit être converti en une adresse interprétable par les protocoles du réseau.  La conversion d’un nom symbolique (http://www.google.com) en une adresse IP (216.239.39.99) est à la charge du service DNS
    38. 38. le réseau vu de l’utilisateur 42  Le serveur (machine physique) peut comporter différents services:  L’adresse IP du serveur ne suffit pas,  il faut préciser le service demandé au moyen d’un numéro de port, qui permet d’atteindre un processus particulier sur la machine serveur.  Un numéro de port comprend 16 bits (0 à 65 535).  Les numéros de 0 à 1023 sont réservés, par convention, à des services spécifiques.  Exemples :  22 : ssh, 23 :telnet (connexion à distance)  80 : serveur web, 25 : mail, 21: FTP

    ×