[Aide] Pourquoi je vois des seeds, mais je ne télécharge pas

[MuppetChaud]

@napster89 Tu as tenté sur le YGG Reborn par hasard ?

[napster89]

@MuppetChaud oui y a pas tout le torrents, il y a un d’ailleurs avec un seul seed, mais il ne commence même pas, c’est vraiment la catastrophe, j’eté sur le point d’acheter un disque dur 30To pour sauver les documentaires qui sont tellement rare, contrairement au film et serie, et la yggleak et hs

[MuppetChaud]

@napster89

Il faut remercier Destroy pour sa soif du partage et la justice divine de Golum ^^

[napster89]

@MuppetChaud je ne sais pas s’ils sont différents l’un de l’autre franchement

[7cf148fd]

@Marchiavel a dit:

Il y a aussi un souci avec les liens magnets, qui obligent à récupérer les métadonnées avant de lancer le téléchargement, ce qui n’est pas toujours autorisé sur les clients

C’est exact mais extrêmement rare. Les torrents privés ne sont quasiment jamais partagés via des liens magnet, pour des raisons de sécurité (c’est pire que “pas toujours autorisé”, à ma connaissance tous les clients ignorent les requêtes ut_metadata pour les torrents privés)

[kemkem]

De mémoire rtorrent envoi les ut_metadata même pour les torrents privés. Mais c’est peut-être le seul et c’est probablement la raison de l’échec ygg[dot]paspayant. Tous les torrents de ygg sont marqués privés, donc sans les fichiers torrents ça avait peu de chance de fonctionner.

Alors que les specs du protocole bittorrent ne l’interdit pas, la quasi totalité des clients ont prit le parti de ne pas répondre à cette requête, paraît-il pour ne pas courroucer les admins des trackers privés… Incompréhensible. Combien de fois je me suis fait avoir avec des magnets de torrents marqués private sur des trackers publiques qui ne démarre jamais.

[7cf148fd]

Le magnet de contient pas l’infodict, juste l’infohash du torrent, or le fait qu’il est privé est dans l’infodict. Cela signifie que lorsque tu ajoutes ton torrent au client le DHT est a priori activé et l’infohash va y être publié.

Les torrents privés sont supposés restés privés et le DHT est désactivé sur les clients qui les possèdent (ceux qui sont sur le tracker et ont les metadata que tu cherches). Partager le magnet sur le DHT c’est donner aux gens qui sont sur ton tracker et écoutent le contenu de la DHT le moyen d’identifier tous les autres peers qui sont sur ton tracker car ces derniers vont tous se mettre à publier dans la DHT quels infohash ils ajoutent à leurs clients.

C’est d’'autant plus dangereux pour le tracker qu’on peut tracer qui download un .torrent, mais pas qui copie un lien magnet… Un utilisateur malveillant n’a qu’à “récolter” tous les infohash du site (sans rien downloader) pour pouvoir ensuite “écouter” le volume d’activité. On peut alors sans trop de soucis s’en servir pour identifier quelle IP correspond à quel user (par recoupement de qui downloade quoi)

Bref non, ce n’est pas “incompréhensible” du tout.

[kemkem]

Quand j’ajoute un torrent privé via magnet à transmission, et qu’un seeder daigne m’envoyer les metadata, mon client n’a aucun problème à passer le torrent de public à private (et dès lors désactive PEX et DHT).

Pour moi le problème est coté seeder. C’est le fait de ne pas différencier les requêtes émanent d’un peer via DHT d’un peer annoncé par le tracker, pour ne répondre qu’à ceux du tracker. Donc soit rtorrent fait cela, soit il ne désactive pas le DHT sur les torrents privés (ce qui me paraîtrai assez grave en 2026).

[7cf148fd]

@kemkem a dit:

Pour moi le problème est coté seeder. C’est le fait de ne pas différencier les requêtes émanent d’un peer via DHT d’un peer annoncé par le tracker, pour ne répondre qu’à ceux du tracker. Donc soit rtorrent fait cela, soit il ne désactive pas le DHT sur les torrents privés (ce qui me paraîtrai assez grave en 2026).

Ce n’est pas comme ça que le protocole fonctionne.

Les requêtes de connexion n’ “émanent” de personne. Un client essaye de se connecter à toi, point. Ton client n’a aucun moyen de savoir comment le peer a eu connaissance de ton existence. Si le torrent est privé et que le peer t’est inconnu, tu ne peux qu’assumer que c’est le tracker qui lui a donné ton adresse.

Tu vas me dire que tu n’as qu’à comparer aux peers que le tracker t’as envoyés mais ça ne marche pas pour deux raisons:

• Les clients ne se connectent au tracker que toutes les 30 minutes. Tu ne sais donc rien de tous les nouveaux peers auxquels le tracker a donné ton adresse depuis la dernière fois que tu lui as parlé (statistiquement, il y a 15 minutes).
• La BEP0003 stipule que le tracker doit renvoyer “une liste de peers”, pas la liste complète. Ton client envoie dans sa requête au tracker combien il en voudrait (le numwant) mais le tracker est libre d’ignorer ce nombre.

En conséquence:

• Ton client n’a connaissance que d’une partie des peers “légitimes”.
• Beaucoup de trackers privés sont justement configurés pour envoyer une liste de peers très limitée. Notamment, cela diminue le risque de triche par connexion initiale unique + suppression du tracker dans le client.

[kemkem]

@7cf148fd Tout juste. Mon idée était impossible. Cela me rend d’autant plus perplexe, parce que du coup j’ignore comment certains clients envoient bien les ut_metadata de torrents privés et pas les autres. J’ai essayé de mettre le nez dans le code de rakshasa, mais le C++ m’a épuisé…