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)
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.
Has anyone got a link for a torrent of the article? ;-)
http://66.102.7.104/search?q=cache:ef-r7S3esgUJ:ww w.corante.com/getreal/archives/bittorrent_exeem_me tatorrent_podcasting_what_so_what.php+&hl=en
GET REAL
January 11, 2005
BitTorrent, eXeem, Meta-Torrent, Podcasting: "What? So What?"
Posted by Marc Eisenstadt
SUMMARY: The index that facilitates the sharing of files on a large scale is also the Achilles heel of peer-to-peer file-sharing, because it is vulnerable to litigation and closure. So what happens if the index is itself distributed? I try to get my head around the latest in peer-to-peer file sharing, and explain a bit about what I've learned, including the fact that BitTorrent's power rests in its 'swarm' distribution model, but not necessarily in your end-user download speed. What has this got to do with podcasting? (Answer: invisible P2P plumbing helps the podcasting wheel go round).
[Warning: lengthy article follows].
First, some history
(skip ahead to the next section if you're already bored with the Napster, Gnutella, KaZaa, and BitTorrent saga).
Napster opened our eyes to the power of distributed file sharing on a massive scale. But it was closed down by lawsuits to stop it from listing copyrighted works for which the owners would naturally have preferred to collect royalties (there are thousands of commentaries on the pros and cons of such royalties, but that's not the focus of this posting). Successive generations of tools such as Gnutella, KaZaa, and now BitTorrent have created their own buzz, their own massive followings, their own headaches, and their own solutions to others' headaches. Here's my rundown of the 'big ideas' (and the people behind them):
Napster (Shawn Fanning): This was the Mother of big-time peer-to-peer (P2P) file transfers, i.e. my computer directly to yours, with a central server to maintain lists of who had what in order to initiate the transactions. It had a pretty decent user interface, plus the rapid growth, novelty, excitement and publicity that ensured plenty of good content. Those central server lists, leading to mass free trading of copyrighted material, also led it to be shut down.
Gnutella (Justin Frankel and Tom Pepper, creators of WinAmp): This was an open-source protocol that linked autonomous 'nodes' (users of the network) to other nodes, thereby eliminating the need for a central server list. Searching reliability varies, however, because it is subject to outages according to the connection/disconnection of individual users along the way.
KaZaa (Niklas Zennstrom and Janus Friis, who later created Skype): This technology built on a proprietary protocol called 'FastTrack', conceptually an extension to Gnutella, that deployed distributed 'supernode' search indices whose IP addresses were built in to the software, and which avoided the problems of (i) Napster's centralized lists and (ii) Gnutella's over-distributed nodes suffering outages and weakening the search. The prevalence of built-in 'adware' and the distribution of 'junk files' that masqueraded as originals were two of the weaknesses of the (still) wildly popular KaZaa.
BitTorrent (Bram Cohen): This was the next 'creative leap' in the P2P world, based on the following insight: distributing large files in fragments among large numbers of users, and requiring every downloader to be a partial uploader (of these fragments), enables the 'best of breed' of swarming behaviour -- as a file becomes more popular, so it becomes easier to download, rather than harder (as is the case with traditional file distribution)! A good overview explanation and a helpful analogy are provided in this excerpt from Brian Dessent's BitTorrent FAQ and Guide:
BitTorrent is a protocol designed for transferring files. It is peer-to-peer in nature, as users connect to each other directly to send and receive portions of the file. However, there is a central server (called a tracker) which coordinates the action of all such peers. The tracker only manages connections, it does not have any knowledge of the contents of the files being distributed, and therefore a large number of users can be supported with relatively limited tracker bandwidth. The key philosophy
I use aMule
~/.sig: No such file or directory
So BitTorrent is just about spreading the distribution load across multiple peers and can't speed up my physical connection to the internet.
That's why I click on every banner I see that says "click here to increase your download speed". I think of them as the little speed boost arrows you could drive over in Excitebike.
--
This is a joke. You have been joked with.
Google cache
I object to the term "podcasting"
People were doing that WAY before the ipod came about. and people will be doing it way after the ipod is dust. Why do we need to name something people were already doing after a companies product that DIDNT invent it.
It's like the hype surrounding blogs (woo, a webpage....) except worse because atleast blogging is nominally different (in that it's journal-like) and blogging doesn't have the name of a company embeded in it (I know about blogger.com but they came AFTER blogging).
It's just so lame it makes me have a fit, when people talk about their "podcasting" it makes me want to ram a fist into their trendiod eyesockets and scream into the gooey mess that's left "People were doing it way before you even heard that flaming useless branded buzzword".
just had to get that off my chest.
This page suggests that the number of users is due to fake servers.
BitTorrent requires tracker sites to handle all the partial-fragment-negotiation (think of the madness of the floor of the New York Stock Exchange, and you get an idea of the cool juggling that a tracker has to do).
If he knew anything about BT, he would know that the tracker only introduces peers to each other. The tracker only knows which peers are finished and which aren't. Each peer then manages it's own "fragment-negotiation" which is really just downloading the rarest pieces from it's own point of view. There isn't any negotiation at all, really.
burris
HERE! is a torrent of torrents from the former Suprnova! Download and spread the word!
Remember how Exeem is made by Slotnick, who is employed by an unknown suit....! Using exeem you really dont know what you are getting, it could be the *AA's or anything, so dont trust it until the sponsoring partner comes out in the open. ps. exeem is like eMule..... so use eMule/eDonkey -blah-
Check journal for info on Anti-TextBook, an idea by me.
This blog/article does no such thing as the poster suggests of "dig[ging] deep into BitTorrent".
BTW: WTF is podcasting?
I am the maverick of Slashdot
Then, when a low volume, private site suddenly gets its 15 minutes of fame by being mentioned on Slashdot (or some other well-read news broadcast), it would automatically enlist the horde of new requesting sites to help distribute its content. The rest of the time, both before and after the flash mobbing period, it would just serve its own pages itself in the current manner.
Since it is hard to predict which sites will be "discovered", it would be necessary for all standard servers and browsers support the http protocol extension, so this can't happen without a lot of coordinated work, I'm afraid. The protocol would have to be extended, web servers modified (Apache would e adaquate for a start), browsers modified (Mozilla/Firefox would be adequate for a start). When server was becoming overloaded it woud start by discarding requests from browsers that did not support the protocol, so that it can build up the initial seeding of helper sites. As long as there was more demand than available helpers, these old incapable browsers would continue to get ignored. Once a large enough group of capable helpers was built up to fully support itself, the group could start accepting requests from incapable browsers. That would provide incentive to upgrade older browsers.
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
Hey, it's not as crazy as it sounds. If someone would just make a standard of "Content-Encoding: bittorrent", it'd take off ;)
:P It doesn't hurt - just a couple extra bytes per page request. It'd be best, however, if browsers were nice enough to let you set your own Accept tag :P
I've written a script (just finished last night) to make it easier to serve torrents on a website (they create metainfo and serve all files matching a particular pattern in a given set of directories, and shut them down and delete the created torrents when you stop it), designed to be used with MultiViews enabled (i.e., if they request the file, and they have their Accept header tag prefer bittorrent, it'll give them the torrent instead of the regular file; otherwise, they'll get the regular file). The downside is that I'm going to need to see if I can get any browsers to include bittorrent in their Accept tag
Content-Encoding would be better, because it would be transparent. You wouldn't get a bittorrent download launched, but instead it'd be unpacked straight to the browser cache. A good implementation would allow multiple file to be torrented together, although that could get tricky. In theory, you could serve all requested static content in a single torrent; in practice, this may be unreasonable.
We're practicing our labials.
How about a "Peer2Peer" category for Slashdot? Who's with me? :-)
If you don't like the stories posted by Michael why don't you just uncheck his name from the authors list on your profile's homepage tab settings. Then his stories will never appear for you again.
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.