[BitTorrent] Torrent Exchange Protocol

skybuckflying skybuck2000 at hotmail.com
Fri Jan 7 04:20:50 EST 2005


I see many posts about trackers and how they require lot's of 
bandwidth... I have also seen this in practice with certain trackers 
being not available because of limited bandwidth and some trackers 
have even gone done.

Some of these "tracker websites" are great since they allowed a 
person to see what torrents are available. Unfortunately some of 
these great "tracker websites" have gone done and the lists are no 
longer available.

So I propose an idea to bring back some of this loss.

The idea is that many people download their favorite torrent files 
and store them on harddisk in the same folder.

Then when they connect to a torrent and when they start 
swapping "content pieces" they could also start swapping "torrent 
pieces" with other peers and that way get many new torrents etc.

Then the peers simply store the "new" torrents in their torrent 
folder etc.

So the idea is that each peer reserves 1 kilobyte of bandwidth to 
exchange "torrent pieces" while they exchange the "content pieces".

So after a few hours they should have received some new torrents.

Here is a calculation: let's say they are 50 hours online spread over 
many days... 50 hours * 60 minutes * 60 seconds * 1 kilobyte = 50 * 
3600 = 180.000 kilobytes... so that's about 180 MB of new torrents.

Then a client like Azureus (my favorite sorry ;)) can simply add 
a "listview" to their application which reads the torrent 
directory/folder and simply displays all the torrent 
files/information etc in a window/list just like the "tracker 
websites" did.

Further azareus could also build in a search option to search through 
the list just like some "tracker websites" did ;) you get the picture 

So bottum line is that a user should first consult his list on the 
disk for a torrent file... maybe he already downloaded it once... so 
he doesnt have to go to a tracker site.

He only needs to go to a tracker site in case he doesnt find the 
thing he wants... etc...

Now in practice probably only a few people would have to do that 
because after a while the new torrents will simply end up in the 
network anyway ;)

That's the main idea.

Below I will attempt to work out these ideas a little bit more in 

The peers need a way to exchange the torrent pieces ofcourse.

I don't exactly know how the bittorrent client protocol works. I 
haven't reached that point yet ;) :D

But I think it works by peers sending information to each other 
"what they have" and "what they are interested in" at other peers.

They don't do this at once but in little bits at a time ;)

So I ll take that idea and apply it to the torrent files/pieces.

Instead of transferring big lists of torrent files etc let's do it a 
little bit at a time and first ask if another peer is interested in a 
torrent file.

So at this point the protocol and torrent files could be enhanced to 
contain media information. (Maybe they already do ?)

Media information could be a string allowing it to be anything or it 
could be an integer with hard coded values associated with it.

For example: video, music, film, games, clips, trailers, os, 
software, applications, etc :), all :) <- that's a good one :D or 
simply unknown ;)


A peer could simply decide to be interested in everything just for 
the purpose of "spreading/distributing" as many torrents as possible.

A peer could also learn how "distributed" a certain torrent is...

If it receives many "torrent posts" it can increment a local counter 
for each torrent and get a sense of how much a torrent is spread 
around... that way a peer can later choose the more rare torrent to 
be spread first.

So now on to the spreading itself ;)

Here is my simple proposal ;) which is just a scatch nothing 
definitive ;)

Each peer as stated above reserves some bandwidth for eaching torrent 
files. For example 1 kilobyte or maybe 2 ;)

Then it selects a torrent to be spread/distrubted ;)

Then it selects a peer that is interested in this kind of torrent... 
if known... if not known it simply tries it ;)

So then the peer sends to the other peer I have this torrent are you 
interested in it ?

If the other peer says yes I am interested in it... then the torrent 
gets exchanged.

If it says no then not ofcourse ;) and some flag is set that this 
particular peer is not interested in this kind content ;)

There is another reason to first ask the other peer if it is 
interested in this torrent... it might already have this torrent.

So to not waste bandwidth a short description of the torrent can be 
sent first.

For example

torrent filename + torrent filesize + torrent hash.

( the torrent filename might even be omitted since I think filesize 
and torrent hash might be enough to uniquely identify each 
torrent...but if not then the filename helps ;) )

Torrent files are typical small right ? like 30 Kilobyte etc... so 
this can simply be exchanged on a one to one basis.. simply via tcp 
etc... there is no need to use the bittorrent protocol to do that... 

So to make this happen a new "torrent exchange protocol" is needed =D

Without having studied the client wire protocol in detail I will 
attempt a simple design here and you can comment and critic it to 
death if you like :D

The peer needs to be able to tell other peers about the torrent so 
let's just simply call that "torrent info"

"torrent info" id 1

then another peer needs to be able to say that it is interested or 
not interested

"torrent not interesting" id 2

"torrent interesting" id 3

then the peer who has the torrent can exchange the torrent content 
with the other peer

"torrent content" id 4

So think only 4 id's are needed to make it happen.

I will now work these out a bit:

"torrent info" id 1

the content of this message is a bencoded dictionary with the 
following entries:
filename = <torrent filename>
filesize = <torrent filesize>
filehash = <torrent filehash>

Later this could also be enhanced with additional keys&values like:

type = <description of type of content>

video, audio, music, games, software, applications, movie, tv-show, 

genre = <description of genre of content>

sci-fi, soap, pop, rock, operating system, video tools, audio tools, 
talk show, etc

A bittorrent client could even build a list of types and a list of 
genre's etc.... the software can have an option to allow/disallow 
unknown types and/or genres etc to be downloaded ;)

Each new type/genre should also have a marked that indicates if it's 
new or not so that the user can later view new types and or genre's 
and choose to allow or disallow downloading/exchange of the 
types/genre's ;) :D

"torrent not interesting" id 2

the fields/content of this message is exactly the same as id 1
except the id is now 2 indicating that the peer is not interested.

again later an extra field can be added:

reason = <reason why it is not interested>

Some possible values: already present, type not interesting, genre 
not interesting, out of space, torrent exchange not allowed, too busy 
or whatever :D 

"torrent interesting" id 3

well this one speaks for itself I would say... again the same as id 

"torrent content" id 4

this one is also pretty straight forward.

size = <size of torrent file>
data = <data/content of torrent file>

data can then be a bencoded raw binary string.

So in short bencoding is a great way for future enhancements and 
compatibility ;) that's why I would choose to do it like this :D

Ofcourse the wire protocol and the bencoding can be combined a little 
to make it more easy to receive the stuff etc.

here is how it works:

<length><torrent exchange protocol message>

viola ;)

Now a bittorrent client can first receive the length of the torrent 
exchange protocol message and then allocate enough room for a buffer 
to receive the message into it and later process it ;)

Vice versa it first builds the torrent exchange protocol message 
which is like a string... and then the length of the string is 
determined etc... pretty straight forward stuff ;) :P* =D

Finally some other little details:

The torrent folder could be limited to a certain ammount of space on 
the drive like 1 or 2 Gigabyte or so ;)

Then a strategy can be used to make more space.. for example delete 
the most distributed torrents from the list and keep the rarest 
once... or delete the oldest torrents etc... 

Few... sigh... big post =D

  Skybuck ;)

Yahoo! Groups Links

<*> To visit your group on the web, go to:

<*> To unsubscribe from this group, send an email to:
    BitTorrent-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:

More information about the BitTorrent mailing list