Slashdot Mirror
Ratio Vulnerability in BitTorrent Discovered
An anonymous reader writes "The "vulnerability" has been tested on all the major torrent trackers that use the torrentbits source code. The idea is that you will sniff your torrent info using the HTTP Analyzer and with Firefox you will update your stats to the tracker being identified as a client."
Was it really a good thing to make this public?
Won't this cause a new wave of leechers?
A lot of trackers are built on torrentbits.
Have you metaroderated recently?
now this. I can't believe it, my world is falling apart!
Unpretentious Sydney reviews by unqualified Sydney reviewers
I can't wait to see my pornbits ratios go through the roof! j/k
Ok, it's definitley a cool hack, but why are they calling it a vulnerability??? Maybe it's just too early and I haven't had enough Mountain Dew.............
My software never has bugs.
It just develops random features.
http://xyflar.blogspot.com.nyud.net:8090/
Guess now I really have to start seeding files. Thank you for spoiling it for me.
There are any number of parties who will headline "Vulnerability in BitTorrent!" and cound on most readers never bothering to get the facts.
Lacking <sarcasm> tags,
As much as many people will ask if disclosure was a good idea in this case, it's important to remember that if one person can find this vulnerability and make it public, an unknown number of people could have found it and be making use of it in the background. The functionality of BitTorrent depends on clients seeding copies of the file back into the network after having downloaded, and a vulnerability like this in a significant amount of trackers could easily cause serious damage to the operation of many torrents.
Business Voyeur
The way I look at it is this:
Step 1. Load site logs
Step 2. Do a search for these entries
Step 3. Ban any cheaters
I'm sure this it should be pretty easy to tell fake entries from real ones as I'm guessing that the tracker software, with a known IP address, is the only thing that should be accessing that url.
Seems kinda dumb that BT trackers rely on the clients to honestly report their ratios/upload amounts. Is it just this tracker implementation, or does the BT protocol work that way?
IIRC the ed2k network had a similar issue in its infancy, nowadays (with eMule anyway) "upload credit" is maintained as a relationship between each client (i.e. I know how much a person has sent to me, so I know how much I should reward them in my upload queue) -- no potential for abuse that way.
for promoting FF, but one of the steps in that list should be: set FF as the default browser ;)
You can't handle the truth.
Seriously, I thought this was already widely known. All info from the client to the tracker is sent with basic HTTP GET requests. You could fake your ratio with a simple php script. Well, maybe even by just typing the info in your web browser, however I think the urlencoding would be a problem.
This is not a vulnerability .. it's by design.
The statistics reported to the tracker by the client were never meant to be used for things like enforcing ratios because they TRUST THE CLIENT. But there's simply no other way to collect statistics such as amount uploaded.. if the client lies to you (which is what this "vulerability" is exposing), there is little you can do to protect yourself.
It's TRIVIAL (a 1 line change, or if you want to make it a parameter, a 4 line change) to modify any python open source client such that it 'amplifies' the ammount you upload by 10x or 100x. Then you don't need to do any HTTP sniffing, your client can just lie for you.
Now, there is a way to block this author's method because he doesn't amplify the upload, he creates a step-change in the upload ammount (which can be caught on the server side.. if it's been the same ammount of time since the last check-in, but suddenly his cumulative upload ammounts tripled, you're likely being abused). However, using my 'amplifying' trick from above, this is much trickier to detect. Perhaps you measure the client's upload speed on the website and record it to the database, maybe even double it just to be safe.. so you KNOW this client can only do 60 k/sec or whatever. Then when the client reports in stats, you take the time since the last check-in and you calculate his approxomate 'instantenous' rate. If this rate is higher then the upload rate you previously decided was this client's ceiling, then he's lying to you.
The above method is not foolproof, but it would likely be better then the nothing we have now. It was really only a matter of time this surfaced.. and I'm amazed it took this long.
--kRYPT
(author of burst! and MakeTorrent)
DJ kRYPT's Free MP3s!
I've been studying BT for over a year now, and this problem is very obvious and well-known. So, anyone who claims that they shouldn't have posted this because it's going to kill BT is wrong. They shouldn't have posted it because it's obvious to anyone who reads the BT protocol. You can just modify the source code and send a random real from zero to one, plus one, times however much you've downloaded and you've got a share ration between 1 and 2. Simple.
The simplest and best solution to this problem is the one that idiots (especially BT client developers like Bram Cohen and the Azureus dev team) tend to dislike the most: instead of forcing people to be cooperative by enforcing seeding requirements either in the client or at the trackers, simply recognize that swarming creates an inherently competetive environment, as everyone is really only concerned about their download and SHOULD only be concerned about their download, and let people use the most unscrupulous tactics they can think of to game the system. The way it will play out is that people will end up with a share ratio close to 1. The swarms become like little free markets: if you have a valuable piece, you can agree to trade for a lot of data. If someone breaks their agreement, you ban their IP address for a while. If you're willing to upload twice as much as you request from others, EVERYONE will want to trade with you.
If you do the math and economic analysis, everyone ends up trading on a 1 for 1 ratio, seeds only have to upload when there's very few peers (they simply require 2 bits from you for every bit they upload, that way people will only rely on seeds if they can't get a piece any other way, specifically, if the availability of the piece is zero), and no one other than the individual or group publishing the data needs to seed. BT was never meant (whether Bram Cohen realizes this or not) to shift the responsibility of serving from the publisher to the clients, it was meant to reduce the amount of bandwidth needed to publish data.
The current system is like socialism. It needs to become more like capitalism, and I'm not even a laissez-faire capitalist! Why no one realizes this is beyond me.
So please grow up and contribute to torrent communities, it's not difficult and it makes everything work better in the end.
This is nothing new, there's been client hacks for this for quite a while (http://www.00de.com/), there's also been ratio faking programs out for quite a while as well. So I really dont see anything additional that this 'xyflar' guy has added besides posting what's been known to pretty much every torrent user as well as pretty much every torrent site that uses ratios.
Your hair look like poop, Bob! - Wanker.
Anyone who has even so much as glanced at the protocol specification can see that the client is trusted to return an accurate count for how much it has uploaded. This wasn't a "disclosure" or a "vulnerability announcement"- it was a statement of the patently obvious.
The problem is not with BitTorrent. The problem is with BitTorrent trackers and sites which trust that value returned by the client. There are dozens of open-source clients, including the original- and all it takes is adding one operation that multiplies the real upload by whatever number you desire.
The functionality of BitTorrent depends on clients seeding copies of the file back into the network after having downloaded, and a vulnerability like this in a significant amount of trackers could easily cause serious damage to the operation of many torrents.
How did this pseudo-intellectual first-post get modded insightful? You clearly don't understand how the BitTorrent network is designed. Clients evaluate only how much data they receive directly from another client, and how fast. Nothing else factors into their decisions of who to upload. There is absolutely NO mechanism for the client to query the server to see how much you've uploaded, nor is there even a way to ask other clients. Why? Because both sources would be unreliable. Each client CAN only rely on direct "experience", unless they're engaging in a reputation system of their own hacking- if they are, best of luck to them, Bram wasn't an idiot for not trying that.
The "vulnerability" only affects trackers which "enforce" an upload ratio, and only to the extent of letting people bypass that ratio. Ratios is a concept that is pretty stupid with BitTorrent. The more you push back, the more you get, unless there is plenty of bandwidth. About the only "benefit" I see to ratios is that it might keep files available with seeds longer.
I hear a lot of crying about leechers on BitTorrent, but the network is self-regulating. Don't upload? You won't get much back. I think the perceived problem is also because reporting of the stats is unreliable- in the case of Azureus, for example, I can download a big file, upload 3x as much, and then if I get a connection error when my client stops, I "loose" all that uploading. I then look like a leecher, when it is exactly the opposite.
Please help metamoderate.
I tend to use public sites that don't keep track of ratios of individuals--honor system an all that--and I still always try to keep at least a 1.0 on all torrents, many of them usually end up at 2.0 ~ 3.0 just because ratios build up very quickly on popular torrens overnight on broadband connections.
It seems like from the posts the BT community has known about this for a while and it really doesn't seem to matter too much. Most downloaders who have at least a basic understanding of how torrents work will keep those downloads going caust it's just a nice thing to do.
Easy way to get your ratio up is to join a site that only allows you two slots on the tracker at first. Either download two small files and seed them or upload two of your own torrents and stay connected to the tracker so you are using your two tracker slots.
Using azeurus (or any client which stores peer IP's) stop on of your seeding files and connect to a large file you want to download, let your client pick up some IP's or until you are getting the file at a decent speed.
Now stop your download and begin seeding again, when you restart your download you will connect to the clients and your download will be resumed but the tracker will not be updated with the data you are download. AFAIK users who you are leeching off will still be given credit for all the data you upload.
Worked on elite torrents and some of the sites I use now.
All spelling mistakes are due to solar flares...honest
You're only detecting the small fraction of the cheaters that don't realize they're being obvious. If you look at my post above, I explain how it is very easy to trick trackers. You just use a random number generator to generate 1-2x the amount you've downloaded. It'll look totally legit.
Since when Firefox is more appropriate term for HTTP than HTTP?
I've been using Bittornado and Rufus for some time now, and with both, I get away with uploading at 3KBps and downloading as fast as I can manage. I have ADSL, so this means about 60KBps short of my 180KBps upper limit for downloading. But I've been known to download at 180KBps. (It's not that I'm a prick by nature, it's just that with my connection, I can only upload at around 12KBps, and the faster I upload, the slower I download.)
News for merdes. Shit that matters.
Ask me about my sig.
Being a formet BT tracker admin we knew of this well over a year ago.
Just download the original client and change the source code if you want to automate the process.
I just knew the Bittorrent protocol would somehow trust the clients for keeping statistics on downloads and thus be vulnerable to spoofing. The problem is that it's fundamentally impossible to gather statistics about processes on other machines are doing in a reliable way.
What's more interesting to me is how other services (ed2k?) do it, and if this makes them more/less/equally vulnerable.
A scheme I've thought of is where you submit packet length and a checksum (calculated from the packet contents) to the tracker, and the receiver of the packet sends the same data, and the tracker counts only packets for which it receives matching pairs from sender and receiver. This can help identify both cheating senders and cheating receivers, but, ultimately, doesn't provide any real protection, while still introducing quite a lot of complexity.
Please correct me if I got my facts wrong.
It is very, very, very easy to detect cheaters on private torrent sites -- which are the only sites where ratios really matter anyway.
Globally, across an entire torrent, the amount of data uploaded can't be greater than the amount downloaded. Think about it for more than three seconds and its rather obvious. Every single client reports their usage to the tracker. Every byte you upload must have been downloaded by another client, who also reports their usage.
And hash fails are counted as downloads by the client, so thats not a factor.
If the torrent admin looks through a torrent and sees Joe Cheater claiming to have uploaded 3.6GB, and it just so happens that the amount uploaded is 3.6GB more than that downloaded...its not hard to work out who's spoofing their stats.
Granted, the situation becomes worse when multiple people are cheating, but it's not too hard to track users who are on multiple torrents and pick out usernames who always appear to be on the torrents with the discrepancies.
I've seen it happen on private sites before, and it will happen again.
The short answer is -- you can fudge your stats all you want. But unless you can find a way to fudge someone elses stats to minus the discrepancy, you'll get caught. And rightly so.
Ratios is a concept that is pretty stupid with BitTorrent.
Right, stupid as in "people routinely saturate their downstream when ratio is enforced because everyone keeps seeding after having downloaded" and as opposed to smart, non-ratio trackers as in "people often get crappy speeds especially when they're on asymmetric connections because everyone kills the client after having downloaded the file".
BT is kind of self-regulating, upload more and you download more. But the self-regulation only goes so far and offers no incentive whatsoever to actually seeding files. Since a vast majority of the peers are on asymmetric links (e.g. ADSL), there obviously is a need for pure seeds to keep network speed at a high level, because otherwise the maximum network speed would be limited by the total upload speed of the asymmetric links.
Switch back to Slashdot's D1 system.
First of all, I don't use private torrent sites, so don't think I'm a cheater.
However, I can easily get 0.2 to 0.3 on most torrents when I'm done downloading. (I try to get a share ratio as low as possible, and not because I'm an asshole, read my post outside this thread for an explanation) And the thing is, each individual peer has no way of knowing that I'm not uploading lots of data to someone else, so just because my ratio to a given peer is low, does not necessarily mean my overall ratio is low. So, my false upload value reported to the server is not verifiably false, even if you have several "spy" peers that are connected to me and are not getting as much as they upload.
This idea is actually similar to the way plausible deniability works in the current version of Freenet. It is impossible to prove, no matter how many connections you establish to a member, that that member is not actually connected to another member that is requesting the data.
I suggest you take out a book on game theory and try cheating. You'll realize that if everyone were to act like an asshole (and not give away data unless they get the most they can get in return), the system will reach an equilibrium in which, for large swarms, NO seeding is needed.
You just give it the torrent, how much to "upload" and how much to wait between start and stop updates.
it's in SVN in my home PC so, it may not stay there for long if you abuse my DSL.
Just go where you want to install it and type:
svn co svn://arcanum.homelinux.org/cheatbt cheatbt
Please, no complaints about the code... i know :)
Slashdot Sig. version 0.1alpha. Use at your own risk.
If anyone gets hauled to court over their use of BT and these "amount shared" statistics are used as evidence against them, having the data be easily forged should help the defendent.
BitTorrent was designed as a data DISTRIBUTION system, not a data SHARING system. In taking the place of a non-P2P upload (http or ftp), any amount of upload is better than none, and clients that upload zero don't get as good performance downloading as clients that contribute.
Trackers were never meant to try and enforce upload ratios; it's too easy for clients to lie about how much they've shared, and too complicated and exploit-prone to work out a system where peers report on each other.
I've always thought that the best way for the MPAA/RIAA to kill bittorrent would be to break the protocol such that cheaters could leach without giving much back.
If you look at other systems where the amount leechers far outstrip people giving back the system pretty much gets bogged down.
Bram had always said his system works because every client is out for it's own interest. Researchers who have tried to "improve" BT usually have done something to break this model.
If I were the RIAA/MPAA I'd hire a bunch of crack programmers to try and create a "cheat" and then release the source code to that people would get to download with little or no uploading. That would effetively KILL many bittorrent swarms
About the only "benefit" I see to ratios is that it might keep files available with seeds longer.
I think that's what the GP was saying. If people have this hack to get around the upload ratio requirements they won't stick around to seed, destroying one of the most important aspects of BitTorrent (the trust that people will seed once they finish downloading).
So what if you don't use trackers but connect exclusively via trackerless torrents?
It would seem to me that the "vulnerability" only exists if you are sending data to a tracker.
This cheat DOES work... but it's rather suspicious to the admins when you do it. Like a thirty-second leap from a terrible download-upload ratio to a godlike ratio won't go unnoticed... That said, I had no problem TESTING it, but I contacted the admins of my favorite tracker and told them what I did, why, and got them to reverse it. They'll be watching for it now and banning anyone who tries it.
use it on boxtorrents and we will ban your entire ISP for a month. we know about it, we know how to monitor for it.
Ha, indeed. I care a lot about my stats, always tried to have a 2+ ratio 'just in case'. Perhaps there should be a workaround as in having the clients to periodically report their progress in uploading.
This exploit twiddles tracker statistics, but the "self-interest" part of BitTorrent is built into the P2P protocol. Peers upload more to other peers that upload more to them, and there's no way around it. Most BitTorrent trackers don't try to enforce ratios, and I personally think it's stupid to try.
Must be a lack of news today, this isn't by any means a vulnerability. Wow someone just noticed that you could make your browser report directly to the tracker. Most of the sites have anti-cheats that will catch such bogus crap. Might show that any site running on that code is subject to the problem, but mentions nothing about ways the site-ops deal with this problem.
It's very easy to detect cheating in a swarm. If a client reports that it's uploaded ten megabytes, but the remainder of the swarm has only downloaded one megabyte, there's obviously something askew. Of course, not everybody will get their stats counted accurately, due to disconnection and tracker outages, but things should average out reasonably (*). If these community-based ratio-monitoring sites simply count the number of times a given member is part of a swarm with a mismatched overall upload:download ratio, greedy leechers will be identified quickly. Can I recommend the paper "How to cheat BitTorrent, and why nobody does"? It's a lot older than this article. http://www.cs.unibo.it/pub/TR/UBLCS/2005/2005-12.p df
(*) Obviously I've never measured this or anything :)
Mod this tripe down! This has been covered several times throughout this discussion. The only thing this affects are a set of numbers which have absolutely nothing to do with the functionality of the protocol itself.
I'll turn into a supernova and burn up everything. Well I'll turn into a black little hole and you'll turn into string.
but that seems like a lot of work for not much return. I admittedly am not that good at sharing with limewire, and the like, and I almsot like bittorrents just becuse they force me to do so, and I do sleep a little better at night. I'm quite happy with the balance of "power" with torrents and although I love downloading lots of crap, I wouldn't stoop to such levels to increase my leeching ability. Also if a bunch of shitheads utilize this, People will just stop seeding such torrents, and use torrents with a different source.
The problem with that solution is twofold. Already beaten ad-anusium is the issue of two clients collaborating to cheat, which cannot really be compensated for.
The other issue less addressed is bandwidth. The tracker is the one weak link in BT, and if you recall back a year or so ago there was a problem with the trackers where they would send data on ALL peers, to all peers. (trackers now cap at 50 entries, randomly selected usually) This bug caused swarms that doubled in size to quadruple tracker traffic, because now there's 2x the peers, each requesting 2x the data. (so 2x the peers = 4x the traffic) This brought several large swarms to their knees as the trackers buckled under the weight.
Increasing the traffic between the client and the tracker, especially to this extent, would be devastating to BT. Right now all they report is data up and data down. That's like two numbers. Now imagine you're in a swarm and connected to say... 60 peers. That's 60 ups and 60 downs. Anyone can see that is an insane increase in traffic.
Right now things are set up correctly - the main enforcement on leeching is peer to peer review. You don't send me data? I'm not going to send you very much. This is traffic between peers, not between peers and the tracker, which is the best way to manage any distributed system.
I work for the Department of Redundancy Department.
A fix that several of the larger trackers I've used have put in place is to track both upload and download stats for everyone on the torrent. It quickly becomes obvious that someone is cheating if the total amount of uploaded data is greater than the total amount of downloaded data. This makes it rather trivial for admins to track down and ban people who cheat in this manner.
This system could certainly be broken by having clients intentionally amplify reporting of the amounts they upload, but there's no incentive to do this. Amplifying your uploaded amount or shrinking the downloaded amount is the only form of stat cheating that confers any sort of benefit.
You could try the exploits, which only damages the system and will get you eventually banned from your favourite torrent sites, or you could just get half a dozen downloading and go to bed.
Phillip.
Property for sale in Nice, France
For example, here in New Zealand, the fastest speed you can get is 2mbps ADSL, and depending on the plan you choose, when you hit 10GB of traffic (that's traffic in both directions added together), you either start paying excessive data charges designed to be so high as to force you to stop, or your bandwidth is reduced to 64kbps.
The latter option is obviously the one that the huge majority choose, and to the uninitiated, 64kbps seems like not such a bad idea. The problem is that the ISP acheives 64kbps by heavily dropping packets, and that results in much much worse performance than you would have got with a dialup modem connection.
I, for example, would be happy to leave BT running 24/7, seeding files, but I simply can't afford to do that, because at 2mbps, I can chew up 10GB in just 11 hours (actually less, because you have to include transmitted traffic too), and unless I want to have unusable internet access for the remaining 30.5 days of the month, I have to strictly control the amount of traffic I transmit and receive.
I don't see how this is a vulnerability. The bitTorrent protocol, as I understand, is based on a tit-for-tat principle which is worked out on a per-node basis (ie. if you upload to me, I'll be more willing to give you what you want).
I don't see how global ratios play into this in the least.. (each of the other nodes would say something like yeah, you've uploaded 10GB. Good for you. But what have you done for me?
I am the maverick of Slashdot
>You're much less likely to lie about someone
>else's uploads than your own. What's the point?
You aren't evil enough.
With everyone focused on faked uploads, if you deflate your down instead of inflating your up, you make everyone else look like cheaters.
"It couldn't have been me cheating, look I didn't even get to download the whole file before the torrent expired. Do more about all those cheaters!"
Plus, it is easy enough to watch for the delay between clients announcing and then when a leech announces, report a large upload yourself before the true seeder announces. Bam, it looks like the true seeder is cheating.
My favorite pirate site is full of slashdot-reading geeks who keep greed in check. Users who actually upload to get good ratios (favored by the moderators of pirate sites) made a forum thread regarding the problem. The moderators caught several members using the exploit and banned them. Some members of pirate sites are dishonest, so they were weeded out.
Greed, to an extent, is acceptable in a community based on sharing copyrighted material; lying and cheating are not acceptable.
I'll be your candy shop of infinite deliciousity if you'll be my discotheque of endless rump-shaking.
Here in the US, it's annoying that my cable modem company offers about twice the downstream bandwidth I get with ADSL, for about 1/2 - 2/3 the cost of decent static-IP open internet. I might be able to get faster service now that my telco has added 3 Mbps ADSL that my ISP could resell, but I'm far enough from the telco wire center that it may not really pay off, and even at 1.5 Mbps I'm usually not saturating my downstream connection except during occasional good Bittorrent sessions.
There are worse ISPs - VSNL in India, a variety of government-monopoly PTTs, almost anything in Africa. China's duopoly are difficult to deal with, but getting better, and many of their problems are driven by the censorship issues. Of course, China's also got diverse enough service that it not only has spammer-friendly hosting but also zombie-compromised broadband services.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I can't believe this... my post gets "Flamebait" and this gets +5? >Globally, across an entire torrent, the amount of data uploaded can't be greater than the amount downloaded. Guess you've never heard of lost packets. >And hash fails are counted as downloads by the client, so thats not a factor. "CHANGE: Core | Download totals don't include hash fails and discards and aren't included in share-ratio calculation [Parg]" From: http://cvs.sourceforge.net/viewcvs.py/*checkout*/a zureus/azureus2/ChangeLog.txt?rev=HEAD
>If the torrent admin looks through a torrent and sees Joe Cheater claiming to have uploaded 3.6GB, and it just so happens that the amount uploaded is 3.6GB more than that downloaded...its not hard to work out who's spoofing their stats.
This assumes ALL of the following:
1) Nobody has canceled a download.
2) Nobody has falsified their amount downloaded.
3) No data is ever discarded and there are never any hash fails.
4) No one controls more than one client.
>The short answer is -- you can fudge your stats all you want. But unless you can find a way to fudge someone elses stats to minus the discrepancy, you'll get caught. And rightly so.
Because it's SOOO hard to get another IP address.
Goddamn idiots! Learn something about computer networking before you post here, PLEASE!
I can't believe this... my post gets "Flamebait" and this gets +5?
a zureus/azureus2/ChangeLog.txt?rev=HEAD
>Globally, across an entire torrent, the amount of data uploaded can't be greater than the amount downloaded.
Guess you've never heard of lost packets.
>And hash fails are counted as downloads by the client, so thats not a factor.
"Download totals don't include hash fails and discards and aren't included in share-ratio calculation"
From:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/
>If the torrent admin looks through a torrent and sees Joe Cheater claiming to have uploaded 3.6GB, and it just so happens that the amount uploaded is 3.6GB more than that downloaded...its not hard to work out who's spoofing their stats.
This assumes ALL of the following:
1) Nobody has cancelled a download.
2) Nobody has falsified their amount downloaded.
3) No data is ever discarded and there are never any hash fails.
4) No one controls more than one client.
>The short answer is -- you can fudge your stats all you want. But unless you can find a way to fudge someone elses stats to minus the discrepancy, you'll get caught. And rightly so.
Because it's SOOO hard to get another IP address.
Goddamn idiots! Learn something about computer networking before you post here, PLEASE!
>Even in your hypothetical economically ideal system, the system could benefit from people being tricked into giving more than they intended.
The system benefits, yes. And I'm sure that many people would choose to seed if they can spare the bandwidth, even if they get nothing out of it. The problem though is that some clients will allocate bandwidth for seeding even when there's another download in progress. Also, people might be mindful of the amount of data they're uploading. Maybe someone is on an ethernet LAN, and the seeding causes contention with other users. My point is that since seeding is usually of no benefit to the seeder, and since seeding can in some cases be detrimental, it shouldn't be forced on people by moralistic clients (and client developers).
>Your pet peeve with the BitTorrent protocol is that seeds always upload as fast as possible, when that isn't always necessary to get the file distributed. Well I think you have the objective of the BitTorrent protocol wrong.
You are correct in that we disagree on the primary use or "objective" of BT. Most people see BT as a (illegal) file sharing tool for an informal cooperative group, and that is why they get angry when someone doesn't seed. They say, "You're getting something for nothing here, the least you could do is seed!" Instead, I take the view of the researcher comparing this peer-to-peer architecture to the standard client-server architecture. There exists an individual or group that wishes to distribute information to a large number of people. The distributors care only about the health of the swarm. They want to spread their information as wide as possible. And they'd like to do it as cheap as possible. Then there are the downloaders, who just want to download the data as fast as possible, using only as much of their possibly precious upload bandwidth as possible. A good example of this situation would be a movie trailer. Note that I have nothing against illegal file sharing. To me it doesn't matter what the bits represent, only the manner in which they are distributed.
The behavior of the clients should reflect the goals of these "rivals." (economic term) The clients should not act in a way that their users would not want them to, because that creates an "unfair" (networking term) situation: those people knowledgeable enough to modify their clients could take advantage of the rest.
Using seeding and leaching algorithms that are in economically equilibrium is the only way to eliminate the "unfairness" described above.
I advocate maximizing the average download rate, but only with no unfairness. You seem to advocate maximizing the average download rate at any cost. This is actually not a bad thing, and I will not criticise you if that is the case. TCP congestion control has similar fairness problems, and there are two well-established camps: those who believe fairness is more important than speed, and those who believe speed is more important than fairness. While I am in the former camp, I do respect the opinions of the latter, so long as they know why they believe what they believe.
>Furthermore, even if the objective of seeders was to conserve total bandwidth
I believe seeders are really only concerned with distributing whatever data it is they are trying to distribute. They care about the health of the swarm, and will use upload bandwith if it will help the swarm. But if seeding will not help significantly, then it is better for them to do something else with the bandwidth, like seed for a more needy swarm.
>A seed on a symmetric connection would only use half of its upload at maximum
I said 2 bits for every 1 bit, but that could be changed to maybe 11 for 10, just enough to encourage peers to trade with each other as much as possible before asking for assistance from seeds. And while the maximum bandwidth would be slightly less, it would be used much more effectively, if a client is seeding hundreds of swarms.
>downloading from swarms with mostly seeds wo
I did in several hours program that automatically encrease ration without uploading downloading to peers. Here are installer. http://www.esanu.name/programs/ Good luck!
So why is the bittorrent protocol doing (essentially) this?
Because it's considered unimportant data?
Consider that the only people truly relying on the accuracy of the amount of data shared for any serious purpose are the people who want to prosecute you for any illegal works shared.
That the field can be inflated now becomes a defense against inflated charges based on the quantity of data allegedly shared illegally. The accused can claim he falsified the figure and the prosecution would have to go to a greater effort to prove the figure accurate. Can an accurate figure be calculated from tracker-side sources?
I wouldn't recommend relying on this as one's only defense. IANAL.
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
We want a system where everyone is getting a fair chance to get the file using the protocol in the way it was meant to function.
Seems to me a truly fair system won't care how much any one user has shared; everyone would be served equally. The rate of download should be a function of the number of people sharing limited only by your own bandwidth cap. The amount any user shares is braggadocio points and should not have been relied upon to make trafficking decisions in the first place. A meritocracy that punishes latecomers leads to snobbery and those left out game the system at best and sabotage it at worst.
Anyway, it seems to be a basic tenet that unreliable data should not be relied upon.
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
How many who could would bother though. Honestly I could probably whip this up pretty easily, but I've got much better things to do with my time than hack torrent ratios.
Most of the kiddies who would like to use this to leech probably couldn't script it, though I suppose they might find somebody else's script online.
While automatic seeding is *technically* not in equilibrium, you are correct that my argument would be rather poor if that were the only thing that differs between the current client implementations and the ideal which would always act in the downloaders' best interest.
There are many other ways in which the BT clients are "unfair." (again, I stress that this is a technical term) I can't go into all of them here, but one of the biggest that I can explain, since you do obviously have some understanding of this subject, is the problem of optimistic unchoking.
If you don't know what that term means, then Cohen's original economics paper gives a good explanation. Azureus, the best client I know of and the one I use, though there are still problems with it, will even let you see which peers you are currently optimistically unchoking.
Anyway, the problem is that EVERYONE does this, ALL THE TIME. I assume that you already know why. But, now assume that one person modifies their client so that it doesn't. He will still be optimistically unchoked by everyone he is connected to, and can therefore determine the upload rates of his peers, which is the whole reason why the clients do this. By disabling optimistic unchoking, the peer gains a slight advantage in that he can always be uploading to the best peers he knows of, instead of risking bandwidth to test out peers. We therefore conclude that in the current environment of everyone optimistically unchoking, it is in each individual's best interest to completely disable optimistic unchoking.
Of course, this leads to a problem. If all users do this, as we should expect them to, then the environment changes and now NO ONE optimistically unchokes. In this scenario, the best thing to do is once again risk some bandwidth to test peers by optimistically unchoking. Therefore, it becomes in everyone's best interest to optimistically unchoke, and we should assume that they will do so (given the fact that once a client is written that allows people to disable/enable OU, people won't have to know how to modify the source and recompile). This creates the previous environment, where everyone is optimistically unchoking. You would think, therefore, that people would be constantly switching OU on and off. But there is an equilibrium strategy: optimistically unchoke only a certain percentage of the time. Calculating what this percentage is would be difficult, as it would rely on many variables including the number of peers you are connected to, how often and how recently you have OU'ed them, your current download rate, the percentage of OU'ed peers that become permanent, and so on. What the clients should do is EITHER allow the user to choose a value for each of the variables I mentioned as well as a formula for how those values are to be combined, OR allow a plugin that will decide when to OU that the user can write in a high level language, OR both.
Hopefully, you can see now that my last year has not been wasted.
Unreliable data should not be relied on yes. In this case it's upload numbers provided by the user.
By the user or by the client controlled by the user, it's just as unreliable because the user can have compiled his own client. It is after all open source. There is no "fix" so long as the client can lie, and any secret handshake has to be in the open source of every client. Either you try to catch the client in the lie or you just discard the data as untrustworthy and redesign around the problem.
Also, someone lying about their quantity of shared data may not be doing it selfishly but rather altruistically, seeking to get more of the file faster so that they can provide more parts to others. (Though an algorithm that limits the downloading of clients would probably also direct sharing to those with less of the file than those with the whole file to aid in their promotion.)
BTW, I refuse to call them "upload numbers" because there really is no uploading involved. P2P as it exists today--even bittorrent--is strictly downloading. Not even the seeder uploads; no files get transferred without someone choosing to download. If it were uploading, it would be pushing data to people that didn't request it, creating additional mirrors; a bittsunami if you will. (There is at least one system that does behave that way, but its purpose is not to increase the performance of data transfer.)
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?