Cela fait quelques temps que je n'ai pas donné de nouvelles de Peerfuse, je vais donc corriger ceci.

Un été actif

Ainsi que je l'avais raconté dans un billet précédent, il se trouve qu'une nouvelle version du protocole a été définie, plus sécurisée, utilisant moins de bande passante et ne nécessitant pas pour chaque pair à connaître tous ceux du réseau, ce qui permet d'avoir des réseaux de tailles non négligeables.

Le travail a débuté cet été avec l'aide de Eld et tito, le premier spécialiste des réseaux peer-to-peer, qui m'a aidé dans la réalisation du protocole, et le second contributeur plus connu pour avoir été président de l'association de jeux vidéos libres Nekeme Prod. (oui leur site est down), et qui a réalisé entre autres un serveur XML-RPC inclus dans Peerfuse, qui permettra à l'avenir de développer des frontends (graphiques ou non) avec une interaction plus user friendly avec Peerfuse.

Une charge de travail assez importante a été réalisée, et la DHT Chimera a été correctement importée. D'ailleurs, je pense que le mot « réécrite » corresponds davantage à ce qui a été effectué. En effet, tout d'abord la DHT était écrite en C, et j'ai adapté tout le code afin de correspondre au style C++ du projet.

En outre, j'ai séparé la partie réseau de la partie DHT, en réécrivant entièrement le moteur réseau de Peerfuse, beaucoup plus souple et extensible.
Ainsi, la DHT s'allège du code réseau de Chimera qui était, il faut bien l'avouer, complètement moisi (voir ici).

Peerfuse bénéficie d'ailleurs maintenant d'une meilleure architecture. Chaque partie de l'ancien common (la partie de code commune à peerfuse-net et peerfuse-lan) a été transformée en petites bibliothèques indépendantes. Ainsi nous trouvons maintenant :

• util — Diverses classes génériques, pour gérer les threads, la config, les mutex, le logging, etc.
• net — Contient la classe Network ainsi que diverses autres classes qui constituent la fondation du moteur réseau de Peerfuse.
• dht — La fameuse DHT écrite à partir de Chimera, et qui est entièrement fonctionnelle.
• ssl — Des classes faisant couche d'abstraction d'OpenSSL, afin d'assurer la sécurité des transmissions dans Peerfuse
• scheduler — Un système de tâches planifiées qui a été amélioré afin de tourner sur plusieurs threads
• files — Les classes qui gèrent les dossiers et les fichiers, ainsi que leurs contenus et diverses méthodes d'abstraction autour des transferts
• fuse — Ce sont les handlers de la libfuse et qui appellent les fonctions Peerfuse

Un intérêt à la séparation des différentes petites libs, c'est que j'ai pu tester la DHT avec le moteur réseau et la libutil, de façon totalement indépendante dans un programme de test, et que ça marche.

Le desert

Malheureusement, à partir d'octobre, la dépression causée par divers évènements personnels ma conduit à m'intéresser moins au projet.

Le travail qui reste à faire est plus chiant qu'autre chose, c'est à dire réécrire une partie du code de Peerfuse pour supporter la nouvelle API réseau et protocolaire (DHT).

Le souci, c'est que Peerfuse en lui même ne compile pas du tout (contrairement aux mini libs), et que cela ne facilite pas le travail des quelques contributeurs intéressés par le projet, et qui du coup n'en foutent pas une.

Donc je pense qu'il me faudrait un bon coup de remotivation pour reprendre le travail que j'ai laissé inachevé en automne dernier. Ça va être dur, parce que j'avais trouvé un moyen pour me pousser à me remettre au travail, mais les quelques conquetes féminines n'ont pas suffit à me remotiver :)

Les six derniers mois

Ça fait longtemps que j'ai pas raconté ma vie ici, donc je vais en profiter, histoire de.

Tout d'abord, j'ai commencé un nouveau projet que je garde secret pour le moment, mais que certaines personnes connaissent sous le nom d'AuM. Ce projet est écrit en Python, utilise les libs mechanize et html5lib, je vous laisse imaginer quel genre d'utilité cela peut avoir.
Mais je reviendrai dessus dans un billet futur, quand sera venu le moment adéquat pour en parler. Je ferai peut-être une conférence dessus fin mai aux PyCon 2009.

En outre, j'ai remis en place Men Are Ants, à sa version 0.4, qui était plus abouti, et abandonne la réalisation de la version 3D isométrique, l'intérêt étant réduit, et n'ayant plus vraiment envie de m'investir dans ce projet. Je corrigerai sans doute néanmoins les quelques bugs que j'ai remarqué lors d'une partie récente avec pankkake.

J'ai finalement envoyé mes patches pour ncmpc upstream, le projet ayant été depuis repris par un des principaux développeurs de MPD. Il se trouve que la personne, Max Kellermann, a été très intéressé par mes patches, m'a demandé d'en faire d'autres, et m'a très gentilment proposé de devenir contributeur, chose que j'ai accepté avec enthousiasme. En effet, je prends plaisir à participer, pour une fois, à un projet d'envergure et que j'utilise tous les jours.

Je n'ai pas encore eu pour le moment l'occasion de faire grand chose, mais je suis intéressé par la réalisation d'un système de plugins chargés dynamiquement, qui permettrait d'étendre les possibilités offertes par MPD, et de rendre plus propre la gestion des modules de sortie audio.

Enfin, je me suis mis en tête de réaliser un agrégateur de flux RSS deux-tiers (comme disent les décideurs), avec un backend qui récupère les données, et un frontend en ncurses (il pourrait y en avoir d'autres) qui se synchronise et (très important) peut récupérer les articles en local, permettant de les lire même en étant offline.

Ceci résoudrait le problème que j'ai à ne pas pouvoir lire mes flux RSS au boulot, puisque j'utilise Akregator, qui est une application graphique KDE qui ne me permet pas de gérer la synchronisation avec mon PC du boulot.

Je n'ai pas encore commencé, mais avec un peu de motivation ça peut le faire.

Conclusion

J'ai donc pas mal de projets en attente, qui sont tous aussi intéressants les uns que les autres, et j'espère ne pas tomber dans le schéma lodesi, qui a beaucoup d'idées mais jamais le courage de les réaliser jusqu'au bout.

L'activité de Peerfuse reprends de plein pied.

Chimera

Le but du mois de juillet était de convertir la DHT Pastry (écrite en Java) pour l'intégrer au code C++ de Peerfuse. La flemme et la laideur du code Java n'aidant pas, les choses étaient restées en état jusqu'il y a deux semaines...

En effet, il y a deux semaines, j'apprends l'existence d'une DHT similaire à Pastry (plus légère), écrite en C, nommée Chimera.

Le portage a débuté la semaine dernière, et je peux dire que je me suis amusé... Ça a bien avancé, la quasi totalité du code se trouve dans diverses classes, mais j'ai été confronté à certains problèmes...

Je dirais que le plus chiant, était ce qui est résumé par une phrase sur le site de Chimera :

Thanks to Perry Lorier for a patch to make Chimera compatible w/ 64 Bit machines!

Non, je ne le remercie pas. En effet, quand on voit qu'ils stockent l'ID dans des unsigned long, type dont la taille varie suivant l'architecture, et qu'ils font diverses opérations de bits en considérant qu'il s'agit de uint32_t, on peut aisément deviner pourquoi ça ne marche pas.

En outre, toujours un problème similaire :

 
/* encode the message */
type = htonl ((unsigned long) message->type);
memcpy (data, &type, sizeof (unsigned long));
size = htonl ((unsigned long) message->size);
memcpy (data + sizeof (unsigned long), &size, sizeof (unsigned long));
memcpy (data + (2 * sizeof (unsigned long)),
                get_key_string (&message->dest),
                strlen (get_key_string (&message->dest)));
memcpy (data + HEADER_SIZE, message->payload, message->size);
size = HEADER_SIZE + message->size;     /*reset due to htonl */
 

Il est facile de comprendre que si on connecte un chimera x86 sur un chimera x86_64, ils risquent de ne pas parler la même langue...

Bref, j'ai fais remonté l'info à Chimera et pour ma part j'ai corrigé tout ça dans Peerfuse...

Git

Afin de développer au mieux le portage de Chimera, j'ai profité des joies de git et ai créé une branche chimera sur mon dépôt local. C'est un vrai bonheur. D'autant plus qu'on peut travailler à plusieurs sur cette branche.

Depuis peu, deux nouveaux contributeurs se sont joint sur Peerfuse, l'un a déjà travaillé sur une implantation de XML-RPC dans Peerfuse afin de faire communiquer le démon peerfuse avec des frontends (en console ou graphiques), le second a pour le moment la tâche de porter peerfuse en ipv6.

Chacun des développeurs de Peerfuse s'est vu doter d'une dépôt public chacun ainsi qu'on peut le voir : http://git.peerfuse.org/

Je trouve vraiment sympatique cette façon de travailler, même si c'est un peu déroutant au départ pour l'utilisateur de Subversion que je suis habituellement.

Mailing lists

La mailing list a été réinstallée, et une seconde spécifique au développement a été créée.

Pour plus d'informations : http://lists.peerfuse.org

Redmine

Enfin, il semblerait que les fichiers TASKS et BUGS présents dans les sources n'étaient pas satisfaisants pour les contributeurs de Peerfuse, ainsi j'ai été contraint d'installer Redmine, une alternative très sympatique à Trac.

Ça donne ceci : http://dev.peerfuse.org.

Conclusion

Peerfuse reprends son souffle et on devrait maintenant avoir tout ce qui faut pour pouvoir travailler vite. Il ne manque plus qu'à remettre en place les buildbots, mais il faudra de toute façon encore quelques semaines avant de retrouver un état stable.

Le futur de Peerfuse s'annonce radieux. Après plus d'un mois de discussions, une nouvelle version du protocole permettant de meilleurs performances est définie, et va se baser sur Pastry, une DHT qui corresponds à ce que l'on souhaite implémenter.

Le nouveau protocole a été décrit (grossièrement) dans la présentation de Peerfuse aux RMLL08, dont vous pouvez retrouver les slides ici.

Malheureusement, ceci implique une importation de Pastry, qui est écrit en Java, vers le langage utilisé pour Peerfuse qui est le C++.

C'est un travail monstrueux, et malgré la propagande faite par hydromiel et moi aux RMLL, personne ne s'est senti de m'aider à cette tâche. D'ailleurs, dans les discussions que j'ai pu avoir, il semblerait que l'utilisation du langage C++ soit un vrai frein pour les contributeurs (à moins que ça ne soit qu'un prétexte).
Je n'ose imaginer comment ça serait si on avait écrit Peerfuse, comme j'avais soulevé l'idée au départ, en langage D.

Notez que le projet utilise maintenant Git, que le site peerfuse.org est temporairement mort, et que vous êtes donc bien invité de venir sur le canal IRC #peerfuse@freenode si vous souhaitez suivre l'évolution.

Il a été décidé il y a peu que le projet Peerfuse utiliserait dorénavant le système de gestion de version Git.

Je ne reviendrai pas sur l'intérêt qu'apporte un système de révision distribué (indépendance vis à vis d'un serveur central, l'avantage des branches, facilité pour un contributeur irrégulier de contribuer, etc.).

Je me permets juste de donner quelques opérations à suivre pour importer un dépôt subversion (note: installer préalablement git et git-svn) :

$ mkdir project
$ cd project
$ git svn init -t tags -b branches -T trunk https://svn.example.org/prjt
Initialized empty Git repository in .git/
$ git svn fetch

Et.. c'est tout.

Nous disposons maintenant d'un dépôt git indépendant, contenant l'intégralité de l'historique des commits du subversion. On peut ainsi le mettre à disposition pour que d'autres en profitent, et se mettre à travailler immédiatement.

Pour plus d'informations sur comment utiliser git, je préfère vous laisser vous référer à la très bonne documentation de Git.

Je profite de ce bref billet pour rappeler que Peerfuse a besoin de contributeurs.
À ce propos, une conférence se déroulera aux RMLL08 sur Peerfuse, ainsi n'hésitez pas à la regarder si vous êtes intéressé par le projet.

Peerfuse paraît aujourd'hui dans sa version 0.0.

En effet, bien qu'utilisable, le numéro de version traduit le fait qu'il est encore pleinement en développement et qu'il ne faut pas l'utiliser en production, ainsi que la présence éventuelle de divers bugs.

En outre, bien que le concept est présenté, divers éléments d'implémentation sont susceptible d'évoluer, comme la DHT utilisée, etc.

Vous pouvez télécharger les sources sur le site de Peerfuse.

Diverses documentations sont présentes à cette adresse.

Le réseau peerfuse-net officiel, Peerfuse.net, est accessible. Vous pouvez lire ici comment le rejoindre.

Enfin, si vous souhaitez nous rejoindre afin de discuter du développement sur le salon IRC #peerfuse@freenode, vous êtes la bienvenue.

Une mailing list est également à votre disposition.

Hier soir, après de nombreux efforts, le réseau peerfuse.net a été lancé !
Les premiers peers ont rejoint le réseau (que des développeurs et quelques testeurs), et il s'agit bien évidemment d'un réseau "beta", car Peerfuse risque d'évoluer encore fortement (notament au niveau du protocole) cette semaine jusqu'à la sortie de la 0.1.

Nous avons pu procéder à des tests grandeur nature, ce qui n'avait jamais été le cas jusqu'alors (uniquement en local), et la conclusion est la suivante : ça marche !

Enfin... presque. Nous avons tout de même découvert des bugs (dont une partie est corrigée; hier a été une journée particulièrement productive de ce côté là), mais le premier fichier a été transféré avec succès.

Les pairs possédant un certificat et étant connecté au réseau forment la topologie suivante :

sunigav.vaginus.org (1)
|- nivagus.vaginus.org (2)
|- hubb_server (3)
|  `- hubb (4)
|- moonpa.inl.fr (5)
|- lids (6)
`- dehy (7)

Les fichiers contenus actuellement sont :

rom1@nivagus ~/Projets/peerfuse/trunk/nivagus/mnt $ ls -lh
total 0
-rw------- 0 lp   lp   9.2M 2008-04-25 00:40 05 La ritournelle.mp3
-rw------- 0 rom1 rom1 5.5M 2008-04-24 22:32 06 BOA_Get There_A Girl.mp3
-rw-r--r-- 0 lp   lp   100M 2008-04-25 01:07 Fragmovie.avi
-rw-r--r-- 0 lp   lp      0 2008-04-25 01:07 One Page Linux Manual.pdf
-rw-r----- 0 rom1 rom1 1.0M 2008-04-24 21:07 random
-rw-r--r-- 0 rom1 rom1 748K 2008-04-23 18:02 Speedy's Coming [Live].mp3

Dont le premier fichier a être transféré fut 05 La ritournelle.mp3. Attention, il s'agit mieux que de transfert, car en effet une simple utilisation de la commande suivante suffit :

rom1@nivagus ~/Projets/peerfuse/trunk/nivagus/mnt $ mplayer 05\ La\ ritournelle.mp3
MPlayer dev-SVN-rUNKNOWN-4.1.2 (C) 2000-2007 MPlayer Team
CPU: Intel(R) Pentium(R) M processor 2.00GHz (Family: 6, Model: 13, Stepping: 8)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.
Can't open joystick device /dev/input/js0: No such file or directory
Can't init input joystick
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing 05 La ritournelle.mp3.
Audio file file format detected.
==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 44100 Hz, 2 ch, s16le, 192.0 kbit/13.61% (ratio: 24000->176400)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
A: 401.1 (06:41.0) of 401.0 (06:41.0)  1.8%

Exiting... (End of file)
rom1@nivagus ~/Projets/peerfuse/trunk/nivagus/mnt $

La lecture s'est faite de manière tout à fait transparente, sans interruption ni saccade, alors que le transfert se faisait entre dehy et nivagus.vaginus.org (par l'intermédiaire de sunigav.vaginus.org).

Notez la présence de sunigav.vaginus.org au milieu des autres peers. En l'occurence, il s'agit d'un serveur, donc par commodité nous avons connecté la majeur partie de nos pairs à celui-ci. Mais il est tout à fait possible de se connecter à n'importe quel pair du réseau, du moment qu'il n'est pas caché derrière un firewall ou un routeur NAT.

Si vous souhaitez en connaître plus, vous êtes visiter à lire http://peerfuse.net (site du réseau officiel de Peerfuse, en opposition à http://peerfuse.org qui est le site du projet).

Ainsi que les lecteurs attentifs le savent, Peerfuse est un projet de système de fichier distribué pair à pair utilisant la bibliothèque FUSE.

Après quelques mois de développement, la version 0.1 devrait être prête pour le Vendredi 2 mai 2008 !

Beaucoup de travail a été fournis par lodesi et moi même, et le projet est quasiment utilisable. Bien sur, il est loin d'être terminé, seules les fonctionnalités de base sont présentes ;

• Connexion des pairs entre eux
• Synchronisation des arbres
• Transfert des fichiers

Ce sont les fonctionnalités fondamentales qui permettent (malgré un manque côté sécurité) d'utiliser le projet dans son but premier : le partage de fichiers via un système de fichier virtuel.

Les principales fonctionnalités manquantes et qui seront développées après la 0.1 sont :

• Redondance automatique des fichiers dans le réseau
• Optimisation des transferts (par la détermination de la qualité d'un lien, etc)
• Gestion des permissions
• Utilisation de systèmes cryptographiques d'encryption et de signature relatifs aux permissions des fichiers, afin qu'il soit impossible de lire ou d'écrire des données auxquelles on a pas accès
• Interface graphique. Ça sera développé en tant que projet à part par hubbb, et permettra d'assurer des fonctionnalités supplémentaires qu'on ne peut pas retrouver avec l'interface de FUSE (comme la constitution des groupes, système de discussion avec les autres pairs (à un pair en particulier, à un groupe ou à tout le monde, ce que je trouve intéressant afin de créer une communauté autour du projet)).
• Bien sur, afin d'assurer ces fonctionnalités supplémentaires, une petite application ncurse pourra être utilisée à la place de l'interface graphique

Il reste encore beaucoup à faire, et nous espérons que la 0.1 permettra de faire connaître le projet et de trouver des contributeurs.

Dans ce sens est d'ailleurs prévu une petite soirée de lancement le vendredi 2 mai à 19:00, au Dock's café (Paris, XIXe).
N'hésitez pas à venir si vous êtes intéressé par le projet, afin de faire connaissance et de boire quelques bières en discutant de Peerfuse. Quelques t-shirts seront donnés aux futurs contributeurs ;)

Nous vous invitons à nous rejoindre sur le salon IRC #peerfuse@Freenode si vous souhaitez avoir plus d'informations sur le projet ou sur la soirée.
Une mailing list devrait par ailleurs être prochainement créée.

Voici le nouveau site de Peerfuse en exclusivité : http://peerfuse.org/

Il va bientôt également y avoir un site pour peerfuse.net qui se concentrera sur le réseau officiel de peerfuse-net, là où peerfuse.org concerne le projet lui même (développement, etc).

Il y a maintenant plus d'un mois j'ai débuté avec lodesi un projet intitulé Peerfuse, qui est un système de fichiers distribué peer-to-peer.

Le projet est découpé en deux sous projets distincts (possédant une base de code commune) :

• peerfuse-net pour un réseau sur Internet avec des inconnus. La principale utilisation à laquelle on pense, est un but similaire à Emule, à part qu'au lieu d'avoir un espace par utilisateur, ici tout le monde partage le même espace. Ceci permet l'échange de vidéos, photos, musiques, programmes, images CD de distributions Linux, etc.
• peerfuse-lan pour un réseau avec ses propres machines. Il permet par exemple de partager une partition /usr/local entre divers machines. Ainsi chacunes de ces machines possède virtuellement un grand nombre d'applications, et elles ne sont récupérées que lorsqu'on les utilise effectivement.

Le principe en surface est simple :

• C'est un système de fichier, c'est à dire qu'il n'y a pas de GUI (bon en fait on en fera probablement une pour aider à effectuer certaines tâches).
  Il suffit donc de lancer peerfuse avec la commande mount sur un point de montage qui sera l'espace partagé.
• Il n'y a pas de serveur central, lorsque l'on rejoint le réseau, il suffit de se connecter sur l'un des peers, qui va nous mettre en relation avec tous les autres.
• La partition montée est commune à tout le monde. C'est à dire que l'arborescence présente dans le point de montage sera le même pour tout le monde.
  Lorsque l'on souhaite partager un fichier avec le reste du monde, il suffit donc de le copier vers le point de montage, et ainsi chaque utilisateur y verra le fichier et pourra le lire ou le copier à son tour (ce qui effectue un téléchargement).
• Il y a tout de même un système de permissions, comme sur tout système de fichier unix.
  Sur peerfuse-net, chaque peer possède un UID, et chaque fichier qu'il crée aura pour propriétaire cet uid. Après les permissions unix s'appliquent comme d'habitude. Les groupes seront également supportés, avec le principe qu'un utilisateur est propriétaire du groupe au GID = UID. C'est donc lui qui ajoute des personnes à son groupe.
  Sur peerfuse-lan, les permissions du système unix sont concervées. Ainsi root sur une machine pourra voir root sur les autres machines.
• Une autre puissance de peerfuse est de permettre un travail collaboratif. En effet, les fichiers sont modifiables par ceux qui en ont la permission. Il est ainsi facile d'imaginer qu'un projet soit créé sur un réseau peerfuse, dans un dossier où seul le groupe G a droit d'écriture dessus. Tous les membres de ce groupe pourront modifier et faire évoluer ce projet.
  Attention toute fois, pour des projets d'ampleur tels que des logiciels, il est préférable d'utiliser un système de gestion de version tel que Subversion. En effet, peerfuse ne gère pas l'historique des versions, ni les accès concurrents à un même fichier (la dernière écriture gagne).
• Peerfuse fonctionne en mode déconnecté, c'est à dire que même lorsque l'on est déconnecté du réseau, on peut lancer peerfuse et ajouter des fichiers, en supprimer, en modifier, etc. Lors de la prochaine reconnexion au réseau, les changements seront appliqués.
• Tous les échanges sont sécurisés, utilisant SSL pour les connexions.
  peerfuse-net renforce encore les systèmes de sécurité, avec signatures de tous les messages et fichiers, encryptage des fichiers accessible que par une partie des utilisateurs (propriétaire ou groupe), certificat délivré par une autorité afin d'assurer l'authenticité de tel utilisateur, etc.
• Les transferts seront effectués probablement en UDP pour peerfuse-lan, afin de gagner un débit optimal.
• Ces transferts seront effectués dans la limite du possible en streaming. Le but est de pouvoir lire une vidéo de façon totalement transparente même lorsqu'elle n'est pas encore sur la machine locale. Si le débit du transfert est plus rapide que celui de la vidéo, aucune différence ne sera faite.

C'est un projet assez novateur et dont les tentatives similaires (mais n'ayant pas le tiers des fonctionnalités que nous proposons) sont toutes tombées à l'eau. Je pense que Laurent et moi avons la volonté suffisante pour que ça ne soit pas le cas avec ce projet.

Cependant, comme on peut l'imaginer, il y a énormément de problèmes de sécurité dans peerfuse-net qui peuvent se poser, en raison de la présence éventuelle de malfaiteurs. Nous en avons déjà résolu une grande partie, mais il reste encore quelques sujets mineurs sur lesquels plancher.

Développement

Nous recherchons tout de même des développeurs afin de nous aider sur le projet, car il y a du boulot. Cela dit, je pense qu'on atteindra une première version stable et incomplète de peerfure-lan rapidement, étant donné qu'il ne pose plus de problèmes de sécurité, et qu'il manque uniquement les transferts des fichiers.

Vous pouvez récupérer les sources grâce à :

$ svn co https://piggledy.org/svn/peerfuse/trunk peerfuse

Login: anonymous
Password: <Enter>

Vous trouverez la base commune dans common/, la partie concernant peerfuse-net dans peerfuse-net/ et je vous laisse deviner où se trouve le code de peerfuse-lan.
La documentation se trouve dans doc/, cependant ne lisez pas proto.html qui est complètement dépassé maintenant.

Lisez plutôt peerfuse-net/PROTOCOL et doc/pfnet.proto.

N'hesitez pas à nous rejoindre sur le salon IRC #peerfuse@freenode. Une mailing list sera bientôt mise en place.

Plus d'informations sur http://peerfuse.org.