"Filtrer le P2P... Vaste programme !" Pour ceux qui connaissent un peu l'histoire des protocoles de transfert et communication P2P les plus connus, je crois qu'il y a une évidence : ceux qui marchent étaient simples à la base, et se sont alourdis de mesures anti-filtrage qui ont accaparé le temps de cerveau disponible de leurs développeurs respectifs, plus en tout cas que l'optimisation.
Le principe dont on parle, trouver le contenu à un nombre minimal de hop, a une contrepartie majeure : il faut dupliquer le contenu pour maximiser les chances de le trouver. Et annoncer tout le contenu disponible depuis chaque point du réseau. A contrario, pour privilégier la distribution et réplication du contenu rare, il faut prioritariser les transferts lointains. Mais puisque pour optimiser les ratios avec les voisins, il faut fournir un maximum de paquets sur les contenus les plus demandés, on se retrouve avec une race-condition. Un autre problème à annoncer le plus de contenu possible pour augmenter la probabilité de hit voisin, c'est : - Le besoin en capacité de stockage sur chaque noeud - Capacité de stockage à combiner avec une robustesse suffisante pour supporter assez d'IOPS (emule tue les disques durs, plus que bittorrent, à cause du nombre de transferts simultanés possibles et des seek que ça crée sur les têtes de lecture) - Le besoin de chiffrement et discrétion car plus de contenu annoncé = plus de chances de diffuser un contenu potentiellement interdit au partage Qui dit chiffrement et discrétion (pour passer au travers des DPI) dis complication de l'algorithme et possible réduction de l'efficacité en taux de transfert pur (overhead, leurres, ...) Implémenter une recherche en prioritarisant les échanges sur les voisins impose aussi une exploration de la topologie du réseau, qui se fait via ICMP à priori (ou un protocole spécifique dont la signature sera carractéristique). Il serait alors facile de paralyser le système : forger des réponses ICMP foireuses au niveau des box. Enfin, les topologies de réseau peuvent différer du tout au tout en fonction des ISP, de leurs box, des mesures de filtrage en place, du média d'accès, de la politique de routage... Aucun intérêt sur le réseau FT de chercher un voisin sur le même LNS, puisqu'il est à 60ms minimum. Sur un réseau câble, puisque l'upstream est réduit et mutualisé, il faut être très vigilant à ne pas interférer avec les ups rare des voisins. Sur un accès radio / 3G, on peut se retrouver avec des topologies très hétérogènes au sein du même réseau. La modélisation des optimisations pour chaque cas de figure impose une R&D lourde et risque d'aboutir à une usine à gaz. Alors si on limite la spec à privilégier les échanges internes à un seul AS, ça semble simple, et ça peut arranger certains ISP, mais au détriment de la qualité globale (exhaustivité, performance et robustesse du réseau P2P). Si on cherche à optimiser tous les cas de figure, pfiouuu... Vaste programme ! Des volontaires ? -- Jérôme Nicolle --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
