Architecture et mise en oeuvre

l'algorithme ore des garanties de livraison à l'ensemble des sites. Concrètement, Wooki utilise l'algorithme LPBCAST [16], qui fonctionne sur ce principe et y ajoute la ges-tion dynamique de la composiges-tion du réseau. Cette gesges-tion des membres est basée sur la diusion et la découverte dynamique des tables de voisinages. Lors de la diusion d'un message, le site émetteur y insère un extrait de sa table. Le récepteur peut ainsi examiner cette table et ajouter dans sa propre table les voisins dont il n'a pas connaissance. Bien entendu, cet algorithme doit être complété pour traiter le cas des déconnexions.

La gestion des déconnexions est assurée par un mécanisme complémentaire réalisant un protocole d'anti-entropie [10]. Ce protocole fonctionne de la manière suivante. Chaque site maintient un historique de l'ensemble des patchs qu'il a reçus et appliqués. Lorsqu'un site rejoint le réseau après une période de déconnexion, il transmet son historique à l'un de ses voisins. Ce voisin calcule la diérence entre l'historique reçu et son propre histo-rique et détermine ainsi la liste de patchs non reçus par le demandeur au cours de sa période déconnectée, ainsi que la liste des patchs produits par ce demandeur durant cette même période. Les 2 sites procèdent ensuite à l'échange des patchs. Ce protocole d'anti-entropie est déclenché automatiquement lorsqu'un site rejoint le réseau pour la première fois ou après une déconnexion, mais aussi de manière périodique pour réparer les eets d'éventuelles partitions du réseau qui n'auraient pas été détectées.

2.3 Architecture et mise en oeuvre

Le serveur Wooki est une application Web, fonctionnant adossé à un serveur Web et traitant des requêtes HTTP. Il propose une interface wiki classique, permettant de visualiser, éditer ou accéder à l'historique des diérentes pages.

La visualisation et l'édition de pages dans Wooki est classique, et illustrée en gure 2.2. Par contre, la visualisation de l'historique, illustrée en gure 2.3 est diérente des visualisations classiques. L'ensemble des lignes insérées et détruites est aché, et les lignes détruites et non visibles dans la version courante sont grisées et surlignées d'un trait. De cette visualisation, il est possible d'accéder, pour chaque ligne, à des informations concernant l'ensemble des patchs ayant touchés cette ligne.

L'interface du système propose également un certain nombre de services pour gérer l'interaction avec le réseau de pairs : ajout de voisins, visualisation de la table de voisins, connexion/déconnexion au réseau, déclenchement d'une anti-entropie avec un voisin.

Du point de vue de l'architecture, le serveur wiki est composé de plusieurs modules, illustrés en gure 2.4.

Fig. 2.2  Visualisation d'une page Wooki

WootEngine : est le composant réalisant l'algorithme Woot. Il gère donc le stockage des pages Wooki, et assure l'intégration des patchs dans cette structure. Il permet également l'extraction de pages de cette structure. Il utilise le composant Clock pour générer des identiants uniques lors de l'insertion de nouvelles lignes dans la structure de données.

AntiEntropy, LPBCAST : sont les composants pour l'interaction avec le réseau de pairs. Le composant AntiAntropy réalise le protocole d'anti-entropie et gère pour cela un log de patchs. LPBCAST réalise l'algorithme de diusion épidémique et assure donc la gestion des tables de routage.

Radeox : est le composant de rendu HTML, c'est-à-dire chargé de convertir un document textuel en syntaxe wiki en un document HTML visualisable dans un navigateur Web. WookiApp : est le composant central réalisant l'application Web. Il est chargé de rece-voir les requêtes en provenance des utilisateurs, de coordonner leur exécution et de répondre à ces requêtes.

Le composant WookiApp gère principalement 3 types de requêtes en provenance des utilisateurs plus l'arrivée d'un patch distant. Les algorithmes liés au traitement de ces requêtes sont donnés en gure 2.5 :

get(PageId) : demande de visualisation d'une page. Le traitement de cette requête consiste à demander au composant WookiEngine l'extraction de la page depuis le modèle de stockage, puis demander le rendu HTML de cette page au composant Radeox pour, nalement, envoyer ce contenu HTML au navigateur dont est issue la

2.3. Architecture et mise en oeuvre

Fig. 2.3  Visualisation de l'historique d'une page dans Wooki requête.

edit(PageId) : demande d'édition d'une page. Le traitement consiste à demander l'ex-traction du contenu de cette page du modèle de stockage au composant WootEngine. Ce contenu textuel est alors stocké dans un espace temporaire, et renvoyé tel quel au navigateur dont est issue la requête. Ce navigateur l'insère dans une zone HTML d'édition pour permettre sa modication.

save(PageId, contenu) : demande de sauvegarde de modication d'une page. Le nou-veau contenu est transmis au serveur. Le traitement consiste à calculer dans un premier temps le patch correspondant à la modication. Ce patch est construit en calculant la diérence entre la nouvelle version transmise par le client, et l'ancienne version stockée dans l'espace temporaire par l'opération de demande d'édition. Une fois le patch construit, il est transmis au composant WootEngine pour être intégré à la copie locale de la page. Cette intégration modie le patch en y ajoutant les

iden-Fig. 2.4  Architecture du serveur Wooki

tiants des lignes insérées. Ce patch est ensuite transmis au composant LPBCAST pour diusion sur le réseau, et au composant AntiEntropy pour stockage dans son log.

receive(Patch) : demande d'application d'un patch distant. Cette requête est émise par le composant de gestion de la diusion ou le composant d'anti-entropie. Lorsqu'un patch est reçu par un de ces 2 composants, il est transmis au composant WookiApp qui se charge de demander son intégration immédiate au composant WookiEngine. Une fois qu'il est intégré, le patch est transmis au composant AntiEntropy pour stockage dans le log.

2.3. Architecture et mise en oeuvre

2.3.1 Conclusion

Dans sa version initiale, le prototype Wooki ne contenait aucun mécanisme de conscience de la concurrence. L'utilisateur visualisant une page n'avait aucun moyen de savoir que le contenu de la page résultat d'une intégration de patchs concurrents.

Chapitre 3

Un mécanisme de conscience des