systèmes et applications réparties « communication dans
TRANSCRIPT
1
Systèmes et Applications Réparties
« Communication dans les applications distribuées »pp
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 1P. SWEID
2
INTRODUCTIONINTRODUCTIONContexte de développement des applications Réparties (AR)
Plan du chapitre
(AR)
Architectures Client / Serveur :Architectures Deux tiersArchitectures Trois TiersArchitectures N – Tiers
Le middleware (définition et rôle)
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 2P. SWEID
3
COMMUNICATION INTER PROCESSUS : ProtocolesCOMMUNICATION INTER PROCESSUS : Protocoles
Mise en œuvre du modèle client / Serveur
Plan du chapitre
Modèles client serveur en RPC.
• Client serveur à RPC traditionnel
intégré aussi dans DCE (Distributed Computing Environnement) :
• Un environnement intégré d ’applications réparties• Un environnement intégré d applications réparties,
• fondé sur le modèle C/S
RMI : Remote Methode Invocation
Modèles de Communication par Messages
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 3P. SWEID
• (Message Oriented Communication)
Streams Oriented Communication
4
Mise en œuvre du modèle Client / Serveur - suiteClient serveur à objets répartis :
CORBA : un environnement fondé sur un « courtier » d ’objets
Plan du chapitre
CORBA : un environnement fondé sur un « courtier » d objets réparties et un ensemble de services applicatifs (mais aussi DCOM)
Client serveur à composants :COM : un environnement pour la gestion des documents composites
Modèles client serveur de base de données :Exécution des requêtes SQL par exemple
Modèles de client serveur sur le Web.
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 4P. SWEID
Mais égalementModèles à base de code mobile.Modèles à mémoire virtuelle partagée répartie.
5
Première Partie
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 5P. SWEID
6
Contexte de développement des applications Réparties (AR)
Architectures Client / Serveur :
INTRODUCTION
Architectures Client / Serveur :
Architectures Deux tiers
Architectures Trois Tiers
Architectures N - Tiers
Le middleware (définition et rôle)
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 6P. SWEID
7
Évolution des besoinsÉvolution Technologique
Pourquoi des applications réparties Pourquoi des applications réparties ??
CONTEXTE DE DEVELOPPEMENT DES AR
• Structures des entreprises et des organisations : communication et partage( intranet, Internet, …etc.),coopération
• Accès généralisée à l ’information
• Banalisation des réseaux de télécoms
• Évolution vers le haut débit
• Rapport coût / performance des g(Web, ...etc.)
• partage d ’information, accès à des ressources distantes
• Informatique distribuée (vidéo et services interactifs, …etc.)
Rapport coût / performance des équipements informatiques
• Convergence informatique, Téléphonie et vidéo
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 7P. SWEID
Applications RépartiesApplications Réparties‘‘ DistribuéesDistribuées ’’
8
Environnement de développement : Environnement de développement : Modèle dModèle d ’exécution’exécution
CONTEXTE DE DEVELOPPEMENT DES AR
Méthodes et outils de
modélisation
Outils de dé l t
Services applicatifs
MiddleWareMiddleWare
Modèle d’exécution
développementOutils
d ’administration
fichiers répartis, accès BD,moniteurs transactionnels ...
Services SystèmesCommunication, RPC, désignation, sécurité,
…etc.
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 8P. SWEID
Système d ’exploitation
Réseaux
9
Application Application coopérativecoopérative
Application réalisée par des programmes communicantsprogrammes communicants( bj t )
Problématique de la coopération
(processus, objets, ...).
Avantages Avantages potentielspotentiels
1. Modularité.
2 Réutilisation (par composition)2. Réutilisation (par composition).
3. Performances.
Motivations actuelles importantes pour les applications Motivations actuelles importantes pour les applications coopérativescoopératives
1. Applications systèmes et réseaux (algorithmique répartie).
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 9P. SWEID
1. Applications systèmes et réseaux (algorithmique répartie).
2. Applications objets, objets répartis, à base de composants.
3. Systèmes d’informations,
10
Coopération : Le point de vue localCoopération : Le point de vue local
Ensemble de programmes coopérants utilisant des données localesdonnées locales
Exprimer la coopération : Le point de vue localLe point de vue local
Ensemble de programmes coopérants utilisant des données localesdonnées locales
Programmes : Programmes :
schéma de contrôle local à un sitelocal à un site (flot d’exécution local).
Données : Données :
traitées par le programme, disponibles localement sur le site.localement sur le site.
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 10P. SWEID
Vision plutôt Vision plutôt ascendanteascendante : ‘émergence’ du comportement coopératif.
11
Une application coopérativecoopérative offre un service externe en encapsulant une structure de données répartiesréparties
Exprimer la coopération : Le point de vue global
pp
Programme réparti : schéma de contrôle global à un ensemble de sitesglobal à un ensemble de sites (
comportement de groupe).
Données :une structure de données encapsuléesencapsulées par le traitement (en fait distribuéedistribuée sur les différents sites, ‘structure de données partitionnée’ ).
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 11P. SWEID
Vision plutôt descendanteVision plutôt descendante : le comportement coopératif visé est placé a priori.
12
Application Répartie = Traitements coopérants sur des données réparties
Traitements : consistent en
Problématique de la coopération
Traitements : consistent en
Une description : programme
Une exécution : flot d ’exécution (processus)
Coopération = Communication + Synchronisation
Modèle d ’exécution
interface de programmation (modèle de programmation)
Outils de développement
Environnement d’exécution : services systèmes
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 12P. SWEID
(pour différents types d ’infrastructures)
13
Client serveur :une approche universellement adoptée pour structurer les
Coopération avec utilisation d’interactions client serveur
applications coopératives.
Il est à l’origine des services généraux offerts par les couches application réseau.
Exemples :Serveurs de fichiersServeurs de base de données,
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 13P. SWEID
Serveurs d’impressionServeurs de noms (annuaires)Serveurs applicatifs usager.
14
Modèle d ’exécution
Contexte de développement des AR : Modèle d ’exécution
Modèles Client - Serveur
Client - Serveur traditionnel
Client serveur de ‘ données ’
Client serveur ‘ à objets ’ : Corba COM/DCOMClient serveur à objets : Corba, COM/DCOM
Modèle de communication par messages
Modèle de communication par événements
Modèle de communication à base de code mobile
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 14P. SWEID
Modèle de communication à mémoire virtuelle partagée
15
Architecture répartie:Architecture répartie:Réseaux, PC plus puissants, OS ouverts
Architecture des SAR : Exemple
Interfaces et API standards,
BD relationnelles
Langages : SQL, …
Outils de développementSGBD
OS BD
Serveur
Outils de transport
Et C/S.Règles
Réseau d’entreprise
Requête Réponse
Windows OS/2 Unix
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 15P. SWEID
Applications Applications Applications
Windows OS/2 Unix
Clients
16
Idée : Idée : l'application est répartie sur différents sites pour optimiser le traitement le stockage
Architecture Logicielle : approche client serveur
traitement, le stockage...
Le client :Le client :
effectue une demande de service auprès du serveur (requête)
initie le contact (parle en premier) ouvre la sessioninitie le contact (parle en premier), ouvre la session
Le serveur :Le serveur :est la partie de l'application qui offre un service
Il est à l'écoute des requêtes clientes
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 16P. SWEID
Il répond au service demandé par le client (réponse)
17
Le client et le serveur ne sont pas identiques, ils forment un système un système coopératif :coopératif :
Architecture Logicielle : approche client serveur
Les parties client et serveur de l'application peuvent s'exécuter sur
des systèmes différents
Une même machine peut implémenter les côtés client ET serveur
de l'application
Un serveur peut répondre à plusieurs clients simultanément
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 17P. SWEID
18
Client:Client:– Processus demandant l’exécution d’une opération à un autre processus par l’envoi de
message contenant :
Le modèle : concepts du modèle C/S
message contenant :• le descriptif de l’opération à exécuter • et attendant la réponse à cette opération par
un message en retour.
Serveur:Serveur:– Processus accomplissant une opération sur
demande d’un client et transmettant la réponse à ce client.
Requête:Requête:– message transmis par un client à un serveur décrivant l ’opération à exécuter pour le
compte du client.
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 18P. SWEID
compte du client.
Réponse:Réponse:– Message transmis par un serveur à un client suite à l’exécution d’une opération
contenant les paramètres de retour de l’opération.
19
Le modèle Client / Serveur
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 19P. SWEID
L'exemple du Web
20
Le modèle:
Système
Processus Client
Système
Processus ServeurApplication
Des clients et des serveurs...
Plusieurs clients, un serveur:
Hardware
Client
Hardware
Serveur
Un client, un serveur
Client ServeurClient Maître
Esclave Esclave
Client
Un client, plusieurs serveurs:
Requête/Réponse
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 20P. SWEID
Client Serveur Serveur
Le serveur contacté peut faire appel à un
service sur un autre serveur (ex. SGBD)
Le serveur traite plusieurs requêtes simultanées
21
C/S orienté client ou serveur
Les applications client/serveur peuvent se différencier par la façon
d t l f ti é ti t t t l li t t ldont les fonctions réparties se partagent entre le client et le serveur.
Le modèle orienté serveur place plus de fonctionnalités sur le
serveur (serveurs de transactions, serveurs web).
Le modèle orienté client fait l'inverse (serveurs d'informations).
(Les objets répartis peuvent être l'un ou l'autre).
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 21P. SWEID
22
C/S orienté client ou serveur
Client lourd (modèle orienté client)
→ Stocke les données et les applications localement. Le serveur stocke pp
les fichiers mis à jour.
→ Le client effectue une bonne partie du traitement (Le gros de
l'application tourne du côté client).
→ Le serveur (et le réseau) est plus allégé.
Modèle utilisé pour les logiciels individuels. Ils offrent une grande
souplesse et facilitent la création d'outils frontaux qui permettent aux
utilisateurs de créer leurs propres applications.
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 22P. SWEID
23
C/S orienté client ou serveur
Serveur lourd (modèle orienté serveur)- On effectue plus de traitements sur le serveur : transactions, ...
+ Déploiement plus aisé : les applications orientées serveur sont plus faciles à gérer
et à installer sur le réseau du fait que la majorité du code tourne sur les serveurs.
+ Minimisation des échanges sur le réseau.
Les serveurs de transactions et les serveurs d'objets encapsulent les
données.
Au lieu d'exporter des données brutes, ils exportent des procédures et
fonctions qui opèrent sur ces données
Le client fournit l'interface utilisateur graphique (GUI) et interagit avec le serveur
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 23P. SWEID
Le client fournit l'interface utilisateur graphique (GUI) et interagit avec le serveur
au moyens d'appels de procédures distantes (ou invocation de méthodes)
24
Client léger (Thin Client):
Client à fonctionnalité minimale: Terminaux X, stations de travail sans
C/S orienté client ou serveur
disque dur, Périphérique Réseau (Network Appliance), Ordinateur Réseau
(Network Computer), Ordinateur en réseau (Networked PC),…
Beaucoup de charge sur le serveur
Traitement local,
Données et applications Applet, données
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 24P. SWEID
,Caching, …
Client légerServeur
25
ClientServeur
Primitives de service:SendRequest( )ReceiveResponse( )
Dialogue Client/Serveur
Requête
Réponse
ReceiveResponse( )ReceiveRequest( )SendResponse( )
SendRequest() SendResponse()R i R t()ReceiveResponse() ReceiveRequest()
Session Session
1 234
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 25P. SWEID
Transport Transport
Réseau
26
• En général on a trois types de messages: REQ, REP et ACK.• Accessoirement, on peut avoir d ’ autres:
Code Type de paquet De A Description
Messages Client/serveur
od yp d p qu s p o
REQ Demande Client Serveur Le client désire un service
REP Réponse Serveur Client La réponse du serveur au client
ACK Accusé de réception L’un L’autre Les paquet précédent est arrivé
AYA Est-tu vivant ? Client Serveur Le serveur fonctionne-il ?
IAA Je suis vivant Serveur Client Le serveur n’est pas en panne
12
3
4
5
REQREQ
TA Essayer à nouveau Serveur Client Le serveur est saturé
AU Adresse inconnue Serveur Client Aucun processus n’utilise cette
adresse
6
7
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 26P. SWEID
REQREP
REQ
ACK
S C SACK
REP
ACK
C S
ACK
REP
AYAIAA
C
27
1-2: messages types 1et 2 sont essentiels
3 : ajouté pour augmenter la fiabilité (faire face à la perte de messages).
4-7: ne sont pas nécessaires pour les opérations de base, mais intéressant pour d’autres
Messages Client/serveur
p p p , pfonctionnalités supplémentaires.
Besoin pour 4-5:• Supposons que le client a envoyé une requête.• Que-est-ce que se passe si pas de réponse du serveur après un temps raisonnable? • Est-ce que le serveur continue à fonctionner ou bien il a tombé en panne ?(crash du
serveur)?• Le Client utilise le message AYA pour sonder le serveur.
• La réponse est un message IAA (ou REP), dans ce cas, alors tout va bien;
• Si pas de réponse, le client peut raisonnablement conclure que le serveur est
indisponible.
REQ REQREQ
ACK
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 27P. SWEID
REQREP
ACK
S C SACK
REP
ACK
C S
ACK
REP
AYAIAA
C
28
6: (TA: Essayer à Nouveau)Il y des cas ou le serveur n’est plus capable d’accepter les messages RES
Messages Client/serveur
Exemple : Le serveur n’a plus de place dans le buffer pour stocker de nouveaux messages ( le serveurs a déjà reçu des messages REQ qui ont consommé tout le buffer disponible)
Le serveur est alors surchargé et n’accepte plus des REQ futures
REQREP
REQ
SACK
REQACKAYAC
7: (AU: Adresse Inconnue)
• Adresse fausse (il n’y a pas de processus serveur avec cette adresse ), donc relancer un autre essai par le client ne donne aucun résultat.
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 28P. SWEID
REP
ACK
S C SREP
ACK
C S
REP
AYAIAA
C
29
• Dans un environnement hétérogène, on doit effectuer une présentation adéquate des données:
Échanges de messages
– Traduction des données: XDR (SUN) , ASN.1(CCITT),…{Abstract Syntax Notation }
(ASN.1) standard CCITT pour normaliser les données utilisées dans les protocoles de
communication.
– Assemblage de paramètres émis (Marshalling) et des résultats
–– Désassemblage des paramètres reçusDésassemblage des paramètres reçus (Unmarshalling) et de résultatet de résultatg p çg p ç ( g)
Présentation Présentation
TraductionAssemblage
TraductionDésassemblage
Client Serveur
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 29P. SWEID
Session Session
Transport
30
Mise en couches des Applications Réparties
But : structurer les applications en clients et serveurs.
Une application informatique est représentée selon un modèle en trois h ( i i )couches( trois niveaux):
1. la couche présentation (interface Homme/Machine):Gestion de l’affichage (exemple Windows, X-windows, etc.),
Logique de l’affichage, partie intrinsèque de l’applicatif qui transmet à la gestion de
l’affichage Les éléments de présentationl affichage, Les éléments de présentation.
2. la couche traitements qui constitue la fonctionnalité intrinsèque de l’application :
la logique des traitements : l’ossature algorithmique de l’application,
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 30P. SWEID
la gestion des traitements déclenchés par la logique de traitements qui réalise la
manipulation des données de l’applicatif (ex: procédures SQL).
31
Mise en couches des Applications Réparties
3. la couche données qui assure la gestion des données applicatives:
la logique des données constituant les règles régissant les objets de la base g q g g j
de données,
la gestion des données (consultation et mise à jour des enregistrements). Un
système de type SGBDR, habituellement, est responsable de cette tâche.
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 31P. SWEID
32
Mise en couches des Applications Réparties
Le découpage de ces trois parties permet de structurer une application en mode client/serveur;
Exemples:
le module de gestion des données peut être hébergé par un serveur distant,
le module de gestion de l’affichage peut également être géré par un g g p g g pserveur distant (un Terminal X par exemple).
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 32P. SWEID
33
User interface IHM Level
Organisation Générale d ’un application Web en trois couches différentes
User interface
Générateur HTMLGénérateur de Requête
Page HTML contenant la liste
Expression mots clés
IHM Level
P i L l
Classement des composantes
Liste classée des titres de page
Titre page
REQ_BD
Processing Level
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 33P. SWEID
Data Base withWeb pages
Titre page Web avec meta-information
Data Level
34
Dans une application C/S, il faut décider de l’emplacement des
composantes de:
Conception d ’une application C/S
composantes de:
Interface IHM (Présentation):
Interfaces textuelles ou graphiques, interactions, entrée de données,
validation, …
Niveau traitement (Logique d ’application, Processing level):
Traitement associés à l ’application client/serveur
Niveau Données (Accès aux données, Data Level) :
St k t è d é B d d é D t W b
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 34P. SWEID
Stockage et accès aux données: Base de données, Documents Web,...
35
Plusieurs approches : Le but est de distribuer les programmes des trois niveaux
de traitement ‘application layers ’ sur plusieurs machines
ARCHITECTURES CLIENT SERVEUR
de traitement application layers sur plusieurs machines
Première solution : entre deux machines : un client et un serveur =>
architecture deux tiers
(t ti d hit t )(two-tiered architecture)
Deuxième solution : entre trois machines : Architecture trois-tier :
three-tiered architecture (un client, un serveur / client, serveur de base
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 35P. SWEID
de données)
Ou bien entre plusieurs machines (solution N-tier)
36
Interface utilisateur Application
Architecture C/S : différentes alternatives « Modèle de Gartner »
Interface utilisateur‘ Gestion de données ’
Interface utilisateur‘ Gestion de données ’
Interface utilisateur
Application
Application
A li ti
Data Base
D t BA li ti
Data Base Data Base
Dialogue Appli <-> BD‘ SQL-Net ’; ‘ Données Distantes ’
BD Distribuée
Dialogue Appli <-> Appli type RPC
Classe 1
Classe 2
Classe 3Interface utilisateur‘ Gestion de données ’
Interface utilisateur‘ Gestion de données ’
Application Data Base
Data Base‘ Gestion de données ’
Application
Application
Application
Data Base‘ G ti d d é ’
Interface Utilisateur Interface
type RPC (transaction réparties)
Présentations RépartiesUNIX + terminal
Présentations distantes
Classe 3
Classe 4
Cl 5
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 36P. SWEID
‘ Gestion de données ’Utilisateur Utilisateur UNIX + terminal Asynchrone
Classe 5
37
Classe 5 : Présentation répartie
L'application existant sur le serveur n'est pas modifiée.
Seule la partie présentation est reprise sur un poste "intelligent" pour offrirSeule la partie présentation est reprise sur un poste intelligent pour offrir
une interface utilisateur graphique qui permet son intégration au sein d'un
poste métier.
L'application reste accessible par des terminaux passifsL application reste accessible par des terminaux passifs.
Lors de l'usage d'un terminal intelligent,
les informations normalement à destination de l'écran passif sont
interceptées sélectionnées et présentées à l'utilisateur sous une forme
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 37P. SWEID
interceptées, sélectionnées et présentées à l utilisateur sous une forme
différente qui s'intègre généralement dans une fenêtre (forme graphique).
38
Classe 4: /Présentation distante - déportée/
Sur le client :toute la partie IHM (graphical front -end application) qui s ’occupe de la manière de présenter les données)
Le serveur : Le reste de l ’application communiquant avec le client via un protocole du niveau application
La présentation à l'écran est traitée uniquement sur le poste intelligent.
C'est une solution employée par les applications qui utilisent X-Window/Motif
interface graphique devenue standard sous Unix.On peut la mettre en oeuvre sur des poste client PC en utilisant une émulation
de terminal X telle que Exceed
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 38P. SWEID
39
Classe 3: /application « traitement » distribuée/
Dans ce modèle l'application est décomposée en deux parties,l'une sur le serveur, l'autre sur le poste client.aut e su e poste c e t
Les communications entre les deux parties peuvent utiliser les outils suivants :le RPC (Remote Procedure Call) qui vient de TCP/IPLes sockets de TCP/IPL'APPC (Advanced Program - to - Program Communication) reposant sur le protocole LU 6.2 d'IBMOpen CPI-C (Common Programming Interface for Communication), au-dessus de APPC dont il masque les « irrégularités »
La solution RPC est la plus simple l t i t l ti l i t à l h d l' li ti (d d
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 39P. SWEID
car les trois autres solutions laissent à la charge de l'application (donc du
programmeur !) la prise en compte de tous les problèmes de vérification et de
traitements d'incidents pouvant survenir durant le transfert d'informations.
40
Classe 3: /application « traitement » distribuée/
Distribution de composantes
• Sur le client : Toute la partie IHM + UneSur le client : Toute la partie IHM + Une
partie de l ’application
• Le serveur : Le reste de l’application
• Exemple :
• un client sur lequel il y a une fonction
d ’édition qui opère sur des données
cachées ‘en mémoire ou sur disque ’
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 40P. SWEID
41
Classes 2 & 1: les plus populaires
1. Les données sont localisées sur le serveur dans un SGBDR (figure ci-dessous)
2. Le moyen d'accès à ces données est donc le langage de requête SQL.
3. Cette architecture comprend sur le poste client les parties présentation et applicative3. Cette architecture comprend sur le poste client les parties présentation et applicative
générant les requêtes SQL à transmettre au serveur.
4. Le transport peut être assuré par :
SQL*Net, qui utilise le protocole IP si le SGBD est ORACLE ou DB2 (par
l'intermédiaire de SQL Connect) par exemple.
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 41P. SWEID
Cet échange de messages transite à travers le réseau reliant les deux machines. Il met en œuvre des mécanismes relativement complexes qui sont, en général, pris en charge par un middleware.
42
La classe 1 :
lorsque le client contient une partie de données sur son disque local (exemple d ’une
Distributions de composantes
application Web ou le client construit un cache sur son disque local pour stocker les
pages Web le plus récentes
• BD distribuée:
Présentation
Traitement
Données
Données
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 42P. SWEID
Données
Classe 1
43
Architecture à 2 niveaux (2 tiers) : vers l’architecture 3-tiers
Limites du client -serveur 2 -tiers : le client lourdL'expérience a démontré qu'il était coûteux et contraignant de vouloir faire porter
l'ensemble des traitements applicatifs par le poste client. On en arrive à un client
lourd.
On ne peut pas soulager la charge du poste client, qui supporte la grande majorité
des traitements applicatifs.
Le poste client est fortement sollicité, il devient de plus en plus complexe et doit
être mis à jour régulièrement pour répondre aux besoins des utilisateurs.
Les applications se prêtent assez mal aux fortes montées en charge car il est
difficile de modifier l'architecture initiale.
La relation étroite qui existe entre le programme client et l'organisation de la partie
serveur complique les évolutions de cette dernière
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 43P. SWEID
serveur complique les évolutions de cette dernière.
Ce type d'architecture est grandement « rigidifié » par les coûts et la complexité de
sa maintenance.
44
Architecture à 2 niveaux (2 tiers) : vers l’architecture 3-tiers
« Avantages » d'une architecture à 2 niveaux :
Elle permet l'utilisation d'une interface utilisateur riche.
Elle a permis l'appropriation des applications par l'utilisateur.
Elle a introduit la notion d'interopérabilité.
Pour résoudre les limitations du client-serveur deux tiers tout en conservant
ses avantages, on a cherché une architecture plus évoluée, facilitant les forts
déploiements à moindre coût.
→ La réponse est apportée par les architectures distribuées.
P iè i t ti é id it d d l' tili ti d' t li t i l
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 44P. SWEID
→ Première orientation : résiderait donc dans l'utilisation d'un poste client simple
communicant avec le serveur par le biais d'un protocole standard.
45
vers l’architecture 3-tiers : Répartition des traitements
L'architecture trois tiers, encore appelée client-serveur de deuxième génération
ou client-serveur distribué, sépare l'application en trois niveaux de service
distincts :
premier niveau : l'affichage et les traitements locaux (contrôles de saisie, mise en
forme de données... ) sont pris en charge par « le poste client »,
deuxième niveau : les traitements applicatifs globaux sont pris en charge par le
« service applicatif »,« service applicatif »,
troisième niveau : les services de base de données sont pris en charge par un
« SGBD »
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 45P. SWEID
46
vers l’architecture 3-tiers : Répartition des traitements
Tous ces niveaux étant indépendants, ils peuvent être implantés sur des
machines différentes, de ce fait :
le poste client ne supporte plus l'ensemble des traitements, il est moins sollicité et
peut être moins évolué, donc moins coûteux,
les ressources présentes sur le réseau sont mieux exploitées, puisque les
traitements applicatifs peuvent être partagés ou regroupéstraitements applicatifs peuvent être partagés ou regroupés
le serveur d'application peut s'exécuter sur la même machine que le SGBD),
la fiabilité et les performances de certains traitements se trouvent améliorées par
leur centralisation,
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 46P. SWEID
il est relativement simple de faire face à une forte montée en charge, en renforçant
le service applicatif.
47
Présentation Application Données
Présentation Application DonnéesApplication
Client/serveur à 3 niveaux (3-tiers ) selon GartnerLe côté serveur
Présentation Application DonnéesApplication
Présentation Application DonnéesApplication
Présentation Application DonnéesApplication Données Données Application
Client Serveur de milieu Serveur (Tier ressources)
pppp pp
Tier de milieu : Serveur d’application
Découple le client de la ressource commune
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 47P. SWEID
Le client voit des fonctions, non pas des données
Découple la logique de l’application des ressources
Exemple : requête utilisateur -> requête SQL
Répartition des demandes sur plusieurs ressources
48
les traitementsLes données sont répartis/distribués sur plusieurs plates-formes
Architecture C/S trois-tier ( à trois niveaux)
les fonctions de présentation (ou Interface Homme/Machine)
l'accès aux données suivant trois niveaux tels que représentés par le schéma ci-dessous.
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 48P. SWEID
49
Architecture C/S trois-tier ( à trois niveaux)
Architecture N-tiers
Attente du résultat
Attente des DonnéesRequête
traitementRéponse
Traitement
Présentation‘ IHM ’
ServeurTraitement
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 49P. SWEID
Requête Data
Réponse DataServeur
BD
50
Exemple : Intranet
Dans le cadre d'un Intranet,Le poste client prend la forme d'un simple navigateur Web,Le service applicatif est assuré par un serveur HTTP et la communication avec le SGBD met en œuvre les mécanismes bien connus des applications client-serveur de la première génération.
Circuit froid : premier tronçon entre le poste client au serveur Web :
•permet l'interaction avec l'utilisateur et la visualisation des résultats. (des standards : principalement HTML et HTTP)principalement HTML et HTTP).
•Le serveur Web tient le rôle de ``façade HTTP'',
Circuit chaud : Deuxième tronçon permet la collecte des données.
•Les mécanismes utilisés sont comparables à ceux mis en œuvre
Thin Client
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 50P. SWEID
comparables à ceux mis en œuvre pour une application deux tiers.
•Peuvent évoluer sans impacter la configuration des postes clients
51
Architecture 3-Tiers : Limitations
L'architecture trois tiers a corrigé les excès du client lourd en centralisant une grande partie de la logique applicative sur un serveur HTTP.
Le poste client qui ne prend à sa charge que la présentation et les contrôles de saisieLe poste client, qui ne prend à sa charge que la présentation et les contrôles de saisie,
s'est trouvé ainsi soulagé et plus simple à gérer.
Par contre, le serveur HTTP constitue la pierre angulaire de l'architecture et se trouve
souvent fortement sollicité et il est difficile de répartir la charge entre client et serveur.
On se retrouve confronté aux épineux problèmes de dimensionnement serveur et de
gestion de la montée en charge rappelant l'époque des mainframes.
Les contraintes semblent inversées par rapport à celles rencontrées avec les architectures deux tiers :
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 51P. SWEID
le client est soulagé, mais le serveur est fortement sollicité.
Le juste équilibrage de la charge entre client et serveur semble atteint avec la génération suivante : les architectures n-tiers.
52
Dans ce type d'architecture :
les échanges ont lieu toujours sur trois niveaux de services ,
Vers l’architecture N-tiers
Par contre, l'architecture n-tiers qualifie la distribution d'application entre de
multiples services et non la multiplication des niveaux de services
Cette distribution est facilitée par l'utilisation de composants ``métier'', spécialisés et
indépendants, introduits par les concepts orientés objets (langages de
programmation et middleware.
• La requête d'un client peut-être re-routée vers un autre serveur.
• Différents serveurs peuvent accéder à une même base de données ou à un même serveur de données.
L diffé t t êt di t t i ti
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 52P. SWEID
• Les différents serveurs peuvent être directement en communication→ pour se synchroniser, → se répartir les requêtes des clients, → prendre la place d'un autre serveur défaillant, etc.
53
Architecture N-tiers
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 53P. SWEID
54
• Du point de vue des clients, • Accèdent à des composants pour obtenir des services.
• Sans connaître les logiques internes de ces composants ni où ces derniers se
Architecture N-tiers
• Sans connaître les logiques internes de ces composants, ni où ces derniers se trouvent, sur quels serveurs ils sont hébergés, etc.
• Ces composants ont chacun en charge une tâche.
• La somme de toutes ces tâches est égale au service fourni par l'architecture N-tier.
N.B :
• Ce type d'architecture a les mêmes avantages que l'architecture 3-tier, avec en plus des
capacités de scalabilité.
• On comprendra facilement que si cette architecture peut offrir une grande quantité de
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 54P. SWEID
services et de performances, c'est au prix d'une certaine complexité de conception et
d'administration.
55
Le middleware dans le C/S
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 55P. SWEID
56
La communication entre clients et serveurs se fait le plus souvent via
une couche logicielle intermédiaire : MiddleWare « MédiateurMédiateur »
Le middleware (Médiateur) dans le C/S
Dans une architecture NOS, elle masque l’hétérogénéité
Fournit un modèle de programmation simplifiant la construction des
composantes des logiciels travaillant dans un système distribués
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 56P. SWEID
57
S i SGBD
Modèle du Middleware
• Services applicatifs (fichiers répartis, transactionnels,
• Services systèmes (communications, désignation, sécurité…)
GestionRépartie
Transport
ServicesSpécifiques
GestionRépartie
Logique
GestionRépartie
Logique
GUISGBD
OS RéseauOS OS
Client ServeurMiddleware
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 57P. SWEID
58
Processus client Processus serveur
Protocole
Place du middleware
Serviceslocaux
Services réseau
OS et HW
Serviceslocaux
Services réseau
OS et HW
Protocole
Requête/ Réponse
Protocole Réseau
TCP/UDP, …etc.
Midddleware client Midddleware serveur
Exemples:
Les services primitifs: émulateurs terminaux, transfert de fichier, email,...
Services de base tels que le RPC
Services intégrés tels que le DCE
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 58P. SWEID
Services intégrés tels que le DCE,...
Objets distribués tels que CORBA, COM/DCOM, OLE/ActiveX
World Wide Web
59
Modèle client Serveur
Stratégies de Mise en œuvreg
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 59P. SWEID
60
Introduction
Service_1Client_a
Serveur Service_2
Service_nClient_b
Client_c
ClientEmet des requête
(demande de service)
Le client est l ’initiateur du dialogueq p
Serveur- Ensemble de services exécutables
- Exécute des requêtes émises par des clients -> Exécution des services
(séquentielle ou parallèle)
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 60P. SWEID
Certains nombre de considérations dans la mise en œuvre du modèle C/S
61
Introduction
CLIENT SERVEUR
Vu du client
SERVEUR
Préparation de la requêteenvoi de la requêteattente du résultat
Connexion au serveur Attente de requêtes
Analyse de la requête…..
Requête
….
Analyse du résultat reçu
Exécution….Préparation de la réponseenvoi de la réponse
Réponse
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 61P. SWEID
62
Introduction
Vu du serveur
TraitementRequêtes
Sélection
Fil des requêtes
Réponses
→ Gestion des requêtes (priorité)
→ Exécution du service ( séquentiel, concurrent)
Fil des requêtes
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 62P. SWEID
→ Exécution du service ( séquentiel, concurrent)
→ Mémorisation ou non de l’état du client
63
Modèle Client - Serveur : gestion des processus
Client et serveur exécutent des processus distincts
le client est suspendu lors de l’exécution de la requête (appel synchrone) p q ( pp y )
éventuellement, plusieurs requêtes peuvent être traitées concurremment
par le serveur
parallélisme réel (ex : multiprocesseur, entrées -sorties)
pseudo-parallélisme
la concurrence peut prendre plusieurs formes
plusieurs processus (une mémoire virtuelle par processus)
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 63P. SWEID
plusieurs processus légers ( threads) dans le même espace virtuel
(contexte restreint : pile, mot d’état, registres)
64
Le serveur
Plusieurs stratégies de mise en œuvre
– Processus serveur unique
– Processus par service avec pool d’exécution
– Processus par services avec création dynamique des exécutants
Différents types de services
– Sans données persistantes
Avec données persistantes
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 64P. SWEID
– Avec données persistantes
– Modes avec état / sans état
65
Processus serveur unique while (true) {
• receive (client id message);
Stratégie de mise en œuvre (1)
receive (client_id, message);• extract (message, service_id, paramètres); • do_service [service_id] (paramètres, résultats);• send(client_id, résultats);
};
RequêtesSélection
TraitementRequêtes
Réponses
E l R êt S DNS
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 65P. SWEID
Exemple : Requête Serveur DNSService_Id = DNS_LOOKUP ‘ requête d ’interrogation de la base ’Paramètres = ‘ Nom_Machine ’
66
Stratégie de mise en œuvre (1.bis)
Un seul et unique processus serveur :1. Reçoit la requête, 2. il en extrait l'identification du service requis par le client (service_id) et les paramètres
nécessaires à l'exécution de ce service.
3. Une fois le service identifié, le serveur extrait les paramètres du message puis exécute le traitement approprié ;
4. il récupère alors les résultats et construit un message de réponse qu'il transmet au client.
Remarque :
Cette mise en œuvre simpliste, ne permet pas (en première approximation) de parallélisme
dans le traitement des requêtes ; elle est donc essentiellement utilisée dans la cas ou le
temps de traitement des requêtes est court.
Exemple:
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 66P. SWEID
Dans le cas d'un serveur de noms (DNS), le service_id peut être DNS_LOOKUP pour
identifier une requête d'interrogation de la base et les paramètres une chaîne de caractère
contenant le nom de la machine dont on veut retrouver l'adresse IP.
67
Stratégie de mise en œuvre (2)
Création dynamiquedes exécutants
Processus veilleur « aiguilleur »
Processus veilleur + Création dynamique des exécutants
while (true) {receive (client_id, message)extract (message, service_id,params) ;p=create_thread (client_id,service id, params) ;
do_service{service_id}(params, results)send (client_id, results)
it
programme de p
des exécutants
service_id, params) ;};
exit ;
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 67P. SWEID
68
Stratégie de mise en œuvre (2.bis)
Commentaires
Dans cette mise en œuvre, un processus veilleur, p
1. reçoit les requêtes
2. crée un processus pour traiter chacune ;
3. Après traitement de la requête, le processus émet la réponse à
destination du client puis disparaît .
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 68P. SWEID
69
Stratégie de mise en œuvre (3)
Processus veilleur « aiguilleur » Pool d’exécutants
Processus veilleur + Pool d'exécutant « ensemble statique d’exécutants »
while (true) {receive (client_id, message)extract (message, service_id, params) ;work_to_do.put (client_id,service id, params) ;
while (true) {work_to_do.get (client_id, service_id, params) ;do_service{service_id](params, results)send (client id, results)_ , p ) ;
}; ( _ , )
};
activation
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 69P. SWEID
70
Stratégie de mise en œuvre (3.bis)
Remarques :
Cette mise en œuvre est une variante de la précédente ;
→le processus veilleur, au lieu de créer un processus par requête à
exécuter, distribue chaque requête à un processus disponible d'un
ensemble statique d'exécutant.
♦ Cette mise en œuvre est en général utilisée pour paralléliser les
traitements lorsque la durée des traitements est "raisonnable" ;
♦ elle peut être observée par exemple dans l'implémentation Unix de NFS
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 70P. SWEID
♦ elle peut être observée par exemple dans l implémentation Unix de NFS
(un ensemble de processus nfsd répondant cycliquement aux requêtes )
71
Gestion de l’état du serveur
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 71P. SWEID
72
Serveur : statefull « service avec état »
Service avec états :
⌦ Le serveur conserve localement un état pour chacun des clients connectés :
informations sur le client, les requêtes précédentes, …
⌦Les appels successifs s ’exécutent en fonction d’un état laissé par les appels
antérieurs
gestion de l ’ordre des requêtes est indispensable
Exemple
lecture d’un enregistrement d’un fichier en accès séquentiel (dépendant
du pointeur courant)
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 72P. SWEID
du pointeur courant)
appel de méthode sur un objet (on considère l’état courant d’objet)
73
Serveur :Stateless « service sans état »
Service sans état :
Le serveur ne conserve aucune information sur l'enchaînement des requêtes...
Situation idéale ou le service s’exécute uniquement en fonction des paramètres d
’entrée
Opération s’effectue sans lien avec celles qui l’ont précédé
Exemples :Exemples :pp
1.1. NFS NFS (Network File System de SUN - SGF réparti)
2.2. LectureLecture (fichier F, bloc N)
3.3. EcritureEcriture (fichier F, bloc N)
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 73P. SWEID
Voir aussi : Système-fichiers-repartis-NFS-AFS-Florin.pdf « tolérance aux pannes »
74
Serveur avec ou sans état ?
♦ Pour remédier à l'effet des pannes de clients ou d'autre serveurs, un serveur peut maintenir des informations sur les opérations en cours avec ses clients et leur état .... dans ce cas on dit que c'est un serveur avec état.q
♦ Ces informations permettent :1. D'éviter de traiter deux fois la même requête
sémantique d'exécution du service ($ chapitre RPC):→ au moins une fois,
→ au plus une fois,p ,
→ exactement une fois,
→ peut-être
2. De reprendre un traitement à l'endroit où il a été arrêté ou presque (avec des points de reprise) ( tolérance aux pannes)
♦ Quand le serveur ne maintient aucune information sur ses clients il est dit
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 74P. SWEID
♦ Quand le serveur ne maintient aucune information sur ses clients, il est dit serveur sans état.
autonomie de chaque demande de service (ex ouvrir et fermer un fichier à chaque
demande de lecture) ( Performances)
75
Serveur Statefull / Stateless ?
Tolérances aux pannes « Par rapport à la gestion des fichiers distribués »1. Serveur avec Etat : le serveur maintient des informations sur les clients qui utilisent
ses fichiersAvantages :
- identification des clients en permanence- transfert en mode connecté (plus fiable)
Inconvénients :- récupérer les ressources mobilisées à la fermeture- reconstruire l'état du serveur en cas de panne- détecter et éliminer les orphelins en cas de panne des clients
2. Serveur sans Etat : aucune information conservée par le serveur sur ses clients
Convient pour des : Requêtes idempotentes
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 75P. SWEID
- READ/WRITE en mode "append" transformées en opération à une position dans le
fichier
- destructions idempotentes ?
76
Différents types de service
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 76P. SWEID
77
Différents types de service : pas de donnée rémanente (ou persistante)
Situation idéale ou le service s ’exécute uniquement en
fonction des paramètres d ’entrée ( services ne manipulent pas des p ( p p
données persistantes)
→ pas de modification de données rémanente sur le serveur
Solution très favorableSolution très favorable→ pour la tolérance aux pannes
→ pour le contrôle de la concurrence (pb de synchronisation et exclusion
mutuelle entre processus est simplifié)
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 77P. SWEID
Exemple :→ calcul d’une fonction scientifique
78
Différents types de service : avec des données rémanente (ou persistante)
Les exécutions successives manipulent des données persistantes :
M difi ti d t t d’ é ti l it di t t→ Modification du contexte d’exécution sur le site distant
→ Problèmes de contrôle de la concurrence
→ Difficultés en cas de panne en cours d ’exécution
E lExemples :
→ Etat d ’un objet manipulé par ses méthodes
→ Serveur de fichier réparti
Pose de verrou pour les opérations d’écriture
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 78P. SWEID
Pose de verrou pour les opérations d écriture
79
Modèle client Serveur
Stratégies de Mise en œuvre
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 79P. SWEID
80
Les modes de communication : mode « non connecté » (1)
Schéma d’un dialogue C/S en mode sans connexion
Client Réseau Serveur
programme message d’appel prise en compte dela requête
Réveil du serveur
Dans ce mode le client peut envoyer des appels au serveur à n’importe quel moment.
Exécution requêtemessage réponseréception du résultat
poursuite du traitement
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 80P. SWEID
p y pp p q
Le client comme le serveur ne gèrent pas de descriptif de la relation client serveur : absence
de mémoire entre appels successifs.
81
Les modes de communication : mode non connecté (2)
Le mode sans connexion est donc un mode orienté vers le traitement d’un grand nombre de clients:
la gestion de connexions est jugée trop coûteuse.
l’arrivée des données + ordonnancement + non duplication ne sont pas garantis par le protocole; p g p p ;
à gérer par l’application.
l’approche non-connecté implique généralement une « connexion
synchrone ’ bloquante’ »;
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 81P. SWEID
y q
Exemple : tous les RPC
82
Remarque : Connexion Synchrone ?
SDs synchrones (bloquant) limites de temps fixées
Délai d’exécution de chacune des étapes d’un processus est limitéDélai d exécution de chacune des étapes d un processus est limitépar une borne inférieure et une supérieure
Il est terminant (on est certain de la fin).
Chaque message transmis sera reçu après un délai limité
Chaque horloge à une déviation du temps réel limitée et connue
Avec acquittement (réponse).
PB : arrêt complet du fonctionnement du client quand le serveur ne
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 82P. SWEID
p qrépond pas (pourquoi ?).
83
Les modes de communication : mode connecté (1)
Schéma d’un dialogue C/S en mode avec connexion
Client Réseau Serveur
demande de Message de connexion prise en compte dedemande deconnexion
Message de connexionla connexion
Création d’un contexte
• Emission de requêtes• Réception de résultats
• Exécution des requêtes
• Synchronisation et
• Gestion de la synchronisation• Emission de requêtes
• Réception de résultats• Synchronisation
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 83P. SWEID
demande dedeconnexion
Message de déconnexion prise en compte dela déconnexion
Libération du contexte
84
Les modes de communication : mode connecté (2)
Schéma d’un dialogue C/S en mode avec connexion
D d l li t d it i i l ff tDans ce mode, le client doit ouvrir une connexion avec le serveur pour effectuer
des appels puis il doit fermer cette connexion.
Le mode connecté implique une diminution des performances par rapport au
mode non connecté:
→ ceci est une contrainte pour certaines applications.
Le mode connecté permet une implémentation « asynchrone des échanges »,
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 84P. SWEID
plus complexe mais plus performantes que le mode non-connecté.
85
Remarque : Connexion Asynchrone
SDs asynchrones (non bloquant) aucune limite de temps sur :
La vitesse d’exécution d’un processus
Délais de transmission de messages
Taux de déviation des horloges
Pour assurer l’acquittement et la terminaison, il faut un protocole.
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 85P. SWEID
86
Gestion de l’exécution sur le serveur
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 86P. SWEID
87
Serveur itératif en mode non connecté (1)
A. Côté serveur : les serveurs itératifs en mode non-connecté (datagrammes, UDP)
1 ff t i t f d i ti l é d té1. offrent une interface de communication sur le réseau en mode non-connecté,
2. Indéfiniment :
a. réceptionnent une requête client,
b. formulent une réponse,
c et renvoient le message réponse vers le client selon le protocole applicatifc. et renvoient le message réponse vers le client selon le protocole applicatif défini.
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 87P. SWEID
88
Serveur itératif en mode non connecté (2)
B. Côté client : Le client peut envoyer un appel au serveur à tout moment
mode léger permettant
le traitement non ordonné des appels
l’absence de mémorisation entre appels successifs
(serveur sans données rémanentes et sans état)
Exemples DNS (service de noms)
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 88P. SWEID
( )NFS (service de fichiers répartis)
89
Serveur itératif en mode connecté (1)
A. les serveurs itératifs en mode connecté:1. offrent une connexion sur le réseau en mode connecté,
2. réceptionnent une connexion client,
3. offrent une nouvelle connexion sur le réseau,
4 é étiti t4. répétitivement : a. réceptionnent une requête pour cette connexion, b. formulent une réponse, c. et renvoient le message réponse vers le client,
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 89P. SWEID
5. lorsque le traitement pour ce client est terminé --> (2).
90
Serveur itératif en mode connecté (2)
B. Côté client :Ouvre une connexion avec le serveur avant de pouvoir lui adresser des appels, Puis ferme la connexion à la fin de la suite d’opérations
Délimitation temporelle des échangesMaintien de l’état de connexion pour la gestion des paramètres de qualité de service
Traitement des pannes, propriété d’ordre
Orienté versLe traitement ordonné d’une suite d’appels
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 90P. SWEID
Ordre local (requêtes d’un client traitées dans leur ordre d’émission), global ou causal
91
Serveur itératif en mode connecté (3)
Remarque : Le serveur sert une connexion à la fois
Serveurs itératifs: ne gèrent qu’un seul client à la fois g q
Traite séquentiellement les requêtes
Donc, adapté aux requêtes qui peuvent s'exécuter rapidement
sd=socket( );sd=socket(...);bind(...);listen(sd,5);for( ; ; ) {
nsd = accept(sd,…);
Traitement
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 91P. SWEID
Traitement(nsd);close(nsd);...
}
Serveur
92
Serveur parallèle
A. les serveurs parallèles en mode non-connecté:offrent une interface de communication en mode non-connecté,répétitivement :répétitivement :
Réceptionnent la requête client;1. offrent une nouvelle interface de communication sur le réseau, 2. créent un processus secondaire (PR. S.) chargé de traiter la requête
courante.(PR. S.) : formule une réponse à la requête client, et renvoient le message,
(PR. S.) : lorsque le traitement est terminé, libère la communication Exit
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 92P. SWEID
93
Serveur concurrent
B. les serveurs concurrents en mode connecté:Offrent une connexion sur le réseau en mode connecté,
Répétitivement : réceptionnent une connexion client, offrent une nouvelle connexion sur le réseau,
Créent un Processus Secondaire (PR. S.) chargé de traiter la connexion courante.
(PR. S.) : répétitivement : 1. Réceptionne une requête pour cette connexion, 2. Formule une réponse,3. Renvoie le message réponse vers le client selon le protocole
applicatif défini,
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 93P. SWEID
(PR. S.) : lorsque le traitement est terminé (propre au protocole applicatif), libère la connexion, Exit.
94
Serveur concurrent - suite
Remarques :Le serveur accepte les requêtes puis les "délègue" à un
processus fils.traitement de plusieurs clients
Adapté aux requêtes qui demandent un certain traitementLe coût du traitement est jugé, dans ce cas, suffisamment important pour que la création du processus fils ne soit pas pénalisante.Souvent utilisé en mode connecté
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 94P. SWEID
95
Serveur itératif , parallèle ou concurrent ?
Quel type de serveur utiliser ?Serveurs itératifs en mode non-connecté :
• services qui nécessitent très peu de traitement par requête (pas de concurrence).
• Exemple: serveur de temps « Time Server »
Serveurs itératifs en mode connecté : services qui nécessitent très peu de traitement par requête mais requièrent un transport fiable de
type TCP. Peu utilisé.
Serveurs concurrents en mode non-connecté :pas utilisé sauf si :
temps de création d’un processus extrêmement faible (dépend du système
d’ l it ti hôt ) t t d t it t d’ êt
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 95P. SWEID
d’exploitation hôte) par rapport au temps de traitement d’une requête,
Si les requêtes nécessitent des accès périphériques importants (dans ce cas, la solution
itérative est, en effet, inacceptable).
96
Serveur en mode connecté
♦ Avantages :→ Les problèmes de communication sont gérés automatiquement par le protocole grâce à la
gestion de la connexiongestion de la connexion
→ Primitives d'émission et de réception simples
♦ Désavantages :→ Le mode connecté implique plus d'opérations : par exemple la fermeture de connexion
s'effectue en 3 messages (three way handshake)
→ Blocage du serveur quand le client tombe en panne ... La connexion utilise des
ressources, si le client tombe en panne après la dernière réponse du serveur, le serveur ne
peut pas le savoir (car, il n'y a pas de messages échangés sur une connexion inutilisée), il va
maintenir les ressources d'une connexion inutile, lorsque le client va redémarré, il ouvrira
une nouvelle connexion.
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 96P. SWEID
→ Consommateur de ressources système : Exemple : une socket par connexion
→ Mode flot d'octets, il faut délimiter les messages dans le flot
• Lenteur et Ressources consommées
97
Serveur en mode non connecté
♦ Avantages :→ Moins de ressources système consommées→ Permet la diffusion
♦ Désavantage :→ Gérer les problèmes de communication : protocole de
récupération d'erreur entre applications :p pp→ Timer + retransmission→ N° de messages pour détecter les duplications
→ On refait la couche Transport !!!
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 97P. SWEID
98
Exemple : Les sockets
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 98P. SWEID
99
Les sockets - adressage
Deux processus communiquent en émettant et recevant des données via les
sockets
Les processus peuvent se trouver dans la même machine ou dans des
machines différents.
Les sockets sont des portes d'entrées/sorties vers le réseau (la couche
transport)
Une socket est l'extrémité d'une voie bi-directionnelle établie entre deux
processus.
Une socket est identifiée par une adresse de transport « au niveau transport »
qui permet d'identifier les processus de l'application concernée
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 99P. SWEID
100
Les sockets - adressage
• Interface d’accès au réseau• développé dans Unix BSD (Berkeley Software Distribution)• n° port @ IP protocole (TCP UDP )• n port, @ IP, protocole (TCP, UDP, ...)
Client Serveur
n° port :2345 n° port :80Couche Transport (TCP, UDP)
Couches Session à Application
n port :2345 @ IP : 193.168.20.1
n port :80 @ IP : 193.168.20.2
@ IP : 193.168.20.1 @ IP : 193.168.20.2Couche Réseau (IP)
@ Ethernet @ EthernetCouche Liaison
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 100P. SWEID
Une adresse de transport = Un numéro de port (identifie l'application)
+ Une adresse IP (identifie le serveur ou l'hôte dans le réseau)
101
Les sockets - adressage
♦ Le serveur doit utiliser un numéro de port fixe vers lequel les requêtes clientes sont dirigées
i fé i à é é♦ Les ports inférieurs à 1024 sont réservés :♦ « well-known ports »
♦ ils permettent d'identifier les serveurs d'applications connues
♦ ils sont attribués par l'IANA
♦ Les clients n'ont pas besoin d'utiliser des wellknown ports♦ ils utilisent un port quelconque entre 1024 et 65535 à condition que le
triplet [transport, @IP, port] soit unique
♦ ils communiquent leur numéro de port au serveur lors de la requête (à
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 101P. SWEID
l'établissement de la connexion TCP ou dans les datagrammes UDP
102
Communications sous Unix : Les sockets
Il est vu par l'utilisateur (programmeur) comme un descripteur de fichier
ordinaire ; On peut leur appliquer les opérations d'entrées/sorties définies sur les fichiers (read, write, close) en plus d’autres opérations (…).
Les sockets permettent d'utiliser une interface commune pour l'écriture
d'applications réparties,
il en existe de plusieurs types d’interfaces selon le protocole choisi pour
la communication : Circuits virtuels, via TCP : utilisation d'un mode connecté, taille illimité
des messages, ordonnancement, fiabilité.stream sockets (connection oriented) SOCK STREA
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 102P. SWEID
stream sockets (connection-oriented) - SOCK_STREA
Datagramme, via UDP.datagram sockets (connectionless) - SOCK_DGRAM
utilise directement IP ou ICMP (ex. ping)
103
Les sockets en pratique
Un descripteur de socket (sock_id) n'est qu'un
point d'entrée vers le noyau
• Bibliothèque socket est liée à l'application
Deux protocoles de transport sont fournis UDP et TCP
L'adressage à ce niveau est réalisé par des numéros de portes (16 bits),
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 103P. SWEID
• Bibliothèque socket est liée à l application
• La couche socket du noyau réalise l'adaptation au protocole de transport
utilisé
104
L’API socket
• Création de socket : socket(family, type, protocol)
• Ouverture de dialogue :g– Client : connect(...)– Serveur : bind(..), listen(...), accept(...)
• Transfert de données :– mode connecté : read( ) write( ) send( ) recv( )– mode connecté : read(...), write(...), send(...), recv(...)– mode non connecté : sendto(...), recvfrom(...), sendmsg(...), recvmsg(...)
• Clôture du dialogue :– Close(...), Shutdown(...)
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 104P. SWEID
105
La primitive socket()
• int socket(int family, int type, int protocol)• family :
– AF INET : pour des communications InternetAF_INET : pour des communications Internet– AF_UNIX : pour des communications locales (dans ce cas, la socket peut
être vue comme un fichier local)• type ou mode de fonctionnement :
– SOCK_STREAM : mode connecté (TCP)– SOCK DGRAM : mode non connecté (UDP)SOC _ G : ode o co ec é (U )– SOCK_RAW : accès direct aux couches basses (IP)
• protocol :– IPPROTO_TCP (protocole TCP avec SOCK_STREAM)– IPPROTO_UDP (protocole UDP avec SOCK_DGRAM ) – IPPROTO ICMP (protocole ICMP avec SOCK RAW )
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 105P. SWEID
IPPROTO_ICMP (protocole ICMP avec SOCK_RAW )– IPPROTO_RAW (accès direct IP avec SOCK_RAW )
106
Sockets en mode non connecté
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 106P. SWEID
107
Sockets En mode non connecté
♦ Pour que le client puisse contacter le serveur
Il doit connaître l'adresse de la socket du serveurLe serveur doit avoir créé la socket de réception
♦ Le client envoie sa requête en précisant, q p ,lors de chaque envoi :
l'adresse de la socket destinatairel'adresse de la socket émettrice (port, @IP)
♦ L t it l êt t é d
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 107P. SWEID
♦ Le serveur traite la requête et répond au client en utilisant l'adresse de la socket émettrice de la requête
108
Les sockets en mode connecté
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 108P. SWEID
109
Rappel - Une connexion TCP ?
Une connexion = ( @IP_src, port_src, @IP_dest, port_dest)
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 109P. SWEID
Port 80
110
Sockets En mode connecté (1)
Pour que le client puisse contacter le serveur :le processus serveur doit déjà tourner
le serveur doit avoir créé au préalable une socket pour recevoir les demandes de connexion des clients
Le client contacte le serveur en créant une socket locale au client :
en spécifiant une adresse IP et un numéro de port (Port, @IP) pour joindre le processus serveur
Le client demande alors l'établissement d'une connexion avec le serveur
Si le serveur accepte la demande de connexion :
il crée une nouvelle socket permettant le dialogue avec ce client
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 110P. SWEID
il crée une nouvelle socket permettant le dialogue avec ce client
permet au serveur de dialoguer avec plusieurs clients
111
Sockets En mode connecté (2)
SERVEUR
socket
CLIENTMODE CONNECTE
En mode connecté il y a établissement (listen,connect, accept) puis libération
socket
bind
listen
(listen,connect, accept) puis libération (close) d’une connexion entre le client et le serveur.
Demande de
Création du descripteur local
D d
Le serveur autorise NMAX connexions (le service est ouvert
Attachement d'un numéro de port à la socket
connect
write
read
accept
read
write
connexion
requête
Demande d'ouverture de connexion
Traitement de la requête
Le serveur accepte (ou attend) une connexion pendante et créée une nouvelle socket dédiée au client
Connexion ouverte
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 111P. SWEID
read
closecloseréponse
Schéma classique d’un client/serveur qui utilise TCP
112
Côté client : On suit les étapes suivantes:1. Créer une socket,2 Se connecter au serveur en donnant l’adresse socket distante (Adresse
Sockets mode connecté (3)
2. Se connecter au serveur en donnant l adresse socket distante (Adresse Internet du serveur et numéro de port du service). Cette connexion attribue automatiquement un numéro de port au client.
3. Lecture ou écriture sur la socket.Côté Serveur : On suit les étapes suivantes:
1. Créer une socket,2. Associer une adresse socket (Adresse Internet et numéro de port) au
service,3. Se mettre à l’écoute des connexions entrantes,4. Pour chaque connexion:
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 112P. SWEID
qa. Accepter la connexion (une nouvelle socket dérivée de la principale est créée);b. Lire ou écrire sur la nouvelle socket;c. Fermer la nouvelle socket.
113
Exemple : sockets - Serveur itératif en mode connecté
Le processus serveur :
attend une connexion clienteProcessus serveur lit la requête
traite la requête
envoie la réponse
ferme la connexion cliente
Traitement de la requête cliente
ferme la connexion cliente
…
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 113P. SWEID
114
Serveur concurrent en mode connecté - Principe
•Le processus serveur :attend une connexion cliente
Processus
serveur
crée un processus fils ou thread pour traiter le dialogue avec ce client et exécuter sa requête
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 114P. SWEID
115
Concurrence serveur mode connecté (1)
♦ Principe :
♦ Hé it d l d l é ti d♦ Héritage des ressources lors de la création de processus.
1. Mise en œuvre "1 processus serveur par service"
♦ Le processus veilleur attend les connections, crée un processus fils qui
hérite de la socket de communication.
♦ L fil ( ) è l i t t l êt♦ Le processus fils (serveur) gère la connexion et sert la requête.
♦ Le processus père (veilleur) se met en attente d'une nouvelle connexion.
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 115P. SWEID
116
Sockets: Mode connecté : 1 processus par service : principe
Serveur1. Création d'une socket2. Lien de la socket à l'adresse du
serveur (N° IP, port)3. Mise en veille de la socket4. Acceptation d'une connexion et
création d'une socket de communication (l'@ du client est
Client1. Création de la socket2. Connexion de la socket au
serveur (N° IP port)
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 116P. SWEID
communication (l'@ du client est rendue en retour)
5. Création d'un processus pour gérer le dialogue et le traitement
6. Fermeture de la socket esclave et attente d'une nouvelle connexion
serveur (N IP, port)3. Dialogue avec le serveur4. Fermeture de la connexion5. Suite du programme
117
Sockets: Mode connecté : 1 processus par service : principe
• Lors du fork() le fils hérite des descripteurs du père• Exemple de serveur :
int sd new sd;int sd, new_sd;...
sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);...bind(sd, (struct sockaddr *)&serveur, sizeof(serveur));listen(sd, 5);hil (!fi )while (!fin)
{nsd = accept(sd, ...);if (fork() == 0){ // C ’est le fils !
close(sd); // On n’a plus besoin de la socket du père/* On traite ici la connexion avec le client */
close(nsd); // Fin de la connexion avec le client
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 117P. SWEID
close(nsd); // Fin de la connexion avec le clientexit(0); // Mort du fils
}close(nsd); // Le père n’a plus besoin la socket vers le
client}
118
Concurrence serveur mode connecté (2)
2. Mise en œuvre "Pool de processus serveurs"
♦ La socket est initialisée, puis les processus du pool sont créés et hérite
de cette socket.
♦ Chacun se met en attente de connexions sur la socket, et traite les
requêtes qui lui sont transmises.
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 118P. SWEID
119
Sockets: Mode connecté : Pool de processus serveurs : principe
Initialisation1. Création d'une socket2. Lien de la socket à l'adresse du
serveur (N° IP, port)
Client1. Création de la socket2. Connexion de la socket au
serveur (N° IP, port)3. Dialogue avec le serveur4 F d l i
3. Mise en veille de la socket et création des processus serveurs
Serveurs4. Acceptation d'une connexion et
création d'une socket de communication (l'@ du client est rendue en retour)
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 119P. SWEID
4. Fermeture de la connexion5. Suite du programme
rendue en retour)5. Gestion du dialogue et traitement6. Fermeture de la socket esclave et
attente d'une nouvelle connexion
120
Les sockets en mode non connecté...
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 120P. SWEID
121
Mode non connecté – Serveur Itératif / Serveur Concurrent
Serveur concurrent mode non connectéServeur itératif mode non connecté
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 121P. SWEID
122
Utilisation du mode non connecté (datagrammes, UDP)
Caractéristiques♦ pas d’établissement préalable d’une connexion♦ Pas de garantie de fiabilité♦ Pas de garantie de fiabilité♦ adapté aux applications pour lesquelles les réponses aux requêtes des
clients sont courtes (1 message)♦ le récepteur reçoit les données selon le découpage effectué par l’émetteur
Contraintes♦ le client doit avoir accès à l’adresse du serveur (adr. IP, port)♦ le serveur doit récupérer l’adresse de chaque client pour lui répondre
(primitives sendto, recvfrom)
Mode de gestion des requêtes
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 122P. SWEID
♦ itératif (requêtes traitées l’une après l’autre)♦ concurrent (1 processus ou thread par client)
123
Exemple : Les sockets en mode non connecté...(1)
Pour que le client puisse contacter le serveur :
il doit connaître l'adresse de la socket du serveuril doit connaître l adresse de la socket du serveur
le serveur doit avoir créé la socket de réception
Le client envoie sa requête en précisant, lors de chaque envoi, l'adresse
de la socket destinataire (serveur)de la socket destinataire (serveur)
Le datagramme envoyé par le client contient l'adresse de la socket
émettrice (port, @IP)
L t it l êt t é d li t tili t l' d d
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 123P. SWEID
Le serveur traite la requête et répond au client en utilisant l'adresse de
la socket émettrice de la requête
124
Exemple : Les sockets en mode non connecté...(2)
Schéma fonctionnel
Serveur1. Création d'une socket2. Lien de la socket à l'adresse du serveur (N° IP,
Client1. Création d'une socket2 Envoi de la requête au
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 124P. SWEID
port)3. Réception d'une requête 4. Traitement5. Retour du résultat en utilisant l'@ fournie par
recvfrom
2. Envoi de la requête au serveur (N° IP, port)
3. Attente de la réponse4. Suite du programme
125
Exemple : Les sockets en mode non connecté...(3)
Attachement d'unCréation du Attachement d un numéro de port à la socket
Création du descripteur local
Le serveur est en attente d'une requête cliente (bloquante)
Attente de la
Envoi de la requête
(non bloquante)
Le serveur envoie la é
Traitement de la requête
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 125P. SWEID
réponse (bloquante)
réponse
(non bloquante)
Attention : Désignation du serveur et services)
126
Étapes à suivre:
1. Client:
SOCKET EN MODE NON CONNECTÉ (4)
a) Créer une socket,b) Associer une adresse (Adresse Internet et numéro de
port) au service,c) Lecture ou écriture sur la socket.
2. Serveur:a) Créer une socket,b) Associer une adresse socket au service,c) Lecture ou écriture sur la socket.
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 126P. SWEID
127
Exemple : Les sockets en mode non connecté... (5)
En mode non-connecté:
Le client n’établit pas de connexion avec le serveur mais émet un datagramme
(sendto) vers le serveur.
Le serveur n’accepte pas de connexion, mais attend un datagramme d’un client par
recvfrom qui transmet le datagramme à l’application ainsi que l’adresse client.
Les sockets en mode non-connecté peuvent utiliser la primitive connect pour
associer un socket à une destination précise. ==> send peut être utilisée à la
place de la sendto,
De même, si l’adresse de l’émetteur d’un datagramme n’intéresse pas un processus
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 127P. SWEID
, g p p
la primitive recv peut être utilisée à la place de la primitive recvfrom.
128
ANNEXE
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 128P. SWEID
129
Remarque : Utilisation du mode non connecté (datagrammes, UDP)
Caractéristiques :pas d’établissement préalable d’une connexionPas de garantie de fiabilitéadapté aux applications pour lesquelles les réponses aux requêtes des clients sont courtes (1 message)le récepteur reçoit les données selon le découpage effectué par l’émetteur
Contraintesle client doit avoir accès à l’adresse du serveur (adr IP port)le client doit avoir accès à l adresse du serveur (adr. IP, port)le serveur doit récupérer l’adresse de chaque client pour lui répondre (primitives sendto, recvfrom)
Mode de gestion des requêtesitératif (requêtes traitées l’une après l’autre)
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 129P. SWEID
té at ( equêtes t a tées u e ap ès aut e)concurrent (1 processus ou thread par client)
130
Gestion du parallélisme sur le serveur
Avec le schéma précédent, un seul processus serveurS’il y a des clients multiples, ils sont traités en séquence (les requêtes sont conservées dans une file d’attente associée à la socket serveur)
N.B. La longueur max de cette file d’attente peut être spécifiée lors de la création de la
socket serveur. Valeur par défaut : 50
On peut aussi utiliser un schéma veilleur-exécutants
Le thread veilleur doit créer explicitement un nouveau thread exécutant à chaque nouvelle
connexion d’un client (donc à l’exécution de accept())connexion d un client (donc à l exécution de accept())
Une socket service client différente est créée pour chaque client
Le thread veilleur se remet ensuite en attente
while (true) {accepter la connexion d’un nouveau client et
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 130P. SWEID
créer une socket service client;créer un thread pour interagir avec ce client sur la nouvelle socket service client;
}
131
ANNEXE : Primitifs de l’API sockets
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 131P. SWEID
132
La primitive socket()
• int socket(int family, int type, int protocol)• family :
– AF INET : pour des communications InternetAF_INET : pour des communications Internet– AF_UNIX : pour des communications locales
• type ou mode de fonctionnement :– SOCK_STREAM : mode connecté (TCP)– SOCK_DGRAM : mode déconnecté (UDP)– SOCK_RAW : accès direct aux couches basses (IP)
t l• protocol :– IPPROTO_UDP (protocole UDP avec SOCK_DGRAM)– IPPROTO_TCP (protocole TCP avec SOCK_STREAM)– IPPROTO_ICMP (protocole ICMP avec SOCK_RAW)– IPPROTO_RAW (accès direct IP avec SOCK_RAW)
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 132P. SWEID
• L’entier retourné par la fonction socket() est un descripteur de fichier.
Retour
133
La primitive connect()
• La primitive connect initialise la connexion avec un autre processus, il s'agit d'une connexion entre la socket local spécifié par son descripteur sock, et une socket distant dont l'adresse est donnée par adr.
• int connect(int sock_desc, struct sockaddr * @_serveur, int lg_@)– sock_desc : descripteur de socket retourné par socket()– @_serveur : adresse IP et n° de port du serveur distant
• Exemple de client :int sd;struct sockaddr_in serveur; // @IP, n° port, modestruct hostent remote_host; // nom et @IP
sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);serveur.sin_family = AF_INET;serveur.sin_port = htons(13);remote_host = gethostbyname(“brassens.upmf-grenoble.fr”);
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 133P. SWEID
bcopy(remote_host->h_addr, (char *)&serveur.sin_addr, remote_host->hlength); // Recopie de l’adresse
connect(sd, (struct sockaddr *)&serveur, sizeof(serveur));
Retour
134
La primitive bind()
• int bind(int sock_desc, struct sockaddr *my_@, int lg_@)• sock_desc : descripteur de socket retourné par socket()
@ d IP t ° d t l l t é d• my_@ : adresse IP et n° de port auxquels le serveur veut répondre• Exemple de serveur :
int sd;struct sockaddr_in serveur; // @IP, n° port, mode
sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);serveur.sin_family = AF_INET;serveur.sin_port = 0; // Laisse le système choisir un portserveur.sin_addr.s_addr = INADDR_ANY;
// Autorise des connexions de n’importe oùbind(sd, (struct sockaddr *)&serveur, sizeof(serveur));
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 134P. SWEID
bind(sd, (struct sockaddr )&serveur, sizeof(serveur));
Retour
135
La primitive listen()
• int listen(int sock_desc, int backlog)• sock_desc : descripteur de socket retourné par socket()• backlog : nombre maximum de connexions en attente d’être acceptées• backlog : nombre maximum de connexions en attente d être acceptées• Exemple de serveur :
int sd;
struct sockaddr_in serveur; // @IP, n° port, mode
sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);serveur.sin_family = AF_INET;serveur.sin_port = 0; // Laisse le système choisir un portserveur.sin_addr.s_addr = INADDR_ANY;
// Autorise des connexions de n’importe
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 135P. SWEID
poùbind(sd, (struct sockaddr *)&serveur, sizeof(serveur));listen(sd, 5); Retour
136
La primitive accept()
• int accept(int sock_desc, struct sockaddr *client, int lg_@)• sock_desc : descripteur de socket retourné par socket()
li id i é d li d d l i• client : identité du client demandant la connexion• accept : renvoie le descripteur de la nouvelle socket créée
Client Serveursc = socket() ss =socket()
bind(ss)
Création de la socket
établissement de la connexion
bloqué jusqu'à la réception de la requêteenvoi requête
connect(sc)
write(sc)
bind(ss)
read(sa)
listen(ss)
sa = accept(ss)
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 136P. SWEID
bloqué jusqu'à la réception de la réponse
read(sc)
close(sc)
write(sa)
close(sa)
traitement de la requête
envoi réponse
traitement de la réponse
Fermeture de la socket Retour
137
Les primitives d’envoi/réception
• int write(int sock_desc, char *tampon, int lg_tampon);• int read(int sock_desc, char *tampon, int lg_tampon);_ _• int send(int sock_desc, char *tampon, int lg_tampon, int drap);• int recv(int sock_desc, char *tampon, int lg_tampon, int drap);• int sendto(int sock_desc, char *tampon, int lg_tampon, int drap,
struct sockaddr *to, int lg_to);• int recvfrom(int sock_desc, char *tampon, int lg_tampon, int
drap, struct sockaddr *from, int lg_from);
• drap : options de contrôle de la transmission (consulter le man)
Cours NFP111 – SAR - Chapitre 02 – Communication dans les applications répartie - Première partie : concepts de base - Page 137P. SWEID
Retour