CONSERVATOIRE NATIONAL DES ARTS ET METIERS

mindasparagusΔίκτυα και Επικοινωνίες

14 Ιουλ 2012 (πριν από 4 χρόνια και 11 μήνες)

746 εμφανίσεις

CONSERVATOIRE NATIONAL DES ARTS ET
METIERS
Memoire presente en vue de l'obtention du Dipl^ome d'Ingenieur CNAM
specialite
Informatique,Systemes,Reseaux et Multimedias
Solution P2P pour la diusion de ux audio:
contribution au Concert sur Internet avec Pastry
Samundeswary RAMACHANDRA
7 Octobre 2005
JURY
President:M.Eric GRESSIER-SOUDAN,Professeur des Universites CNAM
Membres:M.Nicolas BOUILLOT,ATER CNAM
Mme Samia BOUZEFRANE,Ma^tre de Conference CNAM
Mme Sophie CHABRIDON Ma^tre de Conference INT
M.Bruno DEFUDE Directeur d'etudes au departement Informatique de l'INT
M.Alexandre TOPOL,Ma^tre de Conference CNAM
MEMOIRE D'INGENIEUR CNAM 2004/2005
Resume:Le concert virtuel reparti repose sur le concept de coordination entre musiciens
jouant dans des lieux dierents et sur la repartition des auditeurs.Le sujet de ce memoire se
focalise sur la deuxieme partie.On souhaite pouvoir diuser les ux vers les auditeurs sans le
Multicast IP en reduisant les temps de transmission gr^ace a une application basee sur du mul-
ticast niveau application basee sur une DHT.Par ailleurs,les donnees envoyees par le serveur
sont repliquees pour qu'un client puisse recuperer les donnees envoyees avant son arrivee.Pour
repondre a ces deux problematiques,dans ce projet nous avons choisi le systeme Pastry.Il s'agit
d'un systeme qui par sa taille,ore un espace de stockage non negligeable,et par sa dynamicite
semble repondre aux contraintes du concert reparti.Par ailleurs il propose des algorithmes de
routage et de localisation qui permettent l'amelioration des temps de reponse.Le but de ce pro-
jet est d'evaluer Pastry - une approche P2P - comme outil pour la transmission du concert aux
auditeurs.Puis nous implementons une application pour la transmission de ux multimedias
\Live"vers les auditeurs (via SplitStream) avec de la replication pour les ux envoyes par le
serveur (via Past).
Abstract:The Distributed Virtual Concert relies on the concept of musicians'coordination
playing in dierent places and on the distribution of the concert to the listeners.In this paper
we are focused in the second part.We diuse the streams towards the listeners without IP
Multicast,by reducing transmission delays thanks to DHT-based Application Level Multicast..
Additionally with replication,a listener can recover the data sent by the server before his arrival.
Find a solution including theses two problems came us to choose the Pastry project.Thanks to
his huge size,it oers a considerable storage space,and thanks to its dynamicity,it partially
satisfy the requierements of the Distributed Virtual Concert.In addition they propose routing
and localization algorithms which allow the improvement of the response times.The goal of this
work is to evaluate Pastry - a P2P approach - as a tool to transmit the concert to the listeners.
Then we implement an application for the transmission of live multimedia streams towards the
listeners(via SplitStream) with replication for streams sended by the server(via Past).
Mots cles:Pastry,SplitStream,Past,Scribe,multimedia,replication,distribution en strea-
ming,live,Java,FreePastry
Key words:Pastry,SplitStream,Past,Scribe,multimedia,replication,streaming distribu-
tion,real time,Java,FreePastry
1 2004/2005
Remerciements
Mes remerciements vont en premier lieu a Eric Gressier-Soudan,pour m'avoir donnee envie
de continuer jusqu'au dipl^ome d'Ingenieur,pour m'avoir toujours encouragee tout au long de
ce memoire,pour avoir toujours cru en mes capacites,pour sa disponibilite et pour m'avoir
prodigue ses conseils tout au long de ma formation.
Je tiens a dire un grand merci a Alexandre Vandevelde pour m'avoir aidee (supportee serait
plus juste) tout au long de cette derniere annee au CNAM.Je te remercie,Alexandre,pour les
heures passees a la lecture et relecture de mes ecrits,pour la comprehension et le soutien que tu
m'a apporte tout au long de cette annee.
Je tiens egalement a remercier Nicolas Bouillot qui a fait preuve d'une grande disponibilte
et qui m'a apporte beaucoup par nos discussions,ses remarques et ses conseils sur la conception
et les choix que j'ai eu a faire pour ce projet.
Je remercie cordialement Mesdames Samia Bouzefrane et Sophie Chabridon ainsi que Mes-
sieurs Bruno Defude et Alexandre Topol pour avoir accepte de faire partie de mon jury.
Et enn,je tiens a dire un chaleureux merci a mes camarades et amis du cinquieme Messieurs
Laurent Dehoey et Hans Nicolas Locher qui ont toujours preter une oreille attentive a mes doutes
et mes problemes techniques.
2 2004/2005
Table des matieres
1 Introduction 6
2 Contexte du stage 9
2.1 Le Concert Virtuel Reparti..............................9
2.1.1 Presentation des objectifs...........................9
2.1.2 Un parametre primordial:les auditeurs...................10
2.1.3 L'etat actuel de l'experimentation......................10
2.1.4 Quelle solution?................................10
2.1.5 Conclusion...................................10
3 Architectures speciques au contenu multimedia 12
3.1 Les CDN:Content Delivery Network[1] [36].....................13
3.1.1 Akamai [2]...................................16
3.2 L'architecture MiddleMan [15]............................17
3.2.1 Generalites...................................17
3.2.2 Politiques de stockage de la video.......................18
3.2.3 L'interaction du MiddleMan.........................18
3.3 L'architecture QBIX:Quality-Based Intelligent proXy [14]............20
3.4 L'architecture centralisee autour d'un Broker [16].................21
3.5 Mocha [17].......................................23
3.5.1 Generalites...................................23
3.5.2 L'interaction:..................................23
3.6 Video Caching Network [18]..............................24
3.6.1 Generalites...................................24
3.6.2 L'interaction..................................25
3.7 Synthese.........................................27
3.7.1 Un apercu des solutions proposees......................27
3.7.2 Conclusion...................................27
4 Peer To Peer 30
4.1 Presentation generale..................................30
4.2 Les trois grandes generations.............................31
3
TABLE DES MATI

ERES
4.2.1 Premiere generation..............................31
4.2.2 Seconde generation...............................32
4.2.3 Troisieme generation..............................33
4.3 Les systemes bases sur une DHT...........................33
4.4 CAN...........................................34
4.5 Pastry[4].........................................34
4.5.1 Caracteristiques des noeuds..........................35
4.5.2 Gestion des noeuds...............................36
4.6 Le routage........................................36
4.6.1 Arrivee des noeuds...............................39
4.6.2 Departs et pannes de noeuds.........................39
4.7 Conclusion.......................................39
4.7.1 Une implementation de Pastry:FreePastry [5]...............40
4.7.2 Scribe:un protocole de diusion [6].....................40
4.7.3 SplitStream...................................40
4.7.4 Discussion sur Pastry.............................42
4.8 Une application proche:PeerCast..........................42
4.9 Conclusion.......................................43
5 l'API de FreePastry 45
5.1 Les elements cles de FreePastry............................45
5.1.1 Les elements du noyau.............................45
5.1.2 Les algorithmes.................................46
5.2 PAST:API de stockage...............................48
5.2.1 Le principe de PAST..............................48
5.2.2 Les trois principaux composants.......................49
5.2.3 Insertion et replication des ressources....................49
5.2.4 La recherche et le cache............................50
5.2.5 Gestion des replicats..............................51
5.3 SCRIBE:un systeme de communication de groupe.................51
5.3.1 Creation et gestion d'un groupe........................52
5.3.2 API.......................................52
5.4 SPLITSTREAM:une application de distribution de contenu en fort besoin de
bande passante.....................................53
5.4.1 Presentation..................................53
5.4.2 API rice.p2p.splitstream...........................53
5.5 Conclusion.......................................53
6 Conception et implementations 55
6.1 Conception architecturale et technique........................55
6.1.1 Conception architecturale...........................55
6.1.2 Presentation de l'architecture.........................55
4 2004/2005
TABLE DES MATI

ERES
6.1.3 Conception technique.............................57
6.2 Implementations....................................57
6.2.1 Interface Pastry................................58
6.2.2 L'application CVR..............................60
6.2.3 Realisation...................................66
6.2.4 Dicultes rencontrees.............................71
7 Conclusion et Perspectives 73
7.1 Bilan...........................................73
7.1.1 Ressources...................................73
7.1.2 Latence.....................................73
7.1.3 Debit......................................74
7.2 Ameliorations......................................74
7.2.1 Etudes de performance.............................74
7.2.2 Ameliorations au niveau applicatif......................74
7.3 Conclusion:Solution viable pour le futur?.....................74
8 Annexes 77
8.1 Presentation de la realisation.............................77
8.2 Resultats........................................78
8.3 Les resultats dans iptraf................................78
8.4 RRDTool........................................81
8.4.1 lancement.sh..................................81
8.4.2 La creation des bases..............................82
8.4.3 La creation de graphes.............................83
8.5 FreePastry........................................88
8.5.1 Test de l'application PAST..........................88
8.5.2 Test de l'application PAST..........................89
8.5.3 Lancement de CVR..............................91
8.5.4 Les sources...................................91
8.5.5 Les messages SplitStream...........................113
8.5.6 La gestion du son................................122
5 2004/2005
Chapitre 1
Introduction
De nos jours les applications de streaming connaissent une reelle explosion que ce soit a
travers des produits commerciaux et tres largement utilises tels que Window Media et Quicktime
ou des produits issus de milieu de la recherche tels que PeerCast,NinJam et le concert reparti.
Le streaming est une technique qui consiste a transferer des donnees multimedia sous forme de
ux (stream) de maniere continue a la demande et en temps reel.Le contenu streame peut ^etre
aussi bien pre-enregistre que Live.Le principe du streaming n'est pas nouveau,les cha^nes de
television,la radio recourent a cette technique en revanche c'est leur utilisation sur les reseaux
IP qui est toute recente.Cette nouvelle utilisation est dierente car elle impose des contraintes
autres que celles qui regissent les utilisations precedentes.
Les donnees multimedia,par leur taille et par leurs caracteristiques speciques telles que le
respect des echeances temporelles dans le but de restituer correctement le contenu,dierent des
donnees qui circulent au sein du Web.Les echeances temporelles sont primordiales dans la mesure
ou il faut gerer une dynamicite dans la presentation multimedia a travers le respect de la gigue et
de la synchronisation.Il existe pour ces donnees multimedias une dimension temporelle lors de la
construction des ux ou plusieurs types de synchronisation (par exemple entre les images d'une
video et des echantillons d'une audio) entrent en jeu:il peut s'agir d'une synchronisation intra-
objet (des objets ayant une relation temporelles entre eux),synchronisation inter-objets (il s'agit
la de relations temporelles entre les instants de debut et/ou les instants de n des dierents objets
media),synchronisation avec l'environnement (c'est ce qui permet a une application multimedia
de reagir par rapport a un evenement exterieur:ce peut ^etre typiquement des fonctions de
navigation),synchronisation de groupe (qui met en oeuvre le WYSIWIS:\What You See Is
What I See"donc tous les participants doivent recevoir les m^emes donnees aux m^emes moments).
Pourquoi ce nouvel engouement?Les applications proposees sur Internet sont de plus en plus
nombreuses,cet essor est d^u au fait que des organismes protent de l'essor d'Internet et de ses
capacites pour agrandir leurs activites et leur champ d'action.En eet les algorithmes et les
techniques de compression sont de plus en plus sophistiques et ecaces.
Il existe beaucoup d'applications de streaming actuellement:
{ Les formations a distance qui permettent de mettre en place des cours vituels
{ La diusion de cha^nes de television ou de radio sur Internet
6
CHAPITRE 1.INTRODUCTION
{ la Video-On-Demand qui permet a des utilisateurs d'acheter du contenu multimedia et
donc de l'obtenir a la demande
{ la video conference
Ces applications de streaming sur internet s'executent en general sur une architecture de type
client-serveur ou un client s'adresse a un serveur pour localiser un objet,le serveur envoie le lieu
ou se situe l'objet et le client s'adresse a la personne ayant l'objet an que le ux demande soit
achemine directement au client a travers un canal via Internet.Il s'agit d'une architecture facile
a mettre en oeuvre et qui est ecace.Neanmoins les architectures client-serveur sur Internet
ont une limitation majeure:le probleme de passage a l'echelle face a des millions d'utilisateurs.
Les applications de streaming utilisent beaucoup de bande passante entre le client et le serveur
pour toute la duree de la session.Par ailleurs la qualite du ux dans le canal est limitee par
l'engorgement cree le long du chemin entre le client et le serveur.Pour resoudre une partie de
ces problemes,l'une des solutions est l'utilisation de caches.L'utilisation de caches,"caching"
dans la litterature anglo-saxonne,a ete proposee comme solution pour reduire la charge du
reseau et des serveurs,et ameliorer le temps de reponse observe par l'utilisateur.Un cache est
un systeme logiciel ou materiel permettant d'optimiser les temps de traitement an d'eviter de
reiterer systematiquement les m^emes t^aches et ainsi faire de la repartion de charge.Il existe
beaucoup de technologies utilisant le mecanisme de cache:les caches et proxy web,cache DNS,
dans notre cas nous allons considerer uniquement les caches web et les proxies.La technique
du cache repose traditionnellement sur trois entites:un client qui va eectuer des requ^etes,
une entite intermediaire qui se charge du stockage des documents demandes precedemment et
un serveur qui contient l'objet initialement stocke.Cependant elle devient assez rapidement
inapte face a la croissance de la semantique du contenu des pages du web.On assiste a une
virtualisation des services proposes par l'apparition des contenus hypermedias tels que l'audio,
l'hyperpanoramique,les hypervideos immersives (iPix Movies),les contenus 3D interactifs...Ces
nouveaux contenus sont tres riches et par consequent tres gourmands en ressources et rendent
les caches standards inadaptes.
La conception et la realisation du projet sont dediees a une application precise dans notre
cas:le concert reparti [62].Le CVR (Concert Virtuel Reparti) consiste a repartir l'ensemble des
personnes impliquees geographiquement tout en les maintenant virtuellement ensemble.Nous
nous interessons dans ce projet a deux problematiques cles:la diusion de ux en streaming avec
des proprietes temps reel et la replication de contenu.Il s'agit donc dans un premier temps de
mettre en place une application de streaming qui va permettre a un auditeur de pouvoir ecouter
ou voir en live un ux multimedia et par la m^eme occasion pouvoir acquerir les transmissions
precedentes.Comment repliquer massivement vers des auditeurs?Il existe beaucoup de solutions
basees sur une approche centralisee,voir semi-decentralisee.Nous proposons dans ce projet une
solution basee sur un systeme P2P,Pastry,qui apporte decentralisation,miminisation des temps
de reponse et un espace memoire partage.
Je vais presenter dans un premier temps le contexte du stage an de preciser les objectifs
attendus.Nous allons orir a l'auditeur la possibilite de suivre le concert en Live et de recuperer
le ux envoye avant son arrivee gr^ace a la replication.L'objectif primodial sur lequel repose ce
7 2004/2005
CHAPITRE 1.INTRODUCTION
projet est la reduction des temps de transmission et de la latence pour l'utilisateur nal.Cet
objectif m'a conduite dans l'etude des dierentes solutions speciques au multimedia proposees
dans la litterature.C'est ce que nous verrons dans un second chapitre.Ces architectures n'orant
pas une totale decentralisation je me suis interessee dans un troisieme chapitre aux systemes
P2P.Puis mon choix se portant sur une architecture P2P,Pastry,je presente dans un quatrieme
chapitre l'API de FreePastry qui est une implementation de Pastry et de ses dierents services.
Cette etude permet de mettre en place l'architecture nale de l'application de distribution et de
replication de contenus multimedia,je vais donc le presenter dans les derniers chapitres.Dans
une derniere partie,j'evoquerai les conclusions de mon travail.
8 2004/2005
Chapitre 2
Contexte du stage
Le CEDRICet l'IRCAMmenent depuis 2002 un projet intilule\le Concert Virtuel Reparti"[62],
`citeBou2.2.1 Le Concert Virtuel Reparti
2.1.1 Presentation des objectifs
Ce projet de concert virtuel consiste a repartir physiquement les musiciens tout en restant
virtuellement ensemble pour realiser un concert en temps reel accessible via le reseau IP.Les
musiciens echangent des ux audio de type PCM,chaque musicien diuse le ux qu'il joue et
entend sa propre musique mixee avec les autres sources avec une latence maintenue constante.
La musique ainsi produite est distribuee aux auditeurs a travers une machine passerelle qui
est placee dans le reseau des musiciens.Cette machine sert de passerelle vers les auditeurs qui
ecoutent la musique en direct.
Fig.2.1 { L'architecture generale du CVR
Les contraintes applicatives du projet sont:
{ La repartition des musiciens
{ Les contraintes temps reel
9
CHAPITRE 2.CONTEXTE DU STAGE
{ L'impression temps reel du ux recu par le public,ils doivent avoir un concert de type
\live".
Nous nous interessons dans ce projet uniquement a la partie concernant le public ou entrent
en jeu des problematiques de temps de reponse,replications et distribution de ux.Pour la suite
du projet,l'application a construire dans ce projet va s'intituler CVR.Par ailleurs il sera utilise
le terme de serveur/diuseur pour une personne qui diuse un ux et auditeur/client pour une
personne ecoutant un ux en reception.
2.1.2 Un parametre primordial:les auditeurs
Le besoin de ce projet est cible par une entite claire:les auditeurs.Ils doivent pouvoir
assister en temps reel au concert chez eux ou dans une salle dediee.Il s'agit donc d'orir une
representation avec les moyens dont ils disposent a savoir d'un acces ADSL haut debit (512ko
ou plus).Ils doivent par ailleurs disposer d'une interface simple d'acces au concert.Cette sim-
plicite est requise car on s'adresse a un groupe heteroclite pas forcement familier au milieu de
l'informatique:il faut donc cacher toute l'infrastructure sous-jacente.
2.1.3 L'etat actuel de l'experimentation
Une premiere experimentation a ete eectuee entre l'IRCAM et le CEDRIC avec un tunnel
multicast entre l'IRCAM et le CEDRIC.Deux musiciens jouaient au CEDRIC en interaction
avec trois musiciens situes a l'IRCAM,les auditeurs etaient a l'IRCAM.L'experimentation a pu
fonctionner.Neanmoins des problemes reseau d^us a l'encombrement du reseau et un dysfonc-
tionnement du tunnel ont mis n a l'experimentation.Cette experimentation a montre qu'avec
la technologie d'IP multicast le concert reparti sur Internet etait concevable.Mais c'est une
technologie qui n'apporte aucune garantie de qualite de service.
2.1.4 Quelle solution?
L'experimentation a montre les dicultes d'un projet base sur le multicast IP.Le multicast
IP est la technique la plus utilisee pour la diusion en continu.Il permet d'envoyer des donnees
audio et video a plusieurs utilisateurs a la fois.Cette technologie a certes beaucoup de qualites:le
passage a l'echelle,absence de materiel supplementaire.Cependant il est necessaire que le chemin
entre le fournisseur de media et le client soit entierement compatible et dote de la technologie
Multicast IP:tous ceux qui souhaitent utiliser cette technique doivent adapter leur propre
reseau au multicast.C'est une technologie qui n'est pas forcement accessible a tous,surtout
pour le public.Il a donc fallu trouver une solution alternative au multicast IP,cette solution est
le multicast au niveau applicatif.
2.1.5 Conclusion
Les objectifs a atteindre sont clairement denis:
{ Mulitcast de niveau application pour la diusion vers le public
10 2004/2005
CHAPITRE 2.CONTEXTE DU STAGE
{ Replication vers les utilisateurs
{ Prise en compte d'un facteur primordial:le temps,la solution choisie devra prendre en
compte ce facteur
Ce sont ces objectifs sur lesquels nous allons nous focaliser dans l'etude des dierentes ar-
chitectures.Nous allons voir si les architectures que nous allons etudier repondent a ces points.
Quelle architecture repond a nos objectifs?C'est ce que nous allons voir dans le chapitre suivant.
11 2004/2005
CHAPITRE 3.ARCHITECTURES SP

ECIFIQUES AU CONTENU MULTIM

EDIA
Chapitre 3
Architectures speciques au contenu
multimedia
De nos jours les applications de streaming sur internet s'executent sur une architecture de
type client-serveur ou un client s'adresse a un serveur pour localiser un objet,le serveur envoie le
lieu ou se situe l'objet et le client s'adresse a la personne ayant l'objet an que le ux demande
soit achemine directement au client a travers un canal via Internet.Il s'agit d'une architecture
facile a mettre en oeuvre et qui est ecace.
Neanmoins les architectures client-serveur sur Internet ont une limitation majeure:le pro-
bleme de passage a l'echelle face a des millions d'utilisateurs.Les applications de streaming
utilisent beaucoup de bande passante entre le client et le serveur pour toute la duree de la ses-
sion.Par ailleurs la qualite du ux dans le canal est limitee par l'engorgement cree le long du
chemin entre le client et le serveur.Pour resoudre une partie de ces problemes,l'une des solutions
est l'utilisation de caches.Les donnees multimedias,par leur taille et par leurs caracteristiques
speciques telles que le respect des echeances temporelles dans le but de restituer correctement
le contenu,dierent des donnees qui circulent au sein du Web.Les echeances temporelles sont
primordiales dans la mesure ou il faut gerer une dynamicite dans la presentation multimedia a
travers le respect de la gigue et de la synchronisation.Il existe pour ces donnees multimedias
une dimension temporelle lors de la construction des ux ou plusieurs types de synchronisation
(par exemple entre les images d'une video et des echantillons d'une audio) entrent en jeu:il
peut s'agir d'une synchronisation intra-objet (des objets ayant une relation temporelle entre
eux),synchronisation inter-objets (il s'agit la de relations temporelles entre les instants de debut
et/ou les instants de n des dierents objets media),synchronisation avec l'environnement (c'est
ce qui permet a une application multimedia de reagir par rapport a un evenement exterieur:
ce peut ^etre typiquement des fonctions de navigation),synchronisation de groupe (qui met en
oeuvre le WYSIWIS:\What You See Is What I See"donc tous les participants doivent recevoir
les m^emes donnees aux m^emes moments).
Il devient alors important de denir,de modeliser et de concevoir de nouvelles architectures
adaptees a ces types de donnees emergents.Parmi elles,existent celles qui sont speciques aux
ux video et audio qui commencent a emerger du monde de la recherche (d'ou le peu,voire
12 2004/2005
CHAPITRE 3.ARCHITECTURES SP

ECIFIQUES AU CONTENU MULTIM

EDIA
l'absence de leur utilisation dans le monde instrustriel).C'est notamment le cas des principales
architectures presentees dans ce chapitre.Mais il existe egalement d'autres types d'architectures
non speciquement dediees aux donnees multimedias qui peuvent ^etre etudiees pour le caching:
c'est le cas des systemes P2P qui feront l'objet d'un approfondissement dans cette partie et plus
particulierement sur Pastry une couche de localisation d'objets distribues et de routage dediee
aux applications et systemes P2P.
3.1 Les CDN:Content Delivery Network[1] [36]
Les objectifs de ce type de reseau sont les suivants:
{ La gestion de la totalite des contenus circulant sur le reseau.
{ Une gestion intelligente de l'acheminement de l'information selon la politique d'acces au
contenu.
C'est une des architectures qui conna^t le plus de succes actuellement au sein des grandes
societes:elle denit clairement la tendance a pousser le contenu au plus pres des utilisateurs,
en bordure du reseau (comme le fait Akamai [2]).Ce sont des reseaux avec:
{ Des architectures complexes,a plusieurs niveaux,de proxy/caches cooperatifs
{ Des mecanismes de distribution en fonction du type de contenu
{ et une utilisation croissante du multicast,du codage hierarchique,repartition de la charge
(load balancing),tolerance aux pannes...
En eet,ils font partie d'Internet et sont destines a delivrer des donnees avec une grande qualite
de service
1
quel que soit leur type.Cela se realise en installant des serveurs qui calculent les
meilleurs itineraires en fonction du trac reseau mais egalement en fonction de la nature m^eme
des informations transmises.Ainsi l'itineraire d'un ux video peut changer en permanence an
de s'adapter au trac.
1
Ces types d'architectures sont capables de fournir un service adapte aux besoins speciques des applications
temps reel:il peut s'agir de garantir le debit ou encore le delai
13 2004/2005
CHAPITRE 3.ARCHITECTURES SP

ECIFIQUES AU CONTENU MULTIM

EDIA
Cache Cache
Cache
Serveur de contenu
Cache
Fig.3.1 { Une architecture de CDN
Les t^aches constituantes d'une architecture gure CDN 3.1 sont:
{ La capture et la creation des contenus:les contenus peuvent ^etre des pages statiques
ou dynamiques WEB,des pages necessitant du streaming...Ils doivent ^etre indexes pour
faciliter leur recherche et leur exploitation.
{ La distribution,la diusion,la synchronisation,le deplacement,le remplacement des conte-
nus et le contr^ole de leur version.
{ Le relayage de contenus (cache,reverse proxy...) an qu'ils soient plus proches des clients.
{ La redirection ou routage gure 3.2:le coeur du CDN repose au sein des mecanismes de
redirection,qui acheminent les requ^etes des clients jusqu'aux points de presence les plus
pertinents.Ce choix s'appuie sur plusieurs parametres tels que la charge des caches,la
proximite du reseau,la qualite du service,le co^ut....
14 2004/2005
CHAPITRE 3.ARCHITECTURES SP

ECIFIQUES AU CONTENU MULTIM

EDIA
Client
www.content.com
Internet
ISP
www.cdn.com
Fig.3.2 { Le routage au sein d'un CDN
1.Le client demande un contenu qui se trouve chez le fournisseur du site web en l'oc-
curence:www.content.com
2.content.com ne stocke pas le contenu demande et utilise cdn.com comme fournisseur
de CDN,l'URL redirige la requ^ete vers le site cdn.com
3.Utilisant des algorithmes de redirection,le client est redirige vers le cache le plus
approprie par rapport a sa localisation.Dans ce cas-ci le CDN n'a pas de cache
directement place au niveau de l'ISP.
4.Si le CDN a un cache place au niveau de l'ISP du client,le client sera redirige vers
ce point de presence.
5.Le cache CDN sert le client,et du fait qu'il n'est pas proche du client les performances
ne sont pas tres bonnes.
6.Le cache CDN du FAI sert le contenu et orira moins de latence et une bonne utili-
sation de la bande passante du fait de la proximite par rapport au client.
{ La gestion des requ^etes,le contr^ole d'acces et l'identication interviennent souvent en
conjonction avec les processus de facturation,contr^ole d'acces...
{ La facturation,l'administration et le reporting
{ L'adaptation des contenus:en fonction de la langue,de la version du navigateur,pour des
acces Wap ou mobile utilisateur.
Les Content Delivery Network,par leur architecture,rappelent les architectures P2P.Les
contenus sont disperses au sein de toutes les machines distribuees ainsi,plus un document est
15 2004/2005
CHAPITRE 3.ARCHITECTURES SP

ECIFIQUES AU CONTENU MULTIM

EDIA
demande plus il sera proche de l'utilisateur et donc plus il sera servi rapidement...
3.1.1 Akamai [2]
Il existe dierentes implementations des CDN telles que Network Appliance,Cisco Systems.
Voici l'une des mises en oeuvre de l'architecture CDN:Akamai qui est la plus utilisee actuelle-
ment.L'etude de cette architecture permettra de savoir quels sont les mecanismes qu'ils mettent
en oeuvre par rapport aux specications des CDN et de voir ceux qui sont a retenir dans le
projet.Akamai gure 3.3 dispose d'environ 14000 serveurs repartis dans 1100 reseaux et 65 pays
et est connecte a plus de 650 reseaux de telecommunication.C'est a la fois:
{ une plateforme de calcul totalement distribuee:le contenu et les applications de calcul(qui
permettent de repondre aux QoS speciees) sont echanges dans un systeme de machines
distribuees.Par ailleurs il utilise un algorithme reparti sur tous ses serveurs et il est capable
a tout moment de savoir quel est le serveur a m^eme de repondre le plus rapidement a une
demande.
{ plateforme de diusion de contenus,de ux audio et video et d'applications.Les types de
contenus sont donc:de l'html statique et dynamique,du streaming,des pdf,des chiers
executables...Par ailleurs:
{ permet aussi d'avoir une vision de contr^ole (de supervision).
{ permet le monitoring.
{ met en place un ensemble de services en plus de la distribution de donnees (tels que la
securite des donnees contre les attaques malveillantes)
2
PULL
1
Serveur
Akamai Edge Serveur
Akamai Edge Serveur
Akamai Edge Serveur
Clients
Clients
Clients
INTERNET
Fig.3.3 { L'architecture d'Akamai
Il est sans conteste qu'une telle solution n'est envisagee que par des entreprises ayant toute leur
economie basee sur la technologie d'internet (le commerce electronique).
16 2004/2005
CHAPITRE 3.ARCHITECTURES SP

ECIFIQUES AU CONTENU MULTIM

EDIA
3.2 L'architecture MiddleMan [15]
3.2.1 Generalites
C'est une architecture semblable a celle representee dans la gure 3.3.Elle est constituee
d'un ensemble de serveurs proxy cache video qui sont geres par un coordinateur.L'architecture
minimale gure 3.4 de ce type de systeme de cache est decomposee en deux:une premiere qui
souligne comment le cache peut ^etre utilise dans un systeme de maniere simple avec des objets
distribues et des machines ayant une forte connectivite.La seconde qui s'articule autour d'un
coordinateur.'
P2
1
3
4
6
Machine 2
5
2
WWW
P1B
B
Machine 1
Coordinateur
Fig.3.4 { L'architecture Middleman
1.Le navigateur client souhaitant une video,contacte le serveur proxy P1 qui s'execute en
local sur la m^eme machine.
2.P1 verie s'il a ce titre localement,sinon contacte le serveur directement et commence a
recevoir la video.
3.P1 stocke la video localement et simultanement transmet une autre copie au navigateur
client.
4.Si un client de M2 requiert la video,P2 verie si elle est disponible localement.
5.P2 contacte P1,ce dernier etant le plus proche de P2,puis accede a la video et la transmet
au browser local.
A cette architecture l'ajout d'un coordinateur permet:
17 2004/2005
CHAPITRE 3.ARCHITECTURES SP

ECIFIQUES AU CONTENU MULTIM

EDIA
{ de garder une sorte de resume:un annuaire topographique de tous les chiers qui resident
au sein de chaque proxy pour tout le systeme.
{ de rediriger les requ^etes
{ de decider de la politique de remplacement.
Ainsi MiddleMan est constitue essentiellement de deux types de composants:des serveurs proxy
et des coordinateurs.Une conguration typique comporte un unique coordinateur et un certain
nombre de proxies s'executant sur un LAN.MiddleMan denit deux types de proxies:local et
de stockage (voir LP et SP dans la gure 3.5).
{ Les proxies de type local peuvent s'executer sur la m^eme machine que le client et sont
responsables de la reponse aux requ^etes des clients.
{ Les proxies de stockage ne servent pas directement les requ^etes des clients en revanche ils
stockent les donnees.Ils peuvent ^etre situes n'importe ou au sein du LAN.
3.2.2 Politiques de stockage de la video
Le MiddleMan incorpore le concept de video cache partiel.Une partie est cachee localement
et le reste de la video est demande au serveur.Par ailleurs,la video cachee est fragmentee
en blocs de taille egale dans le systeme de stockage an qu'ils soient disperses dans tous les
proxies de stockage.La video se trouve alors partionnee en une sequence ordonnee de blocs.
On peut ainsi avoir des morceaux d'un unique titre a travers plusieurs proxies an d'obtenir
une meilleure repartition de la charge et par ailleurs la politique de remplacement du cache s'en
trouve simpliee.Si un nouveau titre T1 a besoin d'^etre amene dans le cache et si tout le systeme
est complet alors MiddleMan elimine la n des portions d'un titre T2 moins populaire.Ainsi on
ne supprime pas totalement T2 et si par la suite T2 est demande,une partie sera toujours en
cache m^eme s'il n'y en aura pas autant qu'initialement.
3.2.3 L'interaction du MiddleMan
Voici deux exemples d'interaction de requ^etes au sein de l'architecture avec MiddleMan.
Figure 3.5 la requ^ete d'une video V composee de deux parties:V1 et V2,avec Defaut de cache:
18 2004/2005
CHAPITRE 3.ARCHITECTURES SP

ECIFIQUES AU CONTENU MULTIM

EDIA
V
B3
LAN
1
2
3
4
5
6
7
7
Machine 1
Machine 4
Machine 2
Machine 3
1 2
SP2
LP1
B1
LP3
SP3
C
LP
SP
B Navigateur
Local Proxy Serveur
Coordinateur
Proxy de Stockage
1
2
Web Serveur W
C
Fig.3.5 { Un defaut de cache au sein de Middleman
1.LP1 contacte C et W
2.C repond qu'il ne possede pas la video.V n'est pas cachee dans le systeme.Wrepond avec
les ent^etes de V.
3.Avec ces informations d'ent^ete LP1 demande une allocation d'espace pour stocker V1 a C
4.Si susament de place est disponible,C repond avec la localisation possible du bloc.En
revanche s'il n'y a pas d'espace,C execute l'algorithme de remplacement de cache dans le
but d'identier un bloc a eliminer et retourne une localisation a LP1.Pour l'exemple ce
sera SP2
5.LP1 commence a recevoir V1 de W qui est ensuite streamee a la fois a B1 et a SP2.
6.Apres que V1 ait ete recue entierement,LP1 demande la localisation pour un autre bloc
de C
7.C retourne SP3 pour la localisation du bloc suivant.LP1 continue de recevoir V2 de W
qui est streamee ensuite a B1 et SP3.L'un des inconvenients de ce type d'interaction est
la communication qu'on a en plus avec le coordinateur.
19 2004/2005
CHAPITRE 3.ARCHITECTURES SP

ECIFIQUES AU CONTENU MULTIM

EDIA
Web Serveur W
1 2
Machine 1
Machine 4
Machine 2
Machine 3
SP
LP
C
B
LP
B
V1
SP
4
1
2
3
V2
Fig.3.6 { Un succes de cache
Succes de cache gure 3.6:
Soit la video V cachee dans le systeme,et B3 demande V voici alors l'echange:
1.B3 contacte C et W
2.C repond que la video est cachee au sein du systeme en retournant un pointeur au bloc ou
se trouve la video a savoir SP2
3.LP3 ferme sa connexion avec W
4.LP3 contacte SP2 et commence le streaming de V1 a B3
5.Une fois que V1 est transmise,LP3 contacte encore C pour obtenir le lieu du prochain
bloc
6.C repond avec un pointeur a SP3.LP3 contacte SP3 et demarre le streaming de V2 a B3.
3.3 L'architecture QBIX:Quality-Based Intelligent proXy [14]
Le QBIX supporte l'adaptation temps reel dans le domaine du compresse (video,audio...) et
du non-compresse.Il utilise l'adaptation pour ameliorer les strategies de cache dans les proxies.Le
20 2004/2005
CHAPITRE 3.ARCHITECTURES SP

ECIFIQUES AU CONTENU MULTIM

EDIA
but de QBIX est de faire un cache adaptatif avec une certaine intelligence:au lieu de supprimer
un objet,on reduit sa qualite simplement.L'architecture se compose de cinq modules:
1.IO Layer Ce module realise les entrees/sorties dans le proxy,cachant les acces reseaux et les
chiers par une classe abstraite IO.Il est base sur les frames et les Elementary Streams,
seules des frames complets d'un ES sont lus ou ecrits.
2.Adaptation Engine Ce module utilise un canal de donnees ou les objets sont dans un pre-
mier temps lus pour pouvoir eventuellement utiliser un adaptateur.Cette adapation repose
sur plusieurs supports:la reduction temporelle,la reduction des couleurs,la reduction spa-
tiale et la reduction du debit binaire.Le fontionnement est le suivant:il prend en entree
une frame et rend en sortie une liste de frames ayant subies des adaptations.
3.Module MPEG-7 Ce module ajoute un support pour creer et analyser les descriptions
MPEG-7.MPEG-7 decrit la structure interne des chiers sources MPEG-4 et decrit la
taille,type (video,audio ou BIFS) et le debit pour chaque ES.Un descripteur de variation
contient le nom de ce pas d'adaptation,la qualite de perte attendue et la priorite de cette
adaptation.De plus une description MPEG-7 modiee est generee pour chaque Elementary
Stream.Ainsi le proxy peut prendre connaissance du type d'adaptation qui a ete adopte
selon la description.
4.Cache Management Le gestionnaire de Cache (CM,cache manager) gere toutes les videos
stockees dans le cache,il utilise l'Adaptation Engine pour executer l'adaptation et le
module MPEG-7 pour extraire la liste des sequences de variation (appellee variations sets)
de la description MPEG-7.Dans le cas ou la description MPEG7 n'est pas disponible,une
\variation set"par defaut est utilisee.Le CM cree un objet DataChannel qui va lire sur
une source puis l'envoyer.Les dierentes politiques utlisees sont:
{ LRU
{ CRS (Cache Replacement Strategie ) avances
{ V-CRS:variations de qualites de la video la moins populaire
{ H-CRS:l'adaptation des candidats selon leurs qualites
{ Combinaison des deux precedentes
5.Session Management Ce module est responsable de la creation et de la gestion des sessions.
Une session connecte toujours deux partenaires de communication:il exite deux dierents
types:
{ serveur session:connecte client et proxy
{ client session:connecte proxy et serveur
3.4 L'architecture centralisee autour d'un Broker [16]
C'est une architecture composee d'un certain nombre de serveurs proxy cache,dont un qui
fonctionne comme un intermediaire ou encore un agent de contr^ole,le Broker gure 3.7:
{ est un serveur proxy RTSP
2
ameliore
2
Real Time Streaming Protocol(RFC 2326) est un protocole de contr^ole de niveaux application pour des ux
21 2004/2005
CHAPITRE 3.ARCHITECTURES SP

ECIFIQUES AU CONTENU MULTIM

EDIA
{ execute les fonctions de cache standards
{ toutes les requ^etes sont routees de maniere transparente au broker
{ maintient un etat d'information qui est important dans toutes les sessions RTSP
NOTE:Le serveur permet de mettre en cache un contenu avant toute requ^ete du client,ainsi
la source peut ne pas ^etre en ligne.Neanmoins son contenu sera toujours accessible et conserve
dans un ou plusieurs caches.
Cache
Cache
Cache
Cache
Broker
INTERNET
CLIENT
Fig.3.7 { L'architecture du Broker
Les donnees sont encodees ou divisees en couche (layered).Les objets doivent avoir une
couche de base qui contient l'essentiel des informations et une ou plusieurs couches ameliorees
pour contenir des informations de niveau superieur.L'organisation est la suivante:
{ le cache physique est distribue a travers le broker et il va realiser la fonction de cache a
travers l'ensemble des machines.
{ le broker aura besoin de transporter l'index et de rechercher l'information de maniere
ecace a travers les serveurs proxy
{ pour faciliter cette t^eche:utilisation d'une structure de donnees contenant seulement
l'information relative aux objets caches.On appelle auxiliary cache l'element qui se trouve
localise dans la memoire du broker.Il aide le broker a indexer les entrees et lui permet de
localiser les clips audios et videos facilement.Il est egalement utilise pour s'assurer que le
broker a besoin d'acceder au cache physique seulement pour une ecriture eective.
La politique de remplacement adoptee par cette architecture se base sur les clips encodes par
couche pour fournir une meilleure QoS aux clients.Typiquement le nombre de couches doit ^etre
compris entre 5 et 10.Les couches superieures en general contiendront des informations moins
importantes comparees aux couches basses.La politique de remplacement repose sur une ap-
proche en couche:les clips sont ranges selon leurs poids:Wt = W(1=n) avec Wt le poids de la
couche,West le poids du clip et n le nombre de couches.
multimedias streames sur IP http://www.rtsp.org/
22 2004/2005
CHAPITRE 3.ARCHITECTURES SP

ECIFIQUES AU CONTENU MULTIM

EDIA
3.5 Mocha [17]
3.5.1 Generalites
Mocha est un proxy-cache multimedia pour des ux encodes par couche.Il fonctionne au
dessus de Squid
3
.Le principal objectif de Mocha est d'executer un cache de type qualite modu-
lable (quality adaptative caching).Pour cela il s'appuie a la fois sur la popularite d'un ux mais
aussi sur la disponibilite de la bande passante du client.
Il faut,pour un tel encodage,une organisation en couche an de fournir une opportunite d'ame-
liorer la qualite des ux caches.Les couches basses sont delivrees par le cache et les couches
hautes par le serveur.
ControlCongestion
Client
RSTP
Request Manager
Data packetsAck
AckAck
Ack
Data
packets Data
RTP packets
SERVEUR
RTP
Quality Adaptor
Loss
Repair
Memory
Cache
Acker
Prefesching Manager
RSTP
Serveur
CLIENT
Fig.3.8 { L'architecture de MOCHA
3.5.2 L'interaction:
Le Request Manager (RM) recoit toutes les requ^etes,c'est ce module qui se charge de la
verication de la disponibilite d'un ux dans le cache.
Defaut de Cache:Si un ux f n'est pas dans le cache,RM transmet tous les messages RTSP
dans les deux directions entre le client et le serveur.Mocha relaie donc les donnees et les
Ack (de gestion) dans les deux directions.
Succes de cache:Si une copie est disponible dans le cache de Mocha alors il joue le r^ole
d'un serveur et repond directement aux messages RTSP.Sur l'arrivee d'une demande de
LECTURE du client,Mocha initialise la delivrance du ux cache en ayant de bonnes
performances pour le debit et la qualite d'adaptation basee sur l'etat de la connexion entre
3
Squid est un systeme de proxy cache qui propose l'optimisation de la bande passante a travers le cache et le
contr^ole et ltrage des ux echanges sur Internet.
23 2004/2005
CHAPITRE 3.ARCHITECTURES SP

ECIFIQUES AU CONTENU MULTIM

EDIA
le proxy et le client.Si la qualite du ux cache est inferieure a la qualite maximale qu'on
peut delivrer sur le canal,alors il y a activation du Prefetching Manager qui etablit une
session de prefetching au serveur pour avoir les parts manquantes des couches (autant de
couches hautes du ux demande).
Les donnees dans Mocha:L'une des contraintes est qu'il faut une certaine coherence avec
la structure de donnees denie au sein de Squid.Etant donne que les caches Web stockent
ou fournissent les donnees de facon atomique,on a besoin d'etendre les structures de don-
nees de Squid pour maintenir l'information sur les segments caches de toutes les couches.
De plus toutes les couches de chaque ux doivent ^etre collectivement vues comme un objet
unique.Les paquets de chaque couche d'un ux cache sont stockes dans un chier separe.Chaque
chier contient une collection de chunks qui sont un groupe de paquets contigus.
Le prechargement a granularite ne:Mocha implemente un prechargement a granularite
tres ne dans le but d'ameliorer la qualite du ux cache delivre.Quand la qualite d'un
ux cache est inferieure a la qualite delivrable au maximun pour un client donne,Mocha
initialise une connexion avec le serveur et joue le r^ole d'un client.Puis il envoie les requ^etes
de prefetching.
La politique de remplacement:Mocha implemente un mecanisme de remplacement a gra-
nularite tres ne:pour cela il denit un parametre de popularite a granularite ne pour
chaque partie d'un ux.Puisque la qualite d'un ux cache est determinee par le nombre
de couches cachees,Mocha assigne une popularite a chaque couche separemment.La po-
pularite est denie pour chaque couche c d'un ux f donne.
3.6 Video Caching Network [18]
3.6.1 Generalites
C'est une architecture qui utilise un espace gobal de cache distribue tout au long du chemin
de delivrance entre le serveur et l'utilisateur an de cacher les videos les plus demandees.VCN
est constitue d'un certain nombre de Caching Element (CE) qui se situent tout au long de la
route de delivrance de la video entre le client et le serveur.Un CE:
{ est un module s'executant sur un dispositif de calcul equipe d'un espace de cache.
{ peut s'executer sur un serveur cache dedie ou un routeur equipe d'un espace cache.
Les proprietes du VCN:
{ Une equipe de CE est formee dynamiquement tout au long du chemin de delivrance pour
cacher une video.
{ Contrairement a l'utilisation de cache hierarchique statique ou un ensemble de caches
peer-to-peer xe,le VCN peut ajuster sa structure dynamiquement en reponse a des chan-
gements dans le comportement et le lieu des utilisateurs.
{ Chaque membre de l'equipe cache a peu pres la m^eme quantite de donnees pour une m^eme
video,ce qui permet un meilleur equilibre de la charge parmi les membres sans utiliser un
24 2004/2005
CHAPITRE 3.ARCHITECTURES SP

ECIFIQUES AU CONTENU MULTIM

EDIA
algorithme explicite d'equilibrage des charges.
{ Un membre de l'equipe communique seulement avec ses deux autres membres de proximite,
ce qui permet au membre de s'adapter rapidement aux conditions de changements de ses
voisins.Ce point permet de contrer les inconvenients de l'approche centralisee qui entraine
une utilisation du broadcast.
3.6.2 L'interaction
Soit v1,v2,v3...vn,un nombre n de videos d'un serveur de taille identique.Le serveur video
a un nombre logique de canaux,chacun avec une bande passante.Chaque CE a donc un plan
de son cache,une structure de donnees gardant l'information des videos cachees.Une equipe
est formee seulement quand un client demande une video qui n'est cachee dans aucun des CE
situes le long du chemin entre le client et le serveur.La formation de l'equipe s'eectue en quatre
phases gure 3.9:
Phase 1
{ Le client demande une video Vi au serveur
{ Si aucun CE sur le chemin ne possede la video on atteint le serveur
{ Le serveur recoit la requ^ete
{ Il cherche s'il a un canal disponible pour delivrer la video
si oui:il envoie un message Build
Team au client
si non:la demande est mise en attente pour ^etre traitee plus tard lorsqu'un canal sera
disponible.
{ Le message Build
Team contient des informations telles que:VideoID,taille,l'ID de
l'equipe,le nombre de CE dans cette equipe (initialise a 0 au depart par le serveur) et
l'adresse IP du dernier CE rejoignant l'equipe.
Phase 2:
{ Lorsqu'un CE tout au long du chemin recoit un BTM (Build
Team
Message),le CE
execute un algorithme d'allocation de cache pour reserver un espace de stockage pour
cacher une partie de la video.
{ S'il n'y a pas assez d'espace:alors il y a election de la victime qui est la video la moins
populaire.Si la video est autant populaire que la video demandee alors le CE tranfert
le BTM au client sans la cacher.
{ Si la victime est moins populaire alors tous les blocs de la victime sont supprimes et il
va informer l'equipe stockant cette video de l'imiter.
{ Si la reservation est possible alors le CE devient un membre de l'equipe en creant une
nouvelle entree dans le plan de cache et stocke les informations necessaires pour cacher
cette video.
{ Le CE remplit donc l'entree avec team ID,la taille du cache reellement reservee pour
cette video et l'adresse du CE precedent dans cette equipe.
Phase 3:
25 2004/2005
CHAPITRE 3.ARCHITECTURES SP

ECIFIQUES AU CONTENU MULTIM

EDIA
{ Lorsque le client recoit le message BuildTeam (BTM),il prepare un message Com-
plete
Team (CTM) qui contient:la ID video,la taille,le teamID,le nombre de CE dans
cette equipe et le next
cache
block
{ Le client fait suivre le message au CE qui lui a precedemment envoye le message BTM,
il sera le leader de cette equipe:par ailleurs il sera le cache ayant le premier fragment
de la video.
{ Chaque CE dans l'equipe traite le CTM:les CE allouent alors un espace de cache par
uncommit
space = min((video size/nombre de CE),reserved
size),
next
cache
block:= next
cache
block +commit
space + 1
Phase 4:
{ Quand le CTM est recu par le serveur,le serveur delivre la video demandee au client
{ Au passage chaque CE insere les blocs de donnees
TEAM Leader
Complete_Team
CE
CE
CE
Video Serveur
Video Player
3
1
2
BUILD_TEAM
REQUEST
Ex : 12 blocs
4
Alloue 4 8..11
Alloue 4 4..7
Alloue 4 0..3
Fig.3.9 { L'architecture du VCN
Le fonctionnement d'une equipe de CE durant un Cache Hit est le suivant:
1.Une nouvelle requ^ete pour V1 arrive au CE
2.Le CE cherche dans son plan de cache pour un bloc de Vi
3.S'il n'y a pas de Vi,le CE transmet le message au serveur.Dans le cas contraire le CE est
un membre du team cachant Vi.Si ce CE n'est pas le Team
Leader (celui qui contient la
premiere partie et par qui tout le transfert va commencer),le CE envoie un Cache
Hit Mes-
sage contenant l'adresse du client,la videoID,teamID au prochain CE du team jusqu'au
team-leader.
4.Lorsqu'on atteint le team
leader:il commence le transfert:
1.informe le CE suivant avec un timing
2.le serveur peut ^etre le dernier noeud a servir la demande
26 2004/2005
CHAPITRE 3.ARCHITECTURES SP

ECIFIQUES AU CONTENU MULTIM

EDIA
3.7 Synthese
3.7.1 Un apercu des solutions proposees
Dans la premiere et la seconde partie j'ai presente les solutions qui ont ete proposees dans
la litterature.Il existe beaucoup de solutions pour les applications multimedias,mais certaines
ne considerent qu'une partie du probleme ou ne s'interessent uniquement qu'a un point precis
pour une application precise (par exemple l'amelioration de la politique de remplacement) ou
ressemblent fortement a ce que j'ai deja presente ou encore utilisent une synthese des techniques
deja existantes et explorees dans d'autres (segmentation ou prefetching).Ce sont ces solutions
que je presente brievement dans cette partie.
3.7.2 Conclusion
L'etude de l'ensemble de ces architecture amene a la conclusion suivante:
La technologie des CDN est celle qui semble la plus federatrice au niveau des entreprises et
semble notamment interessante pour le projet du concert car il s'agit avant tout de ltrer un
trac entrant an que les donnees a emettre soient identiees a un utilisateur demandeur de
contenu:en fonction de ce ltrage,il est alors necessaire d'orienter la requ^ete vers le serveur
Web le mieux a m^eme de la servir.Pourtant,ce type d'architecture vise des milliers d'usagers
ce n'est pas pour l'instant l'objectif a court terme vise pour le concert.
Dans le cadre du concert les utilisateurs et le type de ux seront connus donc cette solution
semble repondre a nos besoins cependant il s'agit de deployer toute une infrastrusture impor-
tante:des serveurs de calcul,plusieurs serveurs de contenus,des serveurs de caches,des serveurs
de routage...ce qui n'est pas forcement utile pour une premiere mise en oeuvre et par ailleurs
necessite un co^ut materiel non negligeable.
Le MiddleMan se rapproche d'une architecture centralisee surtout par le fait que l'entite Coor-
dinatrice intercepte toutes les requ^etes.Elle se charge de determiner qui pourra servir telle ou
telle requ^ete.Face a peu d'utilisateurs ce systeme est aisement gerable,mais lorsque le nombre
d'utilisateurs devient important se pose alors des problemes de passage a l'echelle:le coordi-
nateur saura-t-il gerer un nombre important d'utilisateurs?En somme ne se rapproche-t-il pas
nalement d'une architecture de type Client/Serveur?Ne risque-t-il pas nalement de rencon-
trer des problemes identiques a ceux d'une architecture de type C/S?Il ne me semble pas tres
interessant de ce point de vue car on cherche et avance vers une solution de type distribuee.Les
avantages d'une telle architecture:
{ la reduction de la latence
{ un important espace de stockage
{ reduction de la charge
Les inconvenients:
{ l'engorgement se trouve deplace au niveau du coordinateur:bien qu'il ne fasse pas de
transfert de donnees.
{ Le coordinateur est un point de vulnerabilite dans la mesure ou l'apparition d'un pro-
27 2004/2005
CHAPITRE 3.ARCHITECTURES SP

ECIFIQUES AU CONTENU MULTIM

EDIA
Article
Solution
Description
[34]
Architecture
Un systeme de cache qui utilise les ressources utilisateur,ils integrent dans
leurs systeme les aggregations de requ^etes,le prexe caching,des mecanismes
de contr^ole du debit.
[16]
Architecture
La gestion des proxy par un coordinateur qui maintient un etat global des conte-
nus de cache des autres proxy.Tous les algorithmes de cache tournent sur le
broker.
[17]
Mecanisme
Mecanisme de cache proxy pour ameliorer la qualite des ux encodes en couche
les plus demandes (prefetching,algorithmes de remplacement a grain n)
[19]
Technique
Proposition de stockage des clips initiaux les plus demandes
[20]
Algorithmes
Ils utilisent les techniques existantes et proposent une nouvelle techniques pour
le streaming utilisant la segmentation,le cache dynamique,le cache cooperatif et
adaptatif.Il existe une implementation:SOCCER
[21]
coherence
Proposent une amelioration a la gestion des caches a gros grain.Il s'agit de
partionner les pages dynamiques en classe basee sur les patterns de l'URL de
facon a ce qu'une application puisse specier l'id de la page et les dependances
des donnees et invoque l'invalide pour une classe de page dynamique.
[22]
Segmentation
Ils proposent une technique qui segmente en block les ux,les politiques de caches
sont appliquees aux segments avec la prise en compte des distances,et la position
du segment.
[23]
Service
Un systeme de cache et de distribution de video interactives utilisant un service
d'analyse de contenu.Le principe consiste a fournir a l'utilisateur une premiere
recapitulation des donnees et puis par la suite les parties demandees par l'utili-
sateur.
[38]
Algorithme
Propose un algorithme de maintenance unie implementant le remplacement de
cache et un algorithme de coherence
[54]
Segmentation
Ils proposent une segmentation en taille variable.Le schema propose determine
la taille des segments pour -chaque video basee sur la frequence des demandes.
[42]
Protocole
Proposent un protocole de maintien de coherence,le protocole permet a un groupe
de cache web repartis de cooperer pour reduire la latence et la charge des serveurs.
[46]
Architecture
Proposent un schema hybride compose de cache hierarchique et distribues
[47]
Service
Dans
cette article les auteurs examinent les technologies existantes pour permettre aux
concepteurs de concevoir des caches a large echelle,ils proposent un service de
localisation des donnees qui cherche ou les donnees sont repliquees.
[55]
Framework
Proposent un framework qui integre les caches avec un technique de precharge-
ment par broadcast de suxe d'un video de facon periodique(pour les videos les
plus demandees)
[53]
Architecture
Utilisation des ressources des clients pour cela ils se basent sur un arbre de mul-
ticast avec des primitives de redirection.
Fig.3.10 { Les solutions proposees dans la litterature
28 2004/2005
CHAPITRE 3.ARCHITECTURES SP

ECIFIQUES AU CONTENU MULTIM

EDIA
bleme au niveau de ce dernier provoque l'eondrement du systeme entier.La solution a ce
probleme serait la mise en place d'un schema de type coordinateur-cohort:le schema de
type coordinateur maintient un coordinateur de backup qui permettrait un fontionnement
normal si le coordinateur principal venait a ^etre en panne.
L'architecture du QBIX me semble interessante par l'approche modulaire qu'elle met en
avant notamment par une modularisation des techniques pour traiter un ux multimedia.Par
ailleurs ce type d'approche peut plus aisement ^etre modiee par la suite que lorsque l'on adapte
une vue lineaire des traitements de ux.Cette demarche pourrait ^etre pertinente pour jouer vers
un public ayant des terminaux de capacite dierente.Cependant on peut se demander l'utilite
de la reduction de la qualite dans un projet tel que le concert reparti ou la synchronisation des
sons et des images est un element primordial.
L'architecture du broker est proche de celle de MiddleMan,avec une centralisation qui se fait
au niveau du broker et une approche en couches en ce qui concerne la politique de remplacement.
Cette approche parait plus interessante que celle utilisee par le QBIX.Cette architecture a donc
les m^emes inconvenients que MiddleMan en ce qui concerne l'engorgement possible au niveau
du broker.Elle ne convient donc pas pour le concert virtuel reparti.
L'un des inconvenients majeurs de Mocha est son incapacite a ajuster la qualite de ux caches
lorsqu'il s'agit des ux qui ne sont pas encodes par couche.Cette solution me semble complexe
a mettre en oeuvre pour le concert virtuel reparti.
Le fonctionnement d'une architecture telle que VCN proposant une repartition de charge par
la repartition des donnees semble vraiment adapte pour des donnees multimedias.Les donnees
sont poussees pres des lieux ou elles sont les plus demandees.Mais la complexite de mise en
oeuvre (par la constitution et reconstruction d'equipes pour prendre en compte des participants
qui partent,gestion de dierentes phases,et mise en place d'entite au long de la route entre le
serveur et le client) est importante.
En somme,l'ensemble des architectures etudiees sont interessantes car elles repondent a l'une
des specications requises:le desengorgement au niveau du serveur.Cependant,certaines d'entre
elles semblent juste deplacer le point de desengorgement ou bien ne proposent pas une solution
claire pour diminuer la latence pour l'utilisateur.La solution du VCN semble celle qui parait la
plus adaptee au concert avec une repartition des donnees donc des charges,la diminution de la
latence et suppression du point d'engorgement.Elle reste neanmoins une solution lourde a mettre
en place.Toutefois on peut remarquer que cette solution rappelle un autre type d'architecture
tres repandue et qui resout ces problemes de mise-en-oeuvre (puisqu'elle est sous jacente):le
P2P ou on a la possibilite de demander a chaque pair existant de participer a la replication ou
encore de transmettre un ux a un autre pair.Je vais donc voir si ces architectures repondent
aux contraintes xees par l'application CVR.
29 2004/2005
CHAPITRE 4.PEER TO PEER
Chapitre 4
Peer To Peer
Il existe beaucoup d'applications de distribution de contenus basees sur le P2P[9],[7]...Les
systemes et applications P2P (peer-to-peer ou egal a egal) ont ete penses pour remedier aux
problemes de repartition des charges du reseau et aux defaillances des serveurs puisqu'au sein
d'une architecture de type client/serveur toute la charge se trouve ciblee sur le serveur.
Les problemes de droits d'auteurs poses par les applications les plus populaires de P2P en-
gendrent une polemique qui a rendu celebres ces applications alors que ce type d'architecture
est une veritable innovation car elles permettent la rationalisation des ressources disponibles
restees inexploitees.Les ressources que les systemes P2P essaient de rentabiliser et optimiser
sont:la bande passante,l'espace de stockage,la capacite de traitement.De plus,ils permettent
le passage a l'echelle.
4.1 Presentation generale
Nous considerons ici les systemes P2P comme ayant les caracteristiques suivantes:
Description:C'est un ensemble de noeuds interconnectes via Internet,avec une architecture
distribuee c'est-a-dire avec abscence de centralisation.
Caracteristiques:Il s'y opere une certaine dynamicite du reseau (notamment de la topologie
du reseau),avec decouverte progressive et dynamique des pairs et des ressources even-
tuelles.Il permet donc une extensibilite de participants (pairs) ce qui peut ameliorer les
performances.Enn,etant donne l'importance de l'espace de stockage qui peut ^etre extrait
de cette architecture,on peut en deduire une disponibilite haute (replicat).
Localisation:Elle s'eectue par l'attribution d'une cle unique pour chaque donnee,par une
aectation intelligente des cles aux noeuds et ce an de trouver le pair responsable de la
donnee a partir de la cle.
Cependant dans la litterature deux types de modeles coexistent:
L'architecture P2P centralisee:Au sein de ce type de modele un pair se demarque des
autres,il sert de serveur de noms centralisant ainsi tous les appels et orchestre la coor-
dination des autres pairs.Une fois la connexion eectuee,le reste de la communication
s'eectue directement entre les noeuds concernes.
30 2004/2005
CHAPITRE 4.PEER TO PEER
L'architecture P2P decentralisee:Ce modele ne comporte pas de serveurs de noms.Les
pairs doivent assurer la connexion par eux-m^emes,et doivent pouvoir assurer la connexion
des nouveaux noeuds.Il existe dierentes methodes:un pair est toujours connu des nou-
veaux arrivants,envoyer un message pour s'annoncer vers une adresse multicast...Apres la
prise de connaissance des autres pairs,le reste de la connexion s'opere de maniere identique
a celle de l'architecture centralisee.Chaque pair est a la fois serveur et client.Un pair est
serveur lorsqu'il publie des ressources et oriente les requ^etes vers les autres noeuds.Il est
client par la consommation des ressources deposees par d'autres noeuds.
4.2 Les trois grandes generations
Il existe beaucoup d'applications P2P telles que Gnutella,Freenet,Kazaa,eMule...Les sys-
temes P2P ont connu une evolution continue tout au long des annees.On peut les classer selon
leur generation.Il existe trois grandes evolutions au sein des systemes P2P.
4.2.1 Premiere generation
La premiere generation des systemes P2Pevolue essentiellement au sein d'une architecture de
type Client/Serveur.Chaque pair qui souhaite acquerir un chier,fait une demande au serveur
qui contient l'index des chiers echanges an de savoir qui possede le chier recherche.Napster
gure 4.1 fut la premiere application a fournir ce type de service.Il utilise un serveur centralise
qui contient le nom des chiers echanges par la communaute de Napster.Chaque client met le
titre qu'il possede en local sur le serveur.Napster se retrouve tres vite confronte au probleme
d'engorgement du reseau creant un unique point de panne.
31 2004/2005
CHAPITRE 4.PEER TO PEER
1
2
3
Serveur
Pair
Pair
Pair
Pair
Pair
Pair
Pair
Pair
PairPair
Pair
Fig.4.1 { L'architecture de Napster - 1:Le pair envoie sa requ^ete;2:Si le serveur connait
la machine sur laquelle reside le chier recherche,il envoie l'adresse sinon il interroge les autres
machines connectees;3:Telechargement par connexion directe entre les deux pairs.
4.2.2 Seconde generation
Cette generation tente de pallier les problemes de centralisation des systemes tels que Naps-
ter.C'est alors qu'apparaissent Gnutella et Freenet.Gnutella stocke les chiers de facon identique
a Napster:les utilisateurs stockent les chiers.Mais le serveur centralise n'existe plus,la re-
cherche se fait alors par inondation de proche en proche jusqu'au noeud contenant le chier.Ce
systeme est eectivement plus robuste par l'absence d'un point de faille unique.Neanmoins il
consomme beaucoup de bande passante a cause de l'inondation.
Freenet diere de Gnutella par l'existence d'un routage plus deterministe.Chaque noeud de
Freenet possede une table de routage dynamique contenant les adresses des autres noeuds et des
chiers qu'ils sont susceptibles de detenir.Freenet tend vers une structure qui essaye de servir les
utilisateurs le plus rapidement par la replication des donnees vers les\hotspots".Le chier lors
de sa demande est duplique tout au long du chemin.Il repose sur une architecture totalement
distribuee et ore une grande tolerance aux pannes.
Ces deux systemes ont resolu les problemes de la centralisation de leur architecture.Cependant
ils ne resolvent pas le probleme de passage a l'echelle (qui pose un probleme lors de l'inondation
par le protocole Gnutella) et la garantie de trouver un document dans le reseau (comme c'est
le cas au sein de Freenet ou les documents tendent a dispara^tre s'ils ne sont pas demandes).
Le probleme de passage a l'echelle fait appara^tre le concept des\superpeers".Au sein de ces
architectures hybrides il existe deux types de noeuds:les noeuds\simples"disposant d'une faible
bande passante et les super-peers qui sont plus rapides.Ces derniers sont connectes en mode
Client/Serveur aux super-peers formant ainsi un cluster et l'index des ressources du cluster est
32 2004/2005
CHAPITRE 4.PEER TO PEER
centralise dans les superpeers gure4.2.
Mode Client/Serveur
Mode P2P
SuperPeer
SuperPeer
SuperPeer
Pair
Pair
Pair
Pair
Pair
Pair
Pair
Pair
Pair
Fig.4.2 { Une architecture hybride
4.2.3 Troisieme generation
Eectivement les super-peers repondent aux attentes:ils orent plus de robustesse,plus
de disponibilite,diminuent la charge et supportent le passage a l'echelle.Cependant ces divers
systemes reposent souvent sur des routages simplistes utilisant un broadcast massif des messages,
ou de routage avec un temporisateur (TTL).C'est alors qu'apparaissent les systemes reposant sur
une DHT (Distributed Hash Table)[49] qui tentent de minimiser le nombre de messages transmis,
a optimiser la recherche et la localisation des pairs.Avec ce systeme apparait le concept de P2P
structure dont les plus connus sont CHORD[3],P-Grid[56],Pastry[4]....
4.3 Les systemes bases sur une DHT
Fonctionnement de base dans les systemes de DHT[30],le routage et la localisation sont
m^eles,cela est d^u a la structure m^eme qui repose sur les principes suivants:
Identication:Chaque noeud a un identiant unique (ID).Chaque objet est identie par une
cle obtenue par hashage (Cle).Ces identifants partagent un espace de nommage unique
2
160
.
Pairs:Chaque pair du reseau est responsable d'un sous-ensemble d'identiants de l'espace de
nommage global et par consequent des objets qui appartiennent a ce sous-ensemble.
Routage:Il s'eectue de proche en proche.Un peer qui recoit un message le transmet au N
pairs qu'il conna^t et qui sont plus proches de la destination.
33 2004/2005
CHAPITRE 4.PEER TO PEER
Ces systemes sont tous completement decentralises,autonomes (il n'y a pas de serveurs ni
d'administrateurs) auto-adaptables aux departs,arrives et pannes des noeuds et supportent la
montee en charge (on peut facilement passer d'une centaine de noeuds a des milliers de noeuds).
Les systemes bases sur une DHT
Chord est le predecesseur de Pastry.Le principe de fonctionnement est le suivant:
{ Les noeuds et les donnees ont des identiants obtenus par hachage.Chaque noeud a a sa
charge les objets qui sont proches de sa cle.
{ Chaque noeud maintient une table des noeuds des voisins connus sous le nom de\nger
table".Quand un noeud veut faire une recherche il consulte cette table pour savoir a quel
noeud il va envoyer la requ^ete.Cette table est de l'ordre de O(log(N)) avec N le nombre
total de noeuds du systeme,donc chaque noeud ne connait que O(log(N)) noeuds.
{ De m^eme la recherche s'eectue par la propagation de la requ^ete de proche en proche et il
en est de m^eme pour le retour du resultat,ce qui n'est pas optimal puisqu'elle s'eectue en
O(log(N)).Pastry regle ce probleme par un routage beaucoup plus intelligent (la topologie
du reseau est prise en compte) puisque dans Pastry il y a un representant de chaque niveau
qui est dans la table de routage.
4.4 CAN
Content Addressable Network evolue dans un espace virtuel distribue a d-dimensions.Chaque
noeud possede un espace qui lui est propre.Un objet est localise par le transfert d'une requ^ete
vers un voisin qui a les coordonnees les plus proches de la destination.Chaque noeud maintient
une table de routage contenant les coordonnees de ses voisins.Cette table est de taille xe O(d)
avec d la dimension de l'espace.Cependant les recherches sont moins ecaces que dans Chord
et Pastry[49].
4.5 Pastry[4]
Pastry comble les deciences de Chord,CAN et d'autres de m^emes caracteristiques.Pastry
conna^t par ailleurs des developpements d'applications (PAST,ePost
1
) et d'API au-dessous de
la couche de localisation et de routage qu'il ore.Pastry est un reseau P2P developpe par
l'universite de RICE en cooperation avec le centre de recherche Microsoft.Il s'appuie sur des
mecanismes bases sur une table de hachage distribuee an de fournir le routage et la localisation
des noeuds et des objets qu'ils contiennent.Son principal objectif est de fournir un support able
pour les applications ou services qui se baseraient sur un reseau P2P.
Les principales caracteristiques de Pastry:
{ est une couche de localisation d'objets distribues et de support de routage de niveau
applicatif pour des applications P2P
1
http://dsandler.org/wp/archives/2005/02/02/epost
34 2004/2005
CHAPITRE 4.PEER TO PEER
{ met en oeuvre une decentralisation et une extensibilite complete
{ permet une auto adaptabilite aux arrivees et departs des noeuds
{ cherche a minimiser les chemins parcourus par les messages en nombre de sauts.
{ peut ^etre utilise pour supporter un grand nombre d'applications P2P incluant un espace
de stockage de donnees global,de partage de donnees...
Une implementation en Java de Pastry a ete developpee:FreePastry.C'est sur cette couche
de routage que s'appuie notamment d'autres applications telles que PAST[7],SCRIBE[6] et
Squirrel[8].Ces applications ont une architecture en couche decrite par le schema en gure4.3.
Noeud
Noeud
Noeud
Service de localisation et de routage
get(cle)insertion (cle,valeur)
Pastry
DHT
Application
valeur
localisation(message,clé)
réponse : Adresse IP
Fig.4.3 { La separation en couche oerte par Pastry
4.5.1 Caracteristiques des noeuds
Chaque noeud dans Pastry a un identiant unique (nodeID) sur 128 bits,gr^ace a un hachage
ou a une fonction cryptographique de son adresse IP ou de sa cle publique ou tout autre element
qui va permettre d'identier de maniere unique le noeud.
Fig.4.4 { L'espace virtuel de Pastry
35 2004/2005
CHAPITRE 4.PEER TO PEER
Ces noeuds doivent ^etre uniformement distribues dans l'espace virtuel.Ce nodeID indique
sa position dans cet espace des identiants qui va de 0 a 2
128
1.Par ailleurs les objets qui sont
dans ce reseau ont egalement un identiant qui est obtenu de facon identique a celle des noeuds.
Les objets et les nodeID evoluent au sein de ce m^eme espace virtuel.Cet espace de nommage et
de localisation des noeuds se represente en anneau.Chaque noeud ayant a sa charge les objets
dont l'identiant se trouve le plus proche de celui-ci.
4.5.2 Gestion des noeuds
Chaque noeud,dans le but d'optimiser le routage,stocke et contient deux tables dierentes:
une table de routage (Routing Table gure 4.5) et une table des noeuds les plus proches nume-
riquement (Leaf Set).Cette table contient (log
2
b
N) lignes avec 2
b
1 entrees pour chaque ligne
(en general b=4).Les entrees a la ligne n et a la colonne m representent le noeud qui partage
avec le noeud courant n nombre de digits en prexe.Les entrees contiennent les adresses IP des
noeuds.
Le Leaf Set contient les noeuds qui sont proches du noeud numeriquement.Une partie de
cet ensemble contient des IDs qui sont plus grands que le noeudID courant et l'autre partie plus
petits.
Le Routing table est une table a deux dimensions.Une entree a la ligne l et a la colonne c
d'un noeud indique le noeud dont l'identiant partage le m^eme prexe d'une longueur l avec le
noeud local.
4.6 Le routage
Les identiants sont representes en base 16,dans la table de routage gure4.5 il y a un noeud
representatif de domaine de plus haut niveau.Le noeud 65a1fcx:
1.a la ligne 0:il ne partage aucun digit avec les autres noeuds de sa table mais il a un
representant du groupe de noeud commancant avec 0xxxxxx,1xxxxx,2xxxxx etc...
2.a la ligne 1:il partage 1 digit avec les autres noeuds,il connait donc un representant du
groupe de noeud commancant par 60xxxx,61xxxx etc..
3.a la ligne 2:il partage 2 digit avec les autres noeuds presents a cette ligne,il conna^t donc
un representant du groupe de noeuds commancant par 650xxx,651xxx etc..
4....
Le routage d'un message avec une cle D arrive au noeud d'identiant A.
Quelques notations:
R
i
l
est l'entree de la table de routage a la ligne l et a la colonne i.
L
i
est le ieme identiant dans le LeafSet L,une valeur negative indique qu'il est plus petit que
l'identiant du noeud local.
D
l
est la valeur du l-ieme digit de la cle D
shl(A,B) est la longueur du nombre de digits partages par A et B.
Le processus est le suivant:
36 2004/2005
CHAPITRE 4.PEER TO PEER
Fig.4.5 { La table de routage du noeud 65a1fcx
Fig.4.6 { Le pseudo code de l'algorithme de routage de Pastry
37 2004/2005
CHAPITRE 4.PEER TO PEER
Fig.4.7 { Un exemple de routage a partir du noeud 65a1fc vers d46a1c:le noeud 65a1fc envoie
au noeud le plus proche commancant par l'identiant d ce sera le noeud d13da3,ce dernier
envoie vers le noeud commancant pas identiant d4:d4213f et ainsi de suite....
{ Reception du message
{ Si la cle rentre dans l'intervalle de nodeId converti par le LeafSet(ligne 1),le message est
transmis au noeud concerne (ligne 3).
{ Si elle n'est pas couverte par le LeafSet (ligne 4) alors la table de routage est utilisee,le
message est transmis au noeud dont le nodeId partage le prexe le plus long avec la cle qui
doit ^etre au moins plus longue que le prexe partage avec le noeud courant (ligne 6,7,8)
{ Si la table est vide ou si le noeud ne peut ^etre atteint,le message est retransmis au noeud
le plus proche numeriquement de la cle et qui partage un prexe avec la cle au moins
autant que le noeud local (ligne 12,13,14).Il y a une certaine convergence dans la mesure
ou le message est toujours transmis vers un noeud qui partage soit un plus long prexe
avec la cle que le noeud local,soit un prexe aussi long mais qui est numeriquement plus
proche avec la cle que le noeud local.
Par ailleurs une des caracteristiques interessante est le fait que la topologie du reseau (gure
4.7) soit prise en compte dans la table de routage.Les algorithmes utilises par Pastry font en
sorte que les noeuds choisis sont topologiquement proches.Il existe une metrique qui est prise
en charge lors du routage (on considere qu'il existe une fonction qui permet a chaque noeud
de Pastry de connaitre la distance avec un autre noeud).C'est ce qui est visible dans la gure
precedente ou l'on voit la distance eectuee lors du routage dans l'espace topologique.Les noeuds
sont proches au niveaux hauts et sont aleatoires au niveau le plus bas.Le choix du voisin se fait
38 2004/2005
CHAPITRE 4.PEER TO PEER
de facon a ce qu'il soit topologiquement le plus proche.
4.6.1 Arrivee des noeuds
Quand un nouveau noeud N souhaite joindre le reseau,il doit initialiser l'etat de ses tables.
Pour cela il va envoyer un message avec son identiant a un noeud suppose connu A.Le noeud
N demande au noeud A de router un message de jointure avec comme cle son identiant.Pastry
commence alors a transferer le message de jointure qui va atteindre le noeud Z qui est numeri-
quement proche de N.Tous les noeuds rencontres entre A et Z envoient leur tables a N qui peut
initialiser l'etat de sa table de la maniere suivante:
Routing Table:est remplie avec la i-ieme ligne de la table de routage de i-ieme noeud traverse
pour joindre Z
Leaf Set:est base sur celui de Z qui va lui envoyer la sienne.
Neighborhood Set:est base sur celui de A.On admet que A est physiquement proche de N.
Une fois ces etapes eectuees,N envoie l'etat de sa table a chaque noeud contenu dans sa
table an que ces derniers mettent a jour leur table.
4.6.2 Departs et pannes de noeuds
Les noeuds peuvent quitter le reseau sans aucun message de depart.Pour se premunir contre
les erreurs dues aux departs et pannes,chaque noeud verie regulierement la presence des noeuds
de sa table.Lors de la presence d'un noeud en panne la procedure de remplacement est la
suivante:
{ Une panne au niveau de la table de routage a l'entree R
d
l
,le noeud contacte d'abord une
autre entree a la m^eme ligne:R
i
l
avec i i 6= d:cette entree peut contenir une entree pour
R
d
l
dans sa table de routage.Si un tel noeud ne peut ^etre trouve,le noeud etend alors sa
recherche plus en profondeur en utilisant la ligne R
i
l1
.Cette procedure est repetee jusqu'a
trouver un noeud approprie pour remplacer celui qui vient de tomber en panne.
{ Il existe par ailleurs un processus de verication qui va permettre de s'assurer de la dispo-
nibilite des noeuds appartenant au leaf set.Pour remplacer un noeud en panne,on contacte
le noeud avec le plus grand index du c^ote du noeud en panne an d'obtenir son leaf set.
A la reception du leaf set,on parcourt l'ensemble an de trouver un noeud approprie.
{ Le neighborhood set est mis a jour regulierement par un processus de verication perio-
dique de chaque noeud de l'ensemble.
4.7 Conclusion
La solution proposee va donc se baser sur une approche P2P,Pastry plus speciquement.
Pourquoi ce choix?Il repond a l'ensemble des contraintes techniques et fonctionnelles demandees.
Pastry fournit:
1.la decentralisation
39 2004/2005
CHAPITRE 4.PEER TO PEER
2.le passage a l'echelle
3.les avantages oerts par son architecture sous-jacente
4.la distribution de contenu en fort besoin de bande passante a travers SPLITSTREAM
5.la replication de donnees a travers PAST (un service d'archivage de chiers)
4.7.1 Une implementation de Pastry:FreePastry [5]
Il existe deux implementations de Pastry actuellement:FreePastry de Rice University
d'Houston[5] et SimPastry/VisPastry de Microsoft Research.FreePastry est une implementa-
tion en open-source de Pastry.Il est implante en Java.
Il existe beaucoup d'applications et de protocoles construits sur Pastry:Scribe est un protocole
de diusion a base d'arbre,destine a la communication en groupe telle que la messagerie ins-
tantanee ou encore la notication d'evenements telle que la dissemination d'information (stock
alerts) ou de liste de diusion (windows updates).Par ailleurs,il existe des outils qui viennent
au dessus de Pastry comme Splitstream.SplitStream[51] est un systeme qui permet la diusion
de contenu a fort besoin en bande passante.Il s'agit de mettre en place un protocole de diusion
applicatif sachant que le but recherche est la repartition de la charge au sein de tous les noeuds.
SplitStream correspond au prol d'application du concert.Il utilise d'ailleurs Scribe.Dans la
partie suivante nous allons voir en quoi le couplage des deux peut ameliorer une application
multimedia.
4.7.2 Scribe:un protocole de diusion [6]
Scribe est base sur Pastry,son objectif est la creation de groupes avec maintenance de l'etat
de groupe,gestion de l'appartenance,et envoi de messages dans le groupe.Chaque groupe est
deni par la construction d'un arbre multicast base sur le reseau Pastry.A chaque groupe est
associe un identicateur de groupeId.
La racine de l'arbre multicast est le noeud dont le nodeId est le plus proche numeriquement du
groupId.L'inter^et de scribe reside dans la possibilite de faire du multicast de niveau applicatif:
par la primitive Multicast(group,m).Il y a alors routage par l'intermediaire de Pastry en utilisant
l'identicateur de groupe comme destination.Par ailleurs bien qu'ayant une garantie de abilite
\best eort",il est possible de mettre en oeuvre des garanties plus fortes au niveau application.
4.7.3 SplitStream
L'equipe de Pastry propose une approche pour traiter les contenus en fort besoin de bande
passante.Il s'agit d'une solution pour eviter que toute la charge soit supportee par les noeuds
internes comme c'est le cas dans la plupart des reseaux P2P.Leur approche est la suivante:ils
decoupent le ux en plusieurs bandes et les distribuent sur des arbres de multicast.Ces arbres
ont une contrainte particuliere:elles forment une for^et de facon a ce qu'un noeud interne dans
un arbre soit feuille dans toutes les autres gure 4.8.Ainis la charge va ^etre repartie parmi tous
les participants de l'application induisant la disponibilite et l'equite.
40 2004/2005
CHAPITRE 4.PEER TO PEER
Fig.4.8 { Un exemple de diusion utilisee dans SplitStream.La source divise le contenu en
deux ots.Deux arbres multicast independants sont construits pour chaqu'un des ots(stripe).
L'approche SplitStream A l'aide de Pastry et Scribe,SplitStream va pouvoir construire la
for^et de facon a ce qu'un noeud interne soit feuille dans les autres arbres tout en respectant la
bande passante en entree et en sortie des noeuds.Pour cela on va avoir un groupe scribe par
bande.Chaque ot va avoir un identicateur,un StripId qui commence avec un digit dierent
(independance jusqu'a 16 ots).Il est suppose que chaque noeud qui recoit un stripId ayant
un prexe commun avec le nodeId le transmet car ce dernier peut avoir a servir comme noeud