lodesi a écrit 11 commentaires

Oui, je confirme tu lis les news en diagonale. Je vais donc essayer de réexpliquer spécialement pour toi.

Peerfuse 0.0 fait de l'authentification par certficat X509 en se basant sur la librairie OpenSSL.
Quand tu as voulu te connecter au réseau de test Peerfuse.net, tu as dû générer une clé privée, ainsi qu'une requête de certificat que tu as envoyée Romain. A partir de cette requête, Romain a généré un certificat(qu'il a signé avec sa CA), qu'il t'a renvoyé, sans lequel tu n'aurais pas pu te connecter au réseau. Tu trouveras plus d'informations sur l'authentification par certificat sur Wikipedia : http://en.wikipedia.org/wiki/X.509

Ensuite, toute les données transmises sur le réseau sont cryptées (toujours grâce à OpenSSL). Toute les données reçues sont cryptées avec ta clé publique et seule ta machine peut les décrypter à l'aide de ta clé privée (comme avec OpenSSH).

Maintenant, une fois que tu es connecté au réseau, la gestion des permissions du système de fichiers virtuels(et non pas du disque dur) n'est pas encore implémentée, autrement dit, tout les fichiers que tu copies sur le partage Peerfuse sont lisibles et modifiables par les peers connectées (et donc authentifiés) au réseau. D'où le numéro de version 0.0, pour lequel nous indiquons de ne pas stocker de donneés importantes.
Notre projet sort sa 1ère version, donc en effet nous n'avons pas fait de tests à grande échelle.

J'espère que tu as bien compris ce qui était implémenté et ce qui ne l'etait pas... Après on n'a peut-être pas la même conception de la sécurité ...

En fait le cache porte mal son nom, car il sert à la fois de cache et à stocker les données. La raison c'est que à partir du moment où on a des données dans le cache ça parrait naturel de pouvoir les redistribuer immédiatement. Et ça permet aussi de simplifier la configuration du démon.

A l'utilisation, la différence entre pflan et pfnet se fait essentiellement sur la gestion des permissions : pflan distribue des fichiers en utilisant les permissions UNIX de la machine (un user avec un même UID accède aux mêmes fichiers depuis toute les machines), pfnet gère les permissions à partir du certificat passé au démon, càd un démon égal un utilisateur (la gestion des groupes ne se fait donc pas avec /etc/group, mais avec des commandes spécifiques pfnet). Une autre différence majeur entre pfnet et pflan se situe au niveau du réseau, pflan demande à ce que tout les peers puisse se connecter les uns aux autres, alors que pfnet implémente un routage des messages en utilisant d'autres peers comme passerelle (pour gérer les utilisateurs derrière des routeurs NAT).

Pour la gestion des méta-données, les peers stockent toutes les méta-données sur pflan. Ce n'est pas le cas sur pfnet, car un peer n'a pas accès à tout les fichiers. Dans les 2 cas tout les peers se connaissent les un les autres (y'a bcp de broadcast dans pflan, mais pas dans pfnet).
On n'a pas vraiment étudié les limitations, ce n'est pas encore prioritaire ;)
Voilà, maintenant que tu connais tout les détails de l'implémentation, je t'invite à venir contribuer sur peerfuse ! :)
Bref, passe sur #peerfuse@freenode.net si tu veux tester ou si t'as d'autres questions.

FreenetFS et PeerfuseNet sont assez différent, Freenet met l'accent sur l'anonymat des peers ce qui implique certaines contraintes à ce projet, et a pour effet de rendre les tranferts de fichier assez lents. PFNet au contraire se concentre plutôt sur l'authenticité des peers, et au final nous espérons obtenir des performances assez proches des sytèmes de fichiers réseaux standards (nfs, samba ...). Maintenant, je n'ai pas réessayé freenet depuis longtemps ça s'est p-e amélioré (j'ai vu la dépêche sur la réécriture froms cratch).

Sur pf-net:
En gros, les fichiers sont gérés à partir d'un hash sur le nom de fichier. Quand on fait un ls on prend le hash du nom de fichier et ça nous donne la liste des peers ayant les infos sur ce fichier (contenu du répertoire, quels peers possèdent le contenu du fichier ...). Cette méthode permet d'économiser de la bande passante et aussi donne une certaine réactivité quand on fait un ls ;)

Sur pf-lan:
Chaque peer connait en permanence le contenu des dossiers, les modifications sont synchrones et broadcastées.

Pour les datas, c'est commun aux 2 fs:
Dans pf-0.1, le fichier est récupéré au moment de la lecture, la copie est gardée en cache. Lorsque quelqu'un modifie le fichier toute les copies existantes sont invalidées.
Dans pf-0.2, lorsque le cache est plein on le vide, avec migration de fichier sur une autre machine si nécessaire. (donc oui sur la 0.1, le cache explose si on n'y fait pas attention :)
Ca c'est le fonctionnement de base, un peu plus tard on pourra définir un taux de redondance sur le réseau qui propagera les modifications sur un fichier, et on rajoutera surement des fonctions de prefetch... et plein de bonnes choses sont encore à définir pour le version suivantes :)

Pour les problèmes de réaction physique des personnages, voir le post précédent ;)
La seule bonne raison pour laquelle tous détails de worms n'ont pas été codés est surtout le manque de temps :(
On tient compte de tes remarques pour la prochaine version!

Merci pour les points positifs! :)

Merci!

Pour les problèmes de flottements des personnages, c'est des constantes physiques qui sont mal réglées.. :/
Tu peux changer tout ça dans le fichier data/game_mode/classic.xml
Avec quelques connaissance en anglais (heu.. niveau 6ème ?), le gameplay peut être modifié du tout au tout.

Si quelqu'un arrive à qqch d'un peu plus consistent, merci d'envoyer une copie à wormux-dev_AROBAS_gna_POINT_org ;)

Pour les problèmes de changements de résolution et de fullscreen, on a un bugreport classé dans un coin :)

Sinon, pour le reste, j'ai l'impression que ton fichier de config n'est pas ok. Copie le fichier config.xml contenu dans l'archive dans ton ~/.wormux/
Si c'est déja fait, alorsje crains que ce soit un problème de carte graphique..

Aucune idée si le problème vient de clanlib ou de wormux!
Si t'as réussi à tout compiler, alors le problème n'est pas forcément très méchant!
Si tu veux, on peut examiner tous ça sur IRC #wormux sur irc.freenode.net (attention, prépare ton gdb! ;)

La branche 0.9 de clanlib ne contient pour l'instant aucune modification sur le code qu'on utilise, donc aucun intéret.
Vu que la version 0.7.9 (version actuelle) est prévue pour être laissée à l'abandon (pas de release 0.8), il y a de grande chance pour qu'on passe sous 0.9.
Mais bon, pour l'instant,faudrait au moins qu'un développeur de Wormux réussisse à compiler clanlib 0.9 ;)

Wormux pourrait tout aussi bien tourner sur un P2 avec 64Mo de RAM.. Le problème vient effectivement de clanlib qui a abandonné le support de sdl...
Du coup on se retrouve à utiliser opengl pour afficher des sprites 2d!
Ceci dit, grâce à clanlib/opengl, on arrive avec une carte graphique récente à atteindre des taux de 200 images par seconde, avec des calculs de rotations et de zoom en temps réel!

Pourquoi on ne passe pas sous SDL ? Parceque c'est le bordel de changer la lib de laquelle dépend la majeur partie du code (gestion clavier, affichage, son, réseau...), et que ça demenderait énormement de temps.
Voilà. Le support SDL n'est pas prévu _pour l'instant_, donc wormux ne pourra pas tourner sans upgrade de ta carte vidéo.

Oups..
C'est corrigé.

Merci!

Venez nombreux!!

J'offrirait personnellement un VERITABLE ver de terre à chaque nouvel arrivant ;)
Si ça c'est pas motivant!