[p2p-hackers] Common interest, finding trading partners

Vaste mllist at vaste.mine.nu
Fri Dec 31 04:18:20 UTC 2004

One of the reasons e.g. BitTorrent works so great is that when you 
receive a piece from someone, you can trade it for another piece with 
anyone else in the swarm without that piece. This works since everyone 
on a torrent (typically) are interested in the same file. With 
multi-file torrents this assumption is extended to several files as well.

In the file-based filesharing world (ed2k, gnutella) the same assumption 
hold, but but only for one file. And with batchtorrents, this assumption 
might brake even with torrent; one might only want a few files, (and 
e.g. using Azureus not even request the other files).

Still, two people downloading an episode from same tv-series are quite 
likely to be interested in the same files, and thus they might benefit 
from trading.

Has any research been done on how these peers with common interests can 
  find each other?

Mainly it's about finding the peer with the most coinciding interest. 
Still, other factors play in, such as the resources available (does the 
peer lack trading partners, i.e. has bandwidth to spare?) in finding a 
good match. On the networklevel it might also be good to find a balance 
between finding the "best" peer and creating a well-connected network 
(avoiding cliques and bottlenecks). Moreover, as interest's change over 
time, how should this be handled? (The more coinciding the interests, 
the longer it should take for them to deviate from each other.)

This is question is quite similar to finding a peer with pieces of a 
file you're interested in (that you don't already have). (The difference 
being that in the former, you search for _potential_ bearers of the 
piece.) Here the problem of matching a large number of preferences shows 
(namely the pieces; there are usually quite a few of them). The same 
things happens with many (especially small) files.

In the search-layer I believe this is usually handled either not at all 
(random) or in a binary way (complete file vs. only pieces of it), and 
leaving the details to the strict peer-to-peer chatting. Would there be 
any point in using more detailed information of finished pieces in the 
search layer? Would there be any use to use different resolutions (e.g. 
10 pieces resolution might be: piece 1-10: none finished, 11-20: all, 
21-29: some)?

An interesting take on this is the perspective of piece-based networks, 
where one searches for every piece separately. Here it's even more 
obvious how much one would benefit from finding people interested in the 
same file (the same pieces). Yet, introducing things such as patches, it 
would be pleasing to have a solution that didn't depend on peers wanting 
the exactly same pieces (defined by the file), but just roughly the same.


More information about the P2p-hackers mailing list