[bittorrent] BT proxy

Justin Cormack justin at street-vision.com
Tue Apr 12 10:59:20 EDT 2005

On Tue, 2005-04-12 at 09:58 -0500, David P. Mott wrote:
> So, since there hasn't been a lot of traffic through my mailbox lately, I 
> thought I'd post a new topic of discussion and get some feedback on my 
> current line of thinking.

Sorry, been a bit busy on something else for a while, not for much

> Some people have brought up the need for a BT proxy, but all attempts at 
> discussion on that topic were more or less ignored on the yahoo forum. 
> The quote that comes to mind is that "a BT proxy is an unfirewalled BT 
> client" -- which shows that the author either didn't grasp the real need 
> for a true proxy, or didn't care.

Just to make it clear, it would be good to spell out exactly what your
aims are with the proxy - the stuff below is implementation details.
Some other ideas and ways of doing things may then come up.

> So, I've been thinking of using off-the-shelf technology to put together a 
> BT proxy.  Here's how I think it would work:
> 1.  You'd have an HTTP proxy running.  You could use something like James
>      Marshall's cgi-proxy script for such a thing, or write/modify an
>      Apache plug-in.  I say 'modify' because...
> 2.  The HTTP proxy would intercept requests for .torrent files.  Here's
>      part of the magic.  Whenever a .torrent file is requested, two things
>      happen:
>      2a. You, the requestor, get a modified .torrent file that lists a
>          different tracker.

That should be very simple. Actually the client could have a proxy
setting too very simply, just override the supplied proxy.

>      2b. The HTTP proxy kicks off a BT client download, and associates both
>          the original and new tracker with it.  This can be done in
>          Azureus, for instance (at least through the GUI), and while I
>          haven't checked, I'm hoping it can be done via the XML remote
>          control interface as well.
> 3.  Your BT client, behind the proxy, would talk to a tracker that is
>      potentially isolated from the rest of the world.  Everyone behind the
>      firewall can talk to that tracker, and even view the torrents that it
>      is currently hosting (Azureus does this as well).  The nice thing is,
>      if people get the torrent from different places, it'll still result in
>      them getting pointed to the internal tracker so long as they went
>      through the HTTP proxy.
> Assumptions:
> 1.  Azureus XML interface allows the addition of new torrents
> 2.  Azureus XML interface allows modification of the tracker lists
> 3.  Modification of tracker lists can be used to merge BT swarms,
>      as opposed to just specifying an alternate tracker.
> 4.  Azureus XML interface allows the sharing and hosting of a torrent
> So far, I think that most or all of the technology is there and only a 
> little glue-code is required to bring it together.  The only problem that 
> I can't figure out is this -- I don't know of a way to configure the 
> Azureus client (that is connected to both trackers, real and internal) to 
> preferentially serve the internal clients.  So, while the Azureus client 
> might have all of the data, it may choose to serve external peers and snub 
> internal peers.

If you are running the proxy tracker, why not make it give out its own
address with probability 1 for all host requests, so that it stays
connected to all the local peers (no external client will ever connect
to the tracker anyway). You could also limit the number of external
client addresses it hands out. This might be sufficient.

More information about the BitTorrent mailing list