Systèmes et Applications Réparties « Communication dans

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)


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


• (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.


Mais égalementModèles à base de code mobile.Modèles à mémoire virtuelle partagée répartie.

5

Première Partie


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)


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


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.


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).


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.


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’ ).


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


(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,


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


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


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


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


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.


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


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


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).


22


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.


23


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


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


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


,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


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


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


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


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


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.


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


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,


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


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.


32


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).


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


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


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


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

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 ’


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


‘ 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


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


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


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 ’


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.


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


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


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


→ 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 »


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,


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 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


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.


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


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


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 :


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


• 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



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


• 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


services et de performances, c'est au prix d'une certaine complexité de conception et

d'administration.

55

Le middleware dans le C/S


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


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


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


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


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)


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


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


→ 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)


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


– 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


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:


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


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 ;


68


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 .


69


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


70


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


♦ 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


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)


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)


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


♦ 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


- READ/WRITE en mode "append" transformées en opération à une position dans le

fichier

- destructions idempotentes ?

76

Différents types de service


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é)


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


Pose de verrou pour les opérations d écriture

79

Modèle client Serveur

Stratégies de Mise en œuvre


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


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’ »;


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


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


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 »,


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.


86

Gestion de l’exécution sur le serveur


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.


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)


( )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,


5. lorsque le traitement pour ce client est terminé --> (2).

90


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


Ordre local (requêtes d’un client traitées dans leur ordre d’émission), global ou causal

91


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


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


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,


(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é


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


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.


→ 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 !!!


98

Exemple : Les sockets


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


100


• 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


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


♦ 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 (à


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


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),


• 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(...)


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 )


IPPROTO_ICMP (protocole ICMP avec SOCK_RAW )– IPPROTO_RAW (accès direct IP avec SOCK_RAW )

106

Sockets en mode non connecté


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


♦ 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é


109

Rappel - Une connexion TCP ?

Une connexion = ( @IP_src, port_src, @IP_dest, port_dest)


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


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


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:


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

…


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


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.


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)


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


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.


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)


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é...


121

Mode non connecté – Serveur Itératif / Serveur Concurrent

Serveur concurrent mode non connectéServeur itératif mode non connecté


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


♦ 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


Le serveur traite la requête et répond au client en utilisant l'adresse de

la socket émettrice de la requête

124


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


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


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


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.


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


, g p p

la primitive recv peut être utilisée à la place de la primitive recvfrom.

128

ANNEXE


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)


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


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


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)


• 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”);


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));


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


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)


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)


Retour