Je suis en train de réaliser un petit logiciel libre de partage de fichiers sur un LAN : Aybabtu[1] (le nom peut changer).
Le but est de réaliser l'application la plus simple possible à utiliser, sans authentification ni serveur central avec les fonctionnalités suivantes :
- Navigation sur les fichiers partagés des autres personnes
- Recherche sur l'ensemble du réseau
- Téléchargement décentralisé
- Un petit chat
N'hésitez pas à donner un maximum d'idées ! En sachant qu'il existe un brainstorming[2], une description fonctionnelle[3] et une maquette de l'interface[4]. Rien n'est figé évidemment, l'implémentation n'a pour l'instant qu'a peine commencé.
[1] : http://dev.euphorik.ch/projects/show/pmp
[2] : http://dev.euphorik.ch/wiki/pmp/Brainstorming
[3] : http://dev.euphorik.ch/wiki/pmp/Functional_definition
[4] : http://dev.euphorik.ch/wiki/pmp/GUI
# Réutiliser l'existant
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
- WebDAV pour la gestion des fichiers ;
- mDSN pour l'annonce de fichiers ;
- XMPP sans serveur (Bonjour) pour la discussion.
[^] # Re: Réutiliser l'existant
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
[^] # Re: Réutiliser l'existant
Posté par Brioche4012 (site web personnel) . Évalué à 2.
[^] # Re: Réutiliser l'existant
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Le transfert de fichiers est prévu sans XML, avec Jingle, par exemple.
[^] # Jake
Posté par davux (site web personnel) . Évalué à 1.
Si quelqu'un a plus de détails sur comment ça marche, voire même des retours d'expérience, explications bienvenues. :)
[^] # Re: Réutiliser l'existant
Posté par Ummon . Évalué à 3.
Néanmoins cette approche n'est pas forcément la meilleure dans tous les cas car elle peut engendrer :
- Plus de dépendance envers des libs/protocoles ;
- De la gestion des versions de celles-ci, intégration dans le processus de build ;
- Des connaissances à acquérir envers celles-ci (et pas des moindre vue l'étendue de certaine) ;
- Des limitations inhérentes liées au fonctionnement de celles-ci. Difficile d'effectuer des modifs pour coller exactement aux besoins ;
- Un 'overhead' à l'exécution ;
- Plus de couches et donc augmentation de la complexité globale.
Pour l'instant la seul lib que j'utilise (mis à par Qt) est Protocol Buffer[1] permettant la définition des messages ainsi que leur sérialisation.
Quels seraient les avantages concrets, dans mon cas, d'utiliser XMPP ?
[1] : http://code.google.com/p/protobuf/
PS: je veux éviter si possible d'utiliser du XML ;)
[^] # Re: Réutiliser l'existant
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
L'interopérabilité. XMPP : pouvoir parler avec des gens qui n'ont pas forcément ton logiciel. WebDAV : pouvoir accéder à des fichiers ainsi partagés si on n'a pas forcément ton logiciel. mDNS : découvrir les répertoires partagés dans son navigateur ou son explorateur sans forcément avoir ton logiciel.
Bref, s'ouvrir au monde, plutôt que de faire un logiciel à tout faire dans son coin, qui le fera très bien, mais seul. Si le courrier électronique avait été inventé comme ça, je ne vous raconte pas la situation qu'on aurait aujourd'hui.
[^] # Re: Réutiliser l'existant
Posté par Ummon . Évalué à 1.
De plus j'aimerai faire les choses suivantes :
- Calculer les 'hashes' des parties composant un fichier et les échanger entre clients ;
- Transmettre qu'une partie de fichier, en gros pouvoir acquérir un fichier à partir de plusieurs hôtes en même temps ;
- Réaliser une recherche sur un ensemble de clients simultanément (actuellement j'utilise du multicast UDP).
Plus d'informations ici (c'est pas forcément très bien décrit, mais c'est un début) : http://dev.euphorik.ch/wiki/pmp/Protocol_core-core
Est-ce que XMPP/WebDAV me permet de réaliser tout ça ? (Je pose cette question de manière naïve, sans connaitre ces protocoles).
[^] # Re: Réutiliser l'existant
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Le format est plus important que le logiciel.
[^] # Re: Réutiliser l'existant
Posté par Ummon . Évalué à 1.
[^] # Re: Réutiliser l'existant
Posté par the_glu . Évalué à 1.
[^] # Re: Réutiliser l'existant
Posté par syntaxerror . Évalué à 2.
Bref, s'ouvrir au monde, plutôt que de faire un logiciel à tout faire dans son coin, qui le fera très bien, mais seul. Si le courrier électronique avait été inventé comme ça, je ne vous raconte pas la situation qu'on aurait aujourd'hui.
Si, ça s'appelle Lotus Notes, et oui cela reste encore compliqué d'échanger avec le monde extérieur.
(et encore je ne te parle pas d'autres systèmes de courrier plus exotiques qui ont existé)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Réutiliser l'existant
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 2.
Pour ton exemple, rien n'empêche de recoder complètement les deux seules choses dont tu as besoin à l'intérieur de la bibliothèque, et cela profite à tous ceux qui utilisent déjà la bibliothèque en question…
Et du coup au lieu d'avoir pléthore de logiciels de partage de fichiers, il y en aurait 3 ou 4 avec une communauté importante, maintenue et avec des améliorations…
Et les utilisateurs ont moins à se prendre la tête pour chercher partout ce que fait le soft, si le projet est vivant, si je préfère telle ou telle fonctionalité (je préfère avoir un chat dans le logiciel comme avec aybabtu, ou je préfère pouvoir utiliser rsync pour les transferts avec unison par exemple)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Réutiliser l'existant
Posté par Rémi Pannequin . Évalué à 1.
Il est simple d'utilisation (et bientôt traduit en français \o/), performant, relativement stable (par rapport à sa jeunesse), et multi-plateforme. C'est du java, donc pas très-très léger, mais ça ne se sent que sur des machines peu puissantes (genre PII 400)...
Après, reste à voir si ton but est de faire trouver un logiciel qui réponde à tes besoin, ou bien si c'est de faire ton propre développement...
[^] # Re: Réutiliser l'existant
Posté par Ummon . Évalué à 2.
Mes buts sont multiples :
* Réaliser un logiciel libre :)
* Réaliser un projet de A à Z
* Essayer de rassembler une équipe
* Répondre exactement à mes besoins
Je pense que réaliser un logiciel de partage pour LAN uniquement entraine quelques choix spécifiques comme par exemple l'utilisation de multicast, la taille des chunks relativement élevée (unité de partage), le "full-trusting" (pas d'authentification), pas besoin de chiffrage, etc..
[^] # Re: Réutiliser l'existant
Posté par Nor Yarod . Évalué à 1.
Il n'a plus l'air d'être maintenu (https://launchpad.net/ubuntu/+source/giver)
CQFD ?
# SMB
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 1.
Genre Partage Windows et Winpopup ?
Il faut peut-être voir du côté de Bonjour d'Apple ou Avahi en FLOSS.
Pour le chat, je ne m'y suis pas plus penché que ça, mais Empathy propose de voir les personnes du réseau local sans configuration, ça semble être basé sur le protocole XEP-0174 (serverless messaging, avec du XMPP)...
# le nom
Posté par bibitte . Évalué à 1.
Si tu veux que ton logiciel ce difuse il faut deja pouvoir retenir et ecrire son nom la ca risque d'être très compliqué.
Tu a surement des bonnes raison d'avoir choisi ce nom, je ne les juge pas. Mais le nom d'un logiciel c'est la première chose que tu vois. alors il doit être clair et entrer dans la tête facilement. Pouvoir le prononcer en anglais serai surement un grand plus.
Voila, sinon bonne chance dans le dev de ton outils.
[^] # Re: le nom
Posté par Ummon . Évalué à 2.
En fait, Aybabtu signifie 'All you bytes are belong to us' :P
J'avais pensé à 'Pumpage' au début : http://dev.euphorik.ch/wiki/pmp/Logo
(d'ailleurs je préfère toujours à Aybabtu, mais des voix se sont élevées contre moi).
[^] # Re: le nom
Posté par bibitte . Évalué à 2.
par contre Aybabtu j'arrive tourjours pas a le prononcer ni a l'ecrire (je fais un copier coller).
'Pumpage' c'est plus simple ca sonne mieu ... tu perds le sens de l'acronyme mais ca se retient mieux. ca fais un peu pompage quand même (les esprit les plus mal tourné imagineron un logo...) .
Bref c'est pas facile de trouvé un nom...
[^] # Re: le nom
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Anéfé, ça serait bien que le nom change…
Bon, alors
- PartLan (ou NalTrap) (le Partage sur Lan)
- SharaLan (Share on a Lan)
- ShaFiLan (Share Files on a Lan)
- Partoo (Partage, version web an 2000)
- Agglo (Agglomération de données)
- UnionServ (Server de données réunies)
- OctoGroupeur (le rassembleur d'octets, avec un logo à la Goldorak)
# Projet similaire
Posté par Maxime (site web personnel) . Évalué à 5.
Les principes :
- Recherche des clients sur le réseau en unicast UDP (le broadcast est désactivé sur le réseau que j'utilise mais j'avais commencé à coder la possibilité de le faire en broadcast).
- Scan des partages FTP et SMB de la machine en local et de quelques machines voisines (IP proche de la mienne). => chaque client possède une base de donnée des fichiers partagés.
- Lors d'une recherche, ton client va contacter un certain nombre de clients pour faire la recherche et ces derniers vont faire pareil avec une notion de TTL pour que ça s'arrete. Communication en xml sur tcp entre les clients.
Ca c'est pour le coeur du programme. Ensuite au niveau interface graphique, on a la recherche générale, la recherche avancée, la recherche dans les partages des gens. On a aussi un explorateur FTP et SMB intégré dans l'application. Gestionnaire de téléchargement intégré.
Possibilité d'activer un serveur FTP intégré à l'appli et depuis l'interface graphique on peut très facilement partager des dossiers qui vont ensuite apparaitre à la racine du ftp.
J'ai résumé très rapidement mais le logiciel est stable, utilisé et apprécié. Il est fait en java (16000 lignes de codes et 95 classes et on utilise de grosses libs pour le ftp et smb).
L'avantage c'est la conservation de protocoles tel que FTP et SMB ce qui fait que tu pourras facilement changer de logiciel si besoin.
Le seul truc qui manque comparé à ton cahier des charges c'est la conversation mais nous on en a pas besoin, on dispose d'un serveur Jabber...
[^] # Re: Projet similaire
Posté par JoeltheLion (site web personnel) . Évalué à 4.
[^] # Re: Projet similaire
Posté par Maxime (site web personnel) . Évalué à 3.
- Scan en unicast parce qu'on a pas de broadcast (pourtant en broadcast ça serait bcp plus simple)
- Scan de notre plage d'IP
- Tuning pour un réseau allant de 50 à 1500 utilisateurs.
- Chaines de caractères en Français
- Code pas super clean, manque de commentaires, archi pas tjs pertinente
- Système de mise à jour automatique (sous windows) dépendant d'un serveur web à nous qui ne supporterait pas une plus grosse charge :D.
Maintenant ça a un peu évolué :
- J'ai testé le scan en broadcast cet été, j'ai un truc fonctionnel mais ce n'est pas intégré à l'appli. Je l'ai fait dans mon plan de rajouter un support des différents réseaux dont certains seraient en broadcast. Finalement on a voulu stabiliser pour faire une version 1.0 en septembre et donc je n'ai pas mergé mon boulot au trunk pour ne pas rajouter de nouvelles features.
- Le scan se fait sur une plage d'IP configurable.
- Le tuning se fait toujours dans le code source même si c'est simple à modifier.
- Tjs pas d'internationalisation de l'appli. Le code et les commentaires sont principalement en anglais mais les chaines de caractère en francais
- On a fait pas mal de refactoring sur le code, c'est mieux. Par contre, niveau commentaires, c'est encore pas mal light.
- Pour la mise à jour auto, ça se désactive... (c'est désactivé sous linux par exemple)
Je n'exclue pas la possibilité de tendre vers une diffusion de ce logiciel que je trouve quand même très utile et qui pourrait donc servir à d'autres personnes. Ça viendra, je suis confiant sur ça.
[^] # Re: Projet similaire
Posté par Maxime (site web personnel) . Évalué à 2.
C'est basé sur l'api java : http://mina.apache.org/ftpserver/ qui disposait alors d'une documentation vraiment ridicule (pour l'anecdote, une fois je cherchais des infos sur une des classes de l'API, et google m'a donné sur la première page le code de mon appli dispo sur notre trac).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.