Slashdot Mirror
Researchers Create Selfish BitTorrent Client
An anonymous reader writes "Researchers from the computer science department at the University of Washington have released BitTyrant, a new BitTorrent client that is designed to improve download performance via strategic selection of peers and upload rates. Their results call into question the effectiveness of BitTorrent's tit-for-tat reciprocation strategy which was designed to discourage selfish users. Clients are available for Windows, OS X, and Linux."
internet bandwidth usage has just gone up by 300% at the University of Washington... Scientists are baffled and blame global warming.
AFAIK, all bittorrent clients have a "UserAgent"-kind of field. If that happens to be BitTyrant, ban the user.
It looks like all it's doing is trying to allocate its uploads more efficiently. Which, assuming it works, should improve things overall, and (if it works) may even get adopted into the official protocol.
I am trolling
First some crap clients allow easy tunneling of torrents through tor network (http://tor.eff.org/), nearly choking it, and now this.
'Once scientists, even the dim-witted social scientists, get muzzled, the Western Civilization is finished.' - oldhack
I'd rather see some development towards somehow preventing a client from finishing a download until his Down/Up ratio is at least 0.75. This would be difficult to do since you can't trust the client.
Fsck the millennium, we want it now.
Millennium Crisis Line: 0890 900 2000 [calls cost 50p/min]
However it will be only a matter of a couple days before people/trackers just start banning the client. (even thoguh it soundsl ike it is not actualy a bad client).
The only possible downside of the client is that people who regularly hit and run will be doign so that much faster (and thus end with an even lower ratio).
so, a nifty tool in the hands of the godly, and an abomination in the hands of sinners. (or somethign to that effect)
Do Or Do Not, There Is No Spoon, There Is Only Zuul. Everything in the above post is probably opinion.
The private trackers, which require login and facilitate banning of users who abuse the system, will simply deal with this as they always have. That's always been one of the protocol's inherent defenses against something like this.
Slashdot Burying Stories About Slashdot Media Owned
The UserAgent field is not guarenteed to be accurate, just like the HTTP UserAgent field.
The nice thing about BitTyrant is that this strategy only works if everybody else is using different BitTorrent tools. A BitTorrent client which can reasonably detect leechers from sharers (and only shares to those that share) should finish off tools like BitTyrant. In fact, BitTyrant itself would probably kill other BitTyrant users.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Bah. Torrents are only good for wannabees and virals anyway. Just make sure your isp has your mums contact info correct for the riaa.
Never trust the client.
I'm surprised it took this long.
Selfish selection of peers can lead to cliques of clients on the same network. Tit-for-tat has been proven as a highly effective strategy in games resembling the iterated prisoner's dilemna, but it can be defeated when a large enough group of of agents cooperate. This link has more.
"Their results call into question the effectiveness of BitTorrent's tit-for-tat reciprocation strategy which was designed to discourage selfish users."
he said tit,...heh hehe heh.
Just use a leecher modded BT client if you really don't care about ruining BT for your faster download. This has been around for AGES...
I'd like to see the opposite. Haven't these researchers heard of ratio sites? It'd be cool if, when among 20 seeders and 5 peers, my client were involved in the uploading more often. As it stands, in that situation my client usually appears to be sitting idle most of the time, or occasionally uploading 5 - 10K/sec for 30s to a minute before idling again.
Make my client have the ability to seed more proactively and I'll be happy.
RTFA. They didn't create a client that is "selfish" by trying to avoid uploading. They created a client that is selfish by first allocating more upload capacity to other clients that will send them more when they upload more, and only allocate the remaining upload capacity to clients where benefits from increased uploading are not certain. If you read their paper, they regularly bring up the effects of this on the entire network and they don't know if it's good, bad, or has any effect on the network (and not for a lack of trying)
I'm surprised it took this long. Or is it just that we're only hearing about it now, but such clients have existed for ages?
By the way, am I right in thinking good behavior can never be enforced in peer to peer systems?
Please correct me if I got my facts wrong.
Had issues with leechers with ABC so I switched to uTorrent. It automagically stops sending data to anyone who drops below a certain ratio. In short, if you aren't uploading to me, I am not uploading to you. Whereas with ABC, I'd be throwing 50KB/s up and getting mabye 5KB/s down or reverse, with uTorrent it's usually been 40 up and 30-50 down.
Simple, effective, failsafe.
Of course a protocol can be taken advantage of, how is this news? But, responsible researchers would point out the flaw, tell the bittorrent people and come up with a fix or work with the bittorrent people to make a fix. At most, responsible researchers would make proof of concept (which can be done by paper and pencil btw), NOT making a full blown client and publish it for 3 different platforms.
Something tells me that these guys are looking for there 15 minutes instead of doing good research.
Some folks at ETH Zurich took it one step further, and wrote a client - BitThief - that doesn't upload and yet still can download as fast as a regular client. This is especially valuable in countries that define copyright violation to be the uploading of content.
"Enlightened Self-Interest" would be a better term than "selfish".
The anti-leech technology of the bittorrent protocol remains effective. Those ranting about this just haven't bothered to read... This client (despite the unfortunate name) is just smarter about how to use upload bandwidth, in an async world.
In fact, I would say this is an IMPROVEMENT in some ways over bittorrent's default behavior, as it will dedicate more of your outgoing bandwidth to higher-speed peers. They, presumably, can then serve up more data to others than a low-speed peer reasonably could.
Instead of being the end of bittorrent, this could really improve the health of the P2P network, increasing speeds and decreasing download times for everyone (not only those using this program).
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
It would be a welcome feature to be able to tune my uploads so that I don't kill my connection when downloading over bittorrent. the --max-upload-rate feature seems to make my bittorrent client do an endless recursive loop that ends up crashing the client. I have a very low upload cap, around 15 KBPS, and when it gets maxed, I'd like to be able to limit the connection just a little, to leave room for ACK packets.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
BitTyrant (read the paper) [i]follows the protocol[/i].
From any other peer, you can't tell whether someone is using the BitTyrant bandwidth selection strategy or the default allocatino strategy, and user agent is, of course, meaningless.
Test your net with Netalyzr
Buy Steampunk Clothing Online!
Clicky to pirate bay
"I may be full of crap about this game, and I may be wrong, and that's fine." -Jack Thompson
when you see the picture, it really looks like an
azureus http://azureus.sourceforge.net/ fork even the icons are similar
Awesome! If everyone used that client, the MPAA/RIAA wouldn't have a leg to stand on.
Or just being a leech you mean. How's the air all the way up on top of your high horse?
I want to delete my account but Slashdot doesn't allow it.
I'd love to give it a spin, but at 2kbs download for the client installer I'll be here all night. Maybe I can find a torrent for it for a faster download...oh the irony.
My haxored ctorrent does that too, duh, just comment out the right bits of code & tada!
I'm downloading the OSX version right now and the progress is so slow. Getting 5k/s on my 8Mbps connection. Surely they should have torrented the thing???
spoonerize "magic trackpad"
Like you mentioned, one can set Azureus or most other clients to seed indefinitely. What I'd ideally like to see is the opposite of what BitTyrant does. BitTyrant optimizes by selectively choosing peers based on up to down ratio, weighted by upload capacity. I'm assuming at this point that it doesn't do any special handing for seeding.
What would be cool is if there were the ability to have the client selectively prioritize based on completion status and download rate, especially given a limited number of upload slots. Something that will not only guarantee I'll use the amount of upstream I intend, but which will also prolong the amount of demand for my seed. (instead of being optimized to create more seeds, thus reducing my specific seed's demand.)
I have it installed, and I'm currently downloading (Full T1) at 50k and uploading at 60k... I'd say that's more than fair.
This does seem to go up and down more than bitcomet though. in the last Hour I've seen it up to 110/115 and as low as 50k/60k. Maybe this one just averages the xfer rate a lot more often, not producing nearly as smooth of an average as BC.
Do not meddle in the affairs of sysadmins, for they are subtle, and quick to anger.
OK, I downloaded the app and ran a test - an 815M movie file, 634 seeds, 3186 leechers. Test file was pr0n from a chinese server.
My configuration was 1000kB/sec upload, the highest allowed by the setup wizard. I'm on a 100Mb connection so can easily handle that. Everything else default.
It's not so selfish. After connecting normally and downloading initial data at a trickle, my client began uploading at a huge rate - 500kB/sec - a level which continued to rise to the life of the download. The upload rate seemed to "spike" a lot, generally describing a sawtooth pattern on my bandwidth monitor - whether it was the program doing this or something else, I don't know. Anyway, it uploaded like mad, regularly up to the 1 megabyte per second upload cap.
Downloading was fairly slow, certainly no more than I would have expected from regular azureus. It picked up speed slowly through the download but seemed, if anything, to take longer than usual to hit its "stride". Of course it is impossible for me to provide a "control download" to compare, I'm just going on personal experience here.
The download finished after 45 minutes and 48 seconds, which is not all that slow but nowhere near the maximum possible. I regularly see speeds of over 1MB/sec from this "cloud" but speed never exceeded 600kB/sec, and usually much slower. Still, an average of 300 kilobytes a second was not so bad, and who knows, maybe it's faster than azureus alone could have done. I cannot help but feel, however, that it did not go as fast as usual - I am accustomed to much higher speeds from sources like this.
And finally, it completed the download with a ratio of around 1.6, then continued seeding after completion. Hardly "selfish".
So, as always, take the claims with a grain of salt. After seeing the lack of performance here, I certainly won't be switching from regular azureus, I encourage you to peform your own tests. My reference link was here: http://www7.2kdown.com/link.php?ref=BjgWaTvsmP
Of course, the downside is that you won't get many packets from anyone using this new BitTyrant client as it prioritizes outgoing packets to those computers it receives from. So i suppose you make a legality tradeoff for speed.
...they have created a bittorrent client that sucks less than all the other bittorrent clients. This doesn't threaten the bittorrent protocol any more than having better cars threaten the road system.
Gotta say, these speeds are really impressive. Azureus 2.5 would download at about 35kb/s, while the same torrent on BitTyrant is 400kb/s. I use a private torrent network, so I'll have to make up for the ratio afterwards; but still, it's great to get things so quickly.
How does it work? The BitTorrent protocol is supposed to prevent this. The tit-for-tat behavior means each client will initially send you a chunk, but after that you have to send something to get something.
The algorithm covering up/down ratio and bandwidth on bittorrent sucks...
On average, nearly all torrents I've ever downloaded have always maxxed out at around 5-20k/sec download, which makes a download that ftp would do in several minutes take hours or even days on bittorrent.
This seems true even if there are hundreds of other users/seeders on the same torrent.
Also it nearly always turns out that you have to upload 3 or 4 times the amount of data than downloaded before the download finishes. That means the algorithm is (still) broken. Assuming others on the torrent are also experiencing the same thing, where is all the extra data going and why is bittorrent so slow if so much uploading is happening?
Watch this client get banned from every single private tracker in the world!
Uh, high horse? You're the one with the ivory tower up your ass. I'm more than willing to provide some bandwidth to some people whose laws are restrictive. Well, of course, so are ours :P But you see what I'm saying. I still want to prioritize non-leechers first, however.
the bitthief webpage is a big (well, small) pile of shit with basically no content except a download and a claim. I suspect it works, but only by connecting to craploads of peers. If you have few peers, who are uploading to people who are actually uploading to them, it probably doesn't work worth a damn.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
So what you're basically saying is that you want a client that gives more upload capacity to poor uploaders, thus improving your ratio while keeping demand for your upload capacity high through essentially wasting your upload capacity? Sounds like something I'd want to keep far away from my swarm, as a wasteful strategy like that would kill the speed in a torrent.
Emule has a system like this, and it basically slows everything down in the name of fair sharing. It takes absolutely forever to start downloads, since you're stuck in a vicious "chicken and egg" circle of "I can't upload anything to download" and "I can't download anything to upload".
As it stands, Bittorrent is how the Edonkey protocol used to be before ratio systems were added to the clients; Fast. After Edonkey started adding anti-leech systems to the clients, the speed went into the toilet, and the queues started skyrocketing.
I suspect that if this catches on, you can kiss 300kb's downloads goodbye.
In Soviet Russia, Trojan exploits YOU!
It would prolong the longevity of the torrent by keeping it active longer.
Also, I didn't intend for my comment to sound as though it would only help those who aren't uploading much, but a combination of weights based on a client's upload rate and completion status. In fact, though it might help my ratio, I abhor people who just connect to leach and disappear.
Different swarms have different problem behaviors. Private trackers versus public trackers versus commercial versus 'sponsored' trackers (my neologism for trackers hosting 'permanent,' widely available content like linux distributions.) On some you have an issue of hit and run. On others, it's a different game.
In the end, I think these seeding/peering strategies need to be options left up to the user. Let the trackers decide how to deal with users whose clients seem to be behaving against the wishes of the tracker owner.
It does not seem to be really faster, but I notice that my upload speed is at 0 a lot of the time, when with the regular Azureus my upload speed was about always maxed out. It runns just since a few hours, so don't take my comment to serious.
I just don't trust anything that bleeds for five days and doesn't die.
P2P survives on the goodwill of its users.
This is How BitTorrent Will Die From Within.
What is 'tat'?
Where do I get it?
And how do I exchange it for the other thing?"
-- Dennis Miller, Weekend Update
As far as I can tell it would be beneficial. So what if they get the whole torrent faster, it means they will become a seed faster and therefore allow the slower people to have a chance as well. It has always been up to the user to stop seeding before the share ratio is at least 1. BitTyrant would only be truly selfish if it chose not to seed at all, but because it doesn't, it will be the same old asshole leechers (and probably dial-up users and people with poor upload limits) that don't seed anyway.
It gets the torrent faster = it becomes a seed faster
BitTorrent is already based on selfishness. In fact, that's why it works so well, because peers tend to seek out "partners", other peers which can trade high bandwidth with each other. A client which is *completely* selfish and doesn't upload at all will usually not get a decent download. A prioritization algorithm which is more intelligently selfish can only participate better in the bandwidth market and thereby actually improve BitTorrent's performance.
It works.
Bit Torrent has always been rather slow for me, but this is zipping along quite nicely...
High horse?
Sounds like somebody is overly altruistic and foolishly thinks they not only can expect reciprocation, but that they deserve it for some reason.
If you can get what you want as quickly as you want at lower risk to you, you should take advantage. Almost everybody else will.
I'm working on p2p research and BitTyrant reminds me of a paper at the p2p economics workshop called SWIFT that looks at the byte-for-byte trading model from an economics perspective. Other papers by the same guy are here.
On the campus (UW), the firewalls/NAT prevent us from connecting to many other peers so downloads take days. Instead we use DC++.
I wonder when will we see an emotional client which gets upset when it doesn't get the piece it requested; it could get jealous and dump the peer. Or perhaps a vindictive client. A selfish client wouldn't last long in such an environment.
~half the dee~
If you read their info, it seems like the 'standard' method really gives the shaft to high-bandwidth users. So right off the bat, those users are going to see real benefit (up to 70% faster in some scenarios).
Another interesting point they make is that having a great number of 'selfish' users will degrade the service for EVERYONE, including themselves. Kind of like real life!
I use "BitTorrent" on a Mac.
Either the implementation or the protocol is broken anyway. When I like to download a file 'A' it e.g. starts with 14 seeds in 20 peers. Then over time it degradfes to 5 seeds in 6 peers (for example). When I stop the program and restart it, it might be it starts with 13 seeds in 18 peers again. For some reason it does not realsie comming and going seeds/peers.
Even worse: I try to set upload to a max, like 1Mbit or something, but instead of maxing the file A and instead of me getting max downoalds on file A it maxes downlaod on another file like B and maxes uplaod on file A.
So to get max downlaod speed on the file I really want most, I have to stop all other downloads.
In other words: on this client, which is called BitTorrent, the downlaod/upload speeds (and my set limits in the preferecnes) are not swarm specific, but node specific, which is utter nonsense in my eye.
The finding of new seeds/peers improved after I changed my firewall settings and opened some ports, but I don't really understand why this is the case, it did not fix the problem of not getting aware of new comming seeds/peers.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
alot of complaints about the horrible upload/download issues with bit torrent resulting in downloads that take hours when they could take minutes through a ftp. I think these people are missing the key point behind bit torrent - it's not to make your download faster but to make it easier for the distributor to ... well... distribute. To that end, this tech seems fairly useful. The more people who have the file the more people can distribute the file in the end. If these people are pure leechers then they'll be caught and IP banned by any respectable torrent site. And the cycle continues.
If you were offended by anything I said... No, I'm not sorry. Please lighten up.
I don't want anyone else hearing about this so I can keep it for myself.
Wow, thank you! I knew that eventually *someone* would have to come up with a reasonable solution for this. QoS management is surprisingly ineffective and difficult considering the near-ubiquity of asynchronous connections. This seems so much better than each bandwidth-hungry app using some crappy hacked solution.
Agreed, I'm curious too. The only thing I could think of is constant churning of peers in very large networks...or perhaps establishing a new peer identity with every connection. (which could be mostly defeated by other members of the swarm that'd use the IP address instead)
df
I have briefly skimmed the paper for Bitthief. It relies on the good-will of current implementations in helping out someone with 0 chunks, a presumed newcomer -- thus optimistically unchoked.
I'm pretty sure there are some obvious ways this vulnerability can be made much less useful.
The same research group was working on a number of other really interesting things including a system for automatically finding the "closest" peer to connect to by using another system that maintains a map (in terms of the measured throughput from point to point) of the internet. Supposedly that technique was able to increase BT throughput by quite a bit.
I find it funny how people STILL don't get how bittorrent works. More people in the pool is ALWAYS better. A larger swarm is what you want. Private trackers don't get it. They think that by LIMITING the people joining a swarm to "select" members that they increase the bandwidth to those members.
Anybody who has read Bram's writings understand that the protocol is WRITTEN so that nobody trusts anybody. That's the whole REASON the system works. In a talk at Stanford Bram said over and over and over (and I was cheering) that every suggestion coming from people in academia and otherwise are usually about people trying to be "clever" and add some sort of information that the clients are supposed to "trust" to improve the pool.
There are only 3 things you trust as a client until verifying
1. IP address and ports
2. Data as verified by checksums
3. How much good data YOU have received from any particular client.
Your client can choke clients that are hogs and if they hog enough, then enough clients will choke them and their download speed will go down the toilet.
It works.
Adding ratios, having the tracker send out unverifiable data about how much clients "report" they have, etc will NOT work.
If you can get what you want as quickly as you want at lower risk to you, you should take advantage. Almost everybody else will.
An interesting claim -- it all depends on how broad your definition of lower risk is. If one is taking advantage in a way that can never possibly be traced, you're right. And those situations do arise. But most meaningful situations in life are not so completely shielded, for example, if people around us find out that we're the type to "take advantage", even if we're not doing it to them, they're usually going to be less trusting, which is a disadvantage. This is why most people I know who are always taking advantage end up less successful than the more generous people I know.
There's no one answer to everything, but in general the golden rule is very beneficial to the practitioner. I think "ethics" and "morality" are simply our names for our mind's soft understanding of that fact.
Cheers.
...but I must say I find it hilarious how I sometimes run into the same problem with BT as I did with Limewire, et. al. I can have 40 seeds and numerous leeches, and still only be getting my file(s) at 10K/sec. max. If BT worked like it was supposed to, 40 seeds will saturate me, but options like allowing people to throttle their seeding after seeding X times over, etc. kills it.
Largely, I agree with you. When I originally typed that sentence, I wrote "no risk to you" and then revised it to "lower risk". I think that in human interaction you are completely correct in saying that usually being a little trusting and more generous than average is the way to go, but there are also situations in life where that isn't true. Regardless of all that, being greedy in BitTorrent participation isn't human interaction, it is interaction between deterministic algorithms. You can dynamically determine how greedy you can be to maximize your benefit. Also, given that we are talking about avoiding upload to protect the downloader from prosecution for their illegal download, perceptions of ethics and morality are already going to be messed up in any given community of these users.
I didn't get into any of that in my comment though, because my intention with that post was really to get the submitter to think about the fact that most of the people he is "file sharing" with aren't in it for the sense of community, they're in it for personal gain. He shouldn't be so offended when he finds out that somebody is taking advantage of his generosity because if he opened his eyes and took a good look around he would probably realize that the majority of the peers he is trading packets with are doing the same thing.
What happens if all bittorrent clients were BitTyrant clients? So each client is connected to peers, each of which is also a BitTyrant client. It seems to me that any client would end up with only one active peer, because all others would have a lower initial contribution ratio, which would cause the original client to have a lower upload ratio, which would cause each of the peers to decrease their contribution ratio, which would cause the original client to have a lower upload ratio... etc...
Fair enough :)
Anyone got this client working on 64bit machines running Ubuntu edgy?
This is my sig.
Where did you find the paper? I looked on the site you linked earlier, but it's bare - the JAR, no source code, no real documentation, no paper. And that explanation doesn't make much sense to me. How do they keep claiming to be a 0-chunk newcomer without changing their IP? And when they have most of the chunks, how do they get the ones they already have? If the other peers think you have no chunks, they should keep sending you the "rare" ones. You'll never get the highly-available chunks, unless there are peers that only have those, and I think that's not real likely.
bitty rant?