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 meumeu1402 . Évalué à 10.
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 Laurent A. . Évalué à 10.
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 yellowiscool . Évalué à 4.
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 Graveen . Évalué à 1.
[^] # Re: Brevet
Posté par yellowiscool . Évalué à 4.
Faire quelque chose que l'on trouve super, mais qui ne servirait à personne, serait dommage.
Envoyé depuis mon lapin.
[^] # Re: Brevet
Posté par ahuillet (site web personnel) . Évalué à -2.
C'est un projet scolaire, non ?
[^] # Re: Brevet
Posté par seginus . Évalué à 9.
[^] # Re: Brevet
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: Brevet
Posté par yellowiscool . Évalué à 2.
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 khivapia . Évalué à 4.
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 yellowiscool . Évalué à 2.
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 alice . Évalué à 8.
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 yellowiscool . Évalué à -2.
Envoyé depuis mon lapin.
[^] # Re: Brevet
Posté par liberforce (site web personnel) . Évalué à 2.
[^] # Re: Brevet
Posté par yellowiscool . Évalué à 1.
Envoyé depuis mon lapin.
[^] # Re: Brevet
Posté par liberforce (site web personnel) . Évalué à 2.
[^] # Re: Brevet
Posté par zebra3 . Évalué à 7.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Brevet
Posté par Grunt . Évalué à 2.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Brevet
Posté par Victor . Évalué à 5.
[^] # Re: Brevet
Posté par Grunt . Évalué à 5.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Brevet
Posté par SQP . Évalué à 10.
[^] # Re: Brevet
Posté par Victor . Évalué à 2.
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 Grunt . Évalué à 6.
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 Victor . Évalué à 4.
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 Sytoka Modon (site web personnel) . Évalué à 3.
# Idées
Posté par ecyrbe . Évalué à 1.
- 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 Tonton Benoit . Évalué à 2.
[^] # Re: Idées
Posté par Alexandre COLLIGNON (site web personnel) . Évalué à 4.
Ils ont quoi les chinois ?
Alexandre COLLIGNON
[^] # Re: Idées
Posté par Laurent Cligny (site web personnel) . Évalué à 7.
[^] # Re: Idées
Posté par ecyrbe . Évalué à 0.
ç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 fabien . Évalué à 3.
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 LeJulien . Évalué à 3.
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 cosmocat . Évalué à 3.
http://www.generation-nt.com/ue-europe-p2p-next-tv-bittorren(...)
[^] # Re: Quelques idées au hasard
Posté par Olivier (site web personnel) . Évalué à 1.
[^] # Re: Quelques idées au hasard
Posté par psychoslave__ (site web personnel) . Évalué à 3.
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 Defre . Évalué à 3.
=)
[^] # Re: Quelques idées au hasard
Posté par Victor . Évalué à 2.
(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 Grunt . Évalué à 4.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Quelques idées au hasard
Posté par Victor . Évalué à 2.
[^] # Re: Quelques idées au hasard
Posté par LeJulien . Évalué à 1.
# Pour te donner des idées
Posté par Ummon . Évalué à 7.
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 Defre . Évalué à 6.
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 yanndlfp . Évalué à 1.
[^] # Re: Pourquoi une "Application"...
Posté par Defre . Évalué à 1.
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 Grunt . Évalué à 10.
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 yellowiscool . Évalué à 6.
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 Grunt . Évalué à 3.
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 kursus_hc . Évalué à -3.
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 Anonyme . Évalué à 4.
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 Grunt . Évalué à 6.
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 Prae . Évalué à 7.
" 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 pyknite . Évalué à 1.
Sauf que nous on doit le faire en java (:(), en TCP et pas de chiffrage...
[^] # Re: Marrant
Posté par yellowiscool . Évalué à 2.
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 pyknite . Évalué à 1.
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 Defre . Évalué à 1.
[^] # Re: Marrant
Posté par Carl Chenet (site web personnel) . Évalué à 5.
T'as pas encore du croiser Python alors.
[^] # Re: Marrant
Posté par pyknite . Évalué à 2.
Mais le c c'est mieux! (on est bien vendredi non? ;) )
[^] # Re: Marrant
Posté par fearan . Évalué à 2.
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 Ummon . Évalué à 5.
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 fearan . Évalué à 4.
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 Ummon . Évalué à 3.
Par contre je te rejoins sur le coté dynamique qui peut entrainer des difficultés sur les moyens/gros projets.
[^] # Re: Marrant
Posté par fearan . Évalué à 4.
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 Ummon . Évalué à 1.
Je me suis cassé les dents sur du code écrit en C/C++ et bourré de macros comme celle ci...
[^] # Re: Marrant
Posté par galactikboulay . Évalué à 8.
[^] # Re: Marrant
Posté par Littleboy . Évalué à 3.
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 Alexandre COLLIGNON (site web personnel) . Évalué à 2.
- 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 galactikboulay . Évalué à 4.
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 fearan . Évalué à 2.
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 galactikboulay . Évalué à 2.
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 Alexandre COLLIGNON (site web personnel) . Évalué à 3.
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 houra . Évalué à 2.
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Marrant
Posté par case42 (site web personnel) . Évalué à 8.
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 bubar🦥 (site web personnel) . Évalué à 3.
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 Grunt . Évalué à 3.
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 Defre . Évalué à 2.
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 Grunt . Évalué à 2.
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 fabien . Évalué à 1.
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 Florent Fourcot . Évalué à 2.
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 Grunt . Évalué à 3.
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 ckyl . Évalué à 4.
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 khivapia . Évalué à 5.
[^] # Re: Pourquoi UDP ?
Posté par yellowiscool . Évalué à 0.
Envoyé depuis mon lapin.
[^] # Re: Pourquoi UDP ?
Posté par ckyl . Évalué à 4.
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 yellowiscool . Évalué à 1.
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 ckyl . Évalué à 5.
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 Florent Fourcot . Évalué à 4.
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 Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
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 yves a (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 Maxime (site web personnel) . Évalué à 3.
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 Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
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 barmic . Évalué à 1.
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 Maxime (site web personnel) . Évalué à 2.
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 barmic . Évalué à 3.
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 yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: Formation
Posté par barmic . Évalué à 2.
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)
[^] # Re: Formation
Posté par Larry Cow . Évalué à 6.
[^] # Re: Formation
Posté par Laurent Cligny (site web personnel) . Évalué à 6.
Soyez indulgent c'est vendredi :p
[^] # Re: Formation
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
# p2p UDP ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
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 Larry Cow . Évalué à 2.
Jette un oeil à n2n, alors.
[^] # Re: p2p UDP ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Mon truc c'est plus du streaming.
"La première sécurité est la liberté"
[^] # Re: p2p UDP ?
Posté par Florent Fourcot . Évalué à 1.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: p2p UDP ?
Posté par Florent Fourcot . Évalué à 4.
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 alice . Évalué à 3.
[^] # Re: XMPP en P2P?
Posté par zebra3 . Évalué à 1.
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 Maxime (site web personnel) . Évalué à 2.
Déjà implémenté dans certains clients Jabber...
[^] # Re: XMPP en P2P?
Posté par boq . Évalué à 7.
[^] # Re: XMPP en P2P?
Posté par Alban Crequy (site web personnel) . Évalué à 1.
[^] # Re: XMPP en P2P?
Posté par BAud (site web personnel) . Évalué à 1.
[^] # Re: XMPP en P2P?
Posté par Maxime (site web personnel) . Évalué à 2.
No manual entry for humour
J'ai pas compris.
[^] # Re: XMPP en P2P?
Posté par boq . Évalué à 4.
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.