Les torrents, saymieux parce qu'il existe une pléthorée de clients pour tous les goûts (des légers, des lourds, des clients en console, des clients GTK, des démons, etc.), mais aussi supporté sur plus de matos (par exemple tous les NAS ou presque savent télécharger/seeder des torrents tout seuls).
Très juste. Et c'est parce que le protocole est plus léger à implémenter. ed2k pèche sur le "tracking" du fichier, là où BitTorrent commence par mettre en place (au moins) un tracker qui coordonne la recherche et évite de tâtonner sur des dizaines de serveurs et des milliers de peers Kad. Ça se ressent au niveau de la conso mémoire et CPU.
Pour les NAS, faut pas oublier qu'il s'agit d'ordinateurs avec un OS préinstallé par le fabricant et souvent des difficultés pour y installer un autre OS. Des trucs un peu trop proprios et fermés. Du coup, l'argument "le fabricant/éditeur d'OS du NAS a décidé de supporter torrent mais pas ed2k" ne sent pas très bon.. Comme si je disais que le format ".doc" est mieux car la majorité des PC sont vendus avec un truc qui le lit (au moins pendant 30 jours).
Pour la centralisation, après réflexion c'est plus subtil: en fait les deux protocoles ont commencé avec un système centralisé (ed2k, tracker torrent) auquel sont venus d'adjoindre des fonctions acentrées: Kad, DHT, magnet.
"DHT peu implémenté et peu utilisé" -> source?
Je n'ai jamais vu un peer obtenu via DHT, en plusieurs années d'usage de Torrent. Certes, ça peut être le (bon) signe que les trackers sont efficaces. Mais, si on teste aMule de façon totalement acentrée (avec le réseau Kad uniquement), et un client torrent en n'utilisant que le DHT, je ne parierais pas sur le torrent. Je dis ça parce que j'ai testé aMule avec uniquement Kad et ça fonctionne assez bien.
Finalement, l'idéal serait d'avoir un logiciel serveur qui gère les deux protocoles en utilisant une BP globale, et soit capable de partager de l'un à l'autre (exemple, seeder via ed2k/Kad un fichier partiellement obtenu en torrent).
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: plutot un torrent
Posté par Grunt . En réponse au journal Richard Stallman lors des RMLL 2011. Évalué à 4.
Très juste. Et c'est parce que le protocole est plus léger à implémenter. ed2k pèche sur le "tracking" du fichier, là où BitTorrent commence par mettre en place (au moins) un tracker qui coordonne la recherche et évite de tâtonner sur des dizaines de serveurs et des milliers de peers Kad. Ça se ressent au niveau de la conso mémoire et CPU.
Pour les NAS, faut pas oublier qu'il s'agit d'ordinateurs avec un OS préinstallé par le fabricant et souvent des difficultés pour y installer un autre OS. Des trucs un peu trop proprios et fermés. Du coup, l'argument "le fabricant/éditeur d'OS du NAS a décidé de supporter torrent mais pas ed2k" ne sent pas très bon.. Comme si je disais que le format ".doc" est mieux car la majorité des PC sont vendus avec un truc qui le lit (au moins pendant 30 jours).
Pour la centralisation, après réflexion c'est plus subtil: en fait les deux protocoles ont commencé avec un système centralisé (ed2k, tracker torrent) auquel sont venus d'adjoindre des fonctions acentrées: Kad, DHT, magnet.
Je n'ai jamais vu un peer obtenu via DHT, en plusieurs années d'usage de Torrent. Certes, ça peut être le (bon) signe que les trackers sont efficaces. Mais, si on teste aMule de façon totalement acentrée (avec le réseau Kad uniquement), et un client torrent en n'utilisant que le DHT, je ne parierais pas sur le torrent. Je dis ça parce que j'ai testé aMule avec uniquement Kad et ça fonctionne assez bien.
Finalement, l'idéal serait d'avoir un logiciel serveur qui gère les deux protocoles en utilisant une BP globale, et soit capable de partager de l'un à l'autre (exemple, seeder via ed2k/Kad un fichier partiellement obtenu en torrent).
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.