Rapport de Stage dans l équipe ECOO (LORIA) Mise en œuvre d un Wikiwikiweb basé sur l algorithme de réplication optimiste WOOT

Transcription

1 Université NANCY 2 IUT Nancy Charlemagne Département INFORMATIQUE Nabil HACHICHA Licence Professionnelle Internet Rapport de Stage dans l équipe ECOO (LORIA) Mise en œuvre d un Wikiwikiweb basé sur l algorithme de réplication optimiste WOOT Tuteur : M. Pascal MOLLI Parrain : M. Gérôme CANALS Du 10 avril au 31 Juillet 2006 Prolongation jusqu au 1 Septembre Année Universitaire 2005 / 2006

2

3 TABLE DES MATIERES Liste des illustrations... ii Remerciements... iv Glossaire...v Introduction...1 Chapitre I : Environnement Le LORIA L'équipe ECOO...9 Chapitre II : Réplication de données WithOut Operational Transformation L évolution de WOOT Stockage différentiel (JLibDiff)...25 Chapitre III : Le système de réplication La conception du WOOKI Architecture de l application...50 Conclusion...80 Bibliographie...81 Index...82 i

4 Liste des illustrations Numéro Page 1. Organigramme du LORIA Exemple de relation de dépendance précédence Scénario d insertion entre trois sites Diagramme de Hasse du scénario Scénario de synchronisation entre deux sites Use-case Use case (Ajouter un nouveau voisin) Diagramme de séquence (ajouter un nouveau voisin) Use case supprimer un voisin Diagramme de séquence, supprimer un voisin Use cas consulter une page Diagramme de séquence chercher une page Use case Edition d une page Diagramme de séquence édition d une page Use case créer une page Diagramme de séquence créer une page Use case synchronisation Diagramme de classes Profiler de l éditeur NetBeans Profiler Utilisé sous NetBeans Les différents packages de WOOKI Package algorithm Package WOOT Package Op Package Clock Package Core Package Neighbors Package test Package log...65 ii

5 30. Package Editor Package webapp Package HttpUnitTests Package Wiki Package Servlets (partie 1) Package Servlets (partie 2) Package Servlets (partie 3)...78 iii

6 REMERCIEMENTS Tout d abord, je tiens à remercier M. Pascal MOLLI, pour m avoir accueilli dans son équipe de recherche et de m avoir guidé dans mon travail tout au long du stage. Je remercie Messieurs Claude GODART, Pascal URSO, Hala SKAF, François CHAROY, ainsi que tous les autres membres de l'équipe ECOO du Loria pour leur accueil chaleureux. Je souhaite également remercier M. Florent Jouille, ingénieur associé à l équipe, pour le temps qu il m a consacré ainsi que pour les explications qui m ont permis d avancer dans mon travail. Enfin, je remercie Monsieur Gérôme CANALS, mon parrain de stage pour s être assuré du bon déroulement du stage ainsi que pour ses conseils tout au long de ces cinq mois. A l âme de mon cher ami Hacen SIDHOUM A mes parents iv

7 GLOSSAIRE TTF. Tombstones Transformation Functions, algorithme de réplication qui gère les opération undo, redo. Profiling. Le "profiling" est un moyen de déterminer le temps consommé par chacune des parties d un programme. Pour réaliser ces mesures de manière automatique, on peut ajouter une option de compilation ou bien utiliser un logiciel dédié à ça. Refactoring. La notion de refactoring (raffinement) consiste en une réécriture d'un programme en vue de le rendre plus lisible, extensible et facile à maintenir. Il ne s'agit pas d'une modification fonctionnelle : le programme doit se comporter à l'identique avant et après raffinement. Use case. Cas d'utilisation en modélisation UML. Usenet. Également connu sous le nom Netnews, est un système de forums de discussions qui a été inventé en 1979 pour fonctionner sur des ordinateurs reliés par UUCP. Il a été rapidement adapté à Internet où il reste aujourd'hui en usage. Wikiwikiweb. WikiWikiWeb est le premier wiki, inventé par Ward Cunningham en WikiWikiWeb n'est pas un site Web complet, mais seulement une fonctionnalité ajoutée aux Portland Pattern Repository, une section du site de Cunningham & Cunningham, Inc. Ward Cunningham a créé cette fonctionnalité pour faciliter l'échange d'informations entre programmeurs. Le terme «wiki», aujourd'hui utilisé pour décrire la technologie mise en œuvre par WikiWikiWeb, vient du nom de ce premier site. Il arrive que le terme «WikiWikiWeb» soit utilisé de manière générique comme synonyme de «wiki». groupware. Le groupware est l ensemble des technologies et des méthodes de travail associées qui, par l intermédiaire de la communication électronique, permettent le partage de l information sur un support numérique à un groupe engagé dans un travail collaboratif et/ou coopératif. JOnAS. Java Open Application Server est un serveur d'application réparti Java OpenSource. Plus précisement c'est un container EJB (Entreprise Java Bean, composant Java réutilisable) qui supporte les normes de configuration, de transactions, et de messagarie applicatif les plus modernes. Il est possible d'utiliser JOnAS avec RMI, JEREMIE ou CORBA.. v

8 INTRODUCTION Dans le cadre de notre Licence Professionnelle Réseaux et Télécommunications, mention «Concepteur-Intégrateur de systèmes Internet/Intranet», nous avons effectué un stage de fin de formation au LORIA (Laboratoire Lorrain de Recherche en Informatique et ses Applications) ; un laboratoire de recherche se situant sur le campus scientifique de Nancy. Ce stage s est étalé du 4 avril au 1 Septembre 2006 en vue de valider les compétences acquises au cours de la licence. Cette formation professionnelle étant un diplôme de fin d'étude, ce stage a eu aussi pour but de faire une transition vers le monde du travail. Ce rapport présente le stage que nous avons effectué dans l équipe de recherche ECOO. Notre sujet de stage concerne la mise en œuvre d un Wikiwikiweb basé sur un algorithme (WOOT) développé par l équipe ECOO. En effet, l équipe imaginait qu un Wikiwikiweb pourrait être déployé non plus sur une machine centrale mais sur un réseau de type USENET. Cette architecture a de nombreux avantages : la charge peut être distribuée sur le réseau, la panne d un serveur n interrompt pas le service, et enfin, les frais de fonctionnement peuvent être distribués entre les différents hébergeurs. L objectif du projet baptisé «WOOKI» est donc d implanter WOOT pour répliquer un Wikiwikiweb sur un réseau P2P. Ce rapport est organisé comme suit : nous allons commencer par une présentation du laboratoire et de notre environnement de travail. Le deuxième chapitre explique le contexte général et comment donne-il la motivation pour ce travail. Le troisième chapitre est consacré à l étude et l implémentation de l algorithme WOOT au sein du projet WOOKI. Comme prolongement de cette partie, nous allons voir l architecture ainsi que le déploiement et l installation de l application, avant de conclure. 1

9 C h a p i t r e 1 Dans cette partie, nous présenterons tout ce qui est en rapport avec le laboratoire dans lequel nous avons effectué notre stage. Nous définirons tout d abord le LORIA, puis l équipe de recherche où nous avons travaillé. 2

10 1.1 Le LORIA Historique Le Laboratoire Lorrain de Recherche en Informatique et ses Applications (LORIA) est une unité mixte de recherche (UMR 7503) commune au CNRS (Centre National de la Recherche Scientifique), à l'inria (Institut National de Recherche en Informatique et en Automatique), à l'inpl (Institut National Polytechnique de Lorraine), et aux universités Henri Poincaré, Nancy 1 et Nancy 2. Cette unité, dont la création a été officialisée le 19 décembre 1997 par la signature du contrat quadriennal avec le Ministère de l'éducation Nationale, de la Recherche et de la Technologie et par une convention entre les cinq partenaires, succède ainsi au Centre de Recherche en Informatique de Nancy (CRIN), et aux équipes communes entre celui-ci et l'unité de Recherche INRIA de Lorraine Organisation du LORIA Figure 1.1 organigramme du LORIA 3

11 Depuis le 1er janvier 2001, c'est Hélène KIRCHNER qui dirige le LORIA. Actuellement plus de quatre cents cinquante personnes travaillent dans le laboratoire. Ces personnels sont répartis en 25 équipes de recherche et 9 services d'aide à la recherche. Chaque équipe rassemble des chercheurs, des doctorants et des assistants techniques ou administratifs, pour la réalisation d'un projet de recherche. Cinq instances ont été mises en place pour assister le directeur du laboratoire, garantir la cohérence de la politique scientifique et le bon fonctionnement au quotidien : L'Équipe de Direction : composée de plusieurs membres du laboratoire. Elle assiste la Directrice dans ses fonctions. Le Comité de Gestion : composé des chefs de service. Il assiste le directeur dans le fonctionnement journalier du LORIA. Le Comité des Projets : il conseille le Directeur sur la politique scientifique du LORIA, participe à l'évaluation des projets/équipes, et instruit les restructurations nécessaires Le Conseil du LORIA : il émet des avis sur la politique scientifique mise en œuvre par le Comité des Projets. Sa composition est fixée par les statuts d'umr. Le Conseil des Orientations Scientifiques : composé de représentants des équipes de recherche. Il conseille la Direction dans la gestion scientifique du laboratoire Ressources et partenariats Etablissements associés 4

12 LORIA est une "Unité Mixte de Recherche" (UMR 7503) associant les personnels et les moyens des cinq établissements suivants : CNRS : Centre National de la Recherche Scientifique INPL : Institut National Polytechnique de Lorraine INRIA : Institut National de Recherche en Informatique et en Automatique UHP : Université Henri Poincaré, Nancy 1 Nancy 2 : Université Nancy Personnels LORIA regroupe plus de 300 personnes dont : Chercheurs permanents : 109 Thésards : 94 ITA : 61 Post-Doc, ingénieurs experts, membres associés : 53 Les chiffres ci-dessus ne comprennent pas les projets Inria Messins et de l'iecn. Ces personnels se répartissent ainsi dans les établissements de rattachement : INRIA : 165 CNRS : 43 5

13 UHP : 64,5 Nancy 2 : 40 INPL : 24 Divers : Les thématiques de Recherche Dans le secteur des sciences et technologies de l'information et de la communication, le LORIA possède, à travers dix neuf équipes de recherche, cent cinquante chercheurs et une centaine de doctorants, des compétences reconnues dans des secteurs en pleine évolution et porteurs de développement économique potentiel. Les activités de ces équipes sont centrées autour de cinq thématiques principales "transversales" sur lesquelles elles développent des recherches fondamentales et appliquées. Bien entendu, les équipes ont des activités dans plusieurs de ces thématiques. Calculs, réseaux et graphismes à hautes performances Télé-opérations et assistants intelligents Ingénierie des langues, du document et de l'information scientifique et technique Qualité et sûreté des logiciels et systèmes informatiques Bio informatique et applications à la génomique Valorisation et transfert Le LORIA développe de nombreuses relations industrielles (plus de 200 contrats en cours fin 1999) et a une importante activité de diffusion de logiciels. Six logiciels et une marque ont été déposés en Fort de près de 6

14 90 enseignants-chercheurs, le LORIA participe activement à la formation universitaire dans les domaines des sciences et nouvelles technologies. Conscient de la nécessité d'être un élément moteur du contexte socioéconomique régional, le LORIA a décidé de créer le LoriaTech en janvier 1999, club des partenaires du LORIA, qui a pour objectifs : De donner accès plus rapidement aux informations sur les évolutions de la recherche et du secteur ; c'est-à-dire améliorer la veille technologique des entreprises. En particulier, les membres du LoriaTech ont un accès privilégié au centre de documentation du LORIA et de l'inria-lorraine. De monter des partenariats divers. Citons en particulier : 1. dans le cadre des établissements universitaires (ESIAL, ESSTIN, écoles d'ingénieurs de l'inpl, IUT Informatique de Nancy2, IUP-Miage de Nancy), la possibilité de stages de projets industriels. 2. dans le contexte du LORIA, les sujets DRT (Diplôme de Recherche Technologique), des conventions CIFRE. Offrir la possibilité de partenariat LORIA-entreprises en réponse à des appels d'offre français ou européens. Un Espace-transfert a été également créé fin 1999 à proximité du LORIA. Après 3 créations d'entreprises début 2000, 3 autres projets sont en cours de montage Le service et le matériel informatique Le LORIA dispose d un parc informatique très important. Celui-ci est géré par le service des «Moyens Informatiques» qui se charge de l installation, de 7

15 la maintenance et de la gestion des outils informatiques et logiciels. C est à ce service qu il faut s adresser en cas de problème avec un logiciel ou un poste de travail. Chaque bureau du LORIA est équipé de plusieurs stations de travail. Des ordinateurs portables sont également mis à la disposition des employés. Chaque ordinateur est relié au réseau interne du LORIA et dispose d un accès Internet à très haut débit. Ces ordinateurs sont équipés de Windows et aussi de Linux dans certains cas. Des salles machines sont également disponibles en libre accès. De plus, un ensemble d'imprimantes, dont trois imprimantes couleur, vingt-deux imprimantes laser noir et blanc mis à la disposition des utilisateurs, est réparti dans tout le bâtiment. Des scanners (1 par salle console), ainsi que du matériel permettant de faire de l'archivage, sont aussi accessible aux utilisateurs. Une machine de type PC a été mise à notre disposition. Elle est équipée d un processeur rapide (Pentium 4) et de 512 de RAM. Linux (la distribution Ubuntu) est le système d exploitation utilisé. Le projet ne doit utiliser que du code libre en vue de sa diffusion sous licence libre. Par conséquent, la plupart des logiciels utilisés sont issues du monde libre, à coté de ça, nous utilisons comme outils de développement l éditeur NetBeans ainsi qu Eclipse. De plus une plateforme nommé «LibreSoucre» nous accompagnait toute au long du stage. Il s agit d une plate-forme collaborative de seconde génération dédiée au développement logiciel et à l'hébergement de communautés. LibreSource rassemble les fonctionnalités que l'on trouve à la fois dans les plate-formes de développement, telles que les logiciels de forge ou les plates-formes de groupware. Entièrement basé sur la technologie J2EE, un design modulaire utilise la plupart des services offerts par le serveur d'application d'objectweb JOnAS. LibreSource est adapté à des applications professionnelles. 8

16 1.2 L'équipe ECOO Motivations L'objectif du projet ECOO est de concevoir et réaliser des services pour l'hébergement d'équipes distribuées et d'entreprises virtuelles sur le Web. Cette recherche s'intéresse plus particulièrement aux applications multisynchrones créatives (co-conception, co-ingénierie, édition coopérative...) distribuées sur Internet Champs de recherche Le projet ECOO s'intéresse au développement de services pour l'hébergement d'équipes et d'entreprises distribuées (ou virtuelles) sur Internet. Les services considérés incluent des services de partage d'objets, de communication, de gestion de tâches, de maintien d'une conscience de groupe, d'aide à la prise de décisions. L'équipe s'intéresse plus particulièrement aux applications de co-conception et/ou de co-ingénierie pour des domaines variés (Génie Logiciel, Architecture-Génie Civil, Formation-Apprentissage...). L'approche ECOO se caractérise par le fort accent mis sur l'aide à la coordination d'une équipe distribuée, problème crucial du fait de la perte d'unité de lieu liée à la distribution. La recherche s'organise autour de deux axes principaux: La coordination explicite fondée sur l'hypothèse qu'il est possible de formaliser les procédés de travail et de les contrôler sur le terrain. La coordination implicite basée sur l'idée que si les partenaires reçoivent au bon moment la bonne information sur ce que font les autres, cette information va générer de la communication qui conduira à l'auto coordination de l'équipe. 9

17 1.2.3 Membres Responsable scientifique : Claude Godart, Professeur à l'université Henri Poincaré Nancy 1, ESSTIN. Responsable permanent : Pascal Molli, Maître de Conférences à l'université Henri Poincaré Nancy 1. Assistante de projet : Antoinette Courrier Personnel Universitaire : 1. Khalid Benali, Maître de Conférences à l'université Nancy 2 2. Nacer Boudjlida, Professeur à l'université Henri Poincaré Nancy 1 3. Gérôme Canals, Maître de Conférences à l'université Nancy 2 4. François Charoy, Maître de Conférences à l'université Nancy 2 5. Olivier Perrin, Maître de Conférences à l'université Nancy 2 6. Hala Skaf, Maître de Conférences à l'université Henri Poincaré Nancy 1 Chercheurs doctorants 1. Sawsan Alshattnawi, bourse franco-jordanienne 2. Dong Cheng, bourse UHP 3. Walid Gaaloul, bourse INRIA 4. Adnene Guabtni, bourse Gvt. tunisien 10

18 5. Gérald Oster, bourse INRIA Chercheurs post-doctorants 1. Sami Bhiri, DERI Gayway, Ireland 2. Gérald Oster, ETH Zurich, Suisse Ingénieurs experts 1. Florent Jouille Collaborateurs extérieurs 1. Gilles Halin, Université Nancy2, Centre de Recherche en Architecture de Nancy (CRAI) 11

19 C h a p i t r e 2 Dans ce chapitre, nous allons aborder la problématique de la réplication de données. Nous verrons quelques notions clés qui vont nous permettre d aborder les différentes approches théoriques existantes. C est ce qui nous conduira à l approche WOOT. Enfin, dans ce chapitre sont énoncés le modèle de données de WOOT, ainsi que l étude faite sur la librairie DIFF utilisée pendant le développement. 12

20 2.1 Réplication de données Pourquoi répliquer (partie 2.4) La réplication consiste à dupliquer des données critiques pour faire face à : 1. Tolérance aux pannes 2. Disponibilité performances Mais il faut gérer la cohérence des données, et de là, il faut distinguer deux concepts différents qui sont la réplication et la copie. La différence consiste en la gestion de la cohérence des répliques donc finalement une réplique est plus qu une copie. Il existe deux sorte de réplication (en fait il en existe trois nous verrons le troisième type plus tard dans cette partie) ; la réplication pessimiste et la réplication optimiste La réplication pessimiste Donne l illusion à l utilisateur qu il n existe qu une seule copie. Les protocoles les plus connus sont basés sur le principe ROWA (Read One Write All). Les lectures peuvent être faites sur n importe quelle copie tandis qu une écriture doit être appliquée de manière atomique sur toutes les copies La réplication optimiste Est une approche a priori plus adaptée au réseau P2P. Dans le cadre d une réplication optimiste, les copies peuvent diverger. A un instant donné, un utilisateur peut donc observer des copies d un même objet avec des valeurs différentes. Simplement, quand le système sera au repos (i.e. quand toutes les opérations auront été propagées à toutes les copies, alors toutes les copies devront être identiques). La réplication optimiste laisse donc les copies diverger à condition qu elles finissent par converger. 13

21 Si l on compare avec la réplication pessimiste, la réplication optimiste ne nécessite plus la mise à jour atomique de toutes les copies. La réplication optimiste est donc potentiellement plus performante. Cependant, il faut être capable de réconcilier des copies ayant divergés La réplication optimiste (et transformées opérationnelles) Le modèle des transformées opérationnelles a été développé par la communauté des éditeurs collaboratifs synchrones. La préservation de l intention est au centre de la définition du modèle de cohérence de cette approche. L architecture générale du modèle des transformées opérationnelles distingue deux composants. Un algorithme d intégration. Il est responsable de la réception, de la diffusion et de l exécution des opérations. Si nécessaire, il fait appel aux fonctions de transformation. Cet algorithme est indépendant du type des données manipulées (chaîne de caractères, document XML, système de fichiers). Un ensemble de fonctions de transformations. Ces fonctions ont la charge de «fusionner» les mises à jour en sérialisant deux opérations concurrentes. Ces fonctions sont spécifiques à un type de données particulier. L algorithme d intégration est défini comme correct si il assure la causalité, la convergence et la préservation des intentions. Le respect de la causalité garantit que pour les opérations pour lesquelles il existe une relation de causalité, celles-ci seront exécutées dans le même ordre sur toutes les répliques. Par exemple, nous considérons le scénario présenté à la figure

22 Figure 2.1 Exemple de relation de dépendance précédence Puisque l opération op2 a été générée sur le site 2 après que l opération op1 se soit exécutée, op1 précède op2. Si sur un troisième site, l opération op2 est reçue avant l opération op1 alors pour garantir l exécution de op2, op2 sera différée jusqu à la réception et l exécution de op1. Généralement, cette dépendance est maintenue en utilisant des vecteurs d horloges. Dans un système à n sites, un tel Vecteur V possède n composants. Chaque composante V[i] compte le nombre d opérations issues du site i qui ont été déjà exécutées sur le site. Nous parlerons de préservation de l intention ainsi que de la convergence dans le chapitre concernant WOOT. 2.2 WithOut Operational Transformation Introduction WOOT est un algorithme de réplication optimiste adapté aux éditeurs collaboratifs. Il assure la convergence des répliques et préserve les intentions. WOOT est plus simple et plus efficace que les approches existantes. WOOT ne nécessite pas de vecteurs d horloge et peut être déployé massivement sur un réseau P2P. 15

23 2.2.2 Modèle de WOOT WOOT quitte l approche OT (Transformation Opérationnelle). En effet, au lieu de recalculer les relations d ordre a posteriori comme dans OT, WOOT diffuse les relations d ordre avec les opérations. Ainsi, nous sommes déjà sûr de préserver les intentions. Pour expliquer cette approche, nous allons prendre l exemple suivant : quand un utilisateur observe la chaîne de caractères «ABCDE» et qu il insère «12» à la position 2, on peut supposer qu il veut insérer «12» entre «A» et «B». Respecter les effets de cette opération consiste à préserver la relation «A» < «12» < «B» sur tous les futurs états de la chaîne. Nous devons donc adapter le profil des opérations. Plutôt que diffuser l opération insert (2, «12»), nous diffuserons l opération insert («A» < «12» < «B»). Un premier problème se pose : comment exécuter une opération insert («A» < «12» < «B») si nous avons localement supprimé le caractère «A»? Nous choisissons de ne pas détruire les caractères. Nous les marquons seulement comme invisibles. Bien sûr, si nous ne détruisons pas les caractères, cette approche va consommer plus de mémoire et générer des fichiers plus volumineux. Cependant, il a été démontré par les auteurs de l algorithme que la complexité de ce dernier est linéaire en espace et cubique en temps (dans le pire des cas). De plus, la complexité en mémoire de WOOT est inférieure ou égale à celle des algorithmes existants. En effet, nous ne conservons pas le journal des opérations et nous n utilisons pas de vecteurs d horloge L Algorithme WOOT a été testé et prouvé en utilisant les chaînes de caractères, mais cette approche peut être adaptée à n importe quelle structure linéaire. Cette structure linéaire peut être complexe comme un document XML, ou bien comme nous allons le voir plus tard (partie 2.3) dans un fichier modélisé sous forme de lignes. 16

24 2.2.4 Le modèle de données Définitions Définition 1 : WOOT gère des W-caractères. Un W-caractère possède un identifiant unique id, un booléen v indiquant si le caractère est visible ou non ainsi que les identifiants du caractère précédent idcp et du suivant idcn et enfin la valeur alpha. Pour identifier un caractère de manière unique, nous construisons son identifiant avec le numéro du site numsites sur lequel il a été généré et l horloge logique actuelle de ce site Hs. Chaque site possède donc un identifiant unique numsites, une horloge logique Hs, une séquence de W-caractères Strings, et un ensemble d opérations en attente d intégration présent dans la queue d exécution Pools. Définition 2 : Le W-caractère d un W-caractère c est noté CP(c). Le W-caractère suivant d un W-caractère c est noté Cn(c). Définition 3 : L identifiant d un W-caractère id est un couple (ns, ng) où, ns est l identifiant du site (numsite s ) et ng est un entier naturel. Quand un W-caractère est généré sur un site s, ces identifiant sont fixés à (numsite s, H s ). Chaque fois qu un W-caractère est généré sur un site s, l horloge locale H s, est incrémentée. L unicité du couple (numsite s, H s ) forme un identifiant unique au W-caractère. string S est une W-string. Elle contient tous les W-caractères intégrés au site s. 17

25 Définition 4 : Une W-string est une séquence ordonnée composée de W-caractères C B c1 c2 cn C E où C B et C E sont des W-caractères spéciales (avec un identifiant id spéciale) qui marquent le début et la fin de la séquence. Nous définissons les fonctions suivantes pour une séquence S : S représente la taille de la séquence S. S[p] indique l élément à la position p dans la séquence S. On déclare que le premier élément de la séquence S est à la position 0 et le dernier élément est à la position S -1. pos (S, c) retourne la position de l élément c dans S (comme un entier naturel). insert (S, c, p) insert l élément c dans S à la position p. subseq (S, c, d) retourne la partie de la séquence S entre l élément c et d, les deux caractères ne sont pas inclus. Nous avons aussi besoin des fonctions suivantes pour faire le lien entre la W- string et la chaine de caractères que l utilisateur voie. value (S) est la représentation de S. (i.e. la séquence des caractères visible). ithvisible (S, i) est le i ème caractère visible de S. Il existe deux types d opérations affectant une chaîne de caractère. ins (c) insère le W-caractère c entre ses caractères précédent et suivant. La pré-condition pour réaliser cette opération est l existence des ses deux caractères. 18

26 del(c) supprime le W-caractère c. la pré-condition de del(c) est que le caractère c soit existant L ordre Soient a et b deux W-caractères. a < b si et seulement si il existe un ensemble de caractères c0, c1, c ci, tel que, a = c0, b= ci et Cn(cj) = cj+1 ou cj = Cp (Cj+1) pour tous 0<= j <=i. Soit S une séquence, la relation <=S est définie comme : a <=S b si est seulement si pos (S, a) <= pos (S, b) Quand aucune relation d ordre ne peut être établit entre deux caractères, nous devons ordonner ces caractères. Pour arriver à une convergence, l ordonnancement doit être indépendant de l état de site. Pour cela on utilise les identifiant des W-caractères. Soient a et b deux W-caractères avec leur identifiants respectives (nsa, nga) et (nsb, ngb). a < id b si et seulement si : (1) ns A < ns B ou bien (2) ns A = ns B et ng A < ng B Les opérations Quand une réplique est modifiée, une opération correspondante est générée. Cette opération est 1. Immédiatement intégrée localement. 2. Diffusée aux autres sites. 3. Reçue par les autres sites. 4. Intégrées par les autres sites. 19

27 Génération : Pour une opération op, type(op) indique le type de l opération : del ou bien ins. char(op) indique le caractère manipulé par l opération. Quand un utilisateur interagit avec WOOT, il voit juste value(s). Donc, quand une opération d insertion est générée, l interface utilisateur connaît seulement la position et la valeur du caractère à insérer. Par exemple, ins(2, a) dans «xyz» est transformée en ins (y < a < z) Simultanément, quand une opération suppression est générée, on doit récupérer le W-caractère à cette position Réception : Les sites sont susceptible de recevoir des opérations avec des pré-conditions qui ne sont pas vérifiées. La fonction isexecutable vérifie les pré-conditions d une opération. 20

28 Pour gérer l emplacement en suspend des opérations (qui ne peuvent pas être exécutée pour le moment), chaque site maintient une queue d opérations (Pool). Par exemple, un site exécute del(c) seulement si c est présent. Si ce n est pas le cas, l intégration de l opération est reportée jusqu à ce que c soit présent. Intégration : Pour intégrer une opération del(c), nous avons besoin de modifier le booléen indiquant si le caractère est visible ou pas, et cela quelque soit la valeur précédente de ce booléen. Pour intégrer une opération ins(s) dans une strings, nous avons besoin de placer c parmi tous les caractères entre cp et cn. Ces caractères peuvent être soit supprimés soit insérés par des opérations concurrentes. Quand une opération ins(c) est exécutée sur un site, la procédure IntegrateIns(c, cp, cn) peut être appelée. 21

29 Exemple : Soient trois sites : site 1, site 2 et site 3 possédant chacun une réplique d une chaîne vide «CbCe», nous considérons le scénario décrit dans la figure 2.2. Le diagramme de Hasse correspondant est décrit par la figure 2.3. Figure 2.2 : scénario d insertion entre trois sites 22

30 Figure 2.3 Diagramme de Hasse du scénario La relation < id ordonne les caractères de la manière suivante : 1 < id 2 < id 3 < id 4. Le site 2 reçoit les opérations o1, o3, o4 dans cet ordre. L intégration se déroule de la manière suivante : IntegrateIns(1, c b, c e ) : S = L = 2 et 1 < id 2, WOOT intègre 1 entre c b et 2. Au cours de l appel récursif IntegrateIns(1, c b, 2), nous obtenons S =. Donc, le résultat obtenu est la chaîne c b 12c e. 2. IntegrateIns(3, c b, 1) : S =, WOOT insère 3 entre c b et IntegrateIns(4, 1, c e ) : S = L = 2 et 2 < id 4, WOOT intègre 4 entre 2 et c e. Nous obtenons au final la chaîne c b 3124c e. Sur le site 3, l appel IntegrateIns(2, c b, c e ) est résolu : S = 314 et C N (3) = C P (4) = 1, nous avons L = 1. Comme 1 < id 2, WOOT intègre 2 entre 1 et c e. Au cours de l appel récursif IntegrateIns(2, 1, c e ) : nous avons S = L = 4 et 2 < id 4, WOOT intègre 2 entre 1 et 4. Sur le site 3, nous obtenons la chaîne c b 3124c e comme résultat final. Sur le site 1, quelque soit l ordre d arrivée des opérations o2, o3, o4, nous obtenons la chaîne c b 3124c e. Ainsi tous les sites convergent vers l état final attendu

31 2.3 L évolution de WOOT Lors de notre arrivée au sein de l équipe, il existait une implémentation sous forme d un éditeur collaboratif en temps réel de l algorithme WOOT. Cette intégration était écrite en grande partie par l ingénieur associé Florent Jouille, avec le langage Java. Cependant, notre tuteur avait déjà programmé une version en C++. Cette version nous a servi comme base de comparaison des temps d exécutions pendant les travaux d optimisation. L éditeur temps réel utilise la technologie de broadcast afin de propager les opérations faites sur la séquence de caractères d un site. Chaque site rejoint une adresse de Multicast pour écouter ensuite ce qui passe à travers le réseau. Cet éditeur simple est pratique, car il a permis de réaliser des tests avec plusieurs sites partageants le même contenu. L équipe a également mis en place un package de tests qui sert à vérifier la convergence, l intention etc Nous avons tout d abord commencé par l étude de l algorithme WOOT en travaillant sur la documentation fournie sur celle-ci, et en particulier sur l article publié par les auteurs de WOOT, (Real-Time Group Editors Without Operational Transformation [1]). Cela nous a permis d avoir une vue globale de l approche. Ensuite, l étude des codes sources et des tests a fait éclaircir le fonctionnement de l éditeur ainsi que le fonctionnement de WOOT. Après que nous nous sommes familiarisés avec WOOT, nous avons commencé le développement d une version qui utilise une nouvelle structure de données. Cette structure de données linéaire était des pages (fichier texte) donc WOOT ne gérait plus une chaîne de caractère par site mais un ensemble de page. Quant à l élément W-caractère, il a était remplacé par une W-ligne, Ce passage a nécessité plusieurs changements dans le cœur de l éditeur ; à noter que le package de tests a été entièrement réécrit en Junit. Il était important de faire passer d abord les tests à chaque grande modification avant d avancer dans le développement. De plus, pour rendre les tests plus conviviaux, nous avons programmé une application en Swing qui simulait un site et qui proposait des opérations de base tels que l édition, la création et la 24

32 consultation des pages (sans pour autant propager les opérations aux autres sites). Entre temps, l équipe à continuer ses travaux sur l algorithme WOOT. Une nouvelle version plus optimisée venait de sortir. Les modifications concernaient la définition d un W-caractère ainsi que les fonctions d intégration et de génération d une opération. De façon sommaire, la transformation majeure était dans l introduction d un nouveau paramètre degré qui va remplacer le stockage de l identifiant précédent et suivant pour un W-caractère. Par conséquent, nous avons procédé à des changements au niveau du code source de l éditeur ainsi que les tests. Après avoir passé au modèle W-ligne, nous avons entamé l écriture d une nouvelle catégorie de tests visant à s assurer que l application développée jusqu ici est Therad-safe afin de protéger (synchroniser) les blocs d opérations critiques. Nous avons utilisé pour cela la librairie Quartz, qui est une librairie permettant de planifier simplement des tâches en java avec le JDK de manière plus sophistiquée. Nous avons aussi introduit la gestion de la persistance pour les données délicates (tel que le Pool, l Horloge etc ). 2.4 Stockage différentiel (JLibDiff) Cette partie représente l étude effectuée sur la librairie DIFF. Le résultat de cette étude a permis l intégration et l adaptation de la librairie diff au sein du système WOOKI en fonction de nos besoins. La construction d un environnement de travail coopératif est un objectif de l équipe ECOO (Environnement pour la COOpération). Cet environnement doit supporter efficacement la coopération qui s installe, ou qui doit s installer entre les différents acteurs et entre les différentes tâches. L équipe ECOO développe en particulier une approche de coopération indirecte et asynchrone 25

33 c est à dire une approche où les participants coopèrent en partageant les produits du projet à des moments éventuellement différents. Cette approche correspond à un modèle de type copie / modification / fusion. Différentes activités partagent des objets en possédant des copies de ces objets. Elles peuvent ainsi modifier ces objets en parallèle sans interagir avec les autres tâches. Lorsque cela est nécessaire, les différentes copies peuvent être réconciliées en fusionnant les valeurs divergentes. L équipe ECOO a construit un environnement de travail coopératif à travers le Web qui s appelle «Tuamotu». Le prototype est basé sur une architecture «d égal à égal» pour offrir à des activités distribuées un accès partagé. La coopération dans une telle architecture est rendue possible par le fait que les différentes copies d un même objet peuvent résider sur différents sites. Plusieurs activités distantes peuvent ainsi travailler simultanément sur des objets communs qui sont répliqués dans les sites. Dans ce système, tous les objets (fichiers et répertoires) sont «versionnés». Par conséquent, le stockage des différentes versions d un fichier au sein d un site pose des problèmes : Stocker toutes les versions d un fichier peut prendre beaucoup de place sur le disque. Transférer tout le contenu d un fichier entre les site par Internet peut prendre du temps (baisse de performance et augmentation du coût). Ces problèmes sont derrière la nécessité de réaliser un stockage différentiel des versions. En effet, il est plus judicieux de stocker la version initiale d un fichier et une séquence de modifications qui s y rattache plutôt qu une séquence de toutes les versions d un même fichier. On parle alors de data storage. 26

34 Le besoin d écrire une librairie qui calcule les modifications s est fait ressentir d où la naissance de librairie JlibDiff. La librairie DIFF est une librairie Java qui va permettre d effectuer un stockage différentiel des versions d un fichier. A chaque version d un fichier initial correspond un fichier de différences qui va être calculé et stocké. Pour retrouver par la suite une version, il suffit d appliquer le fichier de différences correspondant sur la version initiale La librairie Diff «in a nutshell» La librairie se base sur un programme de comparaison qui produit une liste de différences entre deux fichiers. Ces différences peuvent être vues en terme de lignes ; c'est-à-dire en précisant les lignes qui doivent être insérées, supprimées ou modifiées pour convertir le premier fichier vers le deuxième. Cependant la liste de différences peut identifier le changement, l insertion ou la suppression en terme de caractères (octets). Ce type de comparaison est utile pour les fichiers non-texte tels que les fichiers compilés qui ne peuvent pas être divisés en lignes. L approche donc est de générer des instructions pour changer, insérer ou supprimer entièrement des lignes qui seront vues comme des objets indivisibles. Une ligne peut être symbolisée par un caractère. Donc un fichier qui contient n-lignes peut être modélisé par une chaîne comprenant n- symboles Cette partie étant terminée, nous pouvions passer à l étape suivante qui concerne la mise en place de WOOT au sein du projet WOOKI. C est cette étape qui va nous mener au chapitre suivant. 27

35 C h a p i t r e 3 Nous avons déjà vu dans le chapitre précédent la présentation de WOOT en terme d algorithme et structure de données. Nous allons observer plus précisément dans ce chapitre comment les opérations circulent entre les différents sites du réseau. Nous examinerons par la suite l étape de conception du projet WOOKI jusqu à l arrivée au modèle actuel. Nous nous intéresserons également au déploiement et l installation de l application sur le réseau. 28

36 3.1 Le système de réplication Nous avons déjà vu que pour supporter le travail en parallèle, les données doivent être répliquées d une manière optimiste. Dans ce processus de collaboration, chaque utilisateur travaille sur une copie, produit des opérations (exécution locale) et enfin diffuse aux autres voisins l ensemble de sa coopération. Le projet WOOKI est constitué de deux grandes parties, à savoir l algorithme WOOT plus un système de réplication des données (la partie qui se charge de gérer et de transmettre la coopération entre les pairs). Nous allons donc découvrir dans cette partie les travaux et les recherches qui ont été mené afin de mettre en place un algorithme de gestion de la propagation des messages (coopération) entre les voisins (nœuds) ainsi que la construction de la topologie du réseau pairs à pairs Introduction Les réseaux pairs à pairs permettent la communication, le partage simple d'informations des fichiers le plus souvent, mais également des flux multimédia continus (streaming), le calcul réparti, la téléphonie (comme Skype), etc. sur Internet. Le pair-à-pair permet à chaque participant au système de proposer des ressources aux autres participants tout en accédant aux ressources disponibles dans le réseau. Le pair à pair a permis une décentralisation des réseaux en permettant à tous de jouer le rôle de client et serveur. En particulier, les systèmes de partage de fichiers permettent d'avoir des objets d'autant plus disponibles qu'ils sont populaires, et donc répliqués sur des nœuds. Cela permet alors de diminuer la charge imposée aux nœuds partageant les fichiers populaires, ce qui facilite l'augmentation du nombre de nœuds donc de fichiers dans le réseau, aussi appelé passage à l'échelle (Scalability). 29

37 3.1.2 La diffusion à grande échelle en utilisant les réseaux pairs à pairs La résistance du système global et le maintien en cohérence reposent en fait sur le système de diffusion des mises à jour entre les différentes répliques. Notre système de réplication doit être redondant pour tolérer les pannes de communications Les algorithmes de diffusion «classiques» présentent certaines limites : ils s appliquent à un ensemble bien identifié de processus ; Les contraintes fortes sur leurs spécifications font que ces algorithmes passent très mal à grande échelle. En fait, il existe certains algorithmes, en l occurrence JXTA qui sont obligés de prévenir leur groupe en cas de connexion ou de déconnexion (contraindre à utiliser les fonctionnalités Join et Leave). Or pour notre modèle nous souhaitons utiliser la diffusion pour des applications dans lesquelles : Le nombre de processus (ou sites) est inconnu et variable (par rapport au temps et au nombre) ainsi que la topologie d interconnexion. Le nombre de sites est potentiellement très grand (taille d Internet) ; les sites jouent un rôle symétrique (chacun est client et serveur), de plus la déconnexion et la connexion ne peut pas être anticipée. La première approche choisie était fondée sur un Protocole simple qui est basé sur un mécanisme d anti-entropie. En effet, lorsque la connexion d un appelant vers un appelé est faite, le contenu des deux pairs est mis en commun. Les éventuelles informations obsolètes de l un sont rafraîchies par les informations plus récentes de l autre. A la fin de la mise en relation, le contenu des deux pairs est identique entre l appelant et l appelé. Dans le cas de notre protocole, L appelant envoie un message CONNECT auquel l appelé répond par un RESPONSE en y attachant les informations de sa base de messages local. Il est alors possible pour l appelant de répondre à 30

38 ce RESPONSE par un autre RESPONSE auquel il attache les informations de sa propre base de messages local. Il faut noter toutefois que le site appelant garde en mémoire une estampille associée au site appelé (un espèce de journal sur les messages échangés) qui va permettre aux prochaines synchronisations de récupérer juste les données qui ont été ajoutés dans la base locale du site appelé depuis la dernière synchronisation ; voir l exemple ci-dessous. Figure 2.4 schémas, scénario de synchronisation entre deux sites Mais cette approche a vite montré ses limites en termes de performances et d efficacité lors des tests. De plus, la construction de la topologie du réseau est assez rudimentaire et ne repose sur aucun algorithme ou spécification prouvée. C est ce qui nous a amené à revoir la façon d aborder ce problème avec notre tuteur. Nous sommes arrivés à la conclusion suivante : il est 31

39 nécessaire d utiliser la propagation probabiliste. Notre tuteur nous a soumis un certain nombre de papiers qui traitent de ce sujet notamment NEEM Network-Friendly Epedimic Multicast [3], Bimodal Multicast [6], Lightweight Probabilistic Broadcast [8] et enfin Epedimic Algorithms For Replicated Database Maintenance [5]. L étude et l analyse de ces documents nous ont conduit au résultat suivant : Utiliser un algorithme qui se compose de deux sous protocoles structurés Le premier protocole Ce protocole utilise le principe de la propagation aléatoire (la propagation d une rumeur gossip) Chaque processus (site) participe à la diffusion. Les paramètres sont : Capacité b : nombre de messages qu un processus peut stocker Nombre de retransmissions t : nombre de phases de rediffusion Nombre de destinataires f : à chaque phase, le processus transmet le message à f destinataires choisis aléatoirement Les paramètres b, t, f caractérisent un algorithme de diffusion épidémique. Ils peuvent être fixés indépendamment du nombre total n de processus ou être fonction de n. Au départ, un message (un message représente une coopération à échanger entre pairs, cette coopération comporte des opérations simple comme l insertion d une ligne à tel position dans une page, suppression d une ligne etc.) est initialement taggué avec le nombre maximale de rounds r et ensuite retransmit (forwarder) à f, autre nœuds distincts choisi de manière aléatoire. À la réception (par un pair), le nombre de rounds est décrémenté. Si le nombre de rounds atteint le zéro, le message est supprimé sinon, on l envoie encore 32

40 une autre fois à f autres nœuds connus d avantage par le pair qui vient de recevoir le message. Les garanties offertes par ce Protocole dépendent d une configuration approprié des deux paramètres r et f. d une autre part lors de la réception d un nouveau message par un pairs p ce dernier consulte sa liste de nœuds connus et en supprime un de manière aléatoire et ajoute à sa place le pair auteur du message reçu. Cette manière dynamique d interconnecté les pairs et de crée les liens entre eux permet d avoir une topologie fiable et tolérante au panne (notamment la déconnexion massive des pairs) Le deuxième protocole Ce protocole est un protocole biphasé d'anti-entropie qui opère parmi une série désynchronisé de pairs. Chaque site choisit régulièrement (de manière aléatoire) un autre site (voisin). Le site appelant calcule la différence avec le site appelé et obtient une liste de messages perdus. La deuxième phase consiste à corriger de telles pertes en récupérant les coopérations manquantes. On constate que la diffusion épidémique sur un réseau pair à pair est utilisée sur des systèmes de grande taille. Avec une évolution dynamique, parmi les avantages de ce type de diffusion on cite : Facilité de réalisation et de mise en place Robustesse (vis-à-vis des modifications de l environnement) Grande tolérance aux défaillances Pas de reconfiguration pour la reprise 33

41 Ajustement via un petit nombre de paramètres Malheureusement ce système révèle quelques limitations : Nécessite des ressources en mémoire Pas de garanties strictes (seulement probabilistes) Par conséquent, nous avons mis en place une troisième couche qui permet de combler plus au moins ces difficultés : Gestionnaire d état : Le gestionnaire d état est une autre couche du protocole qui intervient dans des moments bien précis. Pour résoudre le problème lié à la mémoire, nous avons adopté une politique de purge qui consiste à lancer une suppression du log qui contient les messages reçus de part et d autres. Cette suppression n est pas aléatoire. Elle peut être déclenchée par exemple pour supprimer les anciens messages qui datent de plus d un mois, ou bien si une certaine taille du log est atteinte (log cyclique) la purge est lancée. Au même instant et avant de supprimer réellement les messages, un état qui correspond au site à ce moment là est créé. Cet état est très important car il permet aux autre sites qui sont hors synchronisation (un site qui s est déconnecté pendant trois mois et qui voudrait commencer une opération d anti-entropie à partir d un message qui ont déjà été supprimé est considéré comme out of sync) de récupérer un état cohérent à partir duquel il peut commencer à synchroniser avec le site émetteur de l état. Un site nouvellement ajouté au réseau n a pas besoin de récupérer tous les messages qui ont été émis depuis le départ ; on dit qu il n a pas besoin de 34

42 suivre toute l histoire d une certaine ressource répliquée. Pour cela, il récupère un état à partir d un voisin. En intégrant cet état, il peut être opérationnel et peut commencer à coopérer avec le reste des pairs Conclusion Nous avons un système fortement répliqué qui possède a priori de nombreuses propriétés favorables pour l obtention d une bonne disponibilité des données. En terme de tolérance aux pannes, nous supportons deux types de pannes : les pannes de sites et les pannes de réseau. De plus, la programmation de la partie système de réplication a été faite en suivant l état de l art. C'est-à-dire en utilisant des solutions et des algorithmes prouvées et testées pour leur efficacité et leurs passages à l échelle Complément Mathématique Les algorithmes épidémiques comportent une succession de tours. Soit n la taille de la population, Y(r) le nombre d individus touchés ( infectés ) après le r-ième tour. Alors, si un individu infecté continue la propagation à tous les tours, on a p = Y(r)/n! 1/( 1 + n exp( fr)) (f = fanout, taille de l ensemble de diffusion) Donc la proportion d individus touchés augmente exponentiellement avec le nombre de tours et avec f. Si un individu touché ne propage l infection que pendant un tour ( infect and die ), alors la proportion p satisfait l équation. p = 1 exp( pf) 35

43 Dans ce modèle, supposons que f = log(n) + c (c est un paramètre) Alors la probabilité que tous les processus soient touchés à terme est P = exp ( exp ( c)) Il y a un changement de comportement quand c change de signe, donc quand f dépasse log(n) 3.2 La conception du WOOKI La conception du projet WOOKI a déjà été entamée au moment ou nous travaillions sur l algorithme WOOT, et ceci par deux stagiaires qui pendant leur présence dans l équipe ont mis en place avec notre tuteur un modèle UML décrivant les principaux composant que le système WOOKI devrait intégrer en plus des relations entre ces composants. Des diagrammes de classes ainsi que les diagrammes des cas d'utilisation (usecases) nous ont été parvenu par ces deux stagiaires. Nous avons donc commencé l analyse de ces documents. Nous avons eu beaucoup de réunion avec l ingénieur associé et les deux stagiaires afin de discuter des schémas fournis. Des modifications et des améliorations ont été introduites au modèle de conception de WOOKI à l issue de chaque réunion. A ce stade de la conception, nous sommes arrivés aux modèles suivants : 36

44 Authentification Not part of the system!! login edit page <<use>> user <<use>> see page synchronization clock create page add a new neighbour administrator delete a neighbour Figure 3.1 : use-case 37