I recently downloaded and installed BitTorrent - and I have been generally
happy with it.

Don't forget to set up the TCP port forwarding if you, like most people, are
behind a NAT.

There is one other problem - in order to share well, you need to have a
fixed internal IP and to configure your router to forward a small stash
of ports.

I have no a priori problems with opening a port, but my entire internal
network is set to dhcp, so I do not have to fiddle on remappings.  It
would make my life easier if the BT had implemented UPnP-NAT and
NAT-PMP.  See <http://www.rogueamoeba.com/utm/posts/2005/Jul> for a
fairly well described reason why we might want this.

(I am using Azerus; if other clients do this, I may just switch.)

Scott

   I'm fascinated by the bittorrent protocol and often wonder how it
manages to achieve the efficientcy that it does, especially since it does
not seem to be conceptually radically different from, for example, the
eDonkey protocol, and yet consistently outperforms the eDonkey protocol. As
part of an examination for a university course on TCP/IP and Internet
Protocol in general, I chose to research and write a bit about the
bittorrent protocol. One of these days, I'll have to take a look at eDonkey,
and try to figure out exactly what key element is missing to give eDonkey
the same performance.

   In the traditional bittorrent protocol, you DO need a server. It's
referred to as a "tracker", and all the peers connect to the tracker to
announce their presence, and locate other peers. The tracker does not itself
host any files (other than the .torrent file, which is usually less than 10
kilobytes), which is why it may seem at first like no server is involved.

   Traditionally, every torrent is related to exactly one tracker, but a
tracker can host multiple torrents at a time. A user can download from
multiple torrents at a time. Whether a single instance of the application is
run to manage all the torrents, or a new instance is created for each
torrent, is left up to the implementor of the client program.

   The people behind Azureus created an extension to the bittorrent
protocol that allows it to discover new peers without a tracker. Azureus
uses a single instance of manage all the torrents the user wishes to
download. As such, a single instance of Azureus could be connected to
multiple trackers simultaneously. When an Azureus client discovers another
Azureus client as a peer, they will exchange a list of known peers, thus
allowing the discovery of new peers without the usage of a tracker.

   Since then, other clients of the bittorrent protocol have implemented
support for Azureus' trackerless extension, but it is a "only" a defacto
standard, not one officially endorsed by the creators of the bittorrent
protocol.

   Also, some trackers were meant to be private (e.g. sharing family home
videos that you don't want others to see, or sharing illegal software that
you don't want other people to know about, etc.), and so yet another
extension was created ontop of Azureus' extension which allows for specific
torrents to be marked as "private", meaning that a well-behaving client
should not share peers that it located via a private torrent.

   Not all clients have implemented the above "private" extension, and so
the tracker softwares have been modified to blacklist certain clients which
do not respect the private flag, thus bring more awareness to the fact that
bittorrent is still, at its core, a server oriented protocol.

   - Oliver