Slashdot Mirror
RSS And BitTorrent, Together At Last
eoyount writes "Wired has an interesting story about a really simple idea I wish I had thought of. Transferring large files across the Internet isn't easy for your average joe, but a combination of RSS and BitTorrent technology might just make it easier - Slashdot ran a previous story on the theoretical blending last year." (LegalTorrents is run by the strangely familiar simoniker, who wrote a short piece on the O'Reilly Network about how it was set up, and offers observations on how well the combination fares.) Update: 03/17 21:45 GMT by T : Ernest Miller submits two related postings he's written on RSS+BitTorrent, a combination he calls "broadcatching."
I've been writing extensively on Corante about RSS + BitTorrent, which I call "Broadcatching" here: Broadcatching Archives See, for example, RSS + BitTorrent Roundup - Broadcatching Isn't MS Active Channels and First Broadcatching App Available! (And Related News).
BitTorrent is basically another p2p service, except it's different (yes, i'm trying to be very specific here)
It allows for people to take advantage of bandwith by downloding bits of a large file from different users hosting a 'torrent.' At the end, all these pieces are put together. Yes, it is pretty good.
The problem with bittorrent is that a lot of users disconnect as soon as their download is finished. Won't this be an even bigger problem with game downloads (specifically multiplayer games) since even if the users knows they should stay connected afterwards, they might not since it would lag their game?
RSS feeds are an easy way to move news from site to site. For example, here is Slashdot's RSS feed
You can find more information here
--
Real-time deal updates, over 400 a day!
No new browser protocol is needed.
The technology is already available at http://freecache.org/ [from the peeps @ archive.org]
I don't why many others have jumped on the bandwagon yet.
RSS is "Really Simple Syndication" and it's best thought of as a spinoff to XML. It's a language under which blog-type news-channels can publish their content using, and then the user can use an RSS client that can group stories together into whatever sequence the user wants to see.
It's also seen as a effective way to replace e-mail mailing lists. Instead of getting your newsletters in your e-mail client, open them up in your RSS client which works on a pull basis rather than a push basis, but can still present the content to the user just like an e-mail program might.
It's very different than Active Desktop... that was just the idea of letting IE browser windows be part of the Windows Desktop level so that users could have a frequently-refreshed mini-page of content on their desktop.
Wow! You're right, with one smallish exception:
Please note that you cannot submit a whole site to FreeCache as in http://freecache.org/http://www.rocklobsters.com/ This will not work as only index.html will be cached. You have to prefix every item that you want to have cached seperately.
Using the last THG article as an example, either the Slashdot story would need to point to each page individually via freecache redirection or Tom's Hardware would need to do it.
Not quite as transparent as incorporating BitTorrent into the browser.
Bittorrent protocol has nothing in common with the protocol used by Kazaa (FastTrack). Even their basic P2P topologies are different.
Also, Kazaa is in trouble not for it's protocol, but for running servers that allow piracy, it's just in Kazaa's case one automatically means the other, since the protocol is closed source. Of course, Bittorrent trackers that host pirated material are also susceptable to such troubles - but this has nothing to do with Bittorrent protocol itself.
Uh, yes...
Here, here, and here.This problem is easily addressed with multicasting. All a server need do is send a multicast datagram to notify all RSS syndicators that the RSS document has been updated, at which time the syndicators can fetch the new document.
BT is non-linear as you suggest. The n'th person gets the n'th chunk. This still allows for (randomly-caused) relative scarcity of certain chunks (although they are not the last ones!), and that is the problem you notice up around 98%.
No, seriously, try playing a partially complete BT download of an AVI with a player that doesn't look for the index (mplayer, DivX, etc.). The file is missing random chunks, not the end.
The previous sig has been removed due to
Unfortunately, one assumption at the beginning, that the cascading model is best-case performance for BitTorrent, is completely wrong. It's actually worst-case performance.
A scattered model gives BT as taking O(log(number of people)/(number of chunks) + 1) time for everyone to download the whole file instead of O(sqrt(number people)) as claimed in the article.
-----------
100% pure freak
Realistically speaking, the biggest problem with Bittorrent is seeding. I think this is how bittorrent works:
.torrent file generated .torrent file is uploaded to a tracker .torrent from the tracker .torrent file, which causes the the bittorrent client asks the tracker for the machines/locations of the seeds and people downloading the file(s) pointed to by the .torrent
.torrent goes missing, the file is inaccessible. If the tracker goes away, the file is inaccessible.
* a file is seeded, and a
* that
* clients who want to download the file download the
* the user opens the
* the client downloads various chunks of the files from both the seeds and the other downloaders
The more people download a file, the better bittorrent is able to spread the bandwidth.
The downside is that if a file isn't seeded, it's no longer available. If a
Bittorrent's main problem right now, which is a client problem, is its upstream usage can easily swamp a home connection. That's just dumb client design.
Upload limiting works, but limits your download speed. The client develoeprs have to recognize that yes, sharing is nice and leeching is bad, but disrupting the users' connection is a Very Bad Thing.