[BitTorrent] Idea - How to make the .torrents searchable

Antonio \"KhaoticMind\" Augusto khaoticmind at gmail.com
Tue Jan 4 10:01:23 EST 2005


Heya guys, 

Its me again.
This time with an idea to make .torrent files searchable.

As i think that the BT protocol doesn't have any plan to introduce
search capabilities in its specification i though of another way of
doing it.
I start from consideration that, a search in the BitTorrent network
would be resumed to find a .torrent file so the user can then download
it with the any BT client. Also, the current way of distributing
.torrent files is very passive for failure in the same way as
centralized trackers are, i.e. if the site offering the torrents goes
down, you can't find it, even if there are tons of users already
downloading the torrent. Not to mention that sometimes you don't even
know where to look to find what you want.

So my idea is to develop a new protocol (yeah, another one) that would
allow the users to find a .torrent file in a distributed way and make
it independent of the BT protocol itself.

>From the user point of view a tool implementing the protocol i have in
mind would work like that:
You select a folder where you store your .torrent files so to make it
available for distribution.
Once the tool is loaded and you are logged on the network (more on
that latter) you would be able to search for torrents from other users
of the network. You would be able to, for example, search a torrent by
name, description or files inside the torrent 5all this info is
already inside the .torrent).
The search would then return a list of files that match this
specification, and you would be able to see  which user answered your
search, what is the tracker for that torrent, the number of peers,
lechers and all the info that is relevant (most of it can be gathered
for the tracker itself).
Once you find the file you are looking you would download the .torrent
file from the a user and use it to start your download with you
favorite client.

Other additional functionalities that could be added is the
possibility to the users rate their torrents (since now a user can
introduce a fake torrent on the network) and comments on that torrent
(basically like eMule).

>From the point of view of the developers the main idea is that you can
find all the info you need about a torrent in the .torrent file itself
(file names, hash, description and tracker address), and you could
probe the tracker for aditional info (seeds, lechers, etc).
So you would mainly create a searchable database for all torrents you
have choose to share, and look at this table to answer the queries
from other cleints.
The protocol would be a pure P2P network, maybe based on the Kadmilia
protocol, and would be used soelly for one time searches (once you
find the torrent you will enver more search for it, unlike programs
that use it to share files, and there are searchers all the time,
trying to find new sources).

My idea is to make it so that when a user joins a network he would try
to find a client that is already on the network and get a list of
clients from it.
The searches would be based on keywords on one of the fields i
mentioned earlier  (file name, description, files in the torrent), and
maybe more.

To make a search user A sends a search request (mainly a udp packet
with the protocol header and the searched string) to the nodes that
are closer to it.
When a node B receives this request it would look at it database to
see any of its torrents match teh search. If yes B would send A a
search reply, containing the tracker Ip/port, the hash of the torrent,
and its file name. A would then query the tracker to get any other
info it needs.
If this is indeed the file that A was is looking for he would then
download it from B.

The propagation of the search by B would be done even if it already
sent a search reply to A.
What i want to do in the propagation is to use a HOP count, so that
the propagation would behave like that:
A would send the request for all nodes that are 0 hops away from
itself. A node B that receives this request would increment the HOP
count and propagate it to nodes that are 1 HOP away from A. When C
receives this request it would them propagate it to nodes that are 2
HOPs away from A, and so on, until a max HOP distance is reached.
I THINK that this is doable with the Kadmilia approach, but i'm not very sure...
But this would reduce a lot the flood in the network and guarantee a
maximum coverage.

Another optimization for the protocol would be that if node B receives
a request for file X from A, it would cache this request. So that when
C tries to find the same file X, B would propagate the request
directly to A, in the hope that it has received a result from its
search. A, of course, would cache the results from its searches as
well.


I think that cover the main ideas I have by know.
Maybe i've not been very clean, but thats the best i can do by know ;)

What do you guys think of it?
-- 
KhaoticMind
TD of Scripting in ClanUED
http://sv4.3dbuzz.com/clanUED

"Things are like they are because that's how they are supposed to be."


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/BitTorrent/

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

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 





More information about the BitTorrent mailing list