Vous êtes sur la page 1sur 70

Systmes distribus : Principes et concepts, Dr D.

Meslati, Universit de Annaba 1















SYSTEMES DISTRIBUES :
PRINCIPES ET CONCEPTS
Programme de Premire Anne Master en Informatique






SUPPORT DE COURS REALISE PAR
DR DJAMEL MESLATI









VERSION 2010
UNIVERSITE BADJI MOKHTAR-ANNABA
FACULTE DES SCIENCES DE LINGENIEUR
DEPARTEMENT DINFORMATIQUE



Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 2
INTRODUCTION


Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 3
PROGRAMME OFFICIEL
DESCRIPTION
Intitul de la matire : Systmes distribus : Principes et concepts Code :
Semestre : 1
Unit dEnseignement : UE2 Code : UE2
Enseignant responsable de lUE : Dr Djamel MESLATI
Enseignant responsable de la matire: Dr Djamel MESLATI
Nombre dheures denseignement : 3h Cours
Nombre dheures de travail personnel pour ltudiant : 2h
Nombre de crdits : 5
Coefficient de la Matire : 1

Objectifs de lenseignement
Ce cours vise introduire les principes de base et les concepts des systmes distribus. Sur le plan
thorique, ltude des architectures et des paradigmes de communication constitue 60% du cours.
Sur le plan pratique, il est vivement recommand dtudier lAPI du multithreading de J ava et le
dveloppement de quelques modles de synchronisation classiques (producteur/comsommateur,
lecteurs/rdacteurs, ) ainsi que ltude de lAPI J ava-RMI et llaboration dun exemple de
session de communication.

Connaissances pralables recommandes
Langage orient objets, systmes dexploitation, logique mathmatique, compilation, rseaux et
communication
CONTENU
Chapitre 1 Introduction aux systmes distribus (20%)
1.1 Dfinitions et caractristiques
Concurrence, partage de ressources, communication par message, absence dhorloge
commune, indpendance des pannes
1.2 Exemples de systmes distribus
Internet, intranet et systmes mobiles
1.3 Problmes
Lhtrognit, la concurrence, la scurit, les pannes, absence dinformations globales sur
un systme distribu
1.4 Dfis et objectifs
Linteroprabilit, louverture, linvariance lchelle (scalability), lefficacit, la
disponibilit, la gestion de la scurit, le maintien de la consistance des ressource, la
transparence (flexibilit), la gestion des situations dexception (dtection des pannes et
reprise), la gestion des transactions rparties

Chapitre 2 Architecture des systmes distribus (30%)
2.1 Taxonomie des systmes distribus
2.2 Architecture Client/serveur
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 4
Principe, rle des processus, rpartition des responsabilits, les variantes du modle
client/serveur (agent mobile, code mobile, proxy, )
2.3 Architecture deux tiers et trois tiers
Les application WEB et les bases de donnes, utilit des modles deux tiers et trois tiers,
scnario de mise en oeuvre
2.4 Processus pairs
Inconvnients du modle client/serveur, notions et avantages de processus pairs, problmes
de coordination

Chapitre 3 Les paradigmes de communication (30%)
3.1 Le passage de messages
Quest ce qun Message?, les primitives de communications, primitives bloquantes et non
bloquantes, les primitives de passage de messages buffriss
3.2 Le RPC (Remote Procedure Call)
Principe, mcanismes et concepts utiliss, paramtres et rsultats dans le RPC, ldition des
liens, exemple
3.3 Le RMI (Remote Method Invocation)
Principe, mcanismes et concepts (interfaces, classes, stub, ), J ava RMI
3.4 Communication de groupe
Principe, structure dun groupe, oprations sur les membres (ajout, suppression, recherche,
), laboration de la communication (diffusion, ordonnancement des messages, )
3.5 Communication par vnements et notifications
Principe, metteur/rcepteur, abonnement, notification
3.6 Communication par mmoire partage
Principe, mcanisme dutilisation, maintien de la mmoire (cration, protection, )

Chapitre 4 Mise en vidence des problmes fondamentaux des systmes distribus
(20%)
4.1 Nommage des ressources et des processus
Processus, fichiers, mmoire, rseaux, objets,
4.2 Rpertoire et dcouverte des services
DNS (domain name system) et espaces de noms, rsolution des rfrences, identification
des services rfrencs, exemple
4.3 La coordination distribue
Lexclusion mutuelle, la synchronisation, linterblocage (mise en vidence)
4.4 Fiabilit, fautes et scurit
Dtection des fautes/pannes, duplication des ressources, reprise aprs pannes, survol des
problmes de scurit (menace par code mobile, fuite dinformation, ), survol des
techniques de scurit (cryptographie, signature digitale, contrle daccs, )
REFERENCES BIBLIOGRAPHIQUES
1- Nicola Santoro, Design and Analysis of Distributed Algorithms, J ohn Wiley & Sons,
2007.
2- J ia Weijia, Zhou Wanlei, Distributed Network Systems, From Concepts to
Implementations, Springer Science, 2005.
3- George Coulouris, J ean Dollimore & Tim Kindberg, Distributed Systems, Concepts and
Design, Addison-Wesley, 2001.
4- Andrew Tannenbaum, Distributed Operating Systems, Prentice Hall International, 1995.
5- Michel Raynal, Synchronisation et tat global dans les systmes rpartis , Editions
Eyrolles, 1992.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 5
CHAPITRE 1
INTRODUCTION AUX SYSTEMES DISTRIBUES
CONTENU
1.1 Dfinitions et caractristiques
Concurrence, partage de ressources, communication par message, absence dhorloge
commune, indpendance des pannes
1.2 Exemples de systmes distribus
Internet, intranet et systmes mobiles
1.3 Problmes
Lhtrognit, la concurrence, la scurit, les pannes, absence dinformations globales sur
un systme distribu
1.4 Dfis et objectifs
Linteroprabilit, louverture, linvariance lchelle (scalability), lefficacit, la
disponibilit, la gestion de la scurit, le maintien de la consistance des ressource, la
transparence (flexibilit), la gestion des situations dexception (dtection des pannes et
reprise), la gestion des transactions rparties.

1.1 DEFINITIONS ET CARACTERISTIQUES
A. Tanenbaum et M. Van Steen [Tan 2002], donne la dfinition suivante : Un systme
distribus est une collection dordinateurs indpendants qui apparaissent lutilisateur
comme un seul systme cohrent.
De cette dfinition ressortent deux aspects : Le premier est de nature matrielle, il
sagit de lautonomie des ordinateurs ou chacun peut excuter des tches en
concurrence (c d au mme moment) avec les autres. Le second fait rfrence au
logiciel qui laisse apparatre le systme distribu comme une seule entit cohrente.
Bien entendu, le second aspect suppose une interconnexion des ordinateurs moyennant
un rseau de communication physique.
Selon G. Coulouris et al [Cou 2001], Un systme distribu ou rparti est un systme
dont les composants sont rpartis sur diffrents nuds dun rseau dordinateurs. Ces
composants communiquent et coordonnent leurs actions uniquement par lchange de
messages.
Les messages tant des suites de bits reprsentant des informations qui ont un sens
pour lmetteur et le rcepteur. Dune manire plus formelle, les systmes rpartis se
caractrisent par :
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 6
Une absence de base de temps commune (horloge commune)
Une absence de mmoire commune semblable celle dun systme
multiprocesseur
Les pannes des composants sont indpendantes
La motivation principale des systmes rpartis est lamlioration du partage des
ressources. Autrement dit, les ressources disponibles dans un ordinateur donn peuvent
tre utilises par un autre et vice versa. Par exemple, une imprimante connecte un
ordinateur peut recevoir des informations imprimer provenant dun autre ordinateur.
De mme, les fichiers disponibles dans un rpertoire dun ordinateur donn peuvent
tre manipuls par les autres ordinateurs, etc.
Naturellement, ce partage de ressources entre tches concurrentes introduit des
problmes souvent dsigns par Problmes de concurrence . Ces problmes existent
aussi dans les systmes centraliss multitches (systmes multiprocesseurs ou
monoprocesseur avec partage de temps). Cependant, dans un systme distribu, les
problmes de concurrence se trouve accentus par le fait que la gestion des ressources
nest pas centralise et la ncessit doprer des communications entre ordinateurs, ce
qui exige des techniques de gestion plus sophistiques.
La communication dans les systmes distribus sopre entre entits physiques ou
logiques et se base sur la possibilit dchange de messages qui est toujours supporte
par le rseau physique dordinateurs. Par exemple, lchange entre deux cartes de
communication rseau est un change entre entits physiques. Lchange entre deux
systmes de gestions de fichiers est un change entre entits logiques. Il en est de
mme pour la communication entre applications o lchange sopre entre entits
logiques appeles processus. Il existe diverses approches de communications allant
dun simple change de bits des protocoles complexes tel que linvocation de
mthodes distance (couramment nomm RMI qui est une abrviation de Remote
Method Invocation) ou la communication par vnements. Notons cependant que
lchange entre entits logiques passe par lchange entre entits physiques.
Labsence dhorloge commune cite prcdemment comme caractristique des
systmes rpartis, signifie que seule la communication de messages peut tre utilise
pour coordonner les activits des diffrentes tches du systmes et garantir la
cohrence lors du partage des ressources. En effet, il nest pas possible de raliser une
synchronisation des horloges des diffrents ordinateurs et coordonner par la suite les
tches en fonction dun rfrentiel temporel unique.
Dans un systme distribu, les ordinateurs peuvent tomber en pannes
indpendamment les uns des autres. De mme, les lignes de communication physiques
peuvent tre dfaillantes. Mais au-del des aspects matriels, les tches excutes sur
chaque ordinateur peuvent choues. Ces pannes dordre physique ou logique peuvent
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 7
avoir un effet local plus ou moins tendu. Par exemple, une panne au niveau dun
rseau de communication engendre lisolation des ordinateurs qui y sont connects
sans pour autant arrter lexcution sur ces derniers. Les programmes (processus) sur
ces ordinateurs peuvent ne pas tre capables de dtecter si le rseau est en panne ou
sil est simplement devenu lent. De mme, lchec dune activit quelconque sur un
ordinateur nest pas directement dtectable par les autres ordinateurs sur le rseau.
Cependant, une des caractristiques des systmes distribus est lindpendance de ces
pannes.
Lorsque, une application fait intervenir plusieurs composants o chacun sexcute sur
un ordinateur spar, il incombe au concepteur de cette application danticiper les
diffrentes pannes qui peuvent arrives et prvoir des mcanismes pour garantir la
poursuite de la coordination et latteinte de lobjectif vis.
1.2 EXEMPLES DE SYSTEMES DISTRIBUES
Les exemples des systmes distribus sont nombreux et varis. Un mme systme
distribu peut tre fond sur plusieurs autres systmes distribus de niveaux diffrents.
En effet, une application distribue est un systme compos de processus qui sexcute
sur plusieurs ordinateurs connects par un rseau. Cet ensemble dordinateurs
connects est lui-mme un systme distribu. Les couches des systmes dexploitation
qui assurent le maintien du rseau constituent un systme distribu, etc. Comme
exemples illustratifs, nous considrons Internet, les intranets et les systmes mobiles.
1.2.1 Internet
Internet est une vaste collection de rseaux dordinateurs interconnects. Les
programmes qui sexcutent sur ces ordinateurs interagissent par lchange de
messages en utilisant un moyen de communication ou un autre. La mise en uvre des
moyens de communication (mcanismes et protocoles) constitue un dfi considrable
qui a permit a un ordinateur quelconque dchanger des messages avec nimporte quel
autre ordinateur dans le rseau.
Internet constitue actuellement le systme distribu le plus large au monde et ceci sur
quasiment tous les plans. Des utilisateurs de nimporte quelle position dans le monde
peuvent utiliser les services offerts par le WWW (World Wilde Web), le FTP (File
Transfert Protocole), et autres applications. Les services disponibles peuvent tre
tendus librement et le systme peut tre agrandi par lajout dordinateurs nimporte
quel moment.
Internet a une structure compose dintranets connects par des backbones. Ces
derniers tant des moyens de communication de haute capacit (utilisant des satellites,
la fibre optique, etc.). Les intranets sont la proprit de compagnie et dorganisations
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 8
diverses. Les fournisseurs des services Internet (Internet Service Providers) sont en fait
des compagnies qui offrent des connexions aux utilisateurs dInternet (personne ou
organisation) par des modems et dautre dispositifs qui leurs permettent laccs aux
services dinternent aussi bien que laccs des services locaux tels que lhbergement
de pages WEB.
Bien que couramment confondus, Internet se distingue du WWW. Le World Wilde Web
nest autre quune application parmi tant dautres que Internet supporte. Par exemple,
le FTP est une autre application trs utilise. De mme, lchange Peer-to-Peer (poste
poste) connat actuellement un succs grandissant. Le WWW reprsente un systme
distribu logique consistant en un nombre considrable de ressources (pages Web,
fichiers de donnes et services) rfrences par des URL (Uniform Resource Locator).
Les pages Web contiennent des liens (des URLs) qui rfrencent des ressources et
dautres pages Web. Lensemble des pages Web constitue une toile immense
interconnecte par des liens qui permettent de naviguer dune page lautre et de
dclencher lexcution de services divers. Le WWW est support par des standards et
normes tels que http et Html qui rgissent sa structure et le comportement des logiciels
qui le supportent tels que les serveurs http et les navigateurs internet.
La figure 1.1 donne un aperu sur larchitecture Internet

Intranet





Intranet



ISP


Intranet



Liaison satellite haut
dbit entre backbones
backbone
(Dorsale)
Liaison
rseau

Figure 1.1. Structure dun fragment Internet
1.2.2 Intranet
Lintranet est une portion Internet administre sparment et dlimit de telle sorte
garantir une politique de scurit locale.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 9
Lintranet est typiquement compos de plusieurs rseaux locaux (LAN ou Local Area
Networks) relis par des backbones. Chaque rseau local dispose de ressources gres
par des serveurs. La configuration dun intranet est la charge de lorganisation qui
ladministre et peut varier largement.
Les intranets se connectent Internet via des routeurs qui permettent aux utilisateurs
davoir accs aux services Internet mais aussi davoir accs aux services dautres
intranets.
Les organisations qui administrent les intranets se protgent des menaces extrieures
en utilisant des Firewalls. Ces derniers sont des programmes qui filtrent les donnes en
entre et en sortie en fonction des politiques de scurit adoptes par les organisations.
La figure 1.2 donne un exemple de structure dintranet.
backbone
(Dorsale)






Rseau
Local




Rseau
Local
Rseau Local


Serveur
Web
Serveur
Email
Serveur de
Fichiers
Serveur
Impression
Autres
serveurs
Autres
serveurs
Autres
serveurs
Firewall
Routeur
Vers
Internet

Figure 1.2. Structure typique dun intranet
1.2.3 Les systmes mobiles
Le progrs dans la miniaturisation et les rseaux sans fil laisse envisager le concept de
lespace dinformation totalement connect (fully connected information space) o
chaque entit dote dune certaine fonctionnalit est connecte aux autres entits
moyennant des dispositifs lectroniques et des liaisons sans fil (voir figure 1.3). Ces
liaisons permettent chacune davoir des informations sur les autres et ventuellement
invoquer les services quelles offrent. Comme la majorit des entits sont dynamiques
ont a affaire des systmes mobiles. Le partage de ressources dans de tels systmes
est une tche complexe qui ncessite une certaine forme dorganisation et des
mcanismes et protocoles ad hoc.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 10

Figure 1.3. Espace dinformation totalement connect
La figure 1.4 donne un exemple dorganisation o un utilisateur visitant une
organisation quelconque, accde son intranet (qualifi de Host) via un rseau sans fil
et utilise les ressources et services disponibles (utilisation de limprimante locale, accs
des bases de donnes, ). Ce mme utilisateur, a aussi la possibilit dutiliser,
distance, lintranet de son domicile via un tlphone portable. Cet exemple illustre une
partie de la diversit des possibilits quoffrent les systmes mobiles.
Site daccueil
Imprimante
Portail
WAP
Ordinateur
portable
Host
Intranet
Tlphone
mobile

Intranet
du Domicile
Internet
Rseau
sans fil

Figure 1.4. Exemple dorganisation pour systmes mobiles

Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 11
1.3 PROBLEMES
Actuellement, les applications distribues apparaissent comme une dernire couche au
dessous de laquelle il y a plusieurs autres. On en distingue trois telles quillustres par
la figure 1.5.
M
M
M
M
M
M
Rseau
physique
Machine
physique
SE
SE
SE
SE
SE
SE
Rseau
virtuel
Systme
dexploitation
SV
SV
SV Rseau
virtuel
Middleware
SV
SV
SV
SV
SV
P
P
Rseau
virtuel
Processus ou
composant
dapplication
P
P
P
P
P
P P
Couche
Matrielle
Couche
Syst. Exploitation
Couche
Middlewares
Couche
Applications
P
P
P
Sexcute
sur
P
a
s

d
e

c
o
r
r
e
s
p
o
n
d
a
n
c
e

b
i
j
e
c
t
i
v
e

e
n
t
r
e

r

s
e
a
u
x

P
a
s

d
e

c
o
r
r
e
s
p
o
n
d
a
n
c
e

b
i
j
e
c
t
i
v
e


P
a
s

d
e

c
o
r
r
e
s
p
o
n
d
a
n
c
e

b
i
j
e
c
t
i
v
e



Figure 1.5. Structuration en couches des systmes distribus
Dans chaque couche, il est possible davoir diverses entits relies par un rseau qui est
physique dans la couche matrielle et virtuel dans les autres couches. Chaque couche
matrialise, elle seule, un systme distribu. Cependant, comme les entits de chaque
couche sexcutent en utilisant les services disponibles dans les couches infrieures, les
applications distribues sont donc mises en uvre moyennant plusieurs systmes
distribus. La couche middleware est une couche spcifique pour les systmes
distribus qui est cense cacher les subtilits des couches infrieures et offrir aux
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 12
concepteurs des applications distribues des services plus convenables de nature
rduire leur complexit.
Le schma de la figure 1.5 laisse apparatre une complexit aussi bien au niveau de
chaque couche mais galement une complexit dans les relations qua une couche avec
les autres. Cette situation engendre plusieurs problmes auxquels la conception des
systmes distribus doit faire face, il sagit de lhtrognit, la concurrence, la
scurit, les pannes et labsence dinformations globales. Nous discutons ces problmes
dans ce qui suit.
1.3.1 Lhtrognit (Heterogeneity)
Elle dsigne les diffrences qui existent entre les diffrents composants dun systme
distribu. Ces diffrences peuvent tre au niveau de la couche matrielle (rseaux
physiques et plateformes matrielles), de la couche systmes dexploitation (divers
systmes dexploitation), de la couche middleware et de la couche application
(utilisation de langages de programmation diffrents, etc.).
Ds lors en se retrouve devant une problmatique : les composants dun systme
distribus sont appels cooprer pour partager les ressources mais chaque composant
peut avoir ses spcificits qui limitent ce partage ou le rendent difficile.
Lhtrognit au niveau matriel vient de la diffrence qui existe entre les ordinateurs
aussi bien quentre les rseaux. Dans un mme systme distribu, il est possible de
trouver un ordinateur personnel, une station de travail sophistique ou mme un
ordinateur multiprocesseur puissant. Les rseaux physiques prsentent, eux aussi,
beaucoup de diffrences : rseau de fibre optique, rseau sans fil, taille et structure des
trames, etc.
La couche systmes dexploitation prsente naturellement une htrognit
relativement importante malgr le fait quelle cache les subtilits de la couche
matrielle. Ainsi, certains ordinateurs dans le systme distribus peuvent tre dots
dun systme dexploitation Unix, dautres utiliseront Windows, Mac OS ou Solaris, etc.
Au niveau middleware, il existe actuellement plusieurs possibilits. En effet, Microsoft
propose sa plateforme .Net qui est cense faciliter la coopration entre les objets de
diverses applications ralises avec des langages de programmation diffrents. Corba
est une spcification ouverte du consortium OMG qui a plusieurs ralisations pratiques
qui offrent des moyens de partage et de coordination entre les composants des
applications rparties. Les diffrents middleware sont appels cooprer malgr leur
htrognit pour faciliter la ralisation des applications distribues.
Dans la couche application, lhtrognit provient principalement de lutilisation de
langages de programmation diffrents, ce qui engendre des problmes lors de la
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 13
manipulation des donnes, lappel de procdures, etc. Par exemple, il peut y exister une
diffrence dans le format des donnes o sur un ordinateur on utilise le stockage Little
Endian, et sur un autre, un stockage Big Endian. De mme pour la reprsentation des
chanes de caractres, les tableaux, les structures de donnes complexes (fichiers), etc.
1.3.2 Problme de la concurrence
Le problme de la concurrence provient de la manipulation simultane des ressources
par plusieurs programmes (processus). En effet, certaines ressources ne sont pas
partageables et leur manipulation ne peut se faire que par un processus la fois. Cest
le cas des ressources physiques telles que limprimante mais aussi des ressources
logiques telles que les fichiers, les tables des bases de donnes, etc.
Le problme de la concurrence se pose pour les systmes distribus comme pour les
systmes centraliss (i.e. multiprocesseurs). La gestion de la concurrence dans les
systmes distribus ncessite des mcanismes et des outils tout comme les systmes
centraliss (moniteurs, smaphore, etc.). Cependant, dans le cas des systmes
distribus, la gestion de la concurrence se base en partie sur la communication par
messages et cette dernire introduit dautres sources de difficults, telles que la perte
de messages ou leur corruption, den-t-il faut tenir compte.
1.3.3 Problme de la scurit
Les problmes de scurit se posent pour tous les systmes informatiques. Cependant,
dans les systmes distribus, la vulnrabilit se trouve accentue par la rpartition
mme. Ainsi, il est naturel dans le commerce lectronique quune partie de lapplication
(un client) envoie des messages (par exemple numro de la carte de crdit) un autre
(un serveur). Malheureusement le message peut tre intercept, lors de sa
transmission, et son contenu divulgu, ce qui peut entraner de consquences graves
aussi bien pour le client que pour le serveur.
Dautres problmes se posent aussi, on cite :
Lauthentification : Comment le client (respectivement le serveur) peut-il
tre sr de lidentit du serveur (respectivement le client) ? Par exemple, le
client dune banque a besoin de connatre lidentit de celle-ci avant
douvrir un compte et y dposer une somme dargent, de mme, le serveur
doit connatre lidentit du client avant dentreprendre une transaction
quelconque sur son compte.
Lattaque de services : Souvent les applications distribues sont organises
selon le modle client-serveur o le client invoque les services du serveur.
Ce dernier dispose de ressources en nombre suffisant pour rpondre un
nombre qui peut tre important mais limit. Lattaque de service consiste
submerger le serveur par un nombre de requtes qui excde ces capacits
et ralentit considrablement sa cadence.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 14
Scurit du code mobile : Le code mobile nest autre quun programme qui
migre dune machine lautre dans un rseau dans le but daccomplir une
certaine tche. A son arrive, le code mobile utilise les ressources dune
machine pour accomplir sa tche. Il peut donc prsenter un risque sil
vhicule un virus ou un code malintentionn.
1.3.4 Problme des pannes
Les systmes peuvent chouer dans laccomplissement de leurs tches suite une faille
matrielle ou logiciel quon appelle couramment panne. Les pannes peuvent conduire
des rsultats errons comme elles peuvent engendrer larrt de toute ou partie de
lapplication distribue.
Les pannes peuvent avoir lieu diffrents niveaux de la structure en couches prsente
dans la figure 1.5. Une panne au niveau matriel peut inclure la perte dun message par
le rseau de communication, des erreurs dentre/sortie, la corruption dune donne ou
dun message, etc. Ces pannes, au niveau matriel, se propagent aux niveaux
suprieurs engendrant dautres pannes de niveau suprieur, par exemple arrt
prmatur dun processus.
Les pannes peuvent apparatrent aussi dans les diffrentes couches et se propager
ventuellement aux autres couches. Lorigine des pannes peut tre une raison
matrielle ou une raison logique lie la conception des applications, des middlewares
et des systmes dexploitation. Certaines peuvent avoir comme origine une faille dans la
gestion de la concurrence ou la coordination en gnral. Les pannes dordre logiques
sont innombrables du fait que les applications distribues sont, par nature mme,
complexes. Par exemple, lomission, dans le programme dun processus, de la libration
dune ressource peut conduire une situation dinterblocage. Labsence de lexclusion
mutuelle pour laccs une ressource critique, par exemple un tampon, peut avoir des
rpercussions importantes sur lensemble de lapplication distribue.
1.3.5 Absence des informations globales
Dans un systme centralis, une application se compose de plusieurs processus qui
cooprent pour raliser un objectif commun. A tout moment, il est possible davoir des
informations sur ltat de chaque processus et sur ltat des diffrentes ressources.
Ainsi, chacun des processus peut avoir une vision globale de lapplication et de son
environnement. La prsence de cette vision globale facilite grandement la mise au point
des mcanismes de coordination des processus dont, par exemple, la gestion des
ressources.
La vision globale dans les applications centralises est due au fait que les processus
partage une mmoire commune qui renferme les informations sur les ressources et les
processus.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 15
Dans le cas des systmes distribus, la mmoire commune est inexistante. Chaque
processus se trouve dans un environnement diffrent (systme dexploitation diffrent)
et son tat est une information interne ce dernier. De mme, les informations sur les
ressources partages ne sont pas accessibles en temps rel. De ces faits, la
coordination dun ensemble de processus distribus ncessite le recours la
communication par change de messages. Malheureusement, un message parvient
toujours sa destination avec un certain retard et par consquent linformation quil
vhicule ne reflte pas toujours ltat dun processus ou dune ressource, car ces
derniers peuvent changer dtat durant la transmission du message.
Il est impossible davoir une vision globale instantane de ltat dun systme distribu
et cette situation rend la coordination dans ces derniers un vritable challenge.
1.4 DEFIS ET OBJECTIFS
Comme soulign dans la dfinition des systmes distribus, lobjectif essentiel est le
partage des ressources. Le concepteur dune application rpartie doit, en plus du
dveloppement des programmes assurant les fonctionnalits de celle-ci, tenir compte
des diffrents problmes cits prcdemment et prvoir des mcanismes pour y faire
face de telle sorte faire apparatre le systme distribu comme un tout cohrent.
Ainsi, la complexit inhrente aux applications rparties, sajoute une complexit due
la distribution, ce qui constitue un dfi considrable pour les concepteurs.
Pour faciliter le travail des concepteurs, les couches middlewares ont vu le jour. Ces
dernires offrent des services plus convenables utiliser. Lide de simplifier le
dveloppement des applications en ajoutant des couches qui prennent en charges
certains aspects lis la rpartition nest pas nouvelle. En effet, les systmes
dexploitation eux mmes comprennent des services spcifiques la rpartition.
Cependant, les disparits entre les divers systmes dexploitations et limpossibilit
darriver un consensus ont conduit la cration des couches middlewares.
Faire face aux problmes des systmes distribus signifie apporter une solution
chacun soit au niveau du middleware (voire au niveau des couches infrieures) soit au
niveau de lapplication elle-mme. Rsoudre ces problmes au niveau des middlewares
vise en premier lieu les masquer pour le concepteur de lapplication et par consquent
pour lutilisateur aussi. Si par contre, les problmes sont rsolus au niveau des
applications, on les masque pour les utilisateurs mais ce sont les concepteurs de ces
applications qui doivent les prendre en charge.
Quelque soit le niveau considr, les solutions apportes doivent garantir des proprits
fondamentales suivantes : linteroprabilit, louverture, linvariance lchelle
(scalability), la gestion de la scurit, lefficacit et la disponibilit, le maintien de la
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 16
consistance des ressource, la transparence (flexibilit), la gestion des transactions
rparties, la tolrance aux fautes et la gestion des situations dexception (dtection des
pannes et reprise) etc.
Ces proprits constituent de vritables dfis pour les concepteurs de systmes
distribus. Nous les discutons dans les paragraphes suivants.
1.4.1 Linteroprabilit
Linteroprabilit est une caractristique importante qui dsigne la capacit rendre
compatibles deux systmes quelconques. A son tour, la compatibilit est la capacit
quont deux systmes communiquer sans ambigut. L'interoprabilit ncessite que
les informations relatives aux parties de communication des systmes considrs soient
disponibles sous la forme de standards ouverts.
Linteroprabilit vise rduire le problme de lhtrognit. Le masquage de celle-ci
passe en premier lieu par lutilisation dun protocole unique de communication (e.g. cas
de TCP/IP pour Internet). Pour tablir un change de message, il faut utiliser des
standards qui cachent les diffrences entre les diffrentes plateformes.
Il existe actuellement deux approches principales de standardisation pour masquer
lhtrognit : les middlewares et les machines virtuelles.
Un middleware est une couche logicielle qui masque lhtrognit en offrant aux
programmeurs dune application un modle de programmation plus convenable.
Concrtement un middleware est reprsent par des processus et des ressources dun
ensemble dordinateurs, qui interagissent les uns avec les autres (communiquent et
partagent des ressources).
Un middleware, tel que CORBA ou DCOM, offre des services qui peuvent tre utiliss
pour construire des composants logiciels pouvant fonctionner ensemble dans un
systme distribu.
Les middlewares amliorent la communication en offrant des abstractions telles que
Le RMI (Remote Method Invocation) : Cest la possibilit, pour un objet,
dinvoquer la mthode dun autre objet situ sur une plateforme distante.
La notification dvnement : Les vnements reprsentent un moyen
efficace de propagation dinformation dune plateforme vers une autre ou
plusieurs autres plateformes ou composants dune application rpartie.
Communication entre groupes de processus
Gestion de la duplication des donnes partages
Transmission de donnes multimdia en temps rel
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 17
Les machines virtuelles permettent de supporter le code mobile. Ce dernier dsigne la
possibilit de transfert de code dune machine source une machine destination et son
excution sur cette dernire. En effet, si les plateformes sont diffrentes, le code
produit pour lune ne peut fonctionner sur lautre. Pour viter ce problme, le code
mobile est gnr dun langage source pour une machine virtuelle donne (e.g.
Machine virtuelle de J ava :J VM).
Chaque plateforme doit disposer dune couche logicielle qui implmente la machine
virtuelle. Les machines virtuelles reprsentent une gnralisation des middlewares dans
le sens o elles noffrent pas seulement quelques services communs mais offrent les
mmes services.
1.4.2 Louverture (Openness)
Elle dsigne la possibilit dajout, de suppression ou de modification des ressources et
services dans un systme distribu.
Louverture ncessite que les interfaces logicielles soient documentes est accessibles
aux dveloppeurs dapplications (i.e. publies publiquement).
Le dfi que pose louverture vient du fait que les composants dun systme rparti ont
des origines diverses. Dans ce cadre, on qualifie un systme douvert sil supporte, sans
difficults :
Lajout dordinateurs au niveau de la couche matrielle
Lajout de nouveaux services au niveau application, middleware et systme
dexploitation
La rimplmentation des services anciens
Les systmes ouverts prsentent implicitement une indpendance vis--vis des
constructeurs des plateformes et fournisseurs de produits logiciels.
1.4.3 Linvariance lchelle (Scalability), efficacit et disponibilit
Un systme est dit invariant lchelle (scalable system) sil reste performant et dun
cot raisonnable lors dune augmentation importante du nombre des utilisateurs et de
ressources gres. Par exemple, Internet a connu une volution exponentielle qui a fait
passer le nombre dordinateurs de 188 en 1979 (dbut dInternet) 56 millions en
1999. De ce fait, il peut tre considr comme un systme invariant au changement de
lchelle des utilisateurs et des ressources.
Avoir un systme invariant lchelle signifie :
Lajout dutilisateurs et de ressources est toujours possible
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 18
Le cot dajout est proportionnel au nombre dutilisateurs ou ressources
ajouts
Maintien de bonnes performances ou baisse raisonnable suite aux ajouts
1.4.4 Gestion de la scurit
Rsoudre le problme de scurit revient assurer :
La confidentialit des informations vis--vis des personnes non autorises
la connatre
Lintgrit vis--vis des altrations ou corruptions (i.e. modifications
malintentionnes)
La disponibilit du systme (i.e. pas dinterfrence entre composants qui
engendre un blocage du systme ou dtrioration des performances)
Dans un systme rparti, lchange de message ncessite leur protection et
lauthentification de leur metteur (e.g. cas du commerce lectronique). La
cryptographie et les mots de passe sont trs utiliss actuellement. Cependant, malgr
leur efficacit, ils ne permettent pas dradiquer compltement les problmes pineux
tels que lattaque des services et la scurit du code mobile.
1.4.5 Gestion de la concurrence
Dans les systmes rpartis, une ressource critique peut tre utilise simultanment par
plusieurs processus physiquement rpartis. Une manire simple de grer cette
concurrence consiste crer un processus dit allocateur de la ressource qui accepte les
demandes des processus dits clients (i.e. qui souhaitent utiliser la ressource) puis
autorise un processus la fois utiliser la ressource. Cette solution est contraignante
car le processus allocateur rduit les performances et peut tomber en panne.
Les applications rparties actuelles autorisent lexcution de plusieurs services en
concurrence (e.g. laccs une base de donnes). Chaque demande est prise en
compte par un processus simple, dit thread, et la gestion de la concurrence fait appel
aux mcanismes de synchronisation classiques tels que les smaphores.
Dautres approches plus complexes existent, il sagit dtablir une coordination entre les
processus clients (dits alors processus pairs), chaque demande, de telle sorte que lun
dentre eux puisse accder la ressource au bout dun temps fini.
Notons que la gestion de la concurrence dans un systme distribu implique sa gestion
aussi dans le cas dun systme centralis car les parties impliques dans un systme
distribu peuvent tre des ordinateurs multitches.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 19
1.4.6 La transparence
En gnral, la transparence dun mcanisme ou dun concept signifie son existence et
son utilisation implicite sans que lutilisateur dune application (qui peut tre le
concepteur de lapplication) ne sen rende compte. En dautres termes, un concept est
transparent dans un systme si ce dernier se comporte, vu de lutilisateur, comme si le
concept ny existait pas. Dans les systmes distribus, la transparence signifie que la
rpartition des composants reste cache pour lutilisateur. Ce dernier peroit le systme
distribu comme un tout et non comme une collection de composants indpendants.
Dans ce contexte, on distingue huit formes de transparence :
Transparence daccs : Il sagit dutiliser les mmes oprations pour laccs
aux ressources distantes que pour les ressources locales.
Transparence la localisation : Il sagit de permettre une transparence
daccs aux ressources sans une connaissance pralable de leur
localisation.
Transparence la concurrence : Il sagit de cacher lutilisateur la gestion
de la concurrence en vitant principalement les interfrences.
Transparence la duplication : Dans le but daccrotre la fiabilit
(implmenter dautres formes de transparence) et amliorer les
performances, on a souvent recours la duplication de certaines
ressources (e.g. fichiers de base de donnes). La gestion de cette
duplication ne doit pas tre perceptible par lutilisateur.
Transparence aux pannes : Il sagit de permettre aux applications des
utilisateurs dachever leurs excutions malgr les pannes qui peuvent
affecter les composants dun systme (composants physiques ou logiques).
Transparence la mobilit : Il sagit de permettre la migration des
ressources et des clients lintrieur dun systme sans influencer le
droulement des applications.
Transparence la reconfiguration : Dans le but damliorer les
performances en fonction de la charge (i.e. les demandes de services des
clients), il devrait tre possible de reconfigurer un systme sans que cela
ne soit perceptible par lutilisateur. Par exemple, les sites dits miroirs
permettent damliorer les performances de laccs travers Internet, les
droutement vers ces sites doivent tre non perceptible pour lutilisateur.
Transparence la modification de lchelle (Scaling transparency) : Cest la
possibilit dune extension importante dun systme sans influence notable
sur les performances des applications.
Remarque : Dans certains cas la transparence nest pas souhaitable. Par exemple la
duplication dune imprimante amliore les performances, cependant lutilisateur doit
toujours avoir la possibilit de spcifier explicitement sur quelle imprimante il souhaite
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 20
imprimer ses documents. Cet aspect est particulirement important si les imprimantes
nont pas les mmes caractristiques (qualits) ou ne sont pas situes dans un mme
endroit.
1.4.7 Gestion des situations dexception
Assurer la gestion des situations dexception ou pannes fait intervenir plusieurs
notions :
Dtection : Certaines pannes ou erreurs peuvent tre dtectes facilement
(cas des erreurs de transmission), par contre, dautres pannes ne peuvent
que tre suspectes. Par exemple, la panne dun processus serveur ou
allocateur dune ressource ne peut tre dtecte avec certitude. On ne
peut conclure une panne alors que le serveur nest peut tre que
surcharg ou que les messages sont perdus. Dun autre cot, on peut
attendre indfiniment alors que le serveur est en panne. Cest un dilemme
difficile rsoudre.
Masquage : Il sagit de rendre les pannes autant que possible
transparentes. Pour cela, diffrentes solutions peuvent tre imagines. Par
exemple :
o Retransmission des messages qui ne parviennent pas destination
o Duplication des ressources importantes pour les maintenir
accessibles en cas de problmes (cas de corruption dun fichier)
Tolrance : Certains composants doivent tre programms (voire conus)
pour tolrer des pannes ou transmettre la dtection des pannes aux
utilisateurs (e.g. panne non masquable). Un composant est dit tolrant, sil
profite de/gre la redondance de ressource.
Reprise : La reprise aprs pannes dsigne la possibilit de remise du
systme (principalement les donnes quil manipule) dans un tat cohrent
aprs la dtection dune panne.
1.4.8 Gestion des transactions rparties

Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 21
CHAPITRE 2
ARCHITECTURE DES SYSTEMES DISTRIBUES
CONTENU
2.1 Taxonomie des systmes distribus
2.2 Taxonomie au niveau matriel
2.3 Taxonomie au niveau systmes dexploitation
2.3.1 Les systmes dexploitation distribus
2.3.2 Les systmes dexplotation rseaux
2.4 Architecture des applications distribues
2.4.1 Architecture Client/serveur et multitiers
Principe, rle des processus, rpartition des responsabilits, les variantes du modle
client/serveur (agent mobile, code mobile, proxy, ). Les application WEB et les bases de
donnes, utilit des modles deux tiers et trois tiers, scnario de mise en oeuvre
2.4.2 Le modle Mandataire/Cache
2.4.3 Les architectures Pair--Pair
Inconvnients du modle client/serveur, notions et avantages de processus pairs,
problmes de coordination

2.1 TAXONOMIE DES SYSTEMES DISTRIBUES
On vise par la taxonomie le partage des diffrents systmes existants en catgories ou
classes de telle sorte faciliter leur comprhension et parvenir aux concepts
fondamentaux communs chaque classe. La recherche dune taxonomie nest pas une
tche facile car les systmes distribus sont complexes et varis. Nous proposons dans
ce chapitre une taxonomie trois niveaux qui reflte la structuration en couche
prsente prcdemment (figure 1.5). On rpartie, dans le premier niveau, les
systmes distribus en considrant leur caractristiques matrielles (couche matrielle).
Dans le second niveau, les systmes distribus sont vus sous langle des systmes
dexploitation qui les supportent. Quant au troisime niveau, il est question de
processus dapplication et darchitecture. Il sagit alors dtudier les diverses approches
de structuration (architecture) des applications distribues en termes de composants
(ou processus) et rpartition des rles.
2.2 TAXONOMIE AU NIVEAU MATERIEL
Dun point de vu abstrait, un ordinateur, se compose de deux types dentits : les
mmoires et les processeurs. On peut envisager un systme distribu physique comme
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 22
une collection de mmoires et de processeurs interconnects de telle sorte pouvoir
communiquer. Linterconnexion peut tre faite de diverses faons en utilisant des
technologies varies ce qui donne lieu au schma de taxonomie de la figure 2.1.
Quelque soit le systme distribu considr, il est possible de le classer dans lune des
quatre catgories de la figure 2.1.
Systmes mmoires partages
Processeur
Processeur
Processeur
Processeur
Mmoire Mmoire
Mmoire
Mmoire
Mmoire
Mmoire
Mmoire
Processeur
Processeur
Processeur
Processeur
Processeur
Processeur
Processeur
Processeur
Mmoire Mmoire
Mmoire
Switch
Mmoire
Mmoire
Mmoire
Mmoire
Processeur
Processeur
Processeur
Processeur
Systmes mmoires locales
S
y
s
t

m
e
s

b
a
s

s

s
w
i
t
c
h

S
y
s
t

m
e
s

b
a
s

s

b
u
s

Switch

Figure 2.1. Interconnexion des processeurs et des modules de mmoire
Les systmes mmoires partages sont souvent appels systmes
multiprocesseurs. Les systmes mmoires locales, dits systmes
multiordinateurs, ne partagent pas de mmoires communes mais chaque
processeur dispose de sa propre mmoire dont il est le seul pouvoir y accder.
Dans les systmes multiprocesseurs bass bus, les processeurs est les
modules de mmoire (un ou plusieurs) sont connects un bus commun de telle sorte
que tous les modules de mmoire soient accessibles nimporte quel processeur. Dans
ce type de configuration, le bus constitue un goulot dtranglement qui baisse
considrablement les performances. Ce problme peut tre rduit par lutilisation de
mmoires caches locales chaque processeur. Mais, leur tour, les caches doivent tre
maintenus cohrents, ce qui nest pas une tche facile.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 23
Dans les systmes multiprocesseurs bass switch, les processeurs et les
modules de mmoire sont relis par un dispositif de communication (rseau) utilisant
des switchs (rseau de commutateurs). Lorsque le commutateur entre un processeur
Pr1 et un module mmoire M1 est ouvert, Pr peut accder M1. Le nombre de switch
peut tre important engendrant un cot prohibitif. Pour rduire ce cot, il est possible
denvisager des rseaux avec des configurations diverses. Voir figure 2.2.
Processeur
Processeur
Processeur
Processeur
Mmoire Mmoire Mmoire
S S S
S S S
S S S
S S S
Mmoire
S
S
S
S
Processeur
Processeur
Processeur
Processeur
Mmoire
Mmoire
Mmoire
Mmoire
S
S
S
S
Rseaux de
commutation
Deux types
de switchs

Figure 2.2. Exemples de rseau de commutation
La construction des systmes mmoires locales (multiordinateurs) est plus simple que
celle des systmes multiprocesseurs. Les systmes mmoires locales bass
bus sont construits partir dordinateurs (processeur + mmoire) identiques (on les
qualifie de systmes homognes). Les processeurs sont relis par un rseau multiaccs
partag (Tel que Fast Ethernet) et communiquent par diffusion de messages. Bien que
la bande passante du rseau soit importante (de lordre de 100 Mbps), les systmes
ainsi construits ont une invariance lchelle limite (25 100 noeuds).
Les systmes bass switchs changent des messages par routage travers un rseau
dinterconnexion pouvant avoir plusieurs topologies, allant des grilles simples aux
hypercubes (voir figure 2.3). Les architectures en grilles, souvent prsentes sur un
seul circuit imprim, conviennent pour les problmes deux dimensions (traitement
dimages, thorie des graphes, etc.).
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 24
Grille de processeurs
Les hypercubes quatre dimensions

Figure 2.3. Exemples de systmes bass switchs
Un hypercube est un cube n-dimensions o chaque nud (un processeur) est reli
n autres nuds processeurs. Les hypercubes conviennent la rsolution de problmes
spcifiques tel que le calcul matriciel. Les systmes bass switchs peuvent avoir des
configurations trs varies allant jusqu des superordinateurs massivement parallles
(MPP : Massively Parallel Processors) contenant des milliers de processeurs et dont le
cot se chiffre en millions de dollars.
Les systmes multiordinateurs htrognes sont les plus utiliss actuellement. Les
ordinateurs peuvent avoir des structures et des performances nettement diffrentes et
sont relis par des rseaux htrognes.
2.3 TAXONOMIE AU NIVEAU SYSTEMES DEXPLOITATION
Il existe une relation troite entre les applications distribues et les systmes
dexploitation. Dans un premier lieu, la mise en uvre des applications distribues
dpend des systmes dexploitation qui grent les diffrentes plateformes matrielles
(i.e. les services quils offrent). Dans un second lieu, les systmes dexploitation, eux-
mmes, peuvent tre distribus (cas du systme dexploitation Chorus de Sun)
On peut diviser les systmes dexploitation en deux catgories : Les systmes fortement
coupls et les systmes faiblement coupls. Dans le premier cas, le systme
dexploitation essaye de maintenir une vue globale unique des ressources quil gre. Ce
type de systme tendance rendre la rpartition physique transparente au niveau
des applications. Dans le deuxime cas, on a affaire une collection de plateformes ou
chacune dispose de son propre systme dexploitation mais ces derniers cooprent pour
rendre leur services et leurs ressources disponibles les uns aux autres, il sagit des
systmes dexploitation rseau.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 25
Notons quil est important de signaler que les systmes dexploitation constituent, eux
aussi, des applications distribues. Cependant, contrairement ces dernires, ils sont
implants directement sur les plateformes matrielles et en dpendent fortement.
2.3.1 Les systmes dexploitation distribus
On en distingue deux types :
Les systmes dexploitation des plateformes multiprocesseurs (MPOS)
(considrs comme des systmes rpartis particuliers)
Les systmes dexploitation multiordinateurs (MCOS).
Les MPOS sont conu pour supporter les hautes performances en utilisant des
processeurs multiples. Un des buts des MPOS est de rendre le nombre des processeurs
transparent pour les applications. Dans ces systmes, les processus communiquent via
lutilisation de donnes situes dans des emplacements de mmoire partags. La
protection de ces emplacements est faite par des smaphores ou des moniteurs.
Les MCOS ont une structure totalement diffrente et complexe par rapport aux MPOS.
Ceci est du au fait que les structures de donnes communes ne peuvent tre
simplement places dans une mmoire physique partage. Lunique moyen de
communication et lenvoi de messages (voir figure 2.4).
Plateforme physique A
Rseau de communication
Plateforme physique B Plateforme physique C
Application distribue
Services du MCOS
Services Services Services
Composants Composants Composants
Noyau SE Noyau SE Noyau SE

Figure 2.4. Positions des MCOS
La figure 2.4 peut tre interprte comme suit. Chaque nud du rseau possde un
systme dexploitation qui permet de grer les ressources locales : mmoire,
processeur, disque, . De mme, chaque nud possde un module charg de la
communication entre plateformes (envoi et rception de messages). Sur chaque noyau
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 26
on greffe une couche commune qui implmente une machine virtuelle capable
dexcuter des tches parallles et concurrentes. Cette couche peut faire apparatre
tout le systme dordinateurs comme une machine multiprocesseur en implmentant
une mmoire partage. Dautres services sont assigns cette couche : affecter une
tche un processeur, masquer les pannes matrielles, assurer la transparence la
localisation et la communication interprocessus.
La programmation des systmes MCOS est beaucoup plus difficile que la
programmation des systmes MPOS. La raison est que lutilisation dune mmoire
partage avec une protection par smaphores ou moniteurs est plus simple que la
manipulation des messages. Cette constatation est derrire la solution qui consiste
crer des MCOS en modifiant les MPOS par lmulation dune mmoire partage
virtuelle partir de la mmoire virtuelle de chaque nud.
Par exemple, on peut utiliser la pagination et avoir une mmoire rpartie partage
base sur la pagination. Les pages sont alors rparties sur tous les nuds et on
maintient une table globale des pages qui indique lemplacement des pages sur les
nuds. Cest essentiellement la pagination classique except quau lieu dutiliser le
disque local, on utilise la mmoire virtuelle distante. Lorsquun processeur gnre une
rfrence dune page qui nest pas prsente localement, un droutement lieu, le
MCOS cherche la page et la ramne dans la mmoire locale au processeur ayant gnr
la rfrence, ce dernier pourra alors continuer son excution. La figure 2.5 donne un
exemple dtat dune mmoire partage virtuelle de 16 pages.
Rseau de communication
Plateforme physique A









RAM locale au
processeur P1
2 0 5
15 9
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Plateforme physique B









RAM locale au
processeur P2
3 1 6
10 8
Plateforme physique C









RAM locale au
processeur P3
7 4 11
14 12 13
Espace Virtuel de 16 pages

Figure 2.5. Une mmoire virtuelle partage
Des amliorations peuvent tre apportes cette solution si on considre que certaines
pages sont accdes uniquement en lecture et peuvent de ce fait tre dupliques.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 27
2.3.2 Les systmes dexploitation rseau
Dans ces systmes, on ne suppose pas que les plateformes matrielles sont homognes
et on ne cherche pas faire apparatre lensemble comme un seul systme. Il sagit de
rseaux o chaque nud est une plateforme diffrente sur laquelle sexcute un
systme dexploitation diffrent (voir figure 2.6).
Les systmes dexploitation rseau offre divers services :
Connexion avec une machine distante. Il sagit de faire apparatre une
machine comme un simple terminal dune autre (c d uniquement envoyer
et afficher des caractres).
Copie de fichiers dun nud un autre (sans transparence).
Une amlioration courante de ces systmes consiste crer des serveurs qui cachent la
rpartition des fichiers sur les diffrentes machines et offrent un service de recherche et
de transfert de fichiers aux machines qui sont alors considres comme des clients.
Plateforme physique A
Rseau de communication
Plateforme physique B Plateforme physique C
Application rpartie
Noyau SE Noyau SE Noyau SE
Services SE
rseau
Composants Composants Composants
Services SE
rseau
Services SE
rseau

Figure 2.6. Les systmes dexploitation rseau
Un systme dexploitation rseau prsente plusieurs inconvnients :
Manque de transparence (connexion explicite, copie de fichiers dune
machine lautre explicitement dsignes).
Les machines tant indpendantes, elles sont gres sparment
(lutilisateur dune machine A partir dune machine B doit avoir un compte
sur A et inversement, il faut alors grer les mots de passes, les comptes et
les droits accords).
En contre partie, lajout dune machine peut se faire librement et tout moment.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 28
2.4 ARCHITECTURE DES APPLICATIONS DISTRIBUEES
Naturellement, les applications rparties ont plus dindpendance vis--vis des
plateformes physiques et peuvent de ce fait tre organises dune multitude de faons.
Larchitecture client/serveur et ses variantes constituent actuellement les modles le
plus utiliss dans lorganisation des applications distribues. Cependant dautres
modles existent et leur utilisation augmente de jour en jour ; cest le cas du modle
poste poste (processus pairs) et ses variantes. Il nest pas rare dans les applications
distribues que plusieurs modles soient combins la fois pour tirer profit des
avantages des uns et attnuer les inconvnients des autres. Dans la suite, nous
prsentons les diffrents modles.
2.4.1 Architecture Client/serveur
Cest le modle le plus utilis et le plus important. Les processus reprsentant le
systme rparti, jouent les rles de client pour un service donn et de serveur
pour un autre. Par exemple, un navigateur Internet se comporte comme client lorsquil
sagit de rcuprer une page Web. Un moteur de recherche est un serveur mais devient
un client sil dclenche dautres moteurs de recherches sur dautres sites Web.
Actuellement, les moteurs de recherche typiques comportent plusieurs threads, certains
servent les clients et dautres se comportent comme client vis--vis des autres moteurs
de recherche.
Dans le modle Client/Serveur, on distingue deux sous modles selon que le service est
effectu par un ou plusieurs serveurs (voir figure 2.7). Dans ce dernier cas, plusieurs
serveurs cooprent pour excuter une requte dun client donn (e.g. Rservation de
places davions pour une tourne impliquant plusieurs systmes de rservation).

Client
Serveur

Client
Serveur

Serveur
Serveur
Demande de
service
Rsultat

Figure 2.7. Un client/Un serveur Vs Un client/Plusieurs serveurs
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 29
2.4.1.1 Variantes de larchitecture Client/Serveur
Il existe diverses variantes du modle Client/Serveur, nous les dcrivons ci-aprs.
A. Le modle Client/Serveur et le code mobile (le serveur vient chez le
client) : Lorsquil sagit de code mobile, le modle Client/Serveur prsente une
particularit. En effet, au lieu que le serveur excute un code et renvoi un rsultat,
il renvoi au client le code excutable lui mme (e.g. cas des applets J ava). Ce
modle prsente un avantage important, celui dun temps de rponse meilleur, et
un inconvnient important celui des risques que le code mobile engendre pour la
scurit du client. En effet, le code mobile peut tre dangereux pour les ressources
locales du client. Dans les cas des applets J ava, les navigateurs ne les autorisent
pas accder aux ressources locales du client.
B. Le modle Client/Serveur et les agents mobiles (le client va chez le
serveur) : Un agent mobile est un programme compos de code et de donnes,
qui passent dune plateforme lautre dans un rseau, dont le but de raliser une
tche donne. A larrive, sur une plateforme donne, lagent invoque les services
disponibles et utilise les ressources locales du serveur. Cette approche rduit le
volume dinformations changes sur un rseau et le temps de rponse. Les agents
mobiles peuvent tre utiliss pour :
La ralisation de tches communes telles que comparaison doffre de prix
en visitant les sites des oprateurs conomiques.
Linstallation et la maintenance de logiciels
La rpartition de charge o lagent mobile migre vers les plateformes sous
utilises pour sexcuter plus rapidement (solution teste au centre de
recherche PARC de Xerox)
Comme pour le code mobile, les agents mobiles peuvent prsenter un danger pour celui
qui les accueille. Pour cela, il faut prvoir un accs restreint aux ressources et
lauthentification de celui qui mandate lagent (lagent doit prserver secrtement
linformation dauthentification). Dun autre cot, les agents mobiles sont vulnrables et
ne peuvent continuer leurs tches (survivre), si laccs aux ressources locales leur est
interdit.
C. Le modle Client/Serveur avec clients limits : En gnral, le client dispose
de donnes locales, dun systme dexploitation et dautres logiciels qui sont parfois
difficiles grer et ncessite des utilisateurs qualifis. Pour remdier cela, on peut
allger le client de deux faons :
Client sans logiciels. La machine cliente ne dispose au dpart que dune
application limit qui doit tlcharger un systme dexploitation et les
logiciels ou composants ncessaires partir dun serveur de fichier distant.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 30
Les parties tlcharges sexcutent sur la machine cliente mais les fichiers
sont grs par le serveur de fichiers distant.
Client interface : Dans cette approche, le client dispose dune couche
logicielle qui se contente de jouer le rle dune interface daffichage. Les
applications sont excutes sur le serveur qui doit tre une machine
multiprocesseur puissante.
Les approches qui visent limiter les capacits des clients ont linconvnient de
produire un systme dont le temps de rponse est long spcialement lorsquil sagit des
applications de conception assiste par ordinateur. Notons que dans la pratique, il
existe une panoplie de modles ou le cot client dune application peut avoir plus ou
moins de responsabilit. Ceci est discut dans les paragraphes suivants.
2.4.1.2 Architecture Client/serveur et rpartition des rles
Dans leur grande majorit, les applications visent le support de laccs des utilisateurs
une base de donnes. De ce fait, on distingue trois niveaux diffrents dans une
application Client/Serveur :
Niveau Interface utilisateur. La partie cliente dans une application
implmente, souvent, linterface utilisateur. Ce niveau permet de grer
linteraction de lutilisateur avec lapplication. Linterface utilisateur peut
tre trs simple comme elle peut tre trs sophistique. Dans le cas ou
linterface ne fait que grer laffichage de caractres et leur saisie par un
clavier, lappellation Client/Serveur nest pas trs approprie. Actuellement,
la majorit des applications assignent au clients au moins laffichage
graphique et diverses fonctionnalits utilisant la souris.
Niveau Donnes. Le niveau Donnes dans une application Client/Serveur
contient les programmes qui maintiennent les donnes de lapplication. Les
donnes ce niveau sont persistantes. Dans le cas le plus simple il sagit
dun systme de fichiers, mais, souvent, cest des bases de donnes
compltes qui matrialisent le niveau Donnes. Dans le cas le plus gnral
du modle client/serveur, les donnes sont du cot du serveur.
Niveau Traitement de lapplication dit aussi logique mtier. Le niveau
traitement dpend des applications. Il consiste en un ensemble de
fonctionnalits qui se situent entre le niveau Interface et le niveau
Donnes.
La figure 2.8 illustre ces niveaux travers un exemple. Il sagit de laccs un moteur
de recherche travers le WEB. Le client nest autre quun navigateur Internet qui
affiche les pages Web et transmet les requtes de lutilisateur en utilisant le protocole
HTTP.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 31
Interface
utilisateur
Gnrateur de
requtes
Gnrateur de pages HTML
Gnrateur de listes
ordonnes selon critres
Base de donnes
Pages Web
N
i
v
e
a
u

T
r
a
i
t
e
m
e
n
t

N
i
v
e
a
u

D
o
n
n

e
s

N
i
v
e
a
u

I
n
t
e
r
f
a
c
e

Expressions
de mots cls
Titres des pages web
avec mta-informations

Figure 2.8. Un moteur de recherche sur le Web
2.4.1.3 Architectures multitiers
La rpartition des rles discuts prcdemment, suggre diffrentes possibilits de
rpartition dune application qualifies de rpartition multitiers (Multitiered en anglais).
Le terme Client/Serveur a t traditionnellement associ la configuration matrielle
qui consistait en un microordinateur connect un serveur SQL de base de donnes. Le
terme dsigne, donc, un modle de partage ou les tches sont rparties entre des
couches clientes et serveurs dites tiers.
Larchitecture un tier correspond aux applications classiques des ordinateurs
centraux (mainframe) o des terminaux permettent des utilisateurs dinteragir avec
une application monolitique qui effectue des traitement (logique mtier), gre des
bases de donnes et communique avec lutilisateur.
Dans les architectures deux tiers, lapplication est partage en deux parties qui,
naturellement, rsident sur deux plateformes distinctes. Le client accde directement au
serveur de la base de donnes et les traitement peuvent tre du cot client comme du
cot serveur de la base de donnes sous forme de procdures.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 32
Lorsque les traitements ont lieu du cot client, on a affaire des clients lourds (fat
client). Le serveur gre la base de donnes et reoit des requtes SQL quil excute et
renvoi un ensemble de donnes rsultats au client.
Plus lapplication est importante, plus le client est lourd ce qui ncessite une plateforme
support performante ce qui est un inconvnient important.
Lorsque les traitements rsident du ct du serveur, on parle de serveur lourd. Les
clients ne font quinvoquer les procdures stockes dans le serveur de bases de
donnes. Du point de vue performances, la configuration o le serveur est lourd est
meilleure que la prcdente car la communication entre client et serveur est moins
importante.
Entre client lourd/lger et serveur lourd/lger, il existe une multitude de variantes que
nous illustrons par le schma de la figure 2.9.
Application
Base de
donnes
Interface
utilisateur
Application
Base de
donnes
Interface
utilisateur
Base de
donnes
Interface
utilisateur
Application
Base de
donnes
Interface
utilisateur
Application
Interface
utilisateur
Interface
utilisateur
Application
Application
Basede
donnes
Base de
donnes
Serveur Client

Figure 2.9. Architecture deux tiers
Dans cette figure, on constate lexistence de cinq cas :
1- La plateforme du cot client joue le rle de terminal
2- Lapplication contient un minimum concernant linterface. Linterface est une
couche graphique qui communique avec lapplication
3- Une partie de lapplication est dans la plateforme cliente. Par exemple
vrification des formulaires (consistance) ou dition de textes sur la plateforme
cliente et des fonctions avances sur le serveur.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 33
4- Configuration trs courante. Le client est un microordinateur ou une station
connect travers un rseau une base de donnes ou un systme de
fichiers. Toute lapplication sexcute sur la plateforme cliente mais les
oprations sur la base se font sur le serveur.
5- Ce cas correspond un maintien local au client dune partie des donnes.
Gnralement larchitecture deux tiers nest pas invariante lchelle. Au-del dune
centaine de clients, les performances chutent considrablement.
Dans les configurations plus rcentes, un tiers du milieu est ajout entre le client
et le serveur de la base de donnes. On a alors affaire des architectures trois
tiers o le premier tiers nest autre quun client lger qui implmente une logique de
prsentation, le second tiers dit serveur dapplication, implmente la logique
mtier et le troisime est un serveur de bases de donnes. Dans un environnement
donn, il est possible de trouver plusieurs serveurs dapplication et plusieurs serveurs
de bases de donnes.
Le tier du milieu implmente, en plus de la logique mtier, des oprations de translation
qui convertissent les demandes des clients en requtes de base de donnes et
convertissent les rsultats de ces requtes selon le format utilis par le client.
Souvent, le tiers client interagit avec le serveur de lapplication moyennant un protocole
standard tel que le RPC (Remote Procedure Call) ou HTTP. A son tour, le tiers du milieu
interagit avec le serveur de bases de donnes en utilisant un protocole standard tel que
SQL, ODBC J DBC.
Cette configuration, permet une meilleure invariance lchelle et lutilisation de
protocoles standards permet de crer une indpendance entre les tiers ce qui permet
chacun dvoluer plus facilement : volution de la logique mtier, changement de la
base de donnes en choisissant un autre fournisseur sans alttrer les autres tiers, etc.
Larchitecture multitiers utilise plusieurs tiers du milieu au lieu dun seul tiers milieu
lourd. Ces architectures sont actuellement trs utilises est permettent de supporter
des applications volumineuses en les dcomposant en couches plus simples
dvelopper et maintenir. Nimporte quelle application client/serveur peut tre
implmente avec une architecture multitiers o la logique mtier est dcompose en
plusieurs serveurs.
Comme avantages de larchitecture multitiers, on cite :
Chaque tiers est plus ou moins indpendant des autres ce qui lui permet
dvoluer sans trop de contraintes. En effet, la concentration de la logique
mtier dans les tiers du milieu permet la modification de celle-ci sans
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 34
ncessiter le changement dune multitude de tiers clients qui peuvent tre
physiquement loigns.
Rduction importante du volume dinformations chang sur le rseau (on
change uniquement les informations ncessaires la ralisation dun
service), ce qui amliore les performances.
La base de donnes peut tre partage par plusieurs utilisateurs ayant
chacun sa logique mtier. Ceci est possible par lutilisation de plusieurs
serveurs dapplications diffrents.
Possibilit de rpartir la charge du tiers milieu sur plusieurs plateformes
physiques.
Possibilit de dupliquer les serveurs de lapplication et les serveurs des
bases de donnes.
Dveloppement et maintenance plus aise des applications distribues.
Lutilisation dune architecture trois/multitiers nexclu pas les architectures un/deux
tiers. Si pour une application rduite, un ou deux tiers sont convenables, pour une
application importante larchitecture multitiers conviendrai davantage.
2.4.1.4 Architecture des applications du World Wide WEB
Lide initiale de lien associatifs entre des donnes et des documents dorigines diverses
est attribu douglas Engelbart, directeur de lARC (Argumentation Research Center of
Stanford Research Institute), dans les annes 50.
Le lien associatif est constitu dune rfrence (la cible) et dune ancre (la
source). La figure 2.10 montre un exemple dhypertexte. La rfrence et lancre
rsident normalement dans des nuds informationnels diffrents (textes, image, voire
sons). Il est ainsi possible de tisser une vritable toile reprsentant les liens
smantiques entre diffrentes informations. Lutilisateur peut alors se dplacer dans ce
rseau, passant dun nud lautre selon ses objectifs.
Des outils tels que les systmes de documentations et daides en ligne des logiciels
utilisent cette approche de navigation o lon doit cliquer pour passer dune explication
une autre, suivant ses besoins.
Le contenu des nuds est dsormais tendu dautres types de donnes tels que :
image, graphisme, vido, son, etc, faisant ainsi, voluer le principe de lhypertexte vers
celui de lhypermdia.

Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 35
Smantique
Syntaxe
La syntaxe peut
sexprimer en BNF
o par des
diagrammes
Langage de programmation
Un langage qui possde une syntaxe
et une smantique qui
Il faut un compilateur pour
Par exemple Java
Syntaxe
La syntaxe peut
sexprimer en BNF
o par des
diagrammes
Programme
Compilateur
Programme qui traduit
du langage source vers
un ..
Le langage Java
La syntaxe de java est
proche de celle de C++
.

Figure 2.10. Exemple dun hypertexte
Si on imagine un instant que nous avons disposition un hypertexte et que les nuds
de celui-ci soient rpartis sur les diffrents platefomes de linternet, nous obtenons le
World Wide Web (WWW). Le WWW nest autre quune toile smantique, compose
de page web et de ressources de divers formats, supportes par une toile physique
quest linternet.
Le passage dun nud lautre (dune page lautre) ou navigation est support par
des outils et des protocoles standards. Lutilisateur dispose dun navigateur qui lui
permet, en cliquant sur un lien (dit URL : Uniform Resource Locator), de demander la
ressource ou la page correspondant ce lien au serveur qui la dtient. Le serveur, dit
serveur Web, communique avec les navigateurs en utilisant le protocole nomm HTTP.
Les navigateurs sont compatibles entre eux et ne diffrent que par les fonctionnalits
supplmentaires quils peuvent offrir. Les navigateurs ont pour principale tche
laffichage des pages Web, quils reoivent, aux utilisateurs. Pour cela, les pages
utilisent un codage spcial qui obit la norme HTML.
Les serveurs Web sont des composants qui ont la capacit dinterprter les requtes
invoques par un client et lui renvoyer une rponse. Le serveur Web prend en charge le
protocole HTTP. Il rceptionne les requtes des clients et leur retourne le contenu des
nuds rfrencs. Il sert galement de passerelle (gateway) vers des applications
invoques par les clients. De plus il gre les droits daccs certains nuds et rcolte
des statistiques sur lutilisation des services. Il existe divers serveurs HTTP (par
exemple NCSA httpd dvelopp par National Center for Supercomputing Applications)
dvelopps pour les principales plateformes : Unix, Windows, etc..
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 36
La figure 2.11 illustre un scnario de lchange entre le navigateur et le serveur lorsquil
sagit dun transfert de page Web.
Serveur
Rseau de
communication
Utilisateur Traitement Base de donne Navigateur
Clique
sur/Introduit un
URL
Cration et envoi
dune requte
dfinissant la page
Web demande
Dcodage de page
HTML et affichage
Visualisation
Base de
donnes
Dcodage de la
requte
Construction de
la rponse et
envoi du fichier
Client
Envoi
Envoi
Rception
Rception
Accs la
base
Rcupration
du fichier
correspondant
la page

Figure 2.11. Fonctionnement de lchange entre client est serveur sur le WWW
Lutilisateur clique sur un lien dans une page Web ou tape un URL dans la barre
dadresse dun Navigateur. Le navigateur commence, alors, par ltablissement dune
connexion avec le serveur. Le navigateur utilise ladresse de nom de domaine pour
contacter le serveur. Le navigateur regarde ladresse du nom de domaine, il envoie
ensuite au domaine identifi les en-ttes de requte suivants :
Un en-tte de requte identifiant le fichier ou le service requis (URL)
Des champs den-tte de requte, identifiant le navigateur
Des informations spcialises concernant la requte elle-mme
Les donnes de la requte
On appelle ces donnes en-ttes de requte HTTP. Elles indiquent au serveur quelles
sont les informations que le client demande, et quel type de rponse est accept par le
client.
Une fois la requte rceptionne par le serveur, il lanalyse et extrait le premier en-tte
entrant, appel en-tte de requte Method, et essaie de localiser la ressource qui
correspond lURL son niveau. Pour se faire, il commence par regarder au plus haut
niveau du rpertoire de la racine serveur pour voir sil contient un fichier qui correspond
cette URL. Le serveur regarde le chemin daccs qui suit le nom de domaine, et
regarde si le rpertoire correspondant contient un nom de fichier convenable.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 37
Une fois la vrification termine, le serveur rpond par des en-ttes de rponse valides.
Le premier en-tte de rponse est une ligne dtat qui indique au navigateur client le
rsultat de la recherche de lURL demande. Cette rponse peut tre Succs ou chec.
Si ltat est succs le contenu de lURL demand est gnralement envoy au
navigateur client et saffiche sur lcran de lordinateur du client. Sinon un message
derreur est renvoy.
Lune des caractristiques les plus remarquables, mises notre disposition par les
serveurs Web, est la possibilit de dvelopper des applications ou des scripts que
lutilisateur distant dmarrent, en cliquant sur des URLs ou en remplissant et
soumettant un formulaire HTML. Avec des langages de programmation on peut crer
des applications ou scripts capables de communiquer avec lutilisateur via des pages
HTML construites dynamiquement.
Les applications du cot serveur doivent respecter certains standards dinterfaage dont
principalement la norme CGI (Common Gateway Interface) et la norme ISAPI (Internet
Server Application Programming Interface). Ces applications respectant la norme ISAPI
sont compiles en tant que DLL (Dynamic-Link Libraries) et charges par le serveur
Web son dmarrage.
La programmation des applications Web consiste concevoir et crire des
programmes rsidants dans un rpertoire, dfini comme tant un rpertoire de scripts
chez le serveur, et recevant leurs commande dactivation dune page Web.
Gnralement cette page WEB utilise un formulaire HTML ou des liens directs pour
lancer le programme ou le script. Le formulaire HTML est devenu le moyen le plus
utilis pour lenvoi des donnes sur internet, car il permet de mettre en place des
fentres de saisie, des cases cocher, des boutons radios, etc. ce qui facilite la
rcupration des donnes.
Dune manire succinte, la dmarche suivre pour la conception dune application sur
le WWW comporte les tapes suivantes :
La cration des pages Web contenants des rfrences des programmes
excutables, en utilisant la norme HTML.
Les rfrences sont gnralement des liens directs dactivation des
programmes (scripts) ou des boutons de soumission de formulaires qui
seront remplis et envoys aux programmes de lapplication.
La cration dun ensemble de programmes qui reoivent leur commande
dactivation par des rfrences dans des pages Web. Ces programmes ont
gnralement une interface standard du type CGI ou ISAPI, et rsident
dans un rpertoire dfinie comme tant un rpertoire de scripts dans
larborescence des rpertoires du serveur (gnralement cgi-bin, scripts,
etc.).
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 38
Les programmes reoivent en entre des arguments dits variables denvironnement
quils traitent, et gnrent en sortie des en-ttes de rponses comprhensibles par le
serveur HTTP. Dans le cas o un programme ne fournit rien en sortie, la rponse sera
vide.
La cration des programmes (scripts) se fait par un langage permettant la dfinition des
interfaces (ISAPI, CGI,) des scripts (J ava, Perl, Delphi ou autres).
La cration dune telle application ncessite un certain niveau de programmation ainsi
quune certaine manipulation des serveurs (installation, configuration, etc).
En conclusion, les applications Web sont des applications multitiers qui se caractrise
par :
Des clients identiques consistant en des navigateurs internet
Des serveurs qui se composent principalement dun serveur Web lcoute
sur un port de communication et de programmes dapplication avec
ventuellement une base de donnes
Des changes entre les tiers qui respectent des normes et des protocoles
standards
2.4.2 Le modle du Mandataire/Cache
Un cache est un espace mmoire qui maintient une copie des objets rcemment utiliss
proches, vis--vis du client, que les objets originaux. Un objet reu est ajout au cache
remplaant ventuellement un objet existant. Lorsquun client demande un objet, le
gestionnaire du cache essaye dabord de le trouver dans le cache et le transmettre au
client. Si lobjet nest pas dans le cache, le gestionnaire transmet la demande au
serveur qui dtient lobjet.
Le cache peut tre gr par le client lui-mme comme il peut tre gr par un
gestionnaire indpendant dit Serveur Mandataire (appel aussi Proxy). Dans ce dernier
cas, le cache peut tre utilis par plusieurs clients (voir figure 2.12).
Par exemple, dans le Web, les mandataires maintiennent des caches des pages
rcemment visites mais avant de livrer une page un client, le mandataire vrifie au
moyen dune requte spciale, du protocole HTTP, si la page quil a est conforme
loriginale.
Les mandataires permettent daugmenter les performances en diminuant le temps de
rponse. Les mandataires peuvent implmenter un protocole de scurit tel que les
pare-feu (Firewall). Le modle du mandataire est souvent utilis comme modle
complmentaire avec dautres modles (i.e. combin avec les autres).
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 39
Client

Client
Serveur
Serveur
Serveur
Demande de
service
Rsultat
Mandataire

Figure 2.12. Le mandataire comme intermdiaire entre clients et serveurs

2.4.3 Architecture pair--pair (Peer To Peer)
Dans ce type darchitecture, il nexiste pas de distinction, en terme de clients et de
serveurs, entre les composants (processus) dun systme distribu. Les processus
jouent des rles similaires et cooprent dgal gal pour raliser une activit rpartie
(Voir figure 2.13).


Processus
Processus
processus
Requte de service
et rponse

Figure 2.13. La coopration des processus pairs
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 40
Le terme Peer-to-peer (abrg en P2P), quon peut traduire par pair--pair
(poste poste ou encore gal gal) dsigne tout systme o les
participants (les pairs) mettent en partage des ressources locales (qui peuvent tre des
capacits de traitement, des fichiers, des espaces de stockage, des moyens de
communication, etc.) sans utilisation de serveurs spcifiques.
Les participants partages les ressources locales en tablissant des communications
directes entre eux moyennant les protocoles TCP/IP. Ainsi, chaque participant est la
fois un client et un serveur. Il est serveur de ce quil possde et souhaite partager et
client de ce que les autres mettent sa disposition. Le P2P dsigne donc une classe
d'applications qui tirent profit des ressources matrielles ou humaines qui sont
disponibles sur le rseau Internet.
Linfrastructure support des applications peer-to-peer comprend principalement des
rseaux utilisant les protocoles TCP/IP, protocoles symtriques qui ne font aucune
distinction entre client et serveur, et des composants logiciels particuliers qui
remplissent, la fois, les fonctions de client et de serveur. Ces derniers sont parfois
appel servents (de la contraction de serveur et de client, due Gnutella), ou, plus
communment mais de faon rductrice, clients. Les servents peuvent matrialiser
toute lapplication, et sont alors en interaction directe avec lutilisateur, comme ils
peuvent ne constituer quune couche offrant des services diverses applications. La
figure 2.14 donne un aperu sur linfrastructure dcrite.
Plateforme physique A
Rseau de communication
Plateforme physique B Plateforme physique C
Application distribue
Servent A Servent B Servent C
Systme
dexploitation A
Systme
dexploitation B
Systme
dexploitation C
Application A Application C
TCP/IP TCP/IP
Protocole
P2P
Protocole
P2P
Chat, Partage de
fichiers,
tlphone, etc

Figure 2.14. Infrastructure des systmes P2P
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 41
2.4.3.1 Avantages des systmes Pair--pair
Bien que lutilisation dominante, des systmes P2P, soit, actuellement, le partage de
fichiers, le modle pair--pair va bien plus loin que ce simple partage. En effet, il est
possible de dcentraliser des services et de mettre la disposition des autres
participants des ressources. Vu que chaque utilisateur d'un rseau pair--pair peut
proposer des ressources et en obtenir, les systmes pair--pair permettent de faciliter le
partage d'informations et rendent la censure ou les attaques des services plus difficiles.
En gnral, les systmes P2P prsentent certains avantages par rapport aux systmes
client-serveur :
Rduction des cots. Au lieu dacqurir un nouveau matriel pour
construire une infrastructure client-serveur, il est possible dutiliser les
plateformes existantes avec une approche P2P ce qui vite des dpenses
supplmentaires et rduit le cot dadministration. A titre dexemple, un
rseau de stockage P2P vite le recours aux serveurs de stockages
centraux tout en offrant des performances meilleures.
Invariance lchelle (passage lchelle): La distribution/duplication des
ressources et services permet de rpartir linformation sur lensemble du
rseau P2P et vite lapparition de goulots dtranglements. Ce qui permet
une bonne invariance lchelle. Par exemple, certains systmes dchange
de fichiers tel que Napster (change de fichiers MP3) pouvaient servir plus
de six millions dutilisateurs simultanment.
Rseaux ad hoc : Lapproche P2P est convenable pour les rseaux ad hoc
o la connexion est intermittente. Lutilisateur est libre de se connecter ou
se dconnecter au rseau pour des dures quelconques. Lapproche P2P
est ainsi convenable pour des applications o un contrle centralis nest
pas envisageable. Cas de linformatique diffuse, linformatique mobile, etc.
La fiabilit : Vu que le bon fonctionnement dun systme P2P ne dpend
pas dun participant spcifique mais donne une importance gale chaque
chacun des participants, la fiabilit se trouve amliore. En effet, la panne
dun nud na pas dinfluence sur le systme dans son ensemble, ce qui
nest pas le cas lors de la panne dun serveur dans une architecture client-
serveur.
Ces avantages font des systmes pair--pair des outils prvilegis pour dcentraliser
des services devant avoir une haute disponibilit et des cots de maintenance faibles. Il
sagit des services telsque : la diffusion de donnes multimdia, la distribution des
logiciels et leurs mises jour, la communication tlphonique et messagerie, la gestion
des noms des domaines (DNS), etc.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 42
2.4.3.2 Les inconvnients des systmes P2P
Lapproche P2P prsente des inconvnients importants aussi. En effet, les problmes de
scurit ou de comptabilit sont plus simples rsoudre dans un systme dot dun
serveur central. De mme, la disponibilit des ressources nest pas toujours garantie
lorsque les participants aux systmes P2P sont peu nombreux. La rupture de la
connexion par un participant peut rendre une ressource non accessible si elle nest pas
disponible chez dautres participants. Cest typiquement le cas dans lchange de
fichiers.
2.4.3.3 Les variantes du modle P2P pour le partage de fichiers
Les variantes des architectures P2P peuvent tre classes en quatre catgories :
architecture centralise, architecture dcentralise, architecture hirarchique et
architecture en anneau. Dans la pratique, ces architectures sont souvent combines
pour avoir des systmes distribus P2P hybrides.
A- Architecture centralise : le peer-to-peer assist
Dans une architecture centralise, il doit y exister un serveur qui se charge de mettre
en relation directe tous les participants connects. Le serveur maintient une base de
donne centrale qui consiste en un index de tous noms des fichiers, que chaque
participant met la disposition des autres, coupls avec les adresses IP des participants
qui les possdent. La base ne contient aucun moment les fichiers eux-mmes mais
seulement leurs intituls. La mise jour de la base se fait chaque fois ds qu'un
participant se connecte ou se retire du rseau. La figure 2.15 illustre cette architecture.
Pour tlcharger un fichier, lutilisateur soumet laide du servent une requte
comportant les mots cls pouvant apparatre dans la nom du fichier. Le serveur rpond
avec une liste de noms accompagns des adresses IP correspondantes. Lutilisateur
dispose alors pour chaque fichier dune ou plusieurs adresses IP. Il ne lui reste qu
tablir (en utilisant son servent) une connexion directe avec le servent possdant le
fichier recherch et le tlcharger.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 43
Requte
et rponse
Base de
donnes
Connexion
directe pour
tlchargement

Fichier

Fichier

Fichier

Fichier

Fichier
Serveur
Pair
Pair
Pair
Pair
Pair

Figure 2.15. Architecture centralise
Comme pour larchitecture client-serveur, le point faible de larchitecture P2P centralise
rside au niveau du serveur. En effet, en cas de panne de ce dernier aucun change ne
peut avoir lieu. De mme, le serveur peut tre souvent sollicit ce qui rduit les
performances (bande passante du serveur). La prsence des adresses IP sur le serveur
ne permet pas un change totalement anonyme des ressources.
B - Architecture en anneau
Dans le but daccrotre la fiabilit de larchitecture centralise, le serveur central est
remplac par un anneau virtuel de serveurs. La figure 2.16 donne un aperu sur cette
architecture.
Chaque serveur de lanneau maintien des informations sur les participants qui lui sont
connects et change ces informations avec les autres serveurs. Ainsi, en cas de panne
dun serveur le systme reste oprationnel. Avec une telle approche, on constate une
meilleure disponibilit des serveurs et une rpartition de la charge qui prserve les
performances (rpartitions des demandes de connexions et requtes qui prserve la
bande passante. Larchitecture en anneau est souvent utilise lorsque les machines sont
relativement proches (appartenant souvent la mme organisation).
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 44
Requte
et rponse
BDD
Connexion
directe pour
tlchargement

Fichier

Fichier

Fichier

Fichier

Fichier
BDD
BDD
BDD
BDD

Fichier

Fichier
Serveur
Serveur
Serveur
Serveur
Serveur
Anneau
Pair
Pair
Pair
Pair
Pair
Pair

Figure 2.16. Architecture P2P en anneau
C Architecture hirarchique : Au lieu dorganiser les serveurs en anneau,
larchitecture hirarchique labore plutt une hirarchie qui rduit le volume
dinformations changes entre les serveurs, ce qui prserve la bande passante. La
figure 2.17 illustre ce principe.
D Architecture dcentralise (Le P2P pur) : Dans ce type darchitecture, il
nexiste pas de serveurs. Tous les participants ont le mme statut. Pour rejoindre le
rseau, un participant P doit dabord diffuser un message spcial sur le rseau
physique. Les pairs directement proches de P et qui reoivent ce message renvoient
leurs adresses IP. Vu quil ny a pas de serveurs, les requtes de P seront diffuses
ces voisins et ses derniers les diffusent leurs voisins immdiats et ainsi de suite. Ce
qui engendre un trafic important sur le rseau physique et rduit ainsi les
performances. Les architectures dcentralises prsentent lavantage dtre insensibles
aux pannes des pairs. La figure 2.17 illustre lapproche.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 45
parcours de
lhirarchie
Connexion
directe pour
tlchargement
Pair
Serveur
Serveur
Serveur
Serveur
Serveur
Serveur
Serveur
Pair
Pair
Pair
Pair
Pair

Figure 2.16. Architecture P2P hirarchique
Requte
et rponse
Connexion
directe pour
tlchargement
Pair
Pair
Pair
Pair
Pair
Pair
Pair
Pair
Pair

Figure 2.17. Architecture P2P dcentralise
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 46
2.4.3.4 Quelques exemples de systmes
e-Mule : e-Mule est la version actuelle de e-Donkey qui est n en septembre 2000. Il
adopte une architecture centralise avec une multitude de serveurs et permet le
transfert de tous types de fichiers en utilisant des servents pour les plateformes
windows et Unix.
Chaque utilisateur peut crer son propre serveur et les serveurs sont relis entre eux.
Lors de sa connexion avec lun des serveurs, le pair fournit la liste des fichiers quil
souhaite mettre la disposition des autres. Aprs connexion, le pair a la possibilit de
soumettre une requte de recherche au serveur auquel il est connect ou tous les
serveurs dont les adresses lui sont fournies par les autres pairs. Les fichiers partags ne
transitent pas par les serveurs, ces derniers se contentent de maintenir des index
composs de noms de fichiers et dadresses IP.
e-Mule utilise au niveau bas le protocole UDP et au niveau des servents le protocole
MFTP (Multisource File Transfert Protocol) qui est une variante du FTP o les fichiers
sont dcomposs en blocs et les tlchargements se font par blocs. Il est ainsi possible
de tlcharger les blocs dun fichier de diffrentes sources, ce qui amliore grandement
les performances.
Gnutella : Il sagit dun rseau P2P dcentralis qui a volu au fil du temps dune
architecture semblable celle de e-Donkey vers une architecture P2P pure qui se
caractrise par labsence de serveurs. Pour se connecter au rseau, le servent diffuse
un message particulier sur Internet (dit PING) pour rcuprer les adresses IP et
quelques informations sur les donnes partages des servents les plus proches (Ces
derniers renvoient des messages dits PONG). Une fois la connexion tablie
(Rcupration des adresses IP), le servent envoi des trames de recherche aux diffrents
pairs et rcupre, par des trames rponses, les noms des fichiers partags. Il ne reste
plus qu tlcharger directement le fichier slectionn du pair qui le dtient. Comme
pour e-Mule, Gnutella utilise le protocole MFTP.
Divers servents Gnutella existent pour les plateformes Windows, Unix et Macintosh :
Pour Windows : Gnutella Clients, BearShare, Gnucleus, Morpheus,
Shareaza, Swapper, XoloX, LimeWire, Phex
Pour Unix et Linux : Gnutella Clients, Gnewtellium, Gtk-Gnutella, Mutella,
Qtella, LimeWire, Phex
Pour Macintosh : Gnutella Clients, LimeWire, Phex
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 47
CHAPITRE 3
LES PARADIGMES DE COMMUNICATION
CONTENU
3.1 Le passage de messages
Quest ce qun Message?, les primitives de communications, primitives bloquantes et non
bloquantes, les primitives de passage de messages buffriss
3.2 Le RPC (Remote Procedure Call)
Principe, mcanismes et concepts utiliss, paramtres et rsultats dans le RPC, ldition des
liens, exemple
3.3 Le RMI (Remote Method Invocation)
Principe, mcanismes et concepts (interfaces, classes, stub, ), J ava RMI
3.4 Communication par vnements et notifications
Principe, metteur/rcepteur, abonnement, notification
3.5 Communication de groupe
Principe, structure dun groupe, oprations sur les membres (ajout, suppression, recherche,
), laboration de la communication (diffusion, ordonnancement des messages, )
3.6 Communication par mmoire partage
Principe, mcanisme dutilisation, maintien de la mmoire (cration, protection, )
3.7 Communication par flux

Lobjet dune communication est de faire parvenir une information transmise par un
processus un autre processus. Cette information peut tre utilise diffrentes fins :
synchronisation, demande de service, renvoi de rsultats, communication dun tat, etc.
On distingue principalement deux types de communication : La communication par
message et la communication par mmoire commune. Cette dernire tant utilise le
plus souvent dans le cas des systmes multiprocesseurs et sa mise en uvre est plutt
triviale.
Il existe dautres outils de communication plus volus qui font appel la
communication par message dans leur mise en uvre. Il sagit de lappel de procdure
distance (Remote Procedure Call ou simplement RPC), de linvocation de mthode
distance (Remote Method Invocation ou simplement RMI) et de la notification
dvnements. Dans ce chapitre, nous dcrivons ces outils.
3.1 LE PASSAGE DE MESSAGES
La communication par message est supporte par deux primitives de communication
quon peut nommer Send et Receive. Un processus P communique avec un processus
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 48
Q en lui envoyant une squence doctet au moyen de la primitive Send. Q reoit cette
squence en utilisant la primitive Receive.
Process P ;
Begin

Send ( M, Q) ;
/ / M est l a squence d oct et

End ;
Process Q ;
Begin

Recei ve ( Mes, P) ;

End ;
Limplmentation de Send et Receive soulve deux problmes particuliers : la
synchronisation et ltablissement dun canal de communication. Nous les discutons
dans ce qui suit.
3.1.1 Problme de la synchronisation lors de la communication
Avant de pouvoir changer une information, les processus doivent, souvent, se
synchroniser dabord (i.e. lun attend lautre). On distingue plusieurs possibilits selon
que les primitives Send et Receive soient bloquantes ou non pour le processus qui les
excute. Lorsque Send et Receive sont toutes les deux bloquantes, on parle de
communication synchrone. Dans ce cas, si un processus excute Send avant que lautre
nexcute le Receive, le processus metteur reste bloqu en attente et inversement. Le
dblocage aussi bien de lmetteur que du rcepteur, intervient lorsque le processus
receveur reoit le message et son excution est relance.
Dans la forme asynchrone de communication, le Send nest pas bloquant pour
lmetteur. Il consiste mettre le message dans un buffer et le systme dexploitation
se chargera de le faire parvenir destination. Le processus metteur continue alors son
excution sans attendre que le message parvienne sa destination. Si le buffer ddi
la communication est plein le Send devient une opration bloquante jusqu ce que une
place se libre. Autrement dit, le processus ne continue son excution que lorsque le
systme dexploitation prend en charge lenvoi du message.
Le Receive peut tre bloquant ou non. Dans le cas ou le Receive est non bloquant, le
receveur continue son excution aprs lopration Receive qui consiste, alors, spcifier
seulement un buffer qui accueillera le message. Une fois le buffer rempli, le Receveur
sera inform par interruption ou par scrutation. Le Receive non bloquant est difficile
mettre en uvre et est peu utilis car il rend la logique de programmation complexe.
3.1.2 Problme du canal de communication
Un canal de communication est dfini par la paire (Expditeur, Destinataire). Une
solution simple serait la spcification dun canal de communication en utilisant les noms
des processus. Cette approche prsente linconvnient de ne pas convenir aux systmes
rpartis car, on ne connat pas pralablement les noms des processus, de plus, ces
processus peuvent provenir de programmes qui ont t dvelopps indpendamment
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 49
les uns des autres. Autrement dit chaque processus peut avoir un espace de nommage
diffrent non connu au moment de la compilation des programmes des autres
processus. Mme si ces noms sont connus au moment de la compilation, il faut aussi
connatre leur quivalent aprs compilation pour pouvoir mettre les processus en
correspondance. Ce qui complique encore les choses, cest le fait quun processus
serveur est souvent dvelopp pour servir plusieurs clients pralablement inconnus.
Dans les systmes actuels, le canal de communication consiste en une paire de Socket
(quon peut traduire littralement par Prise), un pour lmetteur et un pour le rcepteur.
La communication consiste, alors, transmettre des messages entre les deux sockets.
Cest le cas dans les systmes BSD Unix, Windows et MacOS.
Un socket nest autre quun port et une adresse Internet. Ladresse Internet spcifie
une machine et le port spcifie un point (i.e. numro) dmission ou de rception dans
celle-ci. Les ports sont identifis par des numros entiers sur 16 bits et leur nombre
peut atteindre 2
16
pour une machine donne. Les ports sont, simplement, des numros
qui correspondent des buffers de communication au niveau du systme dexploitation.
Un port peut tre associ, au plus, un processus receveur mais peut avoir plusieurs
metteurs.
Pour quun processus reoive des messages, son socket doit spcifier un port local et
une des adresses Internet de la machine sur laquelle il sexcute. Les processus
utilisent les mmes sockets pour lmission et la rception (voir figure 3.1).
Plateforme avec
adresse AdS

Plateforme avec
adresse AdC
Client Serveur
AdS, Pr1
Message 1
Pr1
Pr0
PrN
Pr1
Pr0
PrM
AdS, Pr1
Message 1
AdS, Pr1
Message 1
Message 1
Port
Socket
Rseau de
communication

Figure 3.1. Emission et rception par sockets
3.2 LE RPC (REMOTE PROCEDURE CALL)
Une des formes de communication dans un systme centralis et lappel de procdure.
Un processus appelle une procdure en lui transmettant des paramtres celle-ci
sexcute et met jour ventuellement un espace mmoire. Un autre processus peut,
ensuite, appeler cette mme procdure ou une autre pour rcuprer/utiliser le contenu
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 50
de lespace mmoire en question. Lide du RPC est simple, elle consiste, pour un
processus P, appeler une procdure se trouvant sur une autre plateforme, au lieu
quelle soit sur la mme plateforme que P (i.e. dans son espace accessible de
nommage).
Le RPC peut tre nonc comme suit : Un processus P sur un site S1 donn appelle une
procdure M sur un autre site S2 en lui transmettant ventuellement des paramtres.
Suite cet appel, P est suspendu et M est excute sur le site distant S2. Le transfert
dinformation est concrtement effectu par les paramtres de S1 vers S2 et par le
rsultat que la procdure retourne du site S2 vers S1.
Malgr la simplicit de lide, le mcanisme RPC est difficile mettre en uvre car :
Lmetteur et receveur sexcutent sur deux sites diffrents, donc deux
espaces dadressage diffrents et il faut transmettre les paramtres et le
rsultat.
Les deux sites peuvent tomber en panne.
Dans limplmentation du RPC, lobjectif est toujours doffrir un mcanisme qui rende
lappel distant semblable lappel local (i.e. on cherche garantir la transparence du
mcanisme pour le programmeur).
Pour bien cerner le mcanisme du RPC, considrons un exemple dun appel local de
procdure :
Process P ;
Begin

Cpt : = Li r e ( F, Tampon, Nbr Oct et ) ; / * F est un f i chi er
l ocal , Tampon est dest i n cont eni r l es i nf or mat i ons l ues et
Nbr Oct et est l a t ai l l e de l i nf or mat i on l i r e * /

End ;
Considrons maintenant ltat de la pile dexcution avant et pendant lappel (figure
3.2).
On remarque que F, NbrOctet sont passs par valeur (cest leurs valeurs qui sont
transmises la procdure et occupe un espace dans lespace pile de celle-ci). A
loppos, Tampon est pass par rfrence, en dautres termes, cest juste une adresse
qui est transmise la procdure. Cette adresse indique lespace pile du programme
appelant ou ventuellement un espace mmoire quelconque contenant la valeur de
Tampon.


Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 51

Etat avant lappel
Sommet de pile
Variables locales au
contexte appelant et
rfrence sur des
variables globales
Rfrence Tampon
Segment de donnes
Tampon
Etat pendant lappel
Sommet de pile
Variables locales au
contexte appelant et
rfrence sur des
variables globales
Rfrence Tampon
Adr de retour
Segment de donnes
Tampon
NbrOctet
Tampon
F
Variables passes la
fonction Lire

Figure 3.2. Evolution de la pile dexcution lors dun appel de procdures
Un appel local ncessite lintervention du programmeur, du compilateur et de la
plateforme dexcution :
Le programmeur place une instruction dappel une procdure dans son
code.
Le code de la procdure est extrait de la librairie puis insr dans le
programme objet par le compilateur (cest ldition des liens).
Lexcution de lappel par le processus appelant bloque ce dernier jusqu la
fin de la procdure.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 52
Pour raliser une implmentation transparente du RPC, le compilateur insre dans le
code objet du client non pas le code de la procdure appele mais sa Souche (on parle
de souche du client ou Client Stub). Celle-ci se trouve normalement dans la
librairie qui accompagne le programme.
Contrairement la procdure originale, la souche ne vas pas sexcuter et produire le
rsultat mais elle se contente de construire un message partir des paramtres et
lenvoi au serveur puis excute un Receive bloquant qui bloque la souche, donc le
processus appelant, pour attendre la rception du rsultat du serveur (voir lillustration
la figure 3.3).
Client


Souche Client
Temps
Message
Formation dun
paquet (nom
procedure
+
paramtres)
Appel
Send (Message)
Receive (Rsultat)
Extraction du
rsultat
Serveur






Souche Serveur




Procdure
Rsultat
Appel
Receive (Message)
Send (Rsultat)
Extraction des
paramtres et
appel de la
procdure
Formation
dun paquet
rsultat
Rsultat
Rsultat

Figure 3.3. Communication entre client et serveur par RPC
A larrive du message, le systme dexploitation ne le passe pas directement la
procdure appele mais sa souche du cot serveur (on parle de souche serveur ou
Server stub). La souche du serveur a, pralablement, excut un Receive et sest
bloque pour attendre le message de la souche client. Une fois ce message arriv, la
souche serveur extrait les paramtres puis appelle la procdure du serveur.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 53
Si le serveur supporte plusieurs procdures accessibles distance, la souche du serveur
doit comporter une instruction de choix multiple. Lappel effectu par la souche serveur
de la procdure en question est un appel local dont les paramtres sont des variables
initialises par les valeurs reues dans le message.
Il demeure un problme difficile qui est celui des paramtres pass par rfrences. La
solution consiste transformer lappel par rfrence en un appel par copie/restauration.
Ce dernier consiste transmettre le contenu du paramtre pass par rfrence la
souche du serveur qui le place son tour dans un emplacement accessible la
procdure appele. Cette dernire le modifie puis la souche du serveur transmettra une
copie la souche client qui lui permet de restaurer la valeur du paramtre pass par
rfrence.
Une optimisation peut tre envisage selon que le serveur ne fait que modifier la copie
ou ne fait que consult la copie. On peut alors liminer soit lenvoi de la copie soit
lopration de restauration.
Remarques :
Certaines structures telles que les arbres sont difficiles transmettre. Il est
possible de faire un va et vient entre les souches pour acqurir les lments
des structures complexes selon le besoin.
La gnration des souches se fait suite une description dinterface
(contenant les enttes des procdures accessibles distance) dans un
langage spcifique souvent appel IDL (Interface Definition Language). Le
programmeur du cot client na besoin que de cette interface pour spcifier
des appels aux procdures dans ces programmes (i.e. processus). Du cot
serveur, le programmeur doit implmenter les diffrentes procdures
dfinies dans linterface. Dun cot comme de lautre, les souches sont
gnres automatique.
Dans le cas o une procdure ne retourne aucun rsultat, le serveur peut
retourner avant lexcution de la procdure un accus de rception de la
demande qui libre la souche client et par la suite le processus client. Dans
ce dernier cas, on parle de RPC asynchrone.
3.3 LE RMI (REMOTE METHOD INVOCATION)
Le RMI est une approche spcifique au paradigme orient objet o lapplication est vue
comme une multitude dobjets et o chacun communique avec les autres en appelant
leurs procdures ou mthodes (on parle dinvocation de mthode et souvent de
passage de message entre objet). Linvocation de mthode est souvent une opration
bloquante.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 54
Vu que les applications bases objets sont logiquement partitionnes en objets, la
rpartition de ces objets sur diffrents processus et plateformes (ce qui donne une
application rpartie) est considre comme une extension naturelle de lapproche base
objets.
Dans une architecture Client/Serveur, les objets sont rpartis en deux catgories vis--
vis dun service donn, les objets clients et les objets serveurs. Les clients peuvent
invoquer les mthodes dautres objets (dits alors serveurs) sur le mme site, on parle
dans ce cas dinvocation locale, ou sur des sites distants, il sagit alors du RMI (voir
figure 3.4).

Site A
Ob1

Site B
Site C
RMI Invocation locale
Ob2
Ob5
Ob3
Ob4
RMI

Figure 3.4. Invocation locale et invocation distance
Dans un site donn, lensemble des objets qui peuvent recevoir un RMI est gr par un
module serveur. Il intercepte les message envoys par les clients et dispatche chacun
lobjet serveur correspondant. Ce dernier excute la mthode correspondant au
message puis renvoie le rsultat au module serveur qui le transmet au client. A un
moment donn, plusieurs excutions de la mme mthode peuvent tre invoques.
Dans certains cas, il est ncessaire de faire une synchronisation.
Dans une approche base objets, certains aspects sont noter :
Rfrence des objets distants : Chaque objet susceptible de recevoir un
RMI doit avoir une rfrence distante qui consiste en un identificateur
unique travers tout le systme rparti. La rfrence distante peut tre
construite par une concatnation comme suit :
Adresse
Internet
Ndu port du processus
ayant cr lobjet
Moment de
cration
Numro local de
lobjet
Les rfrences distantes peuvent tre passes comme paramtres et rendus
comme rsultat.
Linterface distante : Chaque objet distant (qui peut recevoir un RMI)
dispose dune interface consistant en un nombre de mthodes que sa classe
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 55
implmente. Les objets dans dautres processus ne peuvent invoquer ces
mthodes que sils disposent des formes exactes de leurs signatures (nom,
paramtre et type du rsultat retourn). Cest pour cela que la dfinition des
interfaces est ncessaire. Elle consiste, dans le cas du RMI, en une srie de
signature de mthodes. Les objets locaux peuvent invoquer les mthodes
dfinies dans linterface en plus de linvocation dautres mthodes
implmentes localement. Dans le mcanisme RMI de J ava, les interfaces
distantes sont dfinies de la mme faon que les autres interfaces,
cependant elles hritent de linterface particulire nomme Remote. Dans
CORBA, le langage spcifique IDL permet de spcifier les interfaces
distantes.
Collecteurs de miettes : La rcupration des espaces allous aux objets
requiert la coopration des diffrents collecteurs de miettes distants. En
effet, le collecteur de miettes local ne peut disposer de lespace allou un
objet que lorsquil ne subsiste plus aucun objet distant maintenant une
rfrence sur le premier
Les exceptions : Limplmentation du RMI doit tre capable de grer des
exceptions lies la rpartition aussi bien que celles lies lexcution
classique des mthodes.
Limplmentation du RMI fait intervenir plusieurs composants dont chacun joue un rle
spcifique. La figure 3.5 donne un aperu sur les intervenants. Nous dcrivons juste
aprs le rle de chacun.
Client
Objet A
Serveur
Proxy de B
Module Rfrences
distantes
M
o
d
u
l
e

C
o
m
m
u
n
i
c
a
t
i
o
n
s

Objet B
Module Rfrences
distantes
M
o
d
u
l
e

C
o
m
m
u
n
i
c
a
t
i
o
n
s

Squelette et
Distributeur
de la classe B
Demande
Rponse
RMI

Figure 3.5. Composants intervenant dans limplmentation du RMI
Rle du module de communication : Les deux modules de communication se
chargent de la transmission de la demande du client vers le serveur et la transmission
de la rponse du serveur au client. La demande et la rponse sont des messages
composs comme suit :
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 56
Type message (0 pour demande et 1 pour rponse)
Identificateur de demande (un entier qui sera retourn avec la rponse)
Rfrence dobjet (spcifie prcdemment)
Identificateur de mthode (un entier ou un nom si on utilise le mme
langage avec possibilit de rflexion)
Arguments (tableau doctet)
Les modules de communication utilisent uniquement les trois premiers champs (ils les
consultent lors de la transmission).
Au niveau du serveur, le module Communications slectionne le distributeur de la classe
de lobjet invoqu et lui passe la rfrence locale de lobjet obtenu du module des
rfrences distantes. La couche logicielle qui implmente le RMI est constitue
essentiellement du proxy, du squelette et du distributeur (nomms parfois objets
middleware). Elle est construite sur les modules Communications et Rfrences
Distantes.
Rle du module Rfrences Distantes : Il est responsable de la translation entre
rfrences locales et rfrences distantes et de la cration des rfrences distantes
pour des objets. Pour cela, le module Rfrences Distantes dans chaque processus
maintient une table dobjets distants qui donne la correspondance entre une rfrence
distante (globale) et la rfrence locale dun objet dans le processus. La table doit
contenir une entre pour chaque objet distant manipul par les processus et une entre
pour chaque Proxy local.
Les principales oprations des modules Rfrences Distantes sont :
Lorsquun objet distant est pass comme paramtre ou rsultat pour la
premire fois, le module Rfrences Distantes distant est charg de crer
une entre qui lui corresponde dans sa table.
Lorsquune rfrence distante arrive dans une demande ou rponse, le
module doit fournir la rfrence locale correspondante. Celle-ci indique soit
un Proxy soit un objet distant. Dans le cas ou celle-ci nest pas dans la table,
un Proxy sera cr et le module ajoutera sa rfrence dans sa table.
Rle du Proxy : Le Proxy offre une transparence lobjet appelant en se comportant
comme lobjet appel. Cependant, au lieu dexcuter une mthode, il constitue un
message et lenvoi lobjet distant puis rcupre le rsultat et le transmet lobjet
appelant. Le Proxy cache tout le dtail de la gestion de linvocation de lobjet distant.
Il existe un objet Proxy pour chaque objet distant. La classe du Proxy implmente la
mme interface que la classe de lobjet distant. Mais cette implmentation diffre de
celle de la classe de lobjet distant. Chaque mthode dans le Proxy forme un message
de demande, lenvoi lobjet distant puis rcupre le rsultat et le transmet lobjet
appelant.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 57
Rle du distributeur : Le serveur a un distributeur est un squelette pour chaque
classe dun objet distant. Le distributeur reoit la demande du module Communication,
utilise lIdentificateur de mthode pour slectionner, dans la table, la mthode
approprie du squelette et lui transmet la demande. Le distributeur et le Proxy utilisent
le mme identificateur de mthode pour une mthode de linterface distante.
Rle du squelette : Il implmente les mthodes de linterface distante, en extrayant
les arguments et en invoquant la mthode de lobjet distant. Ensuite il attend le rsultat
puis forme un message rsultat (avec ventuellement des exceptions) et le renvoi au
Proxy (i.e. sa mthode invocatrice).
Remarques :
Au dpart, les programmes clients on besoin davoir une rfrence distante
pour au moins un objet distant. Lditeur de liens pour un systme rparti
est un service spar qui maintient une table contenant la correspondance
entre les noms textuels et les rfrences distantes. Cette table sera utilise
par les serveurs pour enregistrer les objets distants et par les clients pour la
recherche.
Pour viter quune excution dune mthode invoque ne retarde une autre,
les serveurs lancent un thread spar pour chaque invocation distante.
Dans la suite nous donnons un scnario du RMI du cot client

Objet a

b. mb ( i , j , k) ; / / Va au pr oxy
/ *b est l e pr oxy de l obj et di st ant qui excut er a l a demande */



Proxy de lobjet b / / I l mai nt i ent une r f r ence di st ant e de b

mb1( ) {}
mb2( ) {}
mb( i , j , k) {}

Etape 1 : For mer un paquet r equt e + pl us cr at i on des r f r ences
di st ant es de i , j et k si el l es n exi st ent pas dj
0 ( Si gni f i ant Requt e)
15 ( Numr o de l a r equt e)
b ( Rf r ence di st ant e de l obj et b)
3 ( numr o du ser vi ce, dsi gne l a mt hode mb( ) )
01AF8531C ( oct et s r epr sent ant l es par amt r es)
Etape 2 : Envoyer l e paquet en i nvoquant un ser vi ce du modul e
Communi cat i ons
Etape 3 : At t endr e pui s r ecevoi r l e paquet r ponse
1 ( Si gni f i ant Rponse)
15 ( Numr o de l a r equt e)
( non ut i l i s)
( nomut i l i s)
AB0018F ( oct et s r epr sent ant l e r sul t at )

Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 58
Etape 4 : Ext r ai r e l e r sul t at et l e r et our ner l obj et a ( si l a
val eur r et our ne est une r f r ence d obj et , on cher che sa
r f r ence l ocal e et on l a t r ansmet . S i l n y a pas de r f r ence
l ocal e on cr e un pr oxy l ocal pour l obj et r f r enc et on
t r ansmet sa r f r ence)
. . .
}

3.4 COMMUNICATION PAR EVENEMENTS ET NOTIFICATIONS
Dans un systme, un objet peut ragir un changement qui touche un autre objet. Ce
changement est considr comme un vnement. Par exemple, un clic sur le bouton
dune souris ou la saisie dun texte dans une fentre, constituent des vnements qui
sont notifis aux objets responsables de laffichage.
Dans un systme rparti, la notification ne se fait pas seulement pour les objets locaux
mais pour les objets rsidants sur dautres sites ; ce qui est une extension naturelle.
Les systmes rpartis bass sur les vnements utilisent un mcanisme dit de
publication/abonnement. Un objet qui gnre des vnements publie le type
dvnement quil rend observable aux autres objets. Les objets qui souhaitent recevoir
des vnements, souscrivent un abonnement aux types qui les intressent. Les
vnements peuvent correspondre lexcution de certaines mthodes par un objet.
Les objets qui reprsentent les vnements sont appels notifications. Les notifications
peuvent tre sauvegardes, envoys dans des messages ou utilis de diverses faons.
Les systmes rpartis bass sur les vnements ont deux caractristiques :
Lhtrognit : les diffrents composants sont htrognes mais pour
garantir la communication, il faut utiliser le mcanisme de
publication/abonnement.
Lasynchronisme : les objets gnrateurs dvnements sont totalement
dcoupls des objets abonns. Aucune synchronisation na lieu. Cependant,
les abonns peuvent rester en attente dun objet notification.
Dans un systme rparti bas sur les vnements, on trouve un ensemble dobjets et
des participants :
Objets centre dintrt : Ce sont les objets qui changent dtats suite des
oprations quelconques.
Evnements : Correspondent souvent la fin de lexcution dune opration
sur un objet centre dintrt.
Notification : Objet contenant une information sur lvnement. Il contient
gnralement le type de lvnement, les attributs qui indiquent ltat de
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 59
lobjet centre dintrt, la mthode invoque, le temps doccurrence et un
numro de squence.
Abonns : Des objets intresss par un type dvnement et qui reoivent
des notifications.
Objets observateurs : Ils permettent de dcoupler les abonnes et les objets
centre dintrt. Chaque objet centre dintrt peut avoir plusieurs abonns
avec des intrts diffrents (valeurs diffrentes pour les attributs) et les
objets observateurs permettent de maintenir des objets centre dintrt
simples.
Objets diteurs : Un objet diteur est un objet centre dintrt ou un
observateur qui dclare son intention de gnrer des notification dun type
donn.
La relation entre les diffrents objets peut se faire de diverses faons (voir figure 3.6)
Service
dvnements

Objet centre
dintrt

Abonn

Abonn

Abonn

Objet centre
dintrt

Objet centre
dintrt

Observateur

Observateur
Notification
Notification
Notification
Si lobjet centre
dintrt est
externe au service
dvnement,
lobservateur doit
linterroger
rgulirement pour
savoir si un
vnement a lieu

Objet centre
dintrt

Figure 3.6. Relation entre objets
Les observateurs ont pour rle de :
Transmettre des notifications
Filtrer des notifications
Oprer des compositions dvnements
Servir comme bote aux lettres : Un observateur peut maintenir linformation
en attendant que labonn la rclame (synchronisation).
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 60
3.5 COMMUNICATION DE GROUPE
Lorsquil sagit de la communication dun processus avec un groupe dautres processus,
les modes de communication prsents prcdemment ne sont pas convenables. La
communication multicast (diffusion) est prfrable ; elle consiste envoyer un
message vers un groupe et non plus un seul processus.
Lopration multicast peut tre utilise diffrentes fins :
Tolrance aux fautes : Il sagit de dupliquer le processus serveur (i.e.
former un groupe de serveurs) de tel sorte ce quun processus client
adresse sa requte au groupe plutt qu un processus spcifique. Chaque
serveur du groupe excute la mme requte et ainsi le client aura plus de
chance dtre servi mme si certains processus du groupe chouent.
Dcouverte des services dans un rseau ad hoc : Il sagit de rechercher
dynamiquement des interfaces pour construire par la suite des requtes
invoquant des services particuliers de celles-ci. Un client peut diffuser un
message non pas pour demander lexcution dun service donn mais pour
rcuprer une interface. Les serveurs, leur tour, utilisent des oprations
multicast pour enregistrer leurs interfaces dans divers sites.
Mises jour des donnes dupliques : Lorsquon souhaite amliorer les
performances par la duplication des donnes, lopration multicast est
utilise pour diffuser les nouvelles valeurs des donnes chaque
modification.
Notification des vnements : La notification des vnements fait
naturellement usage de lopration multicast pour notifier les abonns.
Lavantage dune opration multicast rside dans le fait que le processus qui lutilise
gnre une seule opration pour envoyer un message tout le groupe ce qui est
convenable du point de vue programmation mais aussi du point de vue efficacit et
fiabilit.
Sur le plan efficacit, limplmentation du multicast peut se limiter envoyer un
message une seule fois sur chaque lien. Cela est possible en donnant au groupe la
forme dun arbre et en utilisant le support hardware pour le multicast chaque fois que
cela est possible. Par exemple, si un message doit tre transmis deux fois deux
destinataires qui se trouvent dans le mme rseau Ethernet, un multicast-IP permet
dacheminer un seul message jusquau dernier routeur qui utilise le multicast dEthernet
pour transmettre une copie du message chaque destinataire.
Sur le plan fiabilit, le multicast qui est implment par une suite dopration Send
(nomm Multicast-basic) nest pas fiable car si on suppose que chaque opration Send
est prise en charge par un thread, il y aura une explosion dacquittements ds que le
nombre de processus dun groupe devient important. En effet, les buffers du processus
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 61
metteur dbordent entranant des pertes dacquittements qui entranent leur tour
des retransmissions ce qui rduit la bande passante du rseau.
Le multicast fiable se caractrise par trois proprits :
Intgrit : Chaque message reu est identique au message transmis et
aucun message nest dlivr deux fois.
Validit : Nimporte quelle message parvient ventuellement sa
destination sil est correct (ne comporte pas dinformation fausse).
Accord (Agreement) : Tous les processus corrects du groupe doivent
recevoir un message si lun deux le reoit.
Il existe divers algorithmes qui permettent une implmentation fiable du multicast.
Parmi ceux la, lalgorithme qui se base sur le Multicast-IP utilise des acquittements
ngatifs (dtection de labsence dun message attendu) et les acquittements indirects
(Piggy backed acknowledgement: acquittement attach dautres messages). Cet
algorithme part de la constatation que le protocole Multicast-IP russit souvent sans les
dacquittements.
Dans la communication de groupe, la cration et la gestion des groupes constituent un
problme fondamental. En effet, si dans le cas le plus simple, les groupes sont
statiques, dans le cas gnral pratique, les groupes voluent dynamiquement par ajout
ou retrait des processus et chaque processus peut appartenir plusieurs groupes.
Les systmes qui utilisent la notion de groupe doivent contenir un service de gestion de
lappartenance aux groupes dont le rle est :
Offrir une interface de gestion des membres : cration/destruction de
groupes et cration/destruction de membres.
Implmenter une dtection de pannes : Le service dtecte la panne des
membres mais aussi celle des communications. Il exclu un membre sil
devient non atteignable.
Notification des membres lors dun changement : Les membres dun
groupe sont maintenus informs de lintroduction/retrait dun nouveau
membre.
Expansion des adresses de groupe : Les processus qui effectuent une
opration multicast fournissent un identificateur de groupe. Le service
peut coordonner lacheminement dun message en prsence des
changements qui affectent le groupe (ajout/retrait de membres) grce au
contrle de lexpansion des adresses.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 62
3.6 COMMUNICATION PAR MEMOIRE PARTAGEE DISTRIBUEE
Lorsque les processus dune application distribue sont physiquement rpartis sur des
machines distinctes et ne disposant daucune mmoire physique partage, il est
possible de crer une mmoire commune virtuelle qui sera utilise pour changer des
donnes diverses.
La mmoire partag distribue constitue un paradigme de communication qui tente de
rapprocher les systmes distribus dune configuration centralise du type des
machines multiprocesseurs.
Le paradigme de mmoire partage distribue nest gnralement pas convenable pour
les applications client/serveur o gnralement le serveur encapsule les ressources dont
les donnes de lapplication (pour des raisons de modularit et de protection). Ces
dernires peuvent tre limites comme elles peuvent tre des bases de donnes
entire, ce qui ncessite lutilisation dun serveur de donnes.
A loppos, les processus pairs peuvent profiter pleinement des possibilits de
communication par mmoire partage, ce qui rduit la tche du programmeur et lui
vite lutilisation des messages.
Compare la communication par message, la communication par mmoire partage
prsente plusieurs particularits. Nous citons :
Le codage des donnes : Lors de lchange de messages, le processus
metteur doit coder les donnes transmettre sous forme dune suite
doctets ce qui ncessite la reconstitution de ces donnes selon leur type
par le processus rcepteur. A loppos, les processus accdent aux
donnes de la mmoire partage de la mme faon quils accdent leurs
mmoires locales.
Protection des espaces dadressage : Les processus qui changent des
messages prservent lindpendance de leurs espaces dadressages. A
loppos, un processus peut altrer la mmoire partage par erreur et
induire des problmes pour les autres processus.
La synchronisation entre processus : Les processus qui changent des
messages se synchronisent laide des primitives denvoi et de rception.
Lorsquon dispose dune mmoire partage, il est possible dutiliser les
mcanismes de synchronisation classiques entre processus, moyennant
une certaine adaptation. Par exemple, il est envisageable dutiliser des
smaphores.
Excution libre des processus : La programmation des processus en se
basant sur lchange de messages suppose implicitement lexcution
simultane des processus. Un certain chevauchement est ncessaire. A
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 63
loppos, lutilisation dune mmoire partage permet un processus de
dposer des donnes quun autre processus pourra lire immdiatement ou
aprs la terminaison du premier. Lexcution des processus est ainsi
dcouple.
Communication indirecte : Dans la communication par messages, le
processus metteur doit spcifier le ou les processus rcepteurs (problme
du canal de communication). A loppos, la communication par mmoire
commune limine cette exigence en permettant aux processus de
communiquer sans se connatre.
La mise en uvre du paradigme de communication par mmoire partage se base sur
la communication par messages. Cette mise en uvre nest pas aise. Elle doit faire
face au problme de manque de performances lorsque le nombre dordinateurs
concerns devient important (donc nombre de messages important) et doit aussi
maintenir la consistance des donnes stockes qui peuvent existes en plusieurs
exemplaires.
Il existe diverses approches de mise en oeuvre des mmoires partages quon peut
partager en deux groupes : Les approches matrielles et les approches logicielles. Les
approches matrielles concernent les machines multiprocesseurs considres comme un
cas particulier de systmes distribus.
Les approches logicielles quant elles se font soit au niveau des systmes
dexploitation, soit au niveau des middleware (voire des applications).
Dans la suite, nous considrons les aspects importants qui caractrisent toute
implmentation de la communication par mmoire partage. Notons que aspects
diffrent dune limplmentation lautre.
3.6.1 Structure
La structure de la mmoire partage peut consister en un ensemble doctet (ou mots)
auquel les processus accdent par un mcanisme dadressage. Ils utilisent pour cela les
oprations de lecture et dcriture classiques. La structure peut aussi tre une collection
dobjets qui encapsulent des variables. Laccs aux variables ne peut se faire quen
invoquant les oprations associes aux objets qui dtiennent ces variables. Comme
dernire possibilit, la mmoire partage peut avoir une structure compose dlments
de mme type (par exemple des tuples identiques avec des valeurs diffrentes). Dans
ce cas, la mmoire est plutt vue comme une bote aux lettres. Certains processus y
dpose des informations sous un format bien prcis et les autres rcuprent ces
informations et les utilisent.
3.6.2 Synchronisation
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 64
Lutilisation correcte dune mmoire partage ncessite lutilisation dun service de
synchronisation distribu (verrous, smaphores, etc.). Mme lorsque la mmoire est
sous forme dobjets, il est ncessaire dempcher lexcution simultane des oprations
dun objet.
3.6.3 Consistance
Pour amliorer les performances, les diffrentes donnes de la mmoire partage
peuvent tre lues et enregistres dans des mmoires locales qui jouent le rle de
mmoires caches. Dans certains cas, la mmoire partage est physiquement
matrialise par lensemble des caches. Les processus accdent alors aux caches pour
les oprations de lecture. Lorsquun processus met jour une donnes dans un cache,
toutes les autres copies disponibles sur les autres caches doivent tre mise jour aussi.
On parle ici de propagation des mises jour. Il se pose alors le problme de
consistance concernant les valeurs des donnes que le service de maintien de la
consistance doit garantir. En effet, lorsquun processus lis le contenu dune variable
dans sans cache, cette valeur peut ne pas correspondre son tat rel actuel. Le service
de maintien de la consistance doit implmenter un protocole qui garantit la consistance
en fonction du type dapplication. Dans certains cas, on ne tolre aucune inconsistance,
le processus qui effectue une lecture doit rellement lire la dernire valeur.
3.6.4 Options de mise jour

3.6.5 Granularit

3.6.6 Trashing

3.7 COMMUNICATION PAR FLUX (STREAMING)
La communication vue jusqu prsent sintressait lchange dunits dinformation
indpendantes et compltes. Le temps na pas dimportance et il importe peu de savoir
quel moment la communication aura lieu.
Il existe des formes de communication dans lesquelles le temps joue un rle crucial. Par
exemple, considrons un flux audio consistant en une squence dchantillons de 16
bits qui reprsentent lamplitude dune onde sonore (cas de Pulse Code Modulation
(PCM)) chantillon une frquence de 44100Hz. Dans une telle situation, la
reproduction du signal original ncessite que :
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 65
1- Les chantillons doivent tre lus dans lordre qui correspond leur apparition dans le
flux et
2- Quils doivent tre lus des intervalles de 1/44100 seconde exactement. Si le flux est lu
une cadence diffrente, nous obtenons un son diffrent du son original.
Lorsquon parle de prise en compte de linformation dpendante du temps, il sagit de
codage de linformation, de transmission de linformation et de reconstitution de
linformation dorigine en tenant compte du temps. Linformation dpendante du temps
concerne les flux audio et les flux video.
On distingue ainsi deux faon de coder ou reprsenter linformation. Une reprsentation
continue et une reprsentation discrte. Dans la reprsentation continue, les
lments dinformation ont une relation temporelle qui est importante pour interprter
correctement le sens de linformation. Par exemple, dans une animation, une srie
dimages doivent tre prsentes des intervalles fixes de lordre de 30 40 ms par
image et dans un ordre bien dfini.
Dans la reprsentation discrte, la relation temporelle entre les lments
dinformation na aucune influence sur linterpretation correcte des donnes.
Pour changer des informations dpendantes du temps, les systmes distribus offrent
gnrallement le concept de flux de donnes (Data streams) qui ne sont autres que
des squences dunits de donnes. Les flux de donnes peuvent tre appliqus aussi
bien au cas de reprsentation continue quau cas de reprsentation discrte. Par
exemple, la lecture dun fichier son ncessite ltablissement dun flux de donnes
continu entre le fichier et le priphrique audio qui produit le son.
Le temps est crucial pour les flux de donnes continus. Pour capturer laspect temporel,
une distinction est faite entre les modes de transmission. Dans le mode de
transmission asynchrone, les lments de donnes sont transmis lun aprs lautre
sans aucune contrainte temporelle sur le moment o le transfert aura lieu. Cest le cas
des flux de donnes discrets (par exemple un transfert de fichiers ordinaires).
Dans le mode de transmission synchrone, il y a un delai maximal pour la
transmission de chaque lment dinformation dans le flux de donnes. Un lment
peut tre transmis plus rapidement que ce qui est exig, mais cela na pas
dimportance. Par exemple, un capteur peut prendre des chantillons de temprature
avec un certain taux et les transmettre un oprateur via un rseau. Dans ce cas, il est
important de garantir que la propagation de bout en bout travers le rseau soit
infrieure au temps de prise de deux chantillons succssifs.
Dans le mode de transmission isochrone, il est important que les units de donnes
soient transmises temps. Cela implique quil y a un dlai maximal et un dlai minimal
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 66
pour le transfert de bout en bout. Le mode isochrone est intressant pour les systmes
multimedia distribus o il joue un rle important dans la transmission audio et vido.
Dans la suite nous considrons uniquement le mode de transmission isochrone.
Les flux peuvent tre simple ou comlexes. Un flux simple consiste en une seule
squence de donnes alors quun flux complexe consiste en plusieurs flux simples en
relation. Cette relation est souvent temporelle. Par exemple, un son audio streo peut
tre transmis par un flux complexe compos de deux flux simples ou chacun
correspond un canal audio. Il est important que ces deux flux simple restent
synchroniss continuellement pour garantir un effet streo. Un autre exemple, est celui
de la transmission dun film. Dans ce cas, il est ncessaire davoir un flux video et deux
flux audio reprsentant le son streo du film. Un quatrime flux peut contenir un
soustitrage pour sourds/muets ou une traduction dans une langue diffrente de celle du
signal audio. La synchronisation de tous les flux du flux complexe est importante. En
effet, en cas dechec, la reconstitution du film choue.
Un flux peut tre considr comme une connexion virtuelle entre une source et un
puit (Source and Sink). Les deux pouvant tre des processus ou des priphriques. Par
exemple, un processus lit un fichier audio partir dun disque et le transmet octet par
octet sur un rseau. Le puit peut tre un processus qui reoit les octets et les transmet
un priphrique audio local. Dans les systmes multimedia, il peut tre fourni un
support pour une connexion directe entre la source et le puit. La figure 3.7 illustre les
deux situations.


Processus
Application
(Emetteur)
Systme
dexploitation
Processus
Application
(Receveur)
Systme
dexploitation
Flux
Priphrique
audio
Rseau


Systme
dexploitation

Systme
dexploitation
Flux

Figure 3.7. Connexion virtuelle entre Source et Puit
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 67
Un autre aspect important est celui de lexistence de plusieurs sources et plusieurs
puits. Il sagit de communication dite multiparties. Dans la pratique, la situation de
communication multipartie la plus commune est celle de rattacher plusieurs puits un
flux ce qui permet de diffuser linformation plusieurs receveurs.
Le problme majeur de la diffusion de flux vient de la situation o les receveurs ont
diffrents exigences sur la qualit du flux. Par exemple, lorsquil sagit dun flux
complexe reprsentant un film 50 images par seconde et deux sous flux audio. Mme
en utilisant des techniques sophistiques de compression la bande passante ncessaire
avoisine 30 million de bits par seconde. Les receveurs ne peuvent tous manipuler
autant de donnes ce qui nous pousse utiliser des filtres qui saccomodent de bande
passantes rduites (figure 3.8).

Figure 3.8. Diffusion de flux plusieurs receveurs
3.7.1 Notion de qualits de service
Certains besoins non fonctionnels tel que la dpendance vis--vis du temps dun flux ou
la fiabilit de communication reprsente ce qui est communment nomm qualit de
service (QoS ou Quality of Service en anglais). Exprimer la qualit des services peut
tre fait de plusieurs faons. Lune serait de donner une spcification du flux prcise qui
indique :
1- ce quune application attend du rseau de communication. Par exemple :
Sensibilit la perte (en octet) et intervalle de perte (en microseconde) :
Elles expriment conjointement un maximum acceptable de taux de perte (par
exemple : 1 octet par minute).
Sensibilit la rupture (en unit de donnes) : Elle indique combien des
donnes conscutives peuvent tre perdues au maximum.
Le delai minimal dtectable (en microseconde) : Il spcifie de combien le
rseau peut retarder la transmission des donnes sans que le receveur ne sen
rende compte.
Source
Flux

Puit
Puit
Puit
Nud
intermdiare
avec filtres
Bande
passante
rduite
Bande
passante
importante
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 68
La variation maximal du delay (en microseconde) : Cest une mesure
importante pour la video et laudio. Elle spcifie un intervalle de tolrance lors de
la transmission de deux units de donnes conscutives dun flux.
Qualit de la garantie : Cest nombre qui indique limportance des spcifications
de la qualit de service. Un nombre petit indique une grande tolrance de
lapplication, alors quun nombre lv signifie que si les qualits de service ne
sont pas garanties il sera inutile dtablir un flux.
2- Ce que lapplication dlivre en entre pour le rseau, par exemple :
Taille maximale des untits de donnes (en octet)
Taux de transmission maximal (en octet/seconde)
Etc
Dans certains cas ces spcifications ne sont pas faciles dterminer. Une autre
alternative serait de laisser lutilisateur spcifier sil sagit daudio ou de video et dans
lun ou lautre cas, indiquer la qualit souhaite du flux par des termes qui reflte une
classification pralable (par exemple : haut, moyen, bas) des diffrents paramtres.
3.7.2 Configuration dun flux
Une fois les spcifications dcrites, le systme distribu est en mesure dallouer les
ressources ncessaires pour que la communication ait lieu en garantissant les qualits
de service requises. Les ressources ncessaires concernent :
- la bande passante : en ordonnanant la transmission des units de donnes avec
une certaine priorit.
- les buffers : o les units peuvent tre mis en file en attendant leur transmission
(buffers au niveau des routeurs et des systmes dexploitation).
- les capacits de calcul : qui ncessite lallocation, selon un ordonnacement
convenable, du processeur aux ordonnanceurs, filtres, codeurs et dcodeurs.
Un des problmes cls concernant la configuration du flux et celui de la traduction des
spcifications de qualite de service en paramtres concernant les ressources impliques.
Par exemple pour une sensibilit la rupture k, il serait ncessaire dallouer
statiquement des buffers (avec une certaine taille) tout au long du chemin entre la
source et le puit.
La mise en pratique de la notion de qualit de service nest pas une tche facile. Cela
est due trois raisons : absence dun modle de rfrence unique pour la spcification
de la QoS, absence de possibilit de description abstraite des rssources dun rseau de
communication et absence de consensus sur une approche unique de traduction des
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 69
QoS en demande pour les ressources. Notons enfin, que cette traduction ncessite
lutilisation dun protocole spcifique qui rside dans la couche de transport tel que le
RSVP (Resource reSerVation Protocol).
3.7.3 Syncronisation des flux
Lorsquil sagit de flux complexes, il est souvent ncessaire dtablir une synchronisation
entre les flux constituants de telle sorte prserver une relation quelconque entre ces
derniers. La synchronisation peut avoir lieu pour les flux de donnes discrets ou
continus.
Par exemple, pour les flux de donnes discrets, on peut considrer lassociation entre
un affichage cran dune prsentation (par exemple une prsentation Powerpoint) et un
signal audio dcrivant lcran en question. Bienque la prsentation et le signal audio
peuvent tre transmis sans contrainte temporelles sur un rseau, il est primordial que
les laffichage cran soit synchronis avec la partie du signal audio qui lui correspond.
Pour les flux de donnes continus, tel que les films, le problme de synchronisation est
plus complexe. Il est souvent nomm Lip Synchronisation (Synchronisation son-
mouvement des lvres).
La synchronisation de deux flux reprsentant un signal audio stereo ncessite une
synchronisation au niveau de chaque unit de donnes (i.e. echantillon de 16 bits) est
ncessaire. Autrement dit, pour une frequence dechontillonage de 44100 Hz, on doit
lire un chontillon de chaque flux tous les 22,7 microsecondes (1/44100).
Pour la synchronisation audio/video, le standard NTSC utilise une frquence vido de 30
Hz (soit 30 unit image pas seconde), ce qui nous oblige utiliser comme unit de
donne pour le son le nombre dechontillons de 16 bits quil est possible de lire en 1/30
seconde (33 milliseconded) soit 1470 echantillons ou encore 11760 octet
((44100/30)*16/2).
Quen est-il du mcanisme de synchronisation lui-mme ? La synchronisation sopre
sur les units de donnes des flux simples. Cest un processus simple qui opre des
lectures et des ecritures sur plusieurs flux en sassurant que les contraintes temporelles
sont satisfaites. La synchronisation peut tre la charge de lmetteur comme elle peut
tre la charge du receveur. Lorsquelle est la charge de lmetteur, il consitue des
units de donnes en fonction de la synchronisation, le recepteur naura qu
dcompos chaque unit pour en extraire lunit qui correspond chaque flux et la
trasmettre au priphrique adquat. Lorsque la synchronisation est la charge du
recepteur, lmetteur se contente de transmettre les flux simples.
Systmes distribus : Principes et concepts, Dr D. Meslati, Universit de Annaba 70
CHAPITRE 4
MISE EN EVIDENCE DES PROBLEMES FONDAMENTAUX DES
SYSTEMES DISTRIBUES
CONTENU
4.1 Nommage des ressources et des processus
Processus, fichiers, mmoire, rseaux, objets,
4.2 Rpertoire et dcouverte des services
DNS (domain name system) et espaces de noms, rsolution des rfrences, identification
des services rfrencs, exemple
4.3 La coordination distribue
Lexclusion mutuelle, la synchronisation, linterblocage (mise en vidence)
4.4 Fiabilit, fautes et scurit
Dtection des fautes/pannes, duplication des ressources, reprise aprs pannes, survol des
problmes de scurit (menace par code mobile, fuite dinformation, ), survol des
techniques de scurit (cryptographie, signature digitale, contrle daccs, )

4.1 NOMMAGE DES RESSOURCES ET DES PROCESSUS
Processus, fichiers, mmoire, rseaux, objets,
4.2 REPERTOIRE ET DECOUVERTE DES SERVICES
DNS (domain name system) et espaces de noms, rsolution des rfrences, identification
des services rfrencs, exemple
4.3 LA COORDINATION DISTRIBUEE
Lexclusion mutuelle, la synchronisation, linterblocage (mise en vidence)
4.4 FIABILITE FAUTES ET SECURITE
Dtection des fautes/pannes, duplication des ressources, reprise aprs pannes, survol des
problmes de scurit (menace par code mobile, fuite dinformation, ), survol des
techniques de scurit (cryptographie, signature digitale, contrle daccs, )