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.
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]
If you bothered to RTFA, you'd realise selfish!=bad.
Yes, problem is it's similar to changing UserAgent tag in IE or FireFox. Too easy. It's not very viable solution.
"an experienced, industrious, ambitious, and often, quite often, picturesque liar" - Mark Twain
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?
I hear there's rumors on the Slashdots
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.
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.
read the article, it will actually help uploads be more efficient.
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
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.
The Spoon
Updated 6/28/2011
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
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.
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.
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.
Do Or Do Not, There Is No Spoon, There Is Only Zuul. Everything in the above post is probably opinion.
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.
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.
$_="Slashdotter";$syn="OTT";s;..;;;sub _{print shift||$_};s!ash!Perl !;s=$syn=ack=i;tr+LLEd+BLAH+;_"Just Another ";_
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
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 ambitious user could just change the string in the binary itself.
#include ".signature"
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
Only three things are certain; death, taxes, and apocryphal quotations - Ben Franklin.
Clicky to pirate bay
"I may be full of crap about this game, and I may be wrong, and that's fine." -Jack Thompson
Like everyone else has said -- The useragent field is modifiable since most of the clients are open source (or are designed to emulate other clients). I've designed a few large scale P2P protocols, and this is the typical issue with the open source clients for certain protocols. There's of course ways of defeating the "rogue" clients, and that is by detecting packets and their response times. AKA: I need a rare chunk that you have, so I request it. I wait a full 4 seconds, and haven't received this rare chunk yet. So I'll just drop you from my peers list, and/or check with another peer to see if they get the same response.
:)
There's a few ways of going about this, but that's one of the easiest
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.
Responsible researchers would actually RTFA...
Something tells me that this guy is looking for karma instead of doing good research.
"But this one goes to 11!"
Hello, what problems were there with libtorrent? I use rtorrent exclusively, and sometimes I seem to get ignored when there are seeds at 100%, so I wonder if I might be experiencing something similar. Any information you could share would be appreciated. Does the bug hurt performance for the swarm? I'm greedy, but I don't want to do something taht will hurt other folks if I change the UA string.
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.
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"
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.
If you bothered to RTFA, you'd realise selfish!=bad.
That's what Gordon Gecko said.
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.
If there is one thing to be learned on slashdot, it has to be sarcasm.
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.
yeah i bothered and i've already read it but only after posting this quick-and-stupid reply /. didn't get that reply or my
heck i even replyed to myself very quickly to say i was stupid for not even looking at the
titlebar on the screen but apparently either
internet is going berserk on me again
then again i tried the client and it seems to be very unstable and slow on torrents with a low nr of seeders and leechers.
i also tried BitThief like somebody else suggested but that one was even worse.
it looks like and acts like a nice console app when started from cli
but once you get to the gui, if you can even call it that, it crashes when you simply
want to select a torrent, which kinda renders it useless to me
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?
Microsoft cheerleader, blue flag waving, you got a problem with that?
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.
B itTyrant.pdf [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.
This paper http://www.cs.washington.edu/homes/piatek/papers/
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
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.
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.
Done with slashdot, done with nerds, getting a life.
Buy Steampunk Clothing Online!
Just because it doesn't work for you, doesn't mean it doesn't work for anyone :\.. Also, I'm pretty sure it's not supposed to be perfectly polished with a nice fancy gui. It's supposed to get the job done.
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.'"
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 out there.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
What if my upload is jugging away at max speed and max connections? That makes me a good sharer, just not to you, right now. However, in the long run, I'm good for the swarm (assuming these settings are set in a sane manner).
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.
"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!
> 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 how the leech clients find each other, while staying undetected by the rest. This, while solvable too, is not a problem initially, because the other clients must catch up first.
Regards,
Marc
> 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 better than the rest."
If you did this in a laboratory, everyone would complain it was rigged. But when you do it "in the wild", people are more likely to accept and appreciate the results.
Meanwhile, you're still trying to explain to Joe Idiot that game theory is a branch of economics that isn't really about games, but rather a contrasting system to market theory.
Microsoft cheerleader, blue flag waving, you got a problem with that?
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.
While it may not be offtopic, if you read how BitTyrant works, it would seem that private sites would want to demand its usage, as it rewards those who are uploading by creating a clique among them, and penalizes those non-uploaders (leechers) trying to "game the system".
Selfish and Tyrant are probably really bad descriptions. It isn't selfish so much as non-promiscuous.
I wear the ring.
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.
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 Neutrality even needs theoretical explanations. Might make for a decent aside in an episode of Numbers, maybe.
Done with slashdot, done with nerds, getting a life.
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?
Yeah, too bad leeches generally aren't the social type. The "me, me, me" attitude generally tends to keep them as a singular person or small and insignificant group.
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.
Ever heard about port maps?
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 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.
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
On the campus (UW), the firewalls/NAT prevent us from connecting to many other peers so downloads take days. Instead we use DC++.
Right...because EVERYONE is getting sub 4KBps download speeds...that's why BitTorrent is so popular?
Do you really think that maybe, just maybe, it's not something they can do for you...but something on your end?
Nah, couldn't be that.
PS: Forward your damn BitTorrent port.
> why not just use any analogy that's convenient?
What's wrong with this analogy? It's a network. It gives preferential treatment to some clients over others. That will have an effect. Why exactly isn't that effect comparable to ISPs giving preferential treatment to certain customers?
Microsoft cheerleader, blue flag waving, you got a problem with that?
Because no one is PAYING more for preferential treatment with Bittorrent, like they would with an ISP.
"But this one goes to 11!"
I'd say it depends how occasionally is occasionally. It's possible to get lucky on a torrent with a zillion seeds and no other leeches and get really high transfer rates even when you aren't uploading anything. But if you're getting high data rates semi-regularly, then, yeah, it's not a configuration problem. In that case, it's just that you're downloading torrents that don't have enough bandwidth available to feed you.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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.
Sure they are. They're paying with uploads. How do you not see that?
Microsoft cheerleader, blue flag waving, you got a problem with that?
And do you get charged a static rate for uploads with your ISP, or do they charge more or less if you use more or less bandwidth? I get charged the same every month, regardless of how much I use... I am talking about paying more MONEY if you want to talk semantics....
"But this one goes to 11!"
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.
You're missing the point.
Where an ISP violates net neutrality by requiring more MONEY if you want better bandwidth, this client violates net neutrality by requiring more UPLOADS if you want better bandwidth. They're both payment for preferential treatment. They should both produce largely the same result.
Microsoft cheerleader, blue flag waving, you got a problem with that?
My point is - I work for money. If I want a faster connection, it means I need to work more to earn more money. Uploads cost me nothing. If I upload more, nothing else needs to change to facilitate that - it was idle bandwidth to begin with. Technically, I pay for a set amount of bandwidth - if I use all of it, great, if not I don't get a refund. I was just using less of my bandwidth before, in contrast to using more of it now. The two are not neccessarily the same thing.
"But this one goes to 11!"
Or it could be that he has his connections limit set to something 'sane', like 75 or 50 rather than the 300-900 some clients seem to start it at. With that type of setup, even on a very well seeded torrent if you get 5 connections to dialup or sub-dsl users, your download speed can be atrocious. Kind of like my sentance layout.
Of course, that goes back to his configuration. However, I'd like to argue that it's also more polite to not have 500 connections going and totally saturating your connection.
allready have.
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.
..,well amateur home videos.
One thing I've noticed is a problem with torrents that are popular and take some time to seed such as
Quite often new leeches join in on the fun, and everybody starts feeding them packets. They then drop off quickly and all those rare packets being given to the newbies are lost and must be seeded again. I have a feeling this is done intentionally by the RIAA/MPAA to keep torrents really slow.
Perhaps at least the super-seeding mode could be tuned so that clients who have been seen in the swarm the longest gets rewarded with more packets, as they can be assumed to be the most reliable.
Tell your friends about xenu.net
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.
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 send an ACK to the hosts you're downloading from, they'll stop sending more data since they will think that your download bandwidth is saturated.
To avoid this, without a modem / router that can prioritise the smaller ACK packets, simply limit your bittorrent client to just below your actual maximum upload bandwidth. The uTorrent client has a nice bandwidth graph, watch it for a while. If your upload traffic has lots of peaks jumping up and down somewhat close to your maximum available bandwidth, then you are trying to send too much data at once. This flooding your connection, and you are then forced to wait for it to clear again. Reduce your upload limit gradually until the graph appears flat. Then you are probably not saturating your connection anymore and you're smaller ACK packets wont be held up as much on the network.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
I actually knew that, but I hadn't thought it through quite far enough to realize that it's the buffer on my side that causes the worst of the problem. Thanks for pointing it out.
To avoid this, without a modem / router that can prioritise the smaller ACK packetsI have a Linux box acting as a router (among other things) between my network and my modem. It implements traffic shaping and prioritization using a modified version of the wondershaper script that prioritizes VOIP traffic over everything else.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
If my uploading time took away from other activities, you may have a point. But for me, seeing most of it is either done A) while I'm sleeping or B) while I am at work, earning money, that argument doesn't really hold any water, in my case. The uploading time has absolutely no bearing on amount of my free time used.
Now, are you honestly going to tell me while you are uploading a torrent you sit and stare at the screen, and do nothing else until it is finished, or do you do other things?? Because if you are doing other things, uploading isn't cutting into your free time either..
"But this one goes to 11!"
That sounds horribly complicated.
Bring back napster! Much easier, and faster even on 56k!
Bring back napster! Much easier, and faster even on 56k!
Napster had exactly the same issues when both you and the peer you were downloading from were behind NAT routers. The difference was that when you were on dialup you didn't have a router keeping people from connecting to you.
It's complicated because Network Address Translation is evil and wrong. We need IPv6.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Uhm, no, it will upload as little as possible to get as much download as possible. It's based on the principle of offering upload only to the peers it is benefitting from, with less optimistic unchoking. Although they didn't prevent it from using excess upload (i.e. upload that brings no benefit to download rate), but they could have.
"why is BT so slow?"
It may be that your ISP is attempting to detect the BT streams, and if it decides you're "BTing" throttles you... It would seem Rogers here in Canada is doing just that.... I can typically get capped downloads via http or ftp, but minutes after launching a BT session I'm throttled to around 1/3rd my subscribed downstream rate. (Bastards!) I can't say when they started doing this -- A couple years ago I got torrents at full speed.
Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind. - Dr. Seuss
If you read the paper attached to the article you'd see what they are trying to achieve is exploitation of the altruism exhibited by some bit torrent clients. i.e. Using as little upload as possible for as much download as possible. This would be bad for the swarm, but their actual implementation is still somewhat altruistic, i.e. it will still use excess upload capacity even when that extra upload won't benefit download rate. However if all upload capacity is used, it will only upload to the peers it will get the most benefit from. This will obviously skew it's ratio towards 0 if enough peers are willing to dump data to it.
This is what bitTyrant does. It chokes access to peers with a lower rate of data transfer to the bitTyrant client.
I believe you're wrong. From my reading, the BitTorrent system/network world would work better if everybody used BitTyrant, as the leechers would get pushed right to the bottom of the priority queue.... Please correct me if I misunderstood what BitTyrant is about.
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.
Offtopic, but I'm drunk and I've not posted a comment in a while, so...
Aint WWW::Mechanize a Perl's pearl?
P.S.: drink cachaça!
Stupidity is an equal opportunity striker.
Fellow slashdotter Bill Dog
So the sender's TCP sees a sloooowwww link, much slower than it actually is, and feeds new packets in very gingerly to avoid swamping the route. Then BT sees traffic is just taking forever to get to you and figures the quickest way to seed everybody is to seed to the quick links first. It's right, too. It's just got no way of distinguishing between you and a 33.6kbps modem, because the only thing it sees is your data-acknowledgement rates.
As always, all IMO. Insert "I think" everywhere grammatically possible.
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.
It could also be that the ISP is 'shaping' their bandwidth, providing higher priority to web and email than to P2P applications. Here in South Africa, this is the norm. You actually have to tell the ISP that you want 'unshaped' bandwidth if you're planning on using it for P2P file transfer.
Now if we could just get our monopolist telco to provide something faster than 1Mb/s ADSL, we could actually use teh intarwebs for something useful...
remember to loot and pillage before you burn!
...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.
This all well and good, but it assumes that you are sending small ACK's. From my experience and packet captures, the ACK's are sent in the same large data packets you're uploading to the peer you're downloading from. The only case you'd have small ACK's is if you're downloading from a seed or not uploading to a particular peer. I use BitTornado on Linux 2.6; I suppose other clients and TCP stacks might have different results.
I set up an iptables script on my box to prioritize small TCP ACKs (64 bytes) but the performance was almost as bad as when I let my upstream link get saturated. I've found the best method is to just force your client to limit its upload bandwidth. This way you generally avoid TCP retransmissions.
Only if you assume the user is a leacher that'll disappear as soon as the file is complete. Otherwise, it's optimising for increased availability, which can only be a good thing, since it'll become a seed sooner.
sorry I don't quite understand,
>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).
why? if you need say 200 blocks and your friend pretends to send you say blocks 17 and 19 your short blocks 17 and 19 and you don't complete.
please explain how this is an advantage
Blarney Quality Restaurant, Plants
And my point is that the BitTyrant client violates the neutrality of the BitTorrent network, so we could examine how that network behaves as an example of how such violations would affect other networks. It's the first suitable microcosm we've had that can accurately reflect the effects we might see on the internet at large.
I am truly concerned about your apparent inability to distinguish the BitTorrent network from your internet connection.
Microsoft cheerleader, blue flag waving, you got a problem with that?
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.
It's complicated because Network Address Translation is evil and wrong.
:)
Eh, works great for me.
We need IPv6.
Then you pay for it.
Maxim: People cannot follow directions.
Increases in truth directly with the length of time spent explaining them
That sounds horribly complicated.
What's so complicated about:
That will allow the client to automatically tell the router how to configure itself.
Maxim: People cannot follow directions.
Increases in truth directly with the length of time spent explaining them
No, it doesn't. It constrains you, pushing the Internet towards a provider/consumer model, rather than a network of peers, and making things that should be easy complicated. Just because you don't know how it limits you doesn't mean it doesn't do it.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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 :)
Dr. Evil, is that you?
Anyone got this client working on 64bit machines running Ubuntu edgy?
This is my sig.
...Rogers...after launching...I'm throttled... I guess your Google powers aren't all that good. Turn on encryption in uTorrent or Azureus.bitty rant?
Thanks for the tip -- while I didn't bother to Google about this I had already enabled encryption, but in the "allow encryption" mode, vs. the "encrypted only" mode... BTW, you might want to try being a tad less abrasive -- despite what you may have assumed, it's not actually required to be an asshat to qualify as a geek.
(did I just say that out loud?)
Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind. - Dr. Seuss
Let me see if I make sense.
The parent said that one possible method to detect leech clients, is to send him a rare block (one that nobody else in the swarm has).
If the client is not a leech, he will soon announce posession of the block. Others will request it, download it and eventually also announce posession.
If he's a leech, he might announce posession but he will certainly not upload it. You can detect this indirectly, by waiting if the block eventually shows up at other clients of the swarm. If it doesn't, you've identified the leech and can drop him off your queue.
If the leech were to team up with another leech, this method could be circumvented. He could receive all your rare packets, and they would "magically" appear as available at the 2nd leech. The 2nd leech would just pretend to have them, although he doesn't and thus won't be able to upload these blocks to anyone.
You would fall for it. You would think your bandwidth is used for good, even when the leech actually doesn't upload much to you. But he uploads to the swarm, doesn't he? Poor him, he's a new peer and just doesn't have many blocks yet.
Obviously, the 2nd leech won't team up without incentives. I mean, unless the 2nd leech wasn't a just a 2nd machine under control of one leecher.
For voluntary cooperation, both leechers must do service vice-versa. This doesn't cost much bandwidth, but it voids the download consistency. The leech must pretend posession of those rare blocks, that the opposite leech has downloaded from someone. So, he can't download them himself.
A solution for this problem is to only keep the quantity of those blocks down. The leech must keep track of which blocks can be used by the good peers to identify leeches (ie which blocks are rare or unique). Only those are covered, while all other blocks are downloaded "normally".
There will be a point, where the leech must leave the swarm. The swarm thinks he's at 100%, because that's what the leech pretends (in help of another leech client). But in fact he isn't. He must join another swarm, or re-join the same swarm with a different id (dynamic IP?) to complete the download.
Is it clearer now?
Marc