[gull] Bittorrent sous linux?

Marc SCHAEFER schaefer at alphanet.ch
Sun Nov 21 21:21:01 CET 2004


On Sun, Nov 21, 2004 at 08:51:17PM +0000, Thierry de Coulon wrote:
> De plus en plus de distributions proposent des downloads bittorrent. J'avais 
> essayé ce "truc" il y a quelques mois pour Mandrake et j'avais renoncé - 
> dernière durée indiquée pour le download du premier CD, environ une semaine! 

Une alternative plus intéressante ne serait-elle pas l'installation par
réseau ?  Certaines distributions offrent un mini-CD (genre 30 MB) qui
permet ensuite d'activer des sources d'installation par réseau.

D'une distribution typique moderne (2 DVDs, soit 9 GB) on n'utilise en
règle générale que 1-2 GB au grand maximum.  Et on peut installer au fur
et à mesure, et directement installer les dernières versions, ce qui
évite d'installer depuis les CDs téléchargés, puis retélécharger
quelques centaines de MB avec les mises à jour.

La plupart des distributions séparent le processus de téléchargement des
packages de celui de l'installation/configuration, on peut donc laisser
l'ordinateur télécharger pendant la nuit et configurer au petit matin.

> corerctement. Mais les vitesses restent lamentable, même en ouvrant les ports 
> 6881 à 6999.

Je ne connais pas en détail BitTorrent. J'ai un miroir Debian local et
je génère les CD-Rs que je grave avec Jigdo (il télécharge des templates
de fichiers ISO-9660, et construit ensuite les CD-Rs à partir des
données locales, voire de données distantes si non disponible
localement, ce qui est très efficace dans mon cas).

Il est possible que, comme d'autres systèmes de P2P, un système de
`weighting' soit utilisé: plus tu donnes des choses aux autres, plus tes
downloads vont vite.  Une bande passante très asymétrique peut être
un désavantage. Ou la non ouverture de ports accessibles de l'extérieur.

Mais Debian l'utilise également et ils documentent à l'URL
   http://www.debian.org/CD/torrent-cd/
que le principal avantage de BitTorrent est qu'il charge les clients et
non les serveurs. En bref il s'agit d'un téléchargement réparti,
avec `weighting'.

Un client python existe sur Debian testing:
   http://packages.debian.org/testing/net/bittorrent

Il est probablement facilement installable sur d'autres distributions
depuis la source originale, dans la mesure où le toolkit wxWindows
est disponible.

(Il a l'avantage d'être totalement libre, au contraire de toute
implémentation Java, voir à ce sujet
http://www.gnu.org/philosophy/java-trap.html, et peut-être aussi d'avoir
moins de demandes en CPU et mémoire; voire être plus sûr. Il a
l'inconvénient de ne pas être un client simple: il semble demander X11).

> Bon, il parait que les "torrents" prennent de la vitesse avec le temps et, à 

C'est effectivement probablement car le ratio download/upload
s'améliore: plus tu as downloadé de morceaux, plus tu peux en donner aux
autres.

Plus de détails dans les explications:
   http://bittorrent.com/

> - lorsque Azureus fonctionne et que des logiciels sont en download/upload, et 
> malgré des vitesses modestes dans les deux sens, toute activité internet est 
> quasi impossible, comme si bittorrent vampirisait la connection - ce que je 
> n'observe pass lors d'un download ftp ou http.

C'est effectivement possible. On peut s'en sortir avec divers outils de
bandwidth sharing / prioritization / QoS, jusqu'à un certain point.

Avant d'en arriver là, baisser le MTU de l'interface peut augmenter
l'interactivité au prix d'une petite baisse de performance générale.

   ifconfig eth0 mtu 600

p.ex.

> - quel est l'avais des experts quand au danger d'ouvrir les ports du routeur 
> demandés par bittorrent?

C'est clair que c'est ennuyeux, mais il ne faut pas se cabrer sur le
fait d'ouvrir les ports. Il faut utiliser les fonctions qu'UNIX nous
propose pour protéger des machines.

Tourner le client -- de préférence le plus simple possible -- sous un
utilisateur spécifique rendra toute attaque plus difficile.

Malheureusement le client pré-cité n'est pas un petit client simple,
mais une interface graphique complexe.

Exemple ici de sécurisation à comptes multiples:

   testuser at defian:~$ id
   uid=1005(testuser) gid=1005(testgrp) groups=1005(testgrp)

Cet utilisateur n'a pas accès à mes fichiers, même en lecture:

   schaefer at defian:~% ls -lad .
   drwx---r-x   91 schaefer testgrp      8192 Nov 21 21:00 .

Idéal pour tester des programmes Microsoft Windows via WINE, lancer des
binaires (genre client dnetc) ou faire d'autres bêtises.

Inutile de dire que faire comme Lindows, soit travailler sous root en
permanence n'est pas la bonne méthode.





More information about the gull mailing list