Author: bleny Date: 2010-07-29 16:56:07 +0200 (Thu, 29 Jul 2010) New Revision: 116 Url: http://nuiton.org/repositories/revision/diswork/116 Log: diswork 0.2 Modified: trunk/src/site/rst/devel-draft-0.2.rst Modified: trunk/src/site/rst/devel-draft-0.2.rst =================================================================== --- trunk/src/site/rst/devel-draft-0.2.rst 2010-07-28 12:24:33 UTC (rev 115) +++ trunk/src/site/rst/devel-draft-0.2.rst 2010-07-29 14:56:07 UTC (rev 116) @@ -8,8 +8,8 @@ État actuel de la version 0.1 ============================= -Sur les choix de conceptions ----------------------------- +Sur les choix de conception +--------------------------- Hormis les problèmes de sécurité du système, le choix qui a été fait de découper le problème en trois couches semble justifié : @@ -258,3 +258,135 @@ Pistes pour la version 0.2 ========================== +Implémenter une DHT qui assure toutes les propriétés nécessaires +---------------------------------------------------------------- + +1. Nécéssité de pouvoir connecté des nœuds qui se trouvent sur des machines + différentes + +2. Une DHT fonctionnelle : et un get() qui suit un put() doit pouvoir permettre + de récupérer la valeur publiée juste avant. + +3. Nécéssité de gérer la réplication pour ne pas perdre de données + +4. Nécessité d'être robuste vis-à-vis des connexions/déconnexions (dynamicité de + structure du réseau) + +5. Implémenter le contrat Map tel que définit dans java.util.Map, ce qui implique + notamment de permettre de récupérer l'ancienne valeur lors d'un put() ou + d'un remove(). + +6. La nécessité de pouvoir publier des valeurs qui sont volumineuses. On souhaite + découper les fichiers en morceaux de 10 Mo. Notamment, cela exlue d'utiliser + UDP et nécessite d'utiliser TCP pour les échanges, car TCP peut découper + d'aussi gros messages ce qui n'est pas le cas d'UDP. + + +:: + + application + ↓ ↑ + blocks + ↑ ↓ + overlay + ↑ ↓ + network + +** La couche application ** + +Elle contient le code spécifique à l'application P2P, elle est développée +en utilisant des briques fournies par la couche blocks. + +** La couche blocks ** + +La couche blocks devrait fournir les éléments constitutifs d'une application +P2P : collections distribuées notamment. Les blocks doivent être implémentés +de façon à gérer la réplication (propriété 3). +Ces blocks doivent suffir pour écrire une application P2P. Au niveau +des blocks, il faudra veiller à limiter le parallèlisme pour assurer +la propriété 2. + +Un des block proposé dans le couche block sera évidemment une Map. Il faudrait +également proposé MultiMap et Tree. Ce dernier sera idéal pour écrire le FS. + +Idéalement, il faudrait prévoir l'utilisation de plusieurs instances d'un même +block dans une même application. Par exemple, un système de fichier pourrait +utiliser Tree pour stocker l'arborescence, une Map pour stocker les données +et une autre Map pour stoker les utilisateurs. + +Au niveau des blocs collections, il faudra proposer plusieurs méthodes de stockage +des clés stockées localement dont l'une stockera les données sur le système +de fichier local. D'autres implémentations pourront utiliser HashMap, une BdD +embarquée, Cassandra... + +Pour assurer le réplication, la couche overlay doit fournir un ensemble de noeud +accessibles rapidement (des proches). Chaque noeud doit répliquer les clés/valeurs +sur tous les noeuds proches, par exemple en utilisant un algorithme de transaction +distribué comme Two Phase Commit. + +Il faudrait gérer les droits à ce niveau-là. + +** La couche overlay ** + +La couche overlay se charge d'entretenir une table de routage et l'algorithme +pour atteindre tous les noeuds du réseau à partir d'une table de routage partielle. +Dans cette couche se trouve les algorithmes de routages (kademlia, pastry...). + +L'implémentation devra veiller à bien gérer les erreurs et éventuellement, +attendre que le système se stabilise avant de pouvoir exécuter les opérations +demandées au niveau block. La gestion d'erreur peut avoir quelque-chose à voir +avec http://en.wikipedia.org/wiki/Byzantine_fault_tolerance + +L'overlay doit également gérer l'entretien d'un groupe restreint de noeuds proches +(tels que les leafset de Pastry). + +Cette couche doit être implémentée en ayant toujours l'hypothèse qu'un noeud +a pu se déconnecter depuis le dernier message échangé. + +** La couche network ** + +La couche network permet à l'overlay d'envoyer des messages et d'en recevoir +et de pinguer un noeud (pour que la couche overlay puisse assurer la propriété +4). + +Une implémentation réseau pourrait faire usage +d'Apache Mina pour assurer les points 1 et 6 (Mina est basé sur TCP). C'est à ce +niveau qu'on peut intervenir sur la sécurité bas niveau (connexion cryptées via +TLS) et sur le passage de Firewall. D'autres implémentations plus fantaisistes +peuvent se baser sur REST (cf Riak). + +On peut envisager que les connexions entre un +noeud et les noeuds membres de son Leafset soient permanentes. + +Éventuellement, on pourra avoir une sous-couche décourverte qui permet de +d'essayer de découvrir un noeud ou une liste de noeud de bootstrap. Possibilité +de cumuler les méthodes : + +* Aller chercher une liste noeuds souvent connectés dans un fichier (fichier + local livré avec l'appli ou dispo via http) + +* Découverte dynamique de noeuds sur le réseau local via Zeroconf + +Ne plus utiliser de DHT comme base pour le sytème de fichiers +------------------------------------------------------------- + +Comment faire ? + +Ne plus utiliser de système de fichier +-------------------------------------- + +On pourrait préférer faire en sorte que chaque +noeud conserve ses données localement et les propose à qui les demande. + +Ça évite tout risque de perte de données mises en ligne mais ça à l'inconvénient +de nécessiter à un noeud d'être présent et d'attendre que quelqu'un demande +un fichier alors qu'avec la solution précédente, on peut publier un fichier +et quitter le système juste après, le fichier est toujours disponible. + +Ça pose également le problème de la modification d'un fichier qui se trouve +chez l'autre. + +Il faut aussi trouver le moyen de mettre les noeuds en relation, une solution +serait d'avoir, à la eMule, des serveurs centralisés dont le seul rôle est +d'indexé les fichiers proposés par les noeuds. Les noeuds peuvent ensuite faire +des recherches via ce serveur central. \ No newline at end of file