Prototype un moteur de wiki pair à pair pour MANet

 Démonstrateur : un wiki P2P pour MANet

Afin de démontrer la faisabilité des algorithmes proposés, nous les avons développés et intégrés au sein d’une application collaborative s’exécutant sur un intergiciel pour MANet, Transhumance Le prototype proposé est un wiki pair-à-pair permettant le travail collaboratif en nomadisme au-dessus d’un MANet. Dans le scénario de test, les utilisateurs travaillent habituellement au-dessus d’un réseau filaire avec un moteur de wiki centralisé. Cependant, il leur arrive de partir de leurs bureaux en groupe, par exemple pour une réunion, et de ne plus avoir accès au serveur de wiki, ou même à une infrastructure. Le wiki pair à pair leur permet de continuer à travailler collaborativement durant cette phase nomade. Les fonctionnalités proposées sont identiques à celles offertes par un moteur de wiki monolithique classique : ils peuvent donc partager de nouveaux articles, consulter et éditer des articles existants déjà sur le wiki monolithique, et faire des recherches. Bien entendu, lorsque la phase de nomadisme se termine et que les utilisateurs retrouvent leurs bureaux, les modifications qu’ils ont apportées au wiki nomade doivent être répercutées dans le wiki monolithique. Ce service doit être disponible (une donnée est accessible en temps borné), fiable (les données ne disparaissent pas en cas de disparition ou de partition), et doit faire un usage efficace des ressources afin de minimiser l’impact du service sur la durée de vie de la batterie. Dans la suite de ce chapitre, nous allons tout d’abord voir pourquoi nous n’avons pas réutilisé un moteur existant, avant de présenter l’architecture du démonstrateur. Nous verrons ensuite comment la cohérence est gérée, avant de présenter l’intergiciel Transhumance. 187 8.2 Moteur de wiki pair à pair sur réseaux mobiles ad hoc Avant de développer notre propre moteur de wiki, nous avons cherché s’il était plus intéressant d’adapter un moteur existant. Nous avons étudié les moteurs de wiki pair à pair existant, que nous présentons donc dans cette section. Nous voyons aussi leur adaptabilité aux MANets. Les motivations principales pour passer d’une architecture client/serveur à une architecture pair à pair pour un moteur de wiki sur réseau filaire sont les suivantes. Dans un moteur de wiki classique, le serveur stockant les articles constitue un goulot d’étranglement, tant au niveau de l’espace de stockage que de la bande passante. En cas de panne du serveur, le wiki devient inaccessible. Par ailleurs, le fait que les articles soient tous stockés au même endroit rend l’information plus facilement contrôlable par un petit nombre de personnes. Enfin, on voudrait distribuer le contenu du wiki sur les terminaux des utilisateurs afin de ne pas avoir à supporter le coût de l’infrastructure (stockage et bande passante) pour un serveur. 8.2.1 Distriwiki Dans [74], Morris cherche à contourner ces problèmes en proposant Distriwiki, un moteur de wiki pair à pair pour réseaux filaires. Distriwiki est basé sur l’intergiciel JXTA [109], une librairie de protocoles pair à pair spécifiée par SUN. JXTA permet la constitution d’un réseau de recouvrement (overlay), et la découverte/publication de service. Les articles sont donc localisés grâce à ce service et répliqués à la demande. Le passage à JXTA permet de lever les limitations sur la bande passante, et d’empêcher que les données puissent être contrôlées en étant centralisées et en un seul exemplaire. Cependant, la cohérence des données n’est pas assurée, et c’est à l’utilisateur de régler les conflits. Par ailleurs, les articles étant répliqués à la demande, il est possible de voir du contenu disparaître avant d’avoir été répliqué.

Wooki

Wooki [106] est un moteur de wiki pair à pair pour réseaux filaires développé au Loria. Tout comme Distriwiki, Wooki cherche à régler les problèmes liés à la centralisation du wiki. Il veut aussi permettre l’édition d’articles en mode déconnecté. Dans Wooki, chaque site réplique l’intégralité du wiki et utilise Wooto, une version optimisée de WOOT, pour gérer la cohérence des articles, avec comme granularité la ligne. Comme nous l’avons expliqué dans la section précédente, les structures WOOT grandissent en taille sans limitation, à moins de pouvoir mettre en place une phase de compression nécessitant les conditions suivantes : – tous les terminaux ont effectué le même ensemble de modifications, – aucun terminal ne fait d’édition avant la fin de la phase de compression. Sur un wiki à grande échelle, il est peu probable, bien que possible, que ces conditions soient satisfaites, Wooki étant conçu pour fonctionner en mode déconnecté. Bien que conçu pour le travail en mode ad hoc, Wooki n’a pas été testé dans ces conditions. 188 8. Prototype : un moteur de wiki pair à pair pour MANet

 XWiki Concerto

Dans Xwiki concerto [17], chaque terminal est un serveur de wiki embarquant l’intégralité des données. XWiki offre un modèle de cohérence optimiste utilisant WOOT pour gérer la fusion de différentes versions des articles. Il permet le travail nomade : un utilisateur peut modifier une donnée quand il est déconnecté du reste du réseau. 8.2.4 Synthèse Distriwiki ne gère pas la cohérence des données, et ne nous intéresse donc pas dans le cadre de ces travaux. Wooki et Xwiki ont, en revanche, été conçus pour travailler en mode déconnecté. Cependant, l’ensemble du wiki est embarqué sur chaque terminal, ce qui n’est pas toujours possible sur un terminal mobile, et crée une charge réseau liée à la propagation des mises à jour. Nous voulons donc mettre en place un moteur de wiki avec une gestion plus fine de la réplication des données, en utilisant TreeDoc, qui prend moins de place en mémoire, et dont la taille des identifiants plus réduite diminue la taille des messages échangés. Par ailleurs, nous voulons que le démonstrateur s’intègre à Transhumance. Il n’est donc pas intéressant de modifier un moteur existant.