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

[discord5]

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

Torrent of Client

[FinchWorld]

...because there connection seems a little slow now (a friend was getting but 0.2KB/s).

Clicky to pirate bay [thepiratebay.org]

Not really selfish

[m50d]

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:

[jackharrer]

But it prioritizes users with high upload/download speeds. It's better the way it's now - everybody gets their files. Maybe later but it's equal. At least people seed for longer.

If you're after communities and sharing current model is better. If you're after fast download but shorter torrent lives - go for new one.

Re:

[Kjella]

If you're after communities and sharing current model is better. If you're after fast download but shorter torrent lives - go for new one.

If you're after communities and sharing then you're already part of a private tracker, which keeps a tab on your ratio no matter what client you use. Public trackers are a free-for-all grab. I often grab torrents when the seeds are many and peers few, and don't feel bad about that at all.

Re:

[tlhIngan]

Ratio sites would probably not ban the client - people will use it just to get the file faster and seed longer (face it - the only way to keep a good ratio is to get in early). Non-ratio'd site will probably ban it because they'd just leech and run.

Wish that ratio'd sites would take thafact into account - the older the torrent, the less likely it'll be downloaded by new people and the harder it is for seed to keep their ratio. Not everyone can bittorrent at work and refresh every 5 minutes...

Re:

[miyako]

The biggest bottleneck for people getting files off bittorrent isn't their download speed, but the overall upload speed. Even with fairly large swarms, the overall speed can be pretty bad, since most people get crap for upload, so it kinda makes sense for the person who is uploading at the highest rate to get the file first, so they can then upload at their higher rate to everyone in the swarm.
Now what would be interesting would be if they client would give priority to those with more upload up to a certa

Re:Not really selfish

[hal2814]

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

Re:

[DigitAl56K]

If you prioritize communication with nodes that have higher bandwidth then you seed the file faster. What is the point in seeding chunks to 50 dialup users when you could have seeded the same chunks to 5000 cable users or 100x as many chunks to 50 cable users in the same time? When a torrent is in high demand mass seeding is most important. When demand is lesser dialup users should be able to find plenty of willing, now seeded nodes to connect with. Everyone still gets their files, and I bet because of the

Re:

[XNormal]

> But it prioritizes users with high upload/download speeds. It's better the way it's now - everybody gets their files. Maybe later but it's equal. At least people seed for longer.

On the other hand, if a BitTyrant client finishes downloading more quickly it may actually be a more effective seed for the entire file - unless the user intentionally stops uploading as soon as download is complete.

In short, it's virtually impossible to tell what effect this will have on the network without massive empirical

Re:

[grimJester]

Well, it targets uploads at those worth bribing. So those with loads of bandwidth get complete copies faster.

It all depends on how much impact it has that those who don't seed leave the swarm earlier, since they finish faster. Likely no real damage to the network though.

Re:

[mattkinabrewmindspri]

It also prioritizes those with higher share ratios.

leechers

[spazimodo]

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

[PingSpike]

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

Re:leechers

[Nasarius]

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

[smellsofbikes]

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.

Re:

[LearnToSpell]

I don't buy that. You have way more than enough bandwidth to have a good ratio. Do you have your client set to stop seeding when it hits 1.0? If you really want to, grab one of the most active torrents (on the top-10 list), and just let it seed. Doesn't even have to be something you like. Then when you go way over on one, your overall ratio won't get killed when you grab a bunch of other stuff.

Re:

[ElephanTS]

I'm probably wrong on this, but doesn't the tracker keep a verified copy of the u/d stats? Probably just wishful thinking on my apart I accept.

Sounds interesting

[Thansal]

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)

Re:

[Andy_R]

Actually, it was banned on my favourite music torrent site (one which prefers it's identity to be hidden) an hour ago.

Re:

[Thansal]

yup.

I still think it would be better if private trackers (like the one you probably use) just ban people based on ratio instead of desired client.

The trackers will not abide.

[Rob T Firefly]

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.

[simm1701]

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.

Re:

[simm1701]

Actually moral principals guide most people - however they are frequently not the moral principals the the law attempts to represent.

If you accept someones basics premises and moral code you will find that they generally follow that course and act rationally within its bounds.

This may not be what you consider moral however

(I know of people that think that preventing you from downloading something is a sin, that all media content should be free and that people that don't seed until atleast a ratio of 2 shoul

Not necessarily good

[grimsweep]

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:

[lawpoop]

Could you start playing tit-for-tat with groups along with individuals?

Re:Not necessarily good

[ratboy666]

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

Re:

[kripkenstein]

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

Indeed. To put things in a practical way for bittorrent, it is possible to make a client that 'cheats' by favoring other people using the same client, thus forming a cooperative group, that if large enough can have a lot of impact (mainly in con

Not so selfish.

[ckdake]

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)

Re:

[RAMMS+EIN]

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

In other words, they do what any rational client should do.

Re:

[khallow]

At a glance, it looks like it has both positive and negative effects. Isolated (ie, slow connection to everyone like dialup) clients are going to lose out since serving them yields such a low payout. Meanwhile fast connections get preferential treatment since they can so easily be served. I don't know how much tit for tat is permitted. It may turn out that one will need to serve slow clients in order to keep downloading, but I suspect that's probably not the case.

Otherwise, it should result in more effici

Re:

[Splab]

I think it will be good. I'm on a very fast connection, and I try to avoid handing data during the first rush to slow peers, that is, if you don't serve me at a reasonable speed I will block you off until I got the full package and then it is free for all. When distributing it makes sense in my book to make sure that people who can ship data at 1+MB/s should get the full package first and when they are done, up the amount of connections and let the slow seeders have it.

Surprised It Took This Long

[RAMMS+EIN]

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?

Re:

[Sancho]

This isn't necessarily bad behavior. It is distinctly uneven, but not necessarily bad.

If the tracker has a lot of people who seed more than they download, then a few people using this client will help increase the total number of seeders, meaning that there are more people capable of providing a specific portion of the torrent, which should allow for maximum download speeds for whoever is left.

If the tracker has a lot of people who seed less than they download, it means that there will be more load on the

Even better...downloading without ever uploading

[meese]

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

[Anonymous Coward]

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

Re:

[Gothmolly]

Or just being a leech you mean. How's the air all the way up on top of your high horse?

Re:

[drinkypoo]

Or just being a leech you mean. How's the air all the way up on top of your high horse?

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

Re:Even better...downloading without ever uploadin

[DocSavage64109]

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.

Nothing to worry about here...

[evilviper]

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:

[Ingolfke]

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

Re:Nothing to worry about here...

[evilviper]

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.

Re:

[Vreejack]

It seems that the first 90% of posters did not bother to RTFA, and so I had to wade through a lot of redundant and irrelevant garbage to get here. I am tempted to use this client, but I am puzzled. Did they fork Azureus? I would have thought this could simply be run as a plugin. The things they are doing here with BitTyrant are things I have tried to effect manually by tweaking Azureus, but without the automatic dynamic response.

Re:

[osu-neko]

Actually, since this client would tend to trickle data more slowly to people who have poor upload rates, it would hurt leeches who don't upload at all. The overall effect will be to make like more difficult for leeches, while making sure people who can spool out content faster get complete copies to spool out faster. I'm having a lot of trouble understanding how this is a bad thing in any way.

A welcome feature

[CastrTroy]

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.

Re:

[Sancho]

That sort of behavior really seems to belong in the OS or at the firewall, but that upload rate sounds awful. Are you using GPRS for torrenting?

Re:

[CastrTroy]

I'm using low-speed cable. It 1 Mbit, which gives fast (enough) download, but slow upload. I don't really send out a lot of data, so it's not much of a problem. Most cable providers I know of cap even the high speed access to 40 or 50 KBPS (notice the capital B), because they don't want people using their home computers as servers. 15 KBPS isn't really that bad, but when you have a lot of connections going out, it tends to have very slow response times.

Re:

[Nazmun]

Use bittornado, I've used it for over a year and possibly two now. Although my upload cap is higher at 70ish KB/s it's crucial to set an upper bound for us (so as not to completely hamper download capability (at 60 KB/s upload, i can download up to 500 KB/s, at 70 KB/s upload I get under 10 kb/s).
 

Re:

[CastrTroy]

I use the official bittorent client, bittorrent-curses. And it does contain the problem I speak of. It also happens with bittorrent-console.

Try to give it a spin

[stewbacca]

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

[ElephanTS]

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

Re:

[ElephanTS]

as an update: It's now running at about 2.4ks-1.

No one know of a torrent for it?

Re:

[ElephanTS]

another update: it just trickled away to nothing and failed.

Slashdotted I presume so I'll wait.

Re:

[ElephanTS]

thanks!!

Yall quit whining

[alta]

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.

So basically...

[joto]

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

[Culturejammer]

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.

Emule / Edonkey has this

[Deathlizard]

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

[Simon (S2)]

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.

submitter has no idea how BitTorrent works

[TheSHAD0W]

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Well, uhm. Ban the client?

[jdray]

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:

[Bertie]

I dunno. Seems to me that with ADSL and particularly cable connections here in the UK, downstream bandwidth has gone up and up while upstream hasn't changed so much. For instance, one provider offers 10Mb/s downstream, but only 512k upstream.

Re:

[Jherek Carnelian]

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

That's what Gordon Gecko said.

Re:Well, uhm. Ban the client?

[Holmwood]

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?

[jackharrer]

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

Re:

[spellraiser]

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?

[Da Fokka]

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?

[Da Fokka]

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:

[discord5]

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:

[Anonymous Coward]

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

Re:Well, uhm. Ban the client?

[tdc_vga]

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:

[drinkypoo]

Is it really a big deal if you feed a client a few blocks without getting one back? I agree though, clients should send their rarest packets first no matter what.

Re:

[jetmarc]

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

This technique can easily be circumvented. A leech client can co-operate with another leech client. As soon as he receives your rare packet, he can tell the other client to pretend to have it, too (without actually sending it).

It makes sense when he does the same for the other client, so both can leech from the swarm.

The only difficulty is ho

Re:

[drsquare]

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.

Rather than worrying about leeches, why not concentrate on speed?

Re:Well, uhm. Ban the client?

[swillden]

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:

[complete loony]

"as can happen with braindead ISP"

It can happen on any ISP. This is a limitation of TCPIP and the upload buffers in all the devices on the network behind your worst bottleneck.

When TCP decides it can send more data, it dumps a whole window size load of packets onto the network. These will clog up your modem / router's transmit buffers. Normally not a huge drain, but if you're uploading to a number of hosts this can add significant lag for the small ACK packets you have to send periodically. If you can't s

Re:

[eklitzke]

Yes, it is true that there is a "User Agent" field in the bit torrent protocol, but of course this is easy to modify. My favorite client [rakshasa.no] has a bug in it that has caused it to be banned from some private trackers. Since this was hurting me on some files that I download, I modified the user agent string to cause the client to identify itself as uTorrent 1.6. Problem solved!

I think that the user agent field is fixed width, meaning that even if you don't have access to the source code to your client, an ambi

Re:

[forkazoo]

Yes, it is true that there is a "User Agent" field in the bit torrent protocol, but of course this is easy to modify. My favorite client has a bug in it that has caused it to be banned from some private trackers. Since this was hurting me on some files that I download, I modified the user agent string to cause the client to identify itself as uTorrent 1.6. Problem solved!

I think that the user agent field is fixed width, meaning that even if you don't have access to the source code to your client, an ambitio

Sorry, doesn't work...

[nweaver]

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.

Re:

[kwerle]

That would be a great idea, except for the facts that the client can be spoofed (trivially), and that BitTyrant is simply selective about who it shares with - but it still shares.

Re:

[Thansal]

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 will dump that alocation on other users.

The only downside is that peopel who would hit and run can do so faster.

Re:Trivial result

[simm1701]

Did you actually read the paper?

They are looking at improving download time for that user and the overall swarm by the use of their algorithm.

The idea being that you share all the upload space you have - but you do it in such a way as to maximise what you can download in the same amount of time.

This in turn means that when you have finished downloading the file the number of copies within the swarm will have increased - also those that shared with you more will have been able to download quicker themselves.

A client like this will penalise selfish or greedy uploaders far more than the normal client as it rewards those that give back.

Give a leach a block and he will have downloaded that block, teach a leach to seed and he shall have blocks for the rest of his life.

Re:

[CDarklock]

This may have a hidden silver lining, although I haven't RTFA. (Shut up, I admitted it.)

Isn't this essentially a P2P violation of net neutrality? Instead of treating all clients the same, we prioritise the ones we like at the expense of those we don't?

Could we examine its effects and scale them up to get an idea of what would happen without net neutrality?

Re:

[nuzak]

It's simply a problem of cliques. You can extrapolate any game theory having to do with cliques (e.g. iterated prisoners dilemma) instead of trying to analogize a P2P network with a service provider network. Uneven market forces having very little to do with P2P architectures are also at work in the net neutrality case.

Re:

[CDarklock]

> You can extrapolate any game theory
> having to do with cliques

That's as may be, how are you going to explain that to Joe Idiot who doesn't even understand what "net neutrality" means? It seems to me that we could make a much more compelling argument with an experiment:

"A preference system was instituted on this network, very much like what ISPs are proposing to institute across the internet. The results sucked ass and made life worse for everyone except a tiny few people who already had it much bett

Re:

[nuzak]

I was replying to a post that looked more like a thought experiment, not a question on how the metaphor can be made accessable. Far as Joe Idiot goes, you could dismiss my egghead-speak and apply analogies that don't fit. But I can be dismissive too and say why not just use any analogy that's convenient? "It sucked when they raised your tolls, that's what not having net neutrality is like. It sucked when Coke switched sweeteners, that's what not having net neutrality is like."

I don't even think Net Neut

Re:

[Mister Whirly]

Responsible researchers would actually RTFA...

Something tells me that this guy is looking for karma instead of doing good research.

Ummm... it doesn't?

[Xenographic]

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.

Re:

[Dirtside]

"Never trust the client"? In BitTorrent, they're ALL clients (except for the initial seed). BitTorrent is practically a master class in how to get a collection of selfish clients to cooperate.

Re:

[drinkypoo]

"Never trust the client"? In BitTorrent, they're ALL clients (except for the initial seed). BitTorrent is practically a master class in how to get a collection of selfish clients to cooperate.

Yes, and the nodes don't trust each other. They get a block from a peer, they check the block to see if it is valid. If they get too many invalid blocks from someplace they ostensibly stop getting them from there. Meanwhile a central tenet of bittorrent is that your client is supposed to be more willing to upload t

Re:

[evilviper]

Never trust the client.

Name just one way in which Bittorrent breaks this rule...

I'll wait.

Re:

[Rogerborg]

Rule #0: RTFA.

Re:

[deroby]

It's amazing what can be found in that something typically referred to as 'the article' : ...
[Overview] ...
Familiar - BitTyrant is based on modifications to Azureus 2.5, currently the most popular BitTorrent client. All of our changes are under the hood. You'll find the GUI identical to Azureus, with optional additions to display statistics relevant to BitTyrant's operation. ...

Re:

[CSEMike]

Hi,

Indeed, it's true that BitTyrant will not always improve performance, even when directly compared to other clients on the same torrent at the same time! There are several reasons for this:

• Data availability: Suppose seeders are sending out data at 20 k/sec, and a complete copy does not yet exist in the swarm. Then, even if you start downloading quickly, eventually you will catch up to the data production point and download at no faster than 20 k/sec.
• Luck of the draw: sometimes, you'll get a lucky p

Re:Just great

[Rogerborg]

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

Re:

[Hatta]

If it weren't for P2P, ISPs wouldn't have half the customers they do now. And you wouldn't have half the job you do now.

Re:

[Lord_Dweomer]

Um...I know we're not supposed to argue about what we get modded, but could someone please explain to me how this is at ALL offtopic? This sounds like it will tweak settings to give the user an unfair advantage over other users at their expense...I FULLY expect this to be banned if it picks up steam. Private torrent sites are anal about people trying to game the system which is exactly what this new client does.

Re:

[drinkypoo]

I usually download more than I upload. Most of the downloads I make (which come from a variety of sources and involve a variety of material) I have a hard time actually reaching a 1:1 ratio. Maybe it's just what you're downloading. Also, if you AND a peer are both firewalled you can't talk to one another, so you miss out on a lot of potentially good peers who just don't have their firewall configured properly if YOU don't poke holes in YOURS, I don't know if you are or not but I thought I should throw that

Not such a useful feature IMO

[ichigo 2.0]

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.