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."

In other news...

internet bandwidth usage has just gone up by 300% at the University of Washington... Scientists are baffled and blame global warming.

Not really selfish

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.

Re:Not really selfish

"But it prioritizes users with high upload/download speeds. It's better the way it's now - everybody gets their files."

I disagree to an extent. What is high upload/download speed to one node is not neccessarily high upload/download speed to another node. It just depends on the network topography. It's possible for a DSL-connected node to have a faster upload/download connection to a node on a dial-up line than a T3 if the dial-up connection is significantly closer from a network standpoint. If done properly, prioritizing based on uploads could lead to more regionalized torrent relationships. Such a setup still has its downsides but I'm not convinced it's worse or even unfair.

Just great

First some crap clients allow easy tunneling of torrents through tor network (http://tor.eff.org/ [eff.org]), nearly choking it, and now this.

Re:Just great

And now what? You didn't do something really, really foolish, like believing the Slashdot headline before RTFAing, did you? Silly hobbit.

leechers

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.

Re:leechers

And when there's 12 seeders and no one besides you downloading...then what? Its rare, but that does happen.

Re:leechers

Not rare, it's extremely common on private sites with specialized material [dimeadozen.org]. I've had trouble raising my ratio above 0.85 on DIME, in spite of having 250KB/s upload. It's annoying, but there's not much you can do about it.

Re:leechers

Ditto that. I only torrent stuff that is completely unavailable commercially: so-called "out-of-print" material. (What the hell: it's a bunch of zeros and ones, just like all the other zeros and ones. How can it be out of print?) If you're trying to get soundtracks from obscure 1980's movies or ripped '50's jazz LP's, it's pretty frequent that the number of seeders vastly outnumbers the number of people who are still trying to find it.

Sounds interesting

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)

The trackers will not abide.

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.

Re:The trackers will not abide.

Actually this client would likely be favoured by the private tracker sites.

The private tracker already gives you plenty of incentive to make sure your ratio is >1 - even asside from basic morals.

The design of this client means those with higher speed uploads available will complete sooner, and thus you will end up with more high speed seeders.

Seeders who since they are members of private trackers are probably going to stick around until ratio >1

True I admit on piblic trackers something like this may not be as helpful or beneficial, but you can't have everything.

Rule #1

Never trust the client.

I'm surprised it took this long.

Ummm... it doesn't?

It doesn't trust the client. It's just greedier about allocating "spare" bandwidth--that is, bandwidth the other clients can't pay you back for. From their FAQ:

Q: How is BitTyrant different from existing BitTorrent clients?

BitTorrent differs from existing clients in its selection of which peers to unchoke and send rates to unchoked peers. Suppose your upload capacity is 50 KBps. If you've unchoked 5 peers, existing clients will send each peer 10 KBps, independent of the rate each is sending to you. In contrast, BitTyrant will rank all peers by their receive / sent ratios, preferentially unchoking those peers with high ratios. For example, a peer sending data to you at 20 KBps and receiving data from you at 10 KBps will have a ratio of 2, and would be unchoked before unchoking someone uploading at 10 KBps (ratio 1). Further, BitTyrant dynamically adjusts its send rate, giving more data to peers that can and do upload quickly and reducing send rates to others.

Not necessarily good

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 [discourse.net] has more.

Re:Not necessarily good

But the ISP wants to encourage the development of such cliques. It can be directed to keep traffic inside the ISPs bounds.

Interestingly, if bittorrent clients start "cheating", ISPs will be happier, and you will see less throttling.

Ratboy

Altruistic Client instead, please?

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.

Not so selfish.

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)

Surprised It Took This Long

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?

Even better...downloading without ever uploading

Some folks at ETH Zurich took it one step further, and wrote a client - BitThief [dcg.ethz.ch] - 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.

Re:Even better...downloading without ever uploadin

Awesome! If everyone used that client, the MPAA/RIAA wouldn't have a leg to stand on.

Nothing to worry about here...

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).

Re:Nothing to worry about here...

It seems like this is just a scheme to make the rich richer and the poor poorer.

That's far too simple a way to look at it. The analogy just doesn't hold up.

It's giving less of an advantage to those with slow upload speeds (leeches), and high download speeds, but those with low speeds stand to benefit nearly as much as those with high-speed connections. It will take less time to have more full copies of a torrent shared, on higher speed hosts, with lots of bandwidth to spare.

The only senario in which the low-speed clients lose out, is at the very beginning, when only one peer has a full copy, and the high-speeds are actively sharing among each other and competing for access. After that inital rush, the low speed connections should have full-speed access, and more peers with full copies to chose from. The only way that wouldn't work is if ALL the high speed connections disconnect instantly afterwards.

It really should make bittorrent better all-around. The potential for abuse is only marginally higher. And the low-speed (leeches) only lose a little bit in certain senarios, but stand to gain even more in the end, bring them past the break-even point as well.

A welcome feature

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.

Try to give it a spin

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.

Ironically enough

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???

Yall quit whining

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.

not so selfish

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 [2kdown.com]

So basically...

...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.

Trying it out now

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.

Bittorrent sucks anyway

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?

Bye bye!

Watch this client get banned from every single private tracker in the world!

Emule / Edonkey has this

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.

Trying out now

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.

This is How BitTorrent Will Die From Within

P2P survives on the goodwill of its users.
This is How BitTorrent Will Die From Within.

More seeds more quickly

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

submitter has no idea how BitTorrent works

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.

We don't actually use bittorrent on campus

On the campus (UW), the firewalls/NAT prevent us from connecting to many other peers so downloads take days. Instead we use DC++.

Implementation or Protocol broken anyway?

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

I'm seeing...

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.

Please take down the post....

I don't want anyone else hearing about this so I can keep it for myself.

I met these guys

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.

people don't understand bittorrent

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.

Perhaps I'm just completely OT...

...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.

What Happens With a Network of Selfish Clients

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...

ubuntu edgy AMD64

Anyone got this client working on 64bit machines running Ubuntu edgy?

Bitty Rant?

bitty [urbandictionary.com] rant [m-w.com]?

Re:Well, uhm. Ban the client?

If you bothered to RTFA, you'd realise selfish!=bad.

Re:Well, uhm. Ban the client?

I didn't even have to RTFA to figure that out (yay me, right?). AFAIK, most people who could (would) dediate a serious amount of bandwidth to downloading content quickly would be likely to dedicate a serious slice to uploading, therefore enriching the available bandwith for everyone.

Re:Well, uhm. Ban the client?

From the 'article' (really just a brief overview), it's clear that it will generally at present improve performance for the BitTyrant user; it will also statistically improve performance for any peer with substantial spare upload capacity, regardless of client used.

This paper http://www.cs.washington.edu/homes/piatek/papers/B itTyrant.pdf [washington.edu] [cs.washington.edu] goes into considerably more detail, and is well worth reading if you have a nodding acquaintance with the BT protocol and elementary game theory.

It probably will initially hurt performance for users with saturated upload capacity who cannot contribute any more to the swarm than they are at present.

It's not at all clear that this is a bad thing, even if everyone switched to BTyrant. A lot could come down to the social behavior of Tyrant users once they become seeders, for example. If a Tyrant keeps a torrent active as long as s/he presently does, it would clearly be an improvement. For those who say "well a tyrant user may not even seed to 1.0"; fine; that Tyrant user won't really benefit much from the protocol.

Holmwood

Re:Well, uhm. Ban the client?

Yes, problem is it's similar to changing UserAgent tag in IE or FireFox. Too easy. It's not very viable solution.

Re:Well, uhm. Ban the client?

Hi, I'm Bill Gates, and I'm going to give you ONE MILLION DOLLARS if you send your credit card info to me.

See the problem?

Re:Well, uhm. Ban the client?

See the problem?

Yes, a million dollars isn't exactly a lot of money these days. Virtucon alone makes over nine billion dollars a year!

Re:Well, uhm. Ban the client?

Yup, it would only get you 1430 SCO licenses (CA residents add sales tax. Void where prohibited. YCST).

Yes, or 0.0000006 RIAA settlements [slashdot.org].

Re:Well, uhm. Ban the client?

AFAIK, all bittorrent clients have a "UserAgent"-kind of field. If that happens to be BitTyrant, ban the user.

If it's anything like a browsers UserAgent field, I have a set of WWW::Mechanize perl scripts pretending to be firefox 2.0 on windows.

Re:Well, uhm. Ban the client?

read the article, it will actually help uploads be more efficient.

Re:Well, uhm. Ban the client?

No offense, but that can be spoofed quite easily. Make it say BitTorrent, uTorrent, or Azureus and then what? As the co-founder of Azureus this has always been a problem and threat to the BT protocol. The best clients can do is make sure packets are being spread once they're sent to another person. The algorithm works like this --send a "rare" packet, watch to make sure another client shows up with that rare packet in X time. Clients should send their rarest packets first, to keep the swarm happy. So if the packet doesn't show up, you've got a leech and your drop him in the Queue. TdC

Re:Well, uhm. Ban the client?

I have a question: Why the hell is bittorrent so slow? I have a 8MB connection and it downloads slower than I used to get on 56k over non-bittorrent.

Most likely it's misconfiguration on your part. Specifically, you're behind router doing network address translation or a firewall that is blocking inbound connections on the key ports.

In order for you to get good download performance you have to upload at a reasonable rate (at least with clients other than BitTyrant). To do that, you have to make it possible for other peers to connect to your machine.

Odds are it's a NAT problem. See if you can configure your router to forward incoming TCP and UDP packets on ports 6881-6889 to your computer. Even easier, if your router supports Universal Plug-n-Play (UPNP), get a client that does (like Azureus) and tell it to use UPNP. That will allow the client to automatically tell the router how to configure itself.

Once you get the network configuration right, you also need to make sure your upstream connections are choking your downloads, as can happen with braindead ISPs (i.e. pretty much all phone and cable companies). Use your client's upload rate configuration parameter and set it to a little less than the upstream rate that your connection provides. I have 384kbps upload rate and I find I can send as much as 35KBps without trouble.

I have a 5Mbps connection, and I routinely get 500KBps on popular torrents.

Re:Just use BitTyrant yourself :)

RTFA

That is exactly what the client does

basucly it alocated upload so that it will likely improve performance, if it can not come up with a spot that will improve performance then it wi