Is BitTorrent Search Harmful?

protee writes "p2pnet published a report arguing that the robustness of BitTorrent to free-riding might have been more related to the lack of meta-data search rather than to its tit-for-tat-like strategy. The question now is: how the release of such search engines is going to impact the BitTorrent network?"

What difference does it make?

[Bad to the Ben]

If the number free loaders gets too great, nobody will be able to get fast downloads off of BT due to lack of seeds (or whatever they're called). Once that happens, popularity amongst freeloaders declines, service returns to normal. A file sharing system without anybody seeding any files is a waste of time.

There is no "BitTorrent Network"

[stripmarkup]

The main strength of BitTorrent is that it works on individual files. It is not a network, rather a protocol like ftp or http. Ftp sites that offer copyrighted content can be taken down, but the ftp protocol is alive and well.

Not sure I buy the analysis

[Paul Crowley]

The thesis is basically that by causing your client to change identity frequently, you can take advantage of the leniency that BT allows newcomers to the network, and thus "leech" without punishment. This isn't done because you'll get kicked out of the communities that publish BT metadata if you do it.

I don't see it. If you're going to leech, that's the way to do it, but cooperating overall results in even better upload rates; you're not fighting for the few slots afforded newcomers, you will be given as many packets as you can eat as fast as you can eat them so long as you reciprocate. And I'm sure those communities will survive - I suspect that Bram will have thought of how to integrate search with community.

Blocked already

[drhlx]

A quick search of torrentspy [torrentspy.com] ("os x tiger") [torrentspy.com]:

There has been an error with your search This search query has been blocked at the request of the copyright holder, in compliance with the Digital Millennium Copyright Act ("DMCA")

I was betting mates this would happen... shame I didn't put a $ figure on it ;-)

Re:Funny search

[lordsilence]

As piratebay has pointed out before, sweden is not a state in the USA.
Sweden is a small country in the north of europe.

RIAA-imperial navy can stay the fsck out of sweden, thank you very much.

Re:Blocked already

[Anonymous Coward]

Though doing a search for just "tiger" isn't blocked and returns equivalent results.

That just shows that the effectiveness of blocking search parameters to limit search results is minimal, unless you take the baby out with the bath water.

Re:Blocked already

[paul.dunne]

They've blocked the *search*, as they have that for Star Wars III.
So, do an advanced search for "tiger" in the applications category,
and guess what? The torrent files are still there, and still downloadable.

Re:Serious Question

[ScrewMaster]

Afraid not. Bit Torrent depends upon a central "tracker" computer to keep track of who has what pieces of the torrent so that clients know where to go to get said pieces. Remember that Bit Torrent was not designed as an anonymous protocol and was only intended to efficiently distribute large files, such as Linux distros. Consequently, it's almost as easy to monitor who is downloading what as it was for the original Napster service. If you download using Bit Torrent, your IP address is wide open to any media company investigator that wants to query the tracker. And they do, so do it at your own risk. Some clients, like Azureus, offer extensions to the Bit Torrent protocol to support anonymous tracking but I don't know how widespread it is (or how well it works in practice.) But I'd say there's not much question that this is a technological issue that will be effectively addressed in the not-to-distant future, either by Cohen himself or some other equally bright developer.

Re:Isn't the principle of Bittorrent...

[Anonymous Coward]

Not true, the first official BT client had the ability to limit the number of peers you could upload to at a given time on a per torrent basis, but no actual bandwith limiting. (And this was only available at the command-line with python installed using btdownloadheadless.py - not available on the compiled windows GUI version.

By the 2nd (or was it 3rd) release bandwidth limiting became available - but still only at the command-line and only per torrent - no ability to have 3 torrents running with total UL choked at 20K. Instead you would need to limit one to 6K and the other 2 to 7K for example.

At any rate, limiting bandwith at the command-line by running a py script with the required command-line switches to limit the bandwith is not something a newbie would be doing anyway.

AFAIK, it wasn't until Azureus came out that you could limit the bandwidth globally for torrents instead of a strict rate per torrent. I always used the stand-alone limiting program "NetLimiter" before.

Re:Just wait....

[medgooroo]

done. http://www.peercast.org/ [peercast.org]

Re:bittorrent works...edonkey is slow

[Danathar]

I've never been in a torrent where there was'nt at least SOME aggregate downstream bandwidth in and above what the uploading clients were taking. But, when you first join a torrent the protocol is written so that seeders that are done downloading are three times as likely to choose new torrent clients with little or no data over clients that already have some data and are uploading. I should say at this point I really don't know EXACTLY how this works. Except that it seems that there is a percentage involved of how much a seeder gives a leecher before it stopps giving anymore (unless th e leecher starts uploading)
---from the article--

Once a client has obtained a list of other peers, it will contact them to try to fetch the data it is looking for. In BitTorrent, file contents is split into small-sized pieces and each client maintains the list of the pieces it holds. After a handshake, peers exchange their piece lists so that each of them may determine whether the other has some pieces they are interested in obtaining.
The bandwidth being a limited resource, a single client cannot serve every peer interested in pieces it holds at the same time. The maximum number of peers served concurrently (i.e. the number of available slots) is configurable by the user. All other peers connected to a client (whether they are interested or not) which are not being served are said to choked. In consequence, each client implements an algorithm to choose which peers to choke and un-choke among those connected to him over time. The strategy proposed by BitTorrent is named "tit-for-tat", meaning that a client will preferably cooperate with the peers cooperating with him. Practically, this means that each client measures how fast it can download from each peer and, in turn, will serve those from whom it has the better download rates. This strategy is implemented for all but one slot which is attributed to an interested client, regardless of its upload rate. This so-called "optimistic unchoking" allows for the discovery of better peers than those currently selected (i.e. those with higher upload rates). This strategy, however, if implemented strictly, would considerably slow down the insertion of newcomers into a running swarm as, they obviously do not have anything to share at the beginning. Thus, clients that have nothing to share are given three time more chances to be selected by the optimistic unchoke. When a client has finished downloading a file it no longer has a download rate from other peers but it can still share (upload) pieces of the file. In this case the choking algorithm is applied by considering upload rate instead. Peers are selected based on how fast they can be uploaded to. This spreads the file faster. Such "seeder" peers that store the whole file are very important to the functioning of a swarm. If a swarm contains no seeders it may lead to a situation in which pieces of the file are missing from the swarm as a whole. In this sense the system requires at least some level of altruistic behaviour from "seeders".

Seriousness

[tepples]

a problem fixed by the very behaviour of each serious user who downloads then lets the file on his disk (seeding it) 'till it reaches at last a few days there or a good (> 1) share ratio.

True, but as a file transfer system becomes easier for novices to use, it is likely to draw users who aren't "serious", who cancel the upload as soon as the download completes. And if you try to enforce share ratios on a registered tracker, remember that the mean share ratio across all users is exactly 1.0; therefore not everybody can have a cumulative ratio >= 1.0. What happens when demand falls off for a file, and though you leave the upload going, nobody downloads more than a couple megabytes for days?

If it matters, my personal rule when downloading something on BitTorrent or eMule is to let the upload go 24 hours after the download completes, then let it get up to at least ratio>=1.5 or one week, whichever comes first.