P2P packages and bitTorrent Details

Jason Gurtz jason at tommyk.com
Fri Jun 27 09:12:16 PDT 2003

Jeroen Coumans wrote:

> The eDonkey network is setup alike: once the package has spread among 
> clients, every client can download from other clients. Clients who 
> upload a lot are rewarded with more download speed. No leeching! Files 
> can be spread with edk:// links, which are picked up by the eDonkey 
> client. (See sharereactor as a good example of how to distribute content 
> with eDonkey).

BitTorrent sounds real similar to eDonkey in a lot of ways.  Apparently
the only way to make it not serve files is to modify the source.  The
faq noted that doing that can ensure problematic downloading  ;)

> So belgarath doesn't have to be burdened with 
> distributing it, we just need some people who are willing to keep those 
> packages in their shared directory.

Yea, that's the idea.  Maybe the best way is to have lfs-specific
patches and scripts and things still available via http and ftp but
offer all the packages through P2P (as well as the custom lfs stuff).

>>I'm going to do some more research now and see what I can find (I've
>>started reading:  <http://smiler.no-ip.org/BT/BTtutorial.htm#server>).

> That's exactly what we need. I came up with eDonkey and Kazaa since 
> those are the most common P2P networks. Allthough Kazaa doesn't have 
> much Linux users so we can probably concentrate on eDonkey (mlDonkey, 
> xMule), Gnutella2 and now BitTorrent.

Yea, I agree that kazza is about usless in this context.  If edonkey
supports the special mime-type downloading that may just work.

OK, more details I've found, an executive summary of running a
bitTorrent server.  I've also found a full fledged review of the system
written from the context of sysAdmin/user at:

- BitTorrent is a set of python apps.  People feel as they may about
python, but if run continuously, it would probably be well advised to
have a cron job periodicly kill and restart the (tracker) process to
avoid memory leaks.  Maybe this would be every few days.  we'd have to
monitor to figure out how often it should be.

- There are some C/C++ ports started.  In particular I found a nice C
one that implements client functionality (haven't tested):

- An incompomplete port (with nice web site and status is at:

- The file servers Web server is set up with:

AddType application/x-BitTorrent	.torrent

- set up the dir with the files to seed the network.

- create the .torrent file using the btmakefile.py script  This file is
an index of the files offered in the shared dir

- Run the "tracker" app.  This monitors the clients who DL stuff  so
that the "swarming" will occur for other users.  Clients who download
leave the client running and it will automaticly upload via the tracker
on the server.

- I haven't yet found a C/C++ port of the tracker functionality.
Hopefully one will be available soon!

- The server only holds the original files and does not participate in
the mirroring of other possibly illeagle things.  Clients are
responsible for what they DL and offer for mirroring. (importent from a
leagle context)

>>This really seems like a great idea.  I'm rather surprised it hasn't
>>really come up seriously before.
> Obvious things are only in hindsight obvious. I've redesigned some other 
> pages too, eg. the news pages, adopt-a-hint, mirror enforcement, better 
> navigation etc. More is in the queu once my laptop's restored; next up 
> for a redesign is the FAQ.
> The whole redesign of the website is supposed to be "d'oh, why wasn't it 
> like this before?". If I get responses like that, I've succeeded in my 
> mission ;)

Yea, good way to look at it :)  It's all ready looking quite nice.

  The other thing about bit torrent is that I can see a need to develop
a page or few describing the setup of various client browsers to
recognize the .torrent file mime type and also maybe pointers to
relevent software ports.

Hopefully your lappy is fixed soon  :)




More information about the website mailing list