Slashdot Mirror
Today in P2P
Hylton Jolliffe writes "I wanted to alert you to an article by research Marc Eisenstadt that digs deep into BitTorrent, its potential and limitations and its implications for podcasting, filesharing and more."
← Back to Stories (view on slashdot.org)
Yet another third rate 'blog' that no one has heard of tries to get attention to itself by submitting stories to slashdot. The guy doesn't mention eDonkey/eMule at all while it is still the most widely used P2P network in the world.
You really can't be too suprised when Michael "PayPal Accepted" Sims is doing the story approvals.
I grabbed BT for Win2000 and installed it in about 7 minutes, then I hit the torrent link for Knoppix. I was downloading the ISO at around 36KBps (about the limit of my DSL connection).
Since I was heading to bed while it downloaded, I left BT up that night and the next day while I was at work to help other people out.
I had seen BT as a place to snag nothing but rips of movies, and I've stayed away. The legal-usese BT community needs to do a better job of promoting the positive and allowable uses of BT and P2P sharing tools. They have a way to negative stigma right now.
This page suggests that the number of users is due to fake servers.
All of the neat 'broadcast' stuff that could be happening on the net is being stifled by the 10:1 download:upload formula used by cable and phone internet bit carrying companies.
As businesses, selling bit toting services and desireous of entering the IP content delivery business, this makes sense. Why should users be able to distribute content for free when they can charge for delivery.
As it stands now, live music broadcastss are barely possible using a packet synchrounous distributed network. For top quality ogg, it's not possible. The only alternative is a slew of big fat servers like the akamai network.
What to do about it? Who knows. But it's going to kill the internet for individual audio/video broadcasting.
Yes, I know about mbone.
Yes, I know it's not really broadcast when it's distributed throungh a big tree of 'relays' which introduce some tolerable latency.
I'm a user of Gnutella, so let me take that angle on the article. Gnutella today does not match his historical factoids. The network is quite robust and also possesses the multi-sourced download capabilities of BitTorrent. However, where BT requires a centralized "tracker", any node in the Gnutella universe can be a "tracker" at any time. This is the result of a protocol extension introduced quite some time ago (long enough that it seems to be widely supported by all of the clients that I connect to) where the client that you request a file from informs all of the nodes that it knows about who also have the file that they should contact you. They send you a UDP message indicating that they have the file, and you treat that much like a search result.
Thus, when you search you might see 5 sources, but as you start to download, you immediately see that you're downloading from 50 hosts. It's pretty slick, and amazingly resilient.
I don't even bother using anything else these days, when I can download a multi-gig OS image at the capacity of my connection.
I also use magnet links to share my photography under a creative commons license. See, for example, a tree at my grandfather's house
How about a "Peer2Peer" category for Slashdot? Who's with me? :-)
Especially in the past few months, "decentralizing BitTorrent" has become a really hot topic where everybody wants to share his idea of getting rid of the annoyance of a tracker. It surprises me that most people - even many developers of BitTorrent compatible software whom I know and respect - seem to overlook the fact that BitTorrent's "centralized structure" is there for a reason.
The reason is called _control_.
First let me repeat what Bram uses to emphasize on every opportunity: BitTorrent is not a _filesharing_, but a file _distribution_ protocol. Considering that, the tracker is not a "single point of failure", as many suggest, but a "single point of control". With a tracker existing, access to the files being distributed can be (indirectly) controlled via access control lists (ACL) built into the tracker. For instance, one tracker may answer to authenticated users only, another tracker may postpone general access and grand exclusive "early stage access" to peers from certain IP range within a time frame of the files' release. Unfortunately, the ACL part of the (original) tracker has not been implemented until today (partly my own fault, I have to admit), but some alternative tracker implementations do have this since a long time now - often used to reward "good behaving" users (TorrentBits, anybody?).
Control is probably a bad thing for filesharing, but it is an important issue for file distribution. As for the availability of the tracker, it wouldn't be such a widespreed problem if not for legal issues, which in turn is because BitTorrent is actually "misused" for filesharing. So in other words, BitTorrent has not been decentralized not because we couldn't do it, but because we want to keep the option of control open.
Henry 'Pi' James (member of the developer team of the original BitTorrent)
PS: Since I've already explained how BitTorrent is not designed for filesharing, I also want to point out it is in fact not really suitable for filesharing. The "swarming effect" - which is what BitTorrent is all about - can only be achieved in "slashdotting scenarios", that's why BitTorrent has been adapted for filesharing by two major groups first: anime fanssubbers and tv ep captors, both releasing "hot content" whose value decreases fast, compared to movies or software, for example. For the sharing of mid and long term files, BitTorrent does not really have a significant advantage over other P2P systems.