I, as the author of BitTorrent, would like to make it very clear than I have nothing to do with any of the BitTorrent sites, and that BitTorrent is not and never will be designed to be good for illegal distribution. In particular I'm not doing anything to decentralize the tracker or add anonymity. It is in fact quite anonymity-unfriendly.
BitTorrent is also used for a lot more than just TV shows and movies, which people would find out if they bothered doing any web searching.
I keep telling people that running warez sites is stupid, and they keep doing it. If you wanna brazenly run a massive warez site, that's your prerogative, but don't be surprised when the long arm of the law comes down on you.
The most common cause of this is that the local file system didn't properly flush the data out after the final bit of writing was done. Version 3.2.1 explicitly calls flush() before closing file handles, which hopefully fixes the problem on most systems.
That's very complicated. BitTorrent peers use tit-for-tat to prevent leeching, which works quite well, but still results in meandering download rates. Generally speaking, you get about as much download as you provide in upload, but that can vary if there's plent of excess upload capacity, or if too many people are behind NAT, or if the original seed is slow, or a few other things.
So the short answer is that you'll generally get better download rates if you upload more, because peers will upload to you in exchange, but your actual download rate is affected how the particular deployment is going.
Redistribution isn't 'circumvention'. The GPL specifically requires that it be allowed.
Strange that people seem to be so religious about all the details of the GPL, except when it might hurt RedHat, in which case it's okay for them to sell it like proprietary software.
Maybe RedHat should release their stuff under a 'turns into GPL after a week' license if they don't want their software redistributed quickly.
Charging money for a week is no different than charging money indefinitely. BitTorrent is a great tool which RedHat can use to get their bandwidth costs under control so they can focus on their core business, whatever that may be.
BitTorrent is getting widely used for recorded live shows, with the permission of the copyright holders.
BitTorrent works great as a content distribution mechanism for anything, but so far the corporate world hasn't noticed it yet, they're very wary of new technology.
Re:A *real* anti-leech/anti attacker system propos
on
Gnutella2?
·
· Score: 1
Re:A *real* anti-leech/anti attacker system propos
on
Gnutella2?
·
· Score: 1
BitTorrent has real, working leech resistance, with no fancy certs at all. It just uses tit-for-tat.
While it may make you feel authoritative to simply dismiss the technical problems of decentralized trust, that doesn't make them go away - Noone has to date gotten a decentralized cert system to work, period, and I predict noone will within the next decade.
BitTorrent was written using experience gained writing the transport layer of Mojo Nation, however, there are hardly any shared concepts and very little (hopefully soon to be no) shared code.
BitTorrent (which I'm the author of) is currently released under the MIT license. There is a single file in it which is LGPL - if anyone who knows Python hasn't read the code yet and would like to help clean-room that one file I would much appreciate it.
Thankfully, I haven't gotten a single piece of mail pestering me about the license since I switched away from public domain, even though MIT is almost as permissive.
I did do one slightly controversial thing - I capitalized the legal discraimer properly. Usually it's all caps, which I think is ugly and pointless. I did leave the part where it says "AS IS" in caps though.
BitTorrent development, by the way, is proceeding apace. The first mature release, with a finalized protocol and no phoning home on startup to make sure it's still a current version, will probably be released within the next few weeks.
BitTorrent
enables downloaders to send pieces to each other when they have an incomplete file, making almost unlimited scaling possible. Simple multi-source downloading can be good for performance, but still is limited by the server's upload capacity.
We've had several large deployments of files which are a couple hundred megabytes and up, getting sustained downloads of a couple hundred downloaders at once, serving off a dsl line, and it's worked well.
By the way, BitTorrent, Swarmcast, and OCN all check secure hashes under the hood, so data integrity isn't an issue.
real-time streaming imposes more constraints on the client than does "plain old" file transfer.
There's a tradeoff between demands made on the client and demands made on the server. Making life easier for the client is a bad thing - it causes more problems on the server, which is where all the difficulties were to begin with.
Any tree-based distribution mechanism has no way of utilizing the upload capacity of it's leaves, resulting in a huge amount of wasted capacity.
The reason to have a tree structure rather than a mesh structure is, quite simply, that a mesh structure is a lot harder to implement.
BitTorrent,
which I'm the author of, does a mesh properly. It also has real-world deployment experience - it held up against slashdotting quite well. Thanks go out to everyone who's downloaded using it.
I'm a bit skeptical of their claims of robustness
and QoS. I have real experience with the way real machines behave on the net, and trying to get real-time streaming working before you've even got file transfer going seems like putting the cart way before the horse.
There's also the issue of interrupts when peers higher up in the tree drop out or become slow, and then there's leeching problems...
As for doing simulations, I'd love to have a way of doing simulations which was at all useful, but my experience has been that real-world net churn and congestion behavior is just so funky that back-of-the-envelope calculations are as good as you're gonna get.
I understand now - maxing out upload causes on some connections for downlad ACKs to get dropped, resulting in lousy download performance.
I'll look into capping for that reason. I really wish peoples's ISPs configured their net connections right though.
Thanks for your feedback. BitTorrent actually downloads pieces in random order, rather than beginning to end, but there's a tendency for you to finish getting all the pieces the peers you're trading with and have to get the last few from slower ones.
This can be fixed by making peers download pieces fewer of their peers have first, to minimize the chances of stranding their peers. It's on the to do list, along with a bunch of other very tricky improvements.
Yes, there is a general tendency for people to get about the same download rate as the upload rate they provide, due to the tit-for-tat algorithms. That's just a general tendency though, practical download and upload rates are dependent on many factors.
As to whether being on ADSL makes you 'guilty' I don't know, it's very non-judgemental software:-)
BitTorrent does in fact behave generally the way you describe although it's a bit more sophisticated than 'anteloping'. The way furthurnet works, distribution always follows a tree, and the leaf nodes don't do any uploading. BitTorrent is much more mesh-like, with pieces pretty much flowing every which way across the network.
BitTorrent also makes extensive use of checksums, in what I'm guessing is the same way furthurnet does.
It's actually not too surprising that BitTorrent and furthurnet have a lot of similar features - they were both designed with etree in mind as a primary customer.
BitTorrent actually should be working under Netscape currently - I seem to have it setting all the appropriate things in the registry, but I must be missing something, because it doesn't seem to work.
If anyone can help troubleshoot this problem I would much appreciate it! Setting mimetypes in the registry seems to be undocumented mystic voodoo - I got it working under IE by configuring manually and then searching through the registry to see what it had done...
How the hell is it that my upload is working at all? I'm on a network so private that it's scary.
BitTorrent connections are bilateral, so you're able to both upload and download on all connections you have to your peers, regardless of which side initiated them. Your uber-NATing keeps anyone else from connecting in, but once you establish a connection out it can send in either direction.
BitTorrent checks the integrity of each piece of the file individually, based on hashes it gets as part of the original http request. I should probably explain that clearly on the BitTorrent front page, because a lot of people seem to get the impression that it doesn't do any integrity checking at all, when in fact it's integrity checking is extraordinarily good.
Slashdot Mirror
I, as the author of BitTorrent, would like to make it very clear than I have nothing to do with any of the BitTorrent sites, and that BitTorrent is not and never will be designed to be good for illegal distribution. In particular I'm not doing anything to decentralize the tracker or add anonymity. It is in fact quite anonymity-unfriendly. BitTorrent is also used for a lot more than just TV shows and movies, which people would find out if they bothered doing any web searching. I keep telling people that running warez sites is stupid, and they keep doing it. If you wanna brazenly run a massive warez site, that's your prerogative, but don't be surprised when the long arm of the law comes down on you.
The most common cause of this is that the local file system didn't properly flush the data out after the final bit of writing was done. Version 3.2.1 explicitly calls flush() before closing file handles, which hopefully fixes the problem on most systems.
So the short answer is that you'll generally get better download rates if you upload more, because peers will upload to you in exchange, but your actual download rate is affected how the particular deployment is going.
Strange that people seem to be so religious about all the details of the GPL, except when it might hurt RedHat, in which case it's okay for them to sell it like proprietary software.
Charging money for a week is no different than charging money indefinitely. BitTorrent is a great tool which RedHat can use to get their bandwidth costs under control so they can focus on their core business, whatever that may be.
BitTorrent is getting widely used for recorded live shows, with the permission of the copyright holders.
BitTorrent works great as a content distribution mechanism for anything, but so far the corporate world hasn't noticed it yet, they're very wary of new technology.
That's explained in the protocol document.
BitTorrent has real, working leech resistance, with no fancy certs at all. It just uses tit-for-tat.
While it may make you feel authoritative to simply dismiss the technical problems of decentralized trust, that doesn't make them go away - Noone has to date gotten a decentralized cert system to work, period, and I predict noone will within the next decade.
BitTorrent was written using experience gained writing the transport layer of Mojo Nation, however, there are hardly any shared concepts and very little (hopefully soon to be no) shared code.
You could go use an old version as a public domain thing if you really wanted to, although those versions are quite immature.
Thankfully, I haven't gotten a single piece of mail pestering me about the license since I switched away from public domain, even though MIT is almost as permissive.
I did do one slightly controversial thing - I capitalized the legal discraimer properly. Usually it's all caps, which I think is ugly and pointless. I did leave the part where it says "AS IS" in caps though.
BitTorrent development, by the way, is proceeding apace. The first mature release, with a finalized protocol and no phoning home on startup to make sure it's still a current version, will probably be released within the next few weeks.
You can get the BitTorrent installer for windows by running this file. You can then download the url given above by clicking on this link.
We've had several large deployments of files which are a couple hundred megabytes and up, getting sustained downloads of a couple hundred downloaders at once, serving off a dsl line, and it's worked well.
By the way, BitTorrent, Swarmcast, and OCN all check secure hashes under the hood, so data integrity isn't an issue.
The reason to have a tree structure rather than a mesh structure is, quite simply, that a mesh structure is a lot harder to implement.
BitTorrent, which I'm the author of, does a mesh properly. It also has real-world deployment experience - it held up against slashdotting quite well. Thanks go out to everyone who's downloaded using it.
I'm a bit skeptical of their claims of robustness and QoS. I have real experience with the way real machines behave on the net, and trying to get real-time streaming working before you've even got file transfer going seems like putting the cart way before the horse.
There's also the issue of interrupts when peers higher up in the tree drop out or become slow, and then there's leeching problems...
As for doing simulations, I'd love to have a way of doing simulations which was at all useful, but my experience has been that real-world net churn and congestion behavior is just so funky that back-of-the-envelope calculations are as good as you're gonna get.
I understand now - maxing out upload causes on some connections for downlad ACKs to get dropped, resulting in lousy download performance. I'll look into capping for that reason. I really wish peoples's ISPs configured their net connections right though.
This can be fixed by making peers download pieces fewer of their peers have first, to minimize the chances of stranding their peers. It's on the to do list, along with a bunch of other very tricky improvements.
As to whether being on ADSL makes you 'guilty' I don't know, it's very non-judgemental software :-)
It's actually using sha1 hashes instead of md5, since sha1 is the more generally accepted standard for new protocols
BitTorrent also makes extensive use of checksums, in what I'm guessing is the same way furthurnet does.
It's actually not too surprising that BitTorrent and furthurnet have a lot of similar features - they were both designed with etree in mind as a primary customer.
If anyone can help troubleshoot this problem I would much appreciate it! Setting mimetypes in the registry seems to be undocumented mystic voodoo - I got it working under IE by configuring manually and then searching through the registry to see what it had done...
BitTorrent checks the integrity of each piece of the file individually, based on hashes it gets as part of the original http request. I should probably explain that clearly on the BitTorrent front page, because a lot of people seem to get the impression that it doesn't do any integrity checking at all, when in fact it's integrity checking is extraordinarily good.