Journal Application de P2P moderne

Posté par  .
Étiquettes :
-1
10
déc.
2009
Un de mes multiples projet dans le cadre de mes études est de réaliser une application P2P.

Nous sommes en groupes de quatre, et nous devons la rendre fin février.

Évidemment, l'idée n'est pas d'utiliser la libtorrent, mais de redéfinir un protocole simple et efficace dans le but d'apprendre la programmation réseau. Pour le cotés troll, on a le droit d'utiliser la technologie que l'on veut du moment que ça tourne sur linux, mais les cours et tp réseau que l'on fait sont en C# avec mono. Donc, l'application sera en mono :'(

Je viens vous parler de ça, car il faut définir un protocole, et j'aimerais savoir ce que vous aimeriez dans un protocole p2p moderne (post hadopi).

Voici mais premières idées en vrac:
  • Minimaliste
  • Chiffrage obligatoire
  • UDP
  • Autonome (pas de serveur, même pour chercher des fichiers)
  • Liste d'amis de confiance
  • Que hadopi ne soit pas une menace

Évidemment, nous n'aurions surement pas le temps de tout implémenter avant février, car on a d'autres projets en même temps, mais si le protocole est capable de gérer tout ça, se serait super. Puis il sera évidemment sous licence libre, à la fin du projet.

Donc, que proposeriez vous pour un protocole p2p parfait ?
  • # Brevet

    Posté par  . Évalué à 10.

    "Donc, que proposeriez vous pour un protocole p2p parfait ?"

    Ecrit dans un langage sans risque de menace de brevet déja ...
    Pourquoi se préoccuper des menaces d'hadopi si c'est pour utiliser Mono ?
    De plus, pense tu qu'un langage comme mono soit un choix judicieux pour définir un protocole réseau ?



    -- >[], Je reviens dans 4 heures 20 minutes
    • [^] # Re: Brevet

      Posté par  . Évalué à 10.

      Surtout, que vient faire l'histoire du langage de programmation aussi tôt ?!

      Moi, je conseille de suivre le bonne veille méthode suivante pour créer quelque chose :
      1/ faire l'inventaire de tout ce qui existe à propos des protocoles de com' pour le P2P et de sujets connexes ;
      2/ faire des comparaisons avantages/inconvénients ;
      3/ choisir une ou deux technos et combler les manques identifiés selon des buts fixés.

      Pour fixer les buts, c'est bien de connaître les technos du domaine... et ça ne sert à rien de vouloir faire une liste sans fin de fonctionnalités possibles dès le départ. Sauf pour ne jamais la finir.

      Original, n'est-ce pas ?


      Mais dans le fond, j'ai l'impression que les enseignants n'attendent pas un truc compliqué qui essaie, à lui tout seul, de faire papa-maman. Quelque chose de bien architecturé, propre et robuste aura très certainement une bonne note. Il faudrait en parler avec tes enseignants peut-être ?
      • [^] # Re: Brevet

        Posté par  . Évalué à 4.

        Évidemment que j'en parle à mes professeurs, et qu'ils n'attendent pas de leurs élèves de révolutionner le p2p.

        Mais j'ai envi d'aller plus loin, tant qu'à faire. Entre faire un protocole vite fait qui fonctionne et qui nous donne 18, et faire un protocole innovant qui me donne 14 parce qu'il est pas parfaitement implémenté, je préfère la deuxième solution.

        J'ai envi d'avoir quelque chose de qualité qui a fait l'objet d'une réflexion :-)

        Envoyé depuis mon lapin.

        • [^] # Re: Brevet

          Posté par  . Évalué à 1.

          Commence par la mener de ton côté la réflexion, avant de chercher la confrontation d'idées :)
          • [^] # Re: Brevet

            Posté par  . Évalué à 4.

            J'ai envi de partir sur de bonnes bases. En demandant ici ce que la plupart attendent d'un n-ième protocole p2p, cela va nous guider dans la réflexion.

            Faire quelque chose que l'on trouve super, mais qui ne servirait à personne, serait dommage.

            Envoyé depuis mon lapin.

            • [^] # Re: Brevet

              Posté par  (site web personnel) . Évalué à -2.

              Faire quelque chose que l'on trouve super, mais qui ne servirait à personne, serait dommage.

              C'est un projet scolaire, non ?
        • [^] # Re: Brevet

          Posté par  . Évalué à 3.

          Je connais pas tes profs, mais si tu fais transparaitre le côté innovant dans le rapport et le travail de réflexion, ça les intéressera sans doute beaucoup plus que le code.
    • [^] # Re: Brevet

      Posté par  . Évalué à 2.

      Bah pour définir un protocole réseau, il n'y a pas de langage de programmation. C'est pour l'implémentation que mono rentre en scène.

      Et sache que je suis le premier très embêté à devoir utiliser cette technologie. Mais bon, je ne vais pas former trois personnes aux C++ en réseau juste parce qu'aux états unis, il y a des brevets logiciels.

      Si par le plus grand des hasards, notre code doit être utilisé dans un pays où les brevets de microsoft sont en vigueur, il n'auront qu'à réécrire. Par ailleurs, l'implémentation d'un protocole p2p en C# me semble être un gaspillage de ressource, une réécriture sera forcément nécessaire si cela en vaut la peine.

      Envoyé depuis mon lapin.

      • [^] # Re: Brevet

        Posté par  . Évalué à 4.

        Tu ferais alors bien de les former à java, qui a l'avantage (pour vous) de ressembler à C# et pour la communauté d'être un langage libre et librement implémenté.

        D'ailleurs à ce sujet il existe bon nombre de technologies P2P écrites en java (similaire à C# pour ce qui est de performances de leurs implémentations me semble-t-il), donc si la performance était un problème ce serait plutôt au niveau du protocole (d'ailleurs en règle générale les problèmes de performances des applications peer-to-peer sont liées à la limitation de la bande passante).

        Enfin pour répondre à la question de ton journal, nombre de logiciels peer-to-peer regorgent de fonctionnalités à implémenter. Par exemple Freenet (écrit en Java) www.freenetproject.org qui semble à peu près convenir à toutes tes exigences.
        • [^] # Re: Brevet

          Posté par  . Évalué à 2.

          Les trois autres personnes ont tout comme moi des connaissances en java, en C#, et beaucoup en C++. Seulement, la programmation réseau nous a été enseigné qu'en C# pour faire «une technologie de plus».

          Je n'ai pas du tout la prétention de pouvoir les faire passer du C# au C++ et encore moins au java.

          Je sais qu'il existe beaucoup de logiciels java en réseau, qui sont surement plus performants que le C#, mais l'implémentation n'est pas la priorité.

          Envoyé depuis mon lapin.

          • [^] # Re: Brevet

            Posté par  . Évalué à 8.

            Seulement, la programmation réseau nous a été enseigné qu'en C#

            Donc si on ne vous enseigne les boucles qu'en Pascal, vous n'utiliserez pas de boucle dans les autres langages?
        • [^] # Re: Brevet

          Posté par  . Évalué à 2.

          À noter que Freenet s'en sort parfaitement bien avec OpenJRE (OpenJDK), implémentation totalement libre de Java. Testé sur un serveur avec 200 Mo de RAM et des uptimes de plus d'une semaine (pas de fuite de mémoire, pas de pertes de performances, pas de fuite CPU). Donc c'est bien codé :)

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

          • [^] # Re: Brevet

            Posté par  . Évalué à 5.

            Je suis le premier à défendre la JVM, mais "uptimes de plus d'une semaine" n'est pas vraiment un argument satisfaisant...
            • [^] # Re: Brevet

              Posté par  . Évalué à 5.

              Tu es "satisfait" à partir de quelle durée?

              THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

              • [^] # Re: Brevet

                Posté par  . Évalué à 10.

                ça dépend de la partenaire
              • [^] # Re: Brevet

                Posté par  . Évalué à 2.

                Quand on ne parle plus de durée ?

                Plus sérieusement, le problème n'est pas la durée, mais que tu utilises ça comme un argument pour défendre Java (et donc la JVM qui est un truc super à mon avis).
                C'est comme si tu disais d'un dev qu'il était bien parce qu'il avait encore rien cassé : c'est cool mais ça me donne pas envie de l'embaucher… (et encore, si je devais mettre ça dans un ordre du mieux au moins bien, l'ingénieur qui a rien cassé est mieux que l'appli qui tient une semaine).

                Il y a pleins d'arguments super pour défendre la JVM, je ne crois pas que celui-là soit bien pour défendre quoi que ce soit (sauf Windows peut-être…).
                • [^] # Re: Brevet

                  Posté par  . Évalué à 6.

                  Disons que l'argument allait un peu plus loin que "ça tient la route un moment"..
                  Je tenais surtout à préciser que:
                  - du code Java qui tourne avec OpenJDK, c'est possible, et c'est totalement libre (vu que la VM est libre aussi),
                  - non seulement c'est possible, mais ça tourne bien sans pertes de performances avec le temps.

                  Autrement dit, il est possible de créer une application Java qui soit compatible de façon totalement satisfaisante avec une machine 100% libre. Alors que Java était encore, il n'y a pas longtemps, une solution moyennement satisfaisante, dans la mesure où la seule JVM fonctionnelle était propriétaire.

                  Ça mérite d'être précisé, car si par exemple tu fais une appli Flash un peu compliquée, je ne suis pas certain qu'il soit possible de la laisser tourner une semaine avec gnash sans rencontrer de problèmes -il faut dire aussi que Sun est plus coopératif que Adobe-.

                  THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

                  • [^] # Re: Brevet

                    Posté par  . Évalué à 4.

                    Présenté comme ça, je suis entièrement d'accord :)

                    Et j'ajouterais que la JVM est capable de supporter de plus en plus de languages très intéressant (entre autres Scala et Clojure) tout en profitant de l'existant, ce qui en fait un support de dev vraiment super à mes yeux !
        • [^] # Re: Brevet

          Posté par  (site web personnel) . Évalué à 3.

          Sinon, il y a aussi Vala. Avec Vala, y'a plus qu'à ;-)
  • # Idées

    Posté par  . Évalué à 1.

    Tout plein de systèmes de blacklist :
    - Blacklist IP
    - Blacklist geoIP (bloquer toutes les IP chinoises par exemple)
    - Blacklist FAI

    Utiliser un système de noeuds de serveurs décentralisés pour la recherche de clients et de fichiers. cf DHT

    Ne permettre à l'IP du logiciel que d'être envoyé à ceux qui ne sont pas sur les blacklists.
    • [^] # Re: Idées

      Posté par  . Évalué à 2.

      La blacklist d'IP n'est pas forcement une bonne idée, avec son ipfilter.dat eMule en est arrivé a bloquer 50% des ip possibles (enfin ipfilter est un projet à pars d'eMule mais le résultat est là)
    • [^] # Re: Idées

      Posté par  (site web personnel) . Évalué à 4.

      - Blacklist geoIP (bloquer toutes les IP chinoises par exemple)

      Ils ont quoi les chinois ?

      Alexandre COLLIGNON

      • [^] # Re: Idées

        Posté par  (site web personnel) . Évalué à 7.

        Ils bossent au FBI.
      • [^] # Re: Idées

        Posté par  . Évalué à 0.

        La chine est aujourd'hui une des plus grande source d'attaques informatique... bloquer leur ip, c'est un peu se préserver de leurs attaques.
        ça à l'air con, mais sur pas mal de serveurs que j'administre les tentatives d'attaques viennent souvent de chine...
    • [^] # Re: Idées

      Posté par  . Évalué à 3.

      Q : Donc, que proposeriez vous pour un protocole p2p parfait ?

      R :Tout plein de systèmes de blacklist

      ca n'a rien a voir avec le protocole,
      mais plutot une feature du client ca non ?
  • # Quelques idées au hasard

    Posté par  . Évalué à 3.

    Finalement, le streaming est "antihadopi" (et antiDADVSI) dans la mesure où l'utilisateur n'enregistre rien. Problème, les fichiers sont sur des serveurs centraux (qui eux sont couteux et vulnérables).

    Pour moi le P2P ultime serait un P2P streaming. Mais chaque utilisateur ne possède qu'une fraction des fichiers (et pas forcément des fichiers qu'il "consomme"). Une bonne couche de cryptage sur ces fichiers à la freenet et op...

    Enfin, reste à trouver le moyen pour deux machines d'échanger sans avoir la connaissance de l'adresse IP de l'autre. Pourquoi pas s'inspirer de Tor?
    • [^] # Re: Quelques idées au hasard

      Posté par  . Évalué à 3.

      Des entreprises ont reçu des subventions européenne pour développer une solution de streaming P2P.
      http://www.generation-nt.com/ue-europe-p2p-next-tv-bittorren(...)
      • [^] # Re: Quelques idées au hasard

        Posté par  (site web personnel) . Évalué à 1.

        Le streaming p2p (+serveur central) il me semble que c’est précisément ce qu’utilise spotify. Si j’ai bien compris c’est ce qui explique qu’il n’y ai pas de temps de « buffer » quand on lance un morceau.
    • [^] # Re: Quelques idées au hasard

      Posté par  (site web personnel) . Évalué à 3.

      Finalement, le streaming est "antihadopi" (et antiDADVSI) dans la mesure où l'utilisateur n'enregistre rien.

      Heu qu'est-ce que t'en sais ? La seule chose que tu sais c'est que t'envoie un flux de données, qu'il soit redirigé vers un disque dur où un périphérique de sortie audio/vidéo, ou les deux, c'est pareil.
      • [^] # Re: Quelques idées au hasard

        Posté par  . Évalué à 3.

        Tant qu'il ne télécharge pas, ça va!

        =)
      • [^] # Re: Quelques idées au hasard

        Posté par  . Évalué à 2.

        Peut-être d'un point de vue technique, mais du point de vue de nos chers législateur qui n'y captent pratiquement tous rien, c'est pas la même chose !!!

        (Et à la fin on se retrouve avec des DRM pour que la technique rejoigne leur vision : tant qu'ils ne comprendront pas comment ça marche, ils ne voudront pas changer la façon d'aborder le problème et on fera des DRM ou équivalent.)
        • [^] # Re: Quelques idées au hasard

          Posté par  . Évalué à 4.

          Les DRM ne procèdent pas de la vision du législateur, mais de celle du marchand pour qui, à une licence d'utilisation de l'oeuvre vendue, devrait correspondre une et une seule copie numérique. Autrement dit, les DRM visent à "contraindre" une information (copiable à l'infini) à se comporter comme un objet physique (impossible à copier à l'identique).

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

          • [^] # Re: Quelques idées au hasard

            Posté par  . Évalué à 2.

            Je suis d'accord, mais il y aussi l'idée (répandue je pense) que le DRM est la solution technique parfaite pour refléter la vision du législateur.
      • [^] # Re: Quelques idées au hasard

        Posté par  . Évalué à 1.

        Je pensais à la preuve par le disque. À moins que la preuve par le disque signifiait, dans la tête du législateur, la seule possibilité de prouver qu'on a bien installé le logiciel espion (ce qui n'est pas le cas, puisque le CC a cassé cette obligation), c'est bien la possession des fichiers qui constitue la contre façon.
  • # Pour te donner des idées

    Posté par  . Évalué à 7.

    J'ai également un petit projet[1] de logiciel P2P en cours de réalisation à la différence qu'il ne fonctionne uniquement sur un LAN. Le logiciel se veut également assez minimaliste.

    Le protocole est décrit[2] sur le wiki[3], ça peut éventuellement te donner quelques idées.

    Le fait de restreinte un réseau à une liste d'amis de confiance s'appelle du F2F[4] (friend-to-friend), plusieurs logiciels existent déjà, comme par exemple OneSworm[5] ou AllianceP2P[6], ça peut également te donner des idées.

    [1] : http://dev.euphorik.ch/projects/show/pmp
    [2] : http://dev.euphorik.ch/wiki/pmp/Protocol_core-core
    [3] : http://dev.euphorik.ch/wiki/pmp
    [4] : http://en.wikipedia.org/wiki/Friend_to_friend
    [5] : http://oneswarm.cs.washington.edu/
    [6] : http://www.alliancep2p.com/
  • # Pourquoi une "Application"...

    Posté par  . Évalué à 6.

    Il y a nombre d'applications de P2P diverses et variées, leur but final ne varie pas tant que ça (il y a évidemment des exceptions).

    Ce qui pourrait être intéressant, c'est que votre protocole P2P, plutôt que de penser "fichier-de-toi-à-moi", se présente comme un protocole de transport. Une bibliothèque que l'on pourrait utiliser dans des applications variées...

    Le protocole, outre les fonctionnalités que tu suggèrent, devrait permettre un repérage sûr des noeuds: une clé plutôt qu'une IP (ça entre dans le cadre "hadopi ne soit pas une menace").
    (et par conséquent permettre de construire des tunnels, mais je pense que ce serait très ambitieux comme approche...).
    Dans l'idée la plus simple, un dictionnaire ("table de hachage") distribué est une bonne idée.

    Après, puisqu'il faudra sans doute rendre une application "c'est zoliii: je clique sur un bouton pour avoir un fichier", un front-end employant ce protocole à titre d'exemple.

    Des recherches dans ce sens (étendre le P2P à autre chose que des fichiers [sans jouer sur les termes]) me paraissent plus intéressantes qu'une n-ième réinvention de la roue...
    • [^] # Re: Pourquoi une "Application"...

      Posté par  . Évalué à 1.

      Ta description ressemble furieusement à i2p, c'est fait exprès ?
      • [^] # Re: Pourquoi une "Application"...

        Posté par  . Évalué à 1.

        Oui elle y ressemble, fait exprès... pas tout à fait :).

        L'idée d'i2p est à mon avis séduisante. Un peu de concurrence dans le domaine en plus ne ferait pas de mal. Sans vouloir décourager notre ami étudiant, un environnement P2P complet (j'entends protocole bien défini, bien implémenté et suffisament fonctionnel pour être immédiatement attractif) et mêlant autant de domaines technologiques (chiffrement, authentification, mais aussi indexation, calcul distribué, routage... communs aux technologies P2P moderne), c'est difficile à achever en aussi peu de temps...

        Donc avec la volonté qu'il affiche de fournir un travail "bien fait et innovant", je me dis que s'attaquer à une partie restreinte du (gros) problème est plus sujet à innovation.
        Copier i2p n'est pas idéal non plus, juste innover :).
  • # Remets Hadopi où tu l'as trouvé, merci.

    Posté par  . Évalué à 10.

    Hadopi est une menace pour les libertés fondamentales en France, ne serait-ce qu'en créant un dangereux précédent, et ton application n'y changera rien.

    Hadopi est une menace pour tous les internautes, étant donné le risque d'erreurs, et ton application n'y changera rien.

    Hadopi est une menace pour les internautes qui n'ont pas une connaissance approfondie de la sécurité informatique, car ils se verront imposer l'installation d'un logiciel payant si leur voisin sait se servir de BackTrack, et... ton application n'y changera rien!

    Hadopi est une menace pour le logiciel libre, car tout internaute pourra se voir imposer l'installation d'un logiciel propriétaire conçu par un éditeur privé, ce qui représente un recul considérable des libertés que le logiciel libre défend, et ton application n'y changera rien!

    Hadopi est une menace pour les technologies de P2P elles-mêmes, car le simple fait qu'il soit impossible de déterminer de façon algorithmique l'origine légale ou non d'une suite d'octets possiblement chiffrés fait que le mouchard Hadopi bloquera toute application susceptible d'utiliser un protocole de P2P (sauf Skype, et encore.. il est bien filtré en Chine), et ton application subira le même sort que les autres!

    Finalement, tout ce que ton application peut changer aux nombreuses menaces que représente Hadopi, c'est celle-ci: ton application permettra peut-être le téléchargement illégal d'oeuvres dont Hadopi sera chargée de punir la contrefaçon.

    Faut-il en déduire que tu envisages déjà le fait que ton application sera utilisée dans le but d'effectuer des téléchargements illégaux?

    Sérieusement, ça serait cool d'éviter d'assimiler de façon implicite et quasi-systématique l'opposition à Hadopi et le fait de militer pour la légalisation d'échanges aujourd'hui illégaux.

    En tant qu'opposant à Hadopi, mais également totalement respectueux des choix, mêmes très mauvais, faits par les artistes et leurs ayants-droits (moi pas aimer Hadopi, moi pas faire P2P illégal, mais faire que P2P légal), je m'énerve chaque fois que je vois ce raccourci "impossible de surveiller nos échanges de warez = Hadopi ne nous dérange plus."
    Premièrement, parce n'importe quel internaute français devrait se sentir concerné et menacé par Hadopi, indépendamment de la façon dont il utilise sa connection,
    Deuxièmement, parce qu'Hadopi restera une menace quels que soient les moyens techniques que l'on mette en oeuvre pour masquer nos activités. Car, même pour n'utiliser que Freenet ou TOR, il faut avoir une adresse IP attribuée par un FAI français, ce qui implique d'être une victime potentielle de Hadopi.

    Je serais peut-être un jour victime de Hadopi. Toi aussi, peut-être. Mais ton application n'y changerait pas grand chose. En ce qui me concerne, elle ne changera même strictement rien.

    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: Remets Hadopi où tu l'as trouvé, merci.

      Posté par  . Évalué à 6.

      Le but de mon application n'est pas d'échanger des fichiers illégaux, mais d'échanger des fichiers sans se faire espionner. La différence est importante, et ce qui nous dérange dans hadopi est la même chose.

      Après, qu'elle ne change rien en général, j'en ai rien à faire, je veut juste être tranquille pour l'échange de fichiers avec mes amis.

      Envoyé depuis mon lapin.

      • [^] # Re: Remets Hadopi où tu l'as trouvé, merci.

        Posté par  . Évalué à 3.

        Hadopi ne t'empêchera pas plus d'échanger des fichiers avec tes amis si tu utilises du P2P chiffré ou des torrents.

        De toute façon, il n'est même pas prévu que les agents assermentés téléchargent le fichier incriminé avant d'accuser quelqu'un.

        Du reste, pour de l'échange avec des amis, mieux vaut cibler une application de "F2F" (Friend To Friend). Car dans un réseau de P2P ouvert à tous, n'importe qui peut déjà t'espionner.
        Ou, encore mieux, GPG te permet de rendre totalement confidentielles tes échanges inter-personnelles.

        Sinon y'a Freenet, mais tu veux échanger avec tes amis, et Freenet est plutôt fait pour échanger avec des inconnus ;D

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: Remets Hadopi où tu l'as trouvé, merci.

      Posté par  . Évalué à -3.

      Faut-il en déduire que tu envisages déjà le fait que ton application sera utilisée dans le but d'effectuer des téléchargements illégaux?

      Pour quoi utilises-tu exactement de ton application p2p préférée ? (par curiosité)

      Libre, photos de vacances, domaine public ? Porno (dont la plupart se retrouvent là illégalement aussi, ça n'a pas l'air d'intéresser les députés) ? Jamais un film ou un album copyrighté ? Jette la première pierre.
      • [^] # Re: Remets Hadopi où tu l'as trouvé, merci.

        Posté par  . Évalué à 4.

        Pourquoi avoir besoin d'un logiciel de P2P pour écouter sa musique ou regarder tes films ?

        Sans parler des sites pourris comme Deezer (pas du tout accessible), tu peux acheter ta musique et tes films et respecter le droit d'auteurs.

        Le respect des droits d'auteurs est une chose primordial dans le monde du Libre. Sans se respect, pas de Libre. Et les gens qui sont capable de dire « HADOPI tue le libre » et par la suite aller DL le dernier screener sur guiks sont des cons.
      • [^] # Re: Remets Hadopi où tu l'as trouvé, merci.

        Posté par  . Évalué à 6.

        Libre
        Oui, principalement des ISO de distros, pas forcément des distros que j'utilise d'ailleurs (Ubuntu..), je le fais pour "seeder" et rendre service.
        Des vidéos explicitement placées sous licence libre, aussi (conférences de B. Bayart par exemple), ou plus généralement dont la licence me permet de les partager, et dont je trouve qu'il est intéressant de les partager: les débats à l'AN par exemple.
        ( Voir la section "Droit d'auteur": http://www.assemblee-nationale.fr/faq.asp )
        photos de vacances
        Non, c'est plutôt le genre de trucs que j'échange directement, de personne à personne, par exemple en envoyant un lien http vers le .zip, par mail. Ça ne me viendrait pas à l'idée de balancer mes photos de vacances sur un site accessible au premier venu, déjà que ça me contrarie un peu d'envoyer le lien sur des adresses Gmail (même si pour l'instant Google n'a jamais fait de requête GET louche sur un lien envoyé via Gmail, je vérifie les logs sur ce genre de trucs).

        domaine public

        "domaine public" c'est inclu dans "libre", vu que tout ce qui est dans le domaine public est libre (mais pas vice-versa).
        Jamais un film ou un album copyrighté ?
        Ça fait longtemps que je n'ai pas téléchargé une oeuvre dont la licence m'interdit de le faire. Je n'irais pas pour autant "jeter des pierres" aux gens qui font encore cela, mais je partage mon point de vue afin d'amener d'autres personnes à renoncer aux films et albums copyrightés par les méchants qui veulent tuer Internet.
        C'est exactement comme pour les logiciels: y'a un moment où t'es tout content de pouvoir télécharger WIndows XP cracké sans avoir besoin d'acheter une licence, puis tu réfléchis un peu et tu te dis que le meilleur service à rendre aux oeuvres libres est de ne pas toucher aux oeuvres propriétaires. C'est une question d'éthique et surtout de cohérence: comment peut-on défendre le libre et les licences copyleft tout en ne respectant pas une licence qui ne va pas dans "notre sens", comment peut-on présenter le libre comme une alternative viable au modèle propriétaire si on se gave dans le même temps de contenu propriétaire?

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: Remets Hadopi où tu l'as trouvé, merci.

      Posté par  . Évalué à 7.

      "Howto: comment défoncer des portes ouvertes"
      " Chapitre 1: Parler d'un sujet avec des gens qui sont déjà d'accord avec vous"
      " Paragraphe A: Exemple: « HADOPI saymal, discussion avec LQDN »"
      " Chapitre 2: Parler d'un sujet parfaitement convenu"
      " Paragraphe A: Exemple: « Je suis contre le racisme et la pauvreté »"
      " Paragraphe B: Exemple: « L'écologie c'est bien, je suis contre la pollution »"
      " Paragraphe C: Exemple: « Les maladies, c'est pas bien »"

      Certaines personnes appellent cela "être démagogue".

      Ceci dit, je vois toujours pas le rapport entre HADOPI et P2P, dixit yellowiscool.
  • # Marrant

    Posté par  . Évalué à 1.

    Tiens, c'est marrant, mais je dois faire exactement pareil en cours ;)

    Sauf que nous on doit le faire en java (:(), en TCP et pas de chiffrage...
    • [^] # Re: Marrant

      Posté par  . Évalué à 2.

      En fait, on a pas mal de libertés, le sujet est le suivant:

      Vous devez réaliser une application pair à pair (P2P) dédiée au partage de fichiers (légaux).

      Vous avez le droit de vous inspirer de protocoles déjà existant, mais en aucun cas, vous ne devez les ré-implémenter.


      J'ai presque envi de la faire en C++ :-)

      Envoyé depuis mon lapin.

      • [^] # Re: Marrant

        Posté par  . Évalué à 1.

        En même temps, normalement, si tes specs sont bien faites et que tu ne fais pas quelque chose de spécifique à un langage en particulier, tu pourras l'implémenter dans n'importe quel langage ;)

        Je trouve que le c++ ou simplement le c, c'est une bonne idée... Je trouve que ces langages son "agréable" pour ce genre de "d'application".
        • [^] # Re: Marrant

          Posté par  . Évalué à 1.

          Et avec une couche d'abstraction adéquate le travail pourra aisément être porté d'une plateforme à l'autre (peu de plateformes refusent le C89, non ?).
        • [^] # Re: Marrant

          Posté par  (site web personnel) . Évalué à 5.

          Je trouve que le c++ ou simplement le c, c'est une bonne idée... Je trouve que ces langages son *agréable* pour ce genre d'application.

          T'as pas encore du croiser Python alors.
          • [^] # Re: Marrant

            Posté par  . Évalué à 2.

            Si si, Python c'est cool...

            Mais le c c'est mieux! (on est bien vendredi non? ;) )
          • [^] # Re: Marrant

            Posté par  . Évalué à 2.

            désolé, mais pour avoir bossé sur des gros projets avec python, du faire des merges, relire du code, en écrire, j'en suis arrivé à la conclusion qu'il n'est pas adaptés à de gros projets.

            Il est très bien pour les petits utilitaires, pour les machins où on est tout seul sur un fichier, mais dès qu'il y a de l'édition concurrente, ça fout la zone lors des merges, lorsq'une fonction/classe dépasse la hauteur de l'écran rien ne va plus.

            ça tient pourtant à pas grand chose : déclaration implicite et blocs déterminés par l'indentation.

            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

            • [^] # Re: Marrant

              Posté par  . Évalué à 5.

              [..]du faire des merges,[..]
              Tu fais des 'merges' à la main ? Utilises-tu un gestionnaire de versions ? (git, mercurial, etc..)

              [..]relire du code[..]
              N'est-ce justement pas une des forces de Python que d'être concis et lisible ?

              [..]mais dès qu'il y a de l'édition concurrente, ça fout la zone lors des merges,[..]
              Évidemment, la répartition du type "toi tu t'occupe des if et moi des for" n'est pas forcément la bonne approche.

              [..]lorsq'une fonction/classe dépasse la hauteur de l'écran rien ne va plus.
              Ton éditeur doit certainement avoir un bidule sur la droite que l'on appelle vulgairement "ascenseur".
              • [^] # Re: Marrant

                Posté par  . Évalué à 4.

                Tu fais des 'merges' à la main ? Utilises-tu un gestionnaire de versions ? (git, mercurial, etc..)
                J'ai testé les merges auto de svn, synergy, c'est juste bon a faire des boulettes monumentales. Il faut tout se farcir à la main.

                N'est-ce justement pas une des forces de Python que d'être concis et lisible ?
                être typé dynamiquement peut être très dommageable pour la lecture du code.

                Évidemment, la répartition du type "toi tu t'occupe des if et moi des for" n'est pas forcément la bonne approche.
                Si tu pouvais avant de faire une évolution prédire exactement quels fichiers tu allais impacter, et précisément les ligne, ça pourrait être gérable, et encore faut pas avoir de branches.

                Ton éditeur doit certainement avoir un bidule sur la droite que l'on appelle vulgairement "ascenseur".
                et? ça me fait une belle jambe, le gars à codé comme un porc, et quand un bloc dépasse la hauteur de l'écran l'ascenseur et limite pire que le mal. Savoir où débute (ou se termine) un bloc, si il dépasse la hauteur de l'écran, c'est galère.

                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                • [^] # Re: Marrant

                  Posté par  . Évalué à 3.

                  Le problème du "gars qui a codé comme un porc" posera problème dans n'importe quel langage.

                  Par contre je te rejoins sur le coté dynamique qui peut entrainer des difficultés sur les moyens/gros projets.
                  • [^] # Re: Marrant

                    Posté par  . Évalué à 4.

                    Le problème du "gars qui a codé comme un porc" posera problème dans n'importe quel langage.

                    Oui mais en python, le gars qui code comme un porc est plus dommageable qu'en C, C++, java... (encore que des goto en C y 'en a qui le font)

                    Le fait que les variables soient déclarées implicitement, et la détermination des blocs par indentation, donne une autre dimension au nuisible.

                    Et encore je ne te parles pas des boulets qui mixent tabulation et espaces, et qui se foutent royalement du gros warning.

                    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                    • [^] # Re: Marrant

                      Posté par  . Évalué à 1.

                      J'avais posté ça ya quelques temps : http://linuxfr.org/comments/1073189.html#1073189

                      Je me suis cassé les dents sur du code écrit en C/C++ et bourré de macros comme celle ci...
                    • [^] # Re: Marrant

                      Posté par  . Évalué à 8.

                      Faudrait voir à arrêter avec ces histoires de goto en C, c'est encore ce qu'il y a de plus propre pour la gestion d'erreur quand on doit annuler une liste d'actions.
                      • [^] # Re: Marrant

                        Posté par  . Évalué à 3.

                        Ca depend, si tu sors juste d'un IUT, ecole d'inge ou autre, que tu viens de lire un bouquin apprendre le C++ en 21 jours et que ton experience au niveau developpement se resume a 2/3 projets en groupe de quelques semaines, ca peut se comprendre.

                        Repeter betement des generalites, c'est humain, tout le monde le fait. Apres generalement, t'apprends et tu te dis, putain mais qu'est ce que j'etais con quand j'etais jeune!
                      • [^] # Re: Marrant

                        Posté par  (site web personnel) . Évalué à 2.

                        Dans les premiers cours de programmation, on apprend aux élèves les règles suivantes :
                        - pas de goto ;
                        - un seul return ;
                        - les variables sont a déclarées en haut du bloc.

                        Cela peut paraître con mais au début il faut limiter la dispersion des élèves et les aider à se concentrer sur les points importants. Ces règles permettent entre autres d'éviter que les élèves se perdent dans la logique d'exécution de leur programme.

                        Une fois que petit padawan devient jedi, il a le droit de faire ce qu'il veut mais avant de marcher sur ses pattes arrières, il aura d'abord gambader à 4 pattes !

                        Alexandre COLLIGNON

                        • [^] # Re: Marrant

                          Posté par  . Évalué à 4.

                          Se limiter à un seul "return", je trouve ça complètement idiot (pour ne pas dire autre chose), ça permet d'éjecter les erreurs sur les paramètres en début de fonction.

                          Je préfère largement:


                          int blabla(char *path,int truc)
                          {
                          if (!path)
                          return(-1);

                          /* traitement */
                          return(...);
                          }


                          à qqch dans ce style:


                          int blabla(char *path,int truc)
                          {
                          int res;

                          if (!path) {
                          res = -1;
                          } else {
                          /* Traitement */
                          res = ...;
                          }

                          return(res);
                          }
                          • [^] # Re: Marrant

                            Posté par  . Évalué à 2.

                            je ne pense pas que le monsieur dessus te contredise, mais faut bien lire ce qu'il a écrit.

                            Si tu ne donnes pas de consignes strictes aux élèves tu te retrouve avec un plat de spaghettis bourré de goto, return, break, continue, switch imbriqué dans d'autres switch dans un for faisant 10 écrans de 60 lignes (environ 600 lignes donc).

                            Quand le nuisible à enfin appris à écrire du code propre, il peut enfin prendre des libertés avec les consignes de bases (et il vaut mieux). Si tu le laisse sans bornes, tu finis avec un machin non maintenable.

                            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                            • [^] # Re: Marrant

                              Posté par  . Évalué à 2.

                              Si, j'ai bien compris l'idée, mais bon, j'ai pu remarquer que le pb des élèves, ce n'est pas tellement les histoires de goto ou de return, mais principalement l'indentation et l'imbrication à outrance comme tu le signales.

                              Pour l'indentation, si on les laisse faire, on se retrouve avec des pâtés de n'importe quoi, je ne sais même pas comment ils font pour s'y retrouver eux-mêmes (bon en fait si je sais: ils ne s'y retrouvent pas quand il s'agit de finir le TD chez eux). Le pire étant ceux qui mettent tout au même niveau.

                              Pourtant, pour l'indentation, l'imbrication et la longueur des fonctions, un peu de bon sens suffit.
                          • [^] # Re: Marrant

                            Posté par  (site web personnel) . Évalué à 3.

                            Je code tous les jours selon la méthode que tu conseilles :


                            if (!path)
                            return(-1);


                            Mais je te garantie que si tu ne veux pas perdre la moitié de ta classe lors du premier cours de "structure conditionnelle" dans une fonction il est préférable de faire selon la méthode


                            if (!path) {
                            res = -1;
                            } else {
                            /* Traitement */
                            res = ...;
                            }

                            return(res);


                            Après dans la vie de tous les jours, j'aimerai pendre à un croc de boucher ceux qui font cela car on arrive souvent à produire des forêts de If.

                            p.s: les forêts de If c'est juste intéressant pour les facteurs d'arcs.

                            Alexandre COLLIGNON

                        • [^] # Re: Marrant

                          Posté par  . Évalué à 2.

                          mais alors par contre, le continue remplace allègrement le goto . :(

                          Sedullus dux et princeps Lemovicum occiditur

      • [^] # Re: Marrant

        Posté par  (site web personnel) . Évalué à 8.

        Et si au lieu de mettre l'accent sur la confrontation a hadopi, tu mettais l'accent sur le "partage de fichiers (légaux)" ?

        Je pense a un P2P qui forcerait l'utilisateur qui met un fichier a disposition a en déclarer la licence, qui serait exposé par le protocole aux autres paires. L'application ne partagerait que les fichiers dont la licence a été spécifié. On peut imaginer ensuite d'implémenter des heuristiques de détections de licences (par exemple dans les métadonnés des mp3, ogg, etc. (je crois que Jamendo par exemple tag la licence dans ses fichiers), ou en explorant les ISO, zip etc. a la recherche de fichiers LICENCE).

        On peut même aller plus loin et carrément devenir HADOPI-friendly (brrr, je suis sale le vendredi :) ) en forçant l'utilisateur a signer un fichier dont il spécifie la licence.

        Ainsi, si tu télécharge un mp3 de Didier Barbelivien qui était tagé comme étant en CC-by-sa et que la HADOPI te tombe dessus, tu peux toujours plaider la bonne foi, en disant que c'est Toto, le bulgare qui a mis ce fichier a disposition, qui t'a abusé en spécifiant une licence incorrecte, et que tu n'est qu'une innocente victime dans cette sombre histoire.
  • # outils & usages

    Posté par  (Mastodon) . Évalué à 3.

    >Donc, que proposeriez vous pour un protocole p2p parfait ?
    je sais que ça va être hors sujet, dans la mesure ou un protocole n'est qu'un outil. Seule l'utilisation de l'outil est respectable et/ou condomnable... mais bon juste pour le fun :
    Un protocole qui ne permette jamais de récuperer la globalité d'un fichier... Juste pour faire chier les juristes pro-hadopi... Justement pour rappeler qu'un outil n'est qu'un outil, et que ce n'est parceque j'ai le permis de conduire que je vais aller écraser volontairement quelqu'un avec ma voiture.
    • [^] # Re: outils & usages

      Posté par  . Évalué à 3.

      Un protocole qui ne permette jamais de récuperer la globalité d'un fichier.
      Un bit sur deux, comme ça t'es certain que le seul reproche qu'on te fera, c'est de gaspiller de la bande passante en l'utilisant.

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: outils & usages

        Posté par  . Évalué à 2.

        Avec des idées un peu tordues comme ça, il y a bien eu OFFSystem...
        Mais là, un protocole volontairement inutilisable ne montrera pas qu'on peut faire autre chose que "pirater" avec ces technologies...
        • [^] # Re: outils & usages

          Posté par  . Évalué à 2.

          Je ne comprends pas comment OFFSystem peut fonctionner..
          il faut stocker en local autant de volume de données, sous forme de clefs, pour lire un volume égal de données chiffrés stockées "dans le nuage", non?
          Autrement dit, si un bloc A aléatoire de taille T représente des données B de taille T grâce à la clef C de taille T, je devrais faire:
          A XOR C => B, afin de retrouver les données B après avoir téléchargé le bloc aléatoire A.
          Et stocker chez moi la clef C.
          Ça ne sert à rien alors, si? Autant stocker directement B..

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: outils & usages

      Posté par  . Évalué à 1.

      je ne sais pas si le legislateur va prendre soin de verifier si tu a bien recuperé 100% des octets...
      a mon avis il y aura une constatation d'une infraction (DL en cours, partage d'une partie de fichier)
      et même on n'en sera pas grand choses,, je ne suis même pas sur qu'il stipule e qu'ils otn sencé avoir constaté (nom de l'oeuvre)

      sinon, j'ai pas du tout comprendre, mais quel est l'interet de ta proposition puisque on ne peut pas exploiter le fichier ainsi telechargé ?...
  • # Pourquoi UDP ?

    Posté par  . Évalué à 2.

    Dans tes idées en vrac, pourquoi partir immédiatement vers UDP ? Un protocole sans gestion de la congestion, ça risque d'être drôle en P2P.

    Cette absence de contrôle de la congestion rend dans les faits l'UDP « prioritaire » sur TCP (qui lui, quand c'est plein, s'arrête). Ça peut-être désastreux pour toutes les autres applications de l'utilisateur (notamment si tu satures son upload, ce qui est assez facile à faire avec de l'ADSL).

    Ensuite quand tu parles de P2P, pourquoi immédiatement songer au téléchargement de fichier ? Il existe de jolis projets, par exemple Pastis : http://www.irit.fr/GPMC/Talk-BUSCA.pdf
    Mieux que télécharger, mettre en commun un système de fichier, je trouve ça énorme.
    • [^] # Re: Pourquoi UDP ?

      Posté par  . Évalué à 3.

      Au contraire, UDP est une très bonne idée, pour lutter contre la tendance qu'on les opérateurs à filtrer/brider/bloquer/ralentir les protocoles de P2P basés sur TCP, comme BitTorrent.
      UDP leur compliquerait ce sale boulot, surtout si tu rajoutes une dose de chiffrement.

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: Pourquoi UDP ?

        Posté par  . Évalué à 4.

        Peux tu expliquer quel est le rapport entre le fait qu'un opérateur puisse vouloir filtrer un protocole P2P et le fait qu'il soit sur TCP ? En quoi un protocole reposant sur UDP serait techniquement plus difficile à filtrer ou en quoi le fait que ce soit du TCP/UDP pourrait changer la politique de l'opérateur ?

        Je rejoins le commentaire du dessus. Développer un protocole en UDP il faut vraiment avoir de bonnes raisons de le faire et une très bonne connaissance en protocole réseau. Tu te retrouves à réimplanter beaucoup de fonctions de TCP et c'est totalement hors de porté de nos 4 étudiants (ou alors tu fais un gros protocole moisi qui nique tout le réseau ou qui fonctionne carrément moins bien).


        Autrement c'est un projet étudiant de deux mois, rêvez pas trop. Je pense que le but de l'exercice c'est de savoir écrire un client/serveur correctement et il y a déjà beaucoup à faire (surtout si le simple fait de passer de C# à Java ou C vous pose problème). Écrire un protocole réseau correct, c'est je pense; hors sujet, un peu hors de votre portée et surtout d'ici un mois t'aura à peine fini ton état de l'art sur les protocoles existants. Là tu pourras commencer à réfléchir à concevoir quelque chose, puis le coder...
        Bref sois tu t'inventes un jouet, soit tu fais du vrai boulot d'ingé c'est à dire faire une implémentation robuste de specs qui existent déjà. Comprendre les objectifs d'un travail/exercice, c'est aussi important...
        • [^] # Re: Pourquoi UDP ?

          Posté par  . Évalué à 5.

          La difficulté de brider les connexions UDP n'est as forcément technique, mais aussi politique : si les FAI se mettent à filtrer les flux UDP chiffrés qui sortent sur des ports exotiques, ça va râler ferme chez les joueurs en ligne, les mêmes qui achètent les lignes chères avec un ping de la mort qui tue. Idem avec les flux du style voIP (skype & Co) ou streaming...
    • [^] # Re: Pourquoi UDP ?

      Posté par  . Évalué à 0.

      J'ai pensé à l'UDP car dans une trame d'un protocole p2p, il me semble qu'il faille obligatoirement indiquer une position et une somme de contrôle. Utiliser le TCP fait ces deux choses, mais dans le cadre d'une communication client/serveur, et pas dans un cadre pair à pair.

      Envoyé depuis mon lapin.

      • [^] # Re: Pourquoi UDP ?

        Posté par  . Évalué à 4.

        Ce que tu dis ne veux absolument rien dire.

        Tu mélanges allègrement couche 4 et couche 7. Toute communication réseau est point à point et client/serveur (on oublie le multicast on est sur Internet). La couche transport, TCP ou UDP, te permet juste d'envoyer des données d'un point A à un point B. Y'en a un des deux qui initie la connexion, le client, et l'autre qui écoute, le serveur. Après c'est de la logique applicative de savoir si tu fais du p2p ou du client/serveur mais tes communications sont toujours pap et client/serveur.
        Tu confonds aussi checksum et offset couche transport et applicative.

        Pour du transport de donnée les services qu'offrent TCP sont très adaptés: contrôle de flux, contrôle de congestion, connexion fiable. Tu as besoin de ces mécanismes et tu n'arriveras pas à égaler 1/10 de la qualité de TCP tant au niveau design qu'implémentation. Pour faire très simple on passe en UDP quand on se fou de la fiabilité ou qu'on préfère l'assurer au niveau applicatif (streaming, jeux vidéos etc.).

        Bref fais quelque chose de très simple par ce que tu semble partir de très loin en réseau. De plus les algorithmes applicatifs de P2P c'est un tout autre domaine qui n'a aucun rapport à la programmation réseau, et ça n'a rien de trivial (il y a de très bon papier sur l'analyse et le fonctionnement du protocole bittorrent par exemple) .
        • [^] # Re: Pourquoi UDP ?

          Posté par  . Évalué à 1.

          Je te la fais simple: les mécanismes qu'offre TCP par rapport à IP ne me sont pas utiles, car ils sont dupliqués par rapport à ceux que je dois forcément implémenter dans mon protocole. D'où l'envie d'utiliser UDP.

          Puis c'est pas comme si certains on pensé à passer bittorent en udp il n'y a pas si longtemps hein…

          Envoyé depuis mon lapin.

          • [^] # Re: Pourquoi UDP ?

            Posté par  . Évalué à 5.

            > Je te la fais simple: les mécanismes qu'offre TCP par rapport à IP ne me sont pas utiles, car ils sont dupliqués par rapport à ceux que je dois forcément implémenter dans mon protocole

            Ton protocole peut aussi simplement utiliser les services par la couche transport comme tout le monde. Tu peux me donner la liste des services qui sont dommageables pour ton utilisation, celle des services que tu vas devoir réimplementer, et en quoi ce que tu vas niveau applicatif sera redondant ou meilleur que ce que fourni TCP ?

            (Étant donné que tu n'as même pas de spec fonctionnelles de ton produit, cela me semble assez étrange)

            > Puis c'est pas comme si certains on pensé à passer bittorent en udp il n'y a pas si longtemps hein…

            Je n'ai pas dit que c'était stupide d'utiliser UDP. J'ai dit qu'il est stupide d'utiliser UDP sans bonne raison et que ça demande beaucoup de connaissances, d'expériences, et de temps pour faire un protocole potable. Et afaik tu n'as aucun des trois. Fait un protocole merdique en UDP et au mieux tu vas trasher tout les réseaux que tu traverse...

            Puisque tu parles d'uTP. Tu peux m'expliquer en quoi ce protocole est pertinent (il l'est) et les problème qu'il essai d'adresser ? Après des analyses que j'ai vu (puisque le protocole n'est pas publique) c'est pas non plus brillant uTP, et pourtant les mecs sont pas des billes. On peut en discuter quand tu auras répondu a ma question.

            Après si tu penses pouvoir abattre ce travail en 2 mois... Pense tout de même a décider des specs de ton produit avant d'avoir un avis arrêté sur les solutions techniques à utiliser. Utiliser TCP par défaut, c'est juste du bon sens.
          • [^] # Re: Pourquoi UDP ?

            Posté par  . Évalué à 4.

            > Puis c'est pas comme si certains on pensé à passer bittorent en udp il n'y a pas si longtemps hein…

            Avec les débats sur la congestion non maîtrisée que l'on connaît. L'uTP n'est actuellement pas une réponse, l'IETF est très loin d'avoir publiée une RFC à ce sujet.

            Mon premier message était juste une mise en garde, tu ne semble pas avoir énormément de recul sur le fonctionnement des protocoles réseaux. Ne pas utiliser TCP car le checksum est obligatoire contrairement en UDP ou il n'est qu'optionnel (et encore, checksum obligatoire en IPv6), ça manque de pertinence comme argument. Le numéro de séquence, c'est encore pire avec un énorme mélange des couches. Tu risques d'avoir besoin d'un numéro de séquence au niveau applicatif qui n'aura strictement rien à voir avec le numéro de séquence de la connexion TCP, les deux n'ont pas le même rôle.
  • # Hum

    Posté par  (site web personnel) . Évalué à 3.

    >> # Liste d'amis de confiance

    Je fais confiance à Paul.
    Paul accepte n'importe quoi de n'importe qui.
    Par transitivité, je fais confiance à n'importe qui.


    Dans ton P2P, tu peux jouer à TOR.

    Dans ton P2P, pour "inciter" les gens à partager, tu peux crypter les données sur disque, et les déchiffrer uniquement quand l'utilisateur a dépassé un ratio de 1, ou quand le nombre de clients est inférieur à N (genre, si t'es le dernier à télécharger, tu veux pouvoir lire tes données quand même, toi aussi)

    Dans ton P2P, tu peux associer une priorité différente aux morceaux qui composent ton fichier (par exemple, tu peux vouloir télécharger d'abord le début du fichier, avec les headers)
    • [^] # Re: Hum

      Posté par  (site web personnel) . Évalué à 2.


      >> # Liste d'amis de confiance

      Je fais confiance à Paul.
      Paul accepte n'importe quoi de n'importe qui.
      Par transitivité, je fais confiance à n'importe qui.


      Sur le logiciel OneSwarm il y un système d'amis limité ou non:
      Un ami non limité vois votre liste de fichiers.

      Un amis limité peut télécharger vos fichiers, mais ne saura jamais si ces fichiers viennent de chez vous ou de l'ami d'un ami d'un ami....

      Un client peut servir de passerelle entre 2 amis qui eux ne se connaissent pas et en passant par plusieurs nœuds successif on peut échanger avec presque tous les utilisateurs du réseau.

      Tous les échanges sont cryptés.

      [http://www.korben.info/oneswarm-telecharger-sur-bittorrent-e(...)]
    • [^] # Re: Hum

      Posté par  (site web personnel) . Évalué à 3.

      Je pensais comme ça... Pourquoi ne pas associer des niveaux de confiance ?

      Par défaut, quand j'ajoute un ami, il a un niveau de confiance de 50%. Je peux décider de faire confiance plus ou moins aux gens que j'ajoute.
      Les amis de cet ami, je vais leur faire confiance avec un niveau de 0.50 * confiance fixée par cet ami.
      Et je ne tiens compte que de ceux dont le niveau de confiance est supérieur à 10.

      Exemple :

      Mes amis :
      A (50%)
      B (30%)
      C (60%)

      Les amis de A :
      B (20%)
      D (60%)
      E (20%)

      Les amis de B :
      A (30%)
      F (20%)
      G (60%)

      C n'a pas d'ami :(.

      Ce qui fait que je vois :
      A 50%
      B 30%
      C 60%
      D 0,50 * 0,60 = 30%
      E 0,50 * 0,20 = 10%
      F 0,30 * 0,20 = 6% <= Je discuterai pas avec F.
      G 0.30 * 0.60 = 18%


      Voila, c'était juste une idée qui me venait comme ça, et vu qu'elle a rien d'originale, ça doit déjà exister et peut être en plus évolué.
      • [^] # Re: Hum

        Posté par  (site web personnel) . Évalué à 4.

        D'accord. Et maintenant, tu fais quoi de ta confiance ? La confiance, c'est très utile si tu dois faire des votes (dans des systèmes avec replication de calcul et votes) mais là, vu que tu mets un seuil, au final c'est binaire comme usage. Tu télécharges un morceau de fichier à E (10%). Vas-tu demander confirmation du CRC de ce morceau de fichier à un autre pour être sûr que E n'a pas voulu te filer un bout corrompu ? Ou vas-tu traiter ce morceau comme si C (60%) te l'avait donné ? Et si t'as
             80% --> B --> 00%  
           /                                \
        A                                     D
          \                                 /
            100% --> C ---> 80%
        
        
        Et que tu te connectes à D qui t'a été présenté par C, tu vas lui faire confiance ? Car B, lui, il dit pourtant « oh non, c'est un méchant. » Donc tu vas devoir tenir à jour un graphe de confiance de tout ton réseau. Et ça, moi, je crois que c'est pas un projet de master, mais plutôt un sujet de thèse…
        • [^] # Re: Hum

          Posté par  . Évalué à 1.

          Tu peut utiliser un système binaire confiance ou pas confiance. Voir ça comme un graphe et ré-appliquer les algo de moteur de recherche.

          Oui ça n'en est pas plus simple juste une idée.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Hum

          Posté par  (site web personnel) . Évalué à 2.

          Non, je majore les infos. Parce que B ne m'a pas dit que D est un gros méchant mais qu'il connait très mal D et peut pas lui faire trop confiance... Un gros méchant, on l'ajoute pas au réseau. Et l'intérêt du pourcentage c'est que si ya un boulet qui ajoute un agent HADOPI, si tu ne connais pas directement ce boulet, il y a des chances pour qu'arrivé à ton niveau, tu l'ignores.
          Et si tu veux, tu peux aussi coupler ça à un système de méfiance comme ça tu pourras marquer les gens qui ne sont pas dignes de confiance... Mais bon, c'est assez redondant je trouve.

          Tu n'as pas à maintenir de graphe. Tu ne fais qu'ajouter dans ta liste de confiance (couple peer, niveau confiance) les listes des gens que tu connais en appliquant le pourcentage associé au peer. C'est très simple à faire comme ça.
  • # Formation

    Posté par  . Évalué à 3.

    Ça me fait méchamment penser à mon IUT à Aix-en-Provence.

    Une formation « principale » en C++, un peu de Java et le réseau en C# (avec monodevelop qui, à l'époque en tout cas, était absolument instable).

    Serais-tu à l'IUT d'Aix-en-Provence ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Formation

      Posté par  . Évalué à 2.

      Mince, je suis démasqué. Oui, je suis bien à l'IUT d'Aix en Provence, et désormais, monodevelop est utilisable.

      Envoyé depuis mon lapin.

      • [^] # Re: Formation

        Posté par  . Évalué à 2.

        Soit heureux parce qu'il y a 3 ans il plantait sans crier gare.

        C'est toujours A. C. qui donne les cours j'imagine (sinon ça ne serait plus du C#) ?

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # p2p UDP ?

    Posté par  (site web personnel) . Évalué à 3.

    Un moment, j'avais imaginé un système de p2p de socket UDP. Normalement un peu n'importe quoi pourrait passer dedans. L'idée est de faire de la redirection, avec au minimum un entrant et 2 sortant.

    Ce qui est amusant avec udp est que tu peux spoofer l'adresse d'émission sans que cela est trop de conséquence.

    Pour être performant, il faudrait ajouter une fonction d'agrégation pour augmenter la bande passante en entré, cela serait marrant de streamer de la vrai HD.

    Le deuxième point méga complexe est la localisation des données. Il me semble que le système de hash distribué fonctionne bien (mldonkey ?).

    Reste ensuite la base de donné distribué pour faire les recherches, et là c'est pas franchement le top. J'imagine qu'un moteur de recherche distribué est un projet à part entière. C'est encore plus complexe que l'application p2p classique car il y a les modifications à gérer (il y a beaucoup d'écriture par rapport au read only du p2p).

    Un dernier point serait d'avoir un réseau p2p qui respecte la localisation géographique. Il me semble qu'il y a des tentatives de RFC pour connaitre la topologie du réseau physique pour optimiser les échanges dans les tuyaux des FAI. On peut aussi utiliser les bases de données géographiques déjà disponnible.

    Cela a un gros avantage : c'est quasi impossible de scanner un réseau si on est toujours connecté aux personnes les plus proche. (par exemple pour transmettre une demande de connexion, on choisi l'ip la "plus proche" par rapport au demandeur)

    L'avantage d'un streaming de flux arborescente, c'est que la voie de retour ne semble pas nécessaire, il n'y aurai donc pas de moyen de remonter à l'origine. Pour se brancher il suffirait de connaitre un noeud du réseau. Cela descend une demande dans l'arbre pour qu'une feuille envois le flux.

    Pour éviter les nœuds "méchants", on peut utiliser de la signature crypto, un nœud méchant est alors signalé plus haut. Pour éviter les signalements abusifs, on demande une reconnexion au nœud connu en précisant que l'on n'aime pas tels nœuds.

    "La première sécurité est la liberté"

    • [^] # Re: p2p UDP ?

      Posté par  . Évalué à 2.

      Un moment, j'avais imaginé un système de p2p de socket UDP. Normalement un peu n'importe quoi pourrait passer dedans. L'idée est de faire de la redirection, avec au minimum un entrant et 2 sortant.

      Jette un oeil à n2n, alors.
      • [^] # Re: p2p UDP ?

        Posté par  (site web personnel) . Évalué à 2.

        CE n'est pas la même chose. N2n, c'est pour faire du VPN.

        Mon truc c'est plus du streaming.

        "La première sécurité est la liberté"

    • [^] # Re: p2p UDP ?

      Posté par  . Évalué à 1.

      > Ce qui est amusant avec udp est que tu peux spoofer l'adresse d'émission sans que cela est trop de conséquence.

      Si ton fai ne filtre pas les adresses d'origines qui ne lui appartiennent pas, oui. Cependant c'est une mauvaise habitude de ne pas le faire (le filtrage devient obligatoire en IPv6).

      J'y vois également un léger soucis au franchissement des box, le spoof d'IP n'est pas vraiment adapté pour franchir un NAT qui n'est pas configuré pour.

      Si tu t'intéresses aux réseaux p2p qui respectent la localisation géographique, tu peux jeter un œil sur Pastry. Il ne considère pas réellement la distance géographique réelle qui est difficile à estimer, mais le temps de latence, qui est tout de même un très bon indicateur de la distance parcourue entre deux points du réseau.
      C'est d'ailleurs peut-être un très bon point de départ de s'adapter sur la brique réseau de Pastry pour se concentrer sur l'applicatif au dessus.
      • [^] # Re: p2p UDP ?

        Posté par  (site web personnel) . Évalué à 2.

        Plus que la mesure de latence, je pensais à l"utilisation des bases de donnée d'IP. Aujourd'hui on sait parfaitement situer chaque IP sur chaque DSLAM. j'imagine que si les échanges se font au niveau DSLAM, la vitesse est beaucoup plus grande.

        "La première sécurité est la liberté"

        • [^] # Re: p2p UDP ?

          Posté par  . Évalué à 4.

          Ouais, mais non. Tu ne pourras rien faire à ce niveau là. Dès que tu quittes ton modem, tu n'as plus aucun contrôle sur le routage. Si ton voisin n'a pas le même fai, et que ton fournisseur a décidé qu'il faudrait passer par un routeur à 200Km pour le joindre, tu ne peux rien y faire. La mesure de la latence est la bonne solution, à mon avis.

          Ton voisin habite peut-être pas loin, mais s'il est à 200km sur le réseau IP, on s'en fou un peu.
  • # XMPP en P2P?

    Posté par  . Évalué à 3.

    Pourquoi ne pas écrire une version P2P d'XMPP afin de pouvoir faire de la messagerie instantanée sans avoir à s'inscrire ou à installer un serveur?
    • [^] # Re: XMPP en P2P?

      Posté par  . Évalué à 1.

      Un peu comme ce que fait Apple_Bonjour ?

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: XMPP en P2P?

        Posté par  (site web personnel) . Évalué à 2.

        Non mieux : http://xmpp.org/extensions/xep-0174.html

        Déjà implémenté dans certains clients Jabber...
        • [^] # Re: XMPP en P2P?

          Posté par  . Évalué à 7.

          Ça à l'air cool XMPP. Il lui manque juste un protocole de messagerie instantanée pour être complet. :p
          • [^] # Re: XMPP en P2P?

            Posté par  (site web personnel) . Évalué à 1.

            Qu'est-ce que tu veux dire? Le logiciel de messagerie instantanée Empathy supporte déjà la "XEP-0174: Serverless Messaging" avec telepathy-salut.
            • [^] # Re: XMPP en P2P?

              Posté par  (site web personnel) . Évalué à 1.

              man humour # :p
              • [^] # Re: XMPP en P2P?

                Posté par  (site web personnel) . Évalué à 2.

                $ man humour
                No manual entry for humour

                J'ai pas compris.
                • [^] # Re: XMPP en P2P?

                  Posté par  . Évalué à 4.

                  $ man emacs
                  Emacs: a great operating system, lacking only a decent editor.

                  SEE ALSO
                  XMPP: an operating system specification, lacking only a decent IM protocol.

                  C'est juste que xmpp à l'air de faire tellement de choses qu'on finit par se demander si il fait aussi messagerie instantanée. Mais bon c'était juste pour la blague, de toute façon on sait tous qu'y'a aucune chance pour qu'xmpp deviennent un concurrent sérieux d'IRC quoi.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.