There continues to be much discussion on the iPodder developers’ mailing list about bandwidth utilization. Drew (of Dawn and Drew), for example, can’t afford their success. Although BitTorrent has some problems — Drew can’t host it and can’t access it from work due to firewall issues — it’s still one of the best options available to Podcasters.
I’ve been testing BitTorrent for IT Conversations in the lab, and find that it has a few weaknesses for my needs. First, I currently have 260 programs on line, and to use BT effectively, I’d have to run 260 seed processes. Not possible. Second, BT is only truly effective when there are multiple simultaneous downloaders or at least when there are multiple peers running the BT client with the given file in their local caches. I see two solutions to these problems:
First, someone (was it Dave Winer?) suggested a BitTorrent client screensaver. Brilliant! It could dramatically increase the number of peers available at any given time.
Second — and here’s the new idea — in order to increase siumtaneity I would like the ability to announce a schedule of torrents. I know…this sounds antithetical to the ideas of on-demand and timeshifting, but hear me out. Suppose I could publish a schedule in XML that specified a rotation of IT Conversations shows. For example: The most-recent Gillmor Gang would be available every hour, on the hour; my most-recent interview at ten minutes past the hour; Halley Suitt’s most-recent Memory Lane at twenty minutes past the hour, and so on. It would in essence be a broadcast-schedule playlist.
Now imagine a more-intelligent podcatching/BitTorrent client that can process such schedules/playlists and can manage a listener’s queue of requests by mapping them to the schedule. All the BT requests for the latest Gillmor Gang would come in at roughly the top of the hour. All the BT requests for Memory Lane would hit the BT “network” at 00:20, and so on. From my end, I’d start a seed for each of the scheduled programs at the specified hour.
The effect would be dramatic because it would shift otherwise non-simultaneous requests into siumtaneity. Normally, you want to avoid such peaks in requests, but in the case of BitTorrent, they’re actually to your advantage. Since podcasting is based on asynchronous delivery not on-demand in real time, there’s no problem if an automated client such as this has to wait an hour or two to gain access to a desired file. If all of this happens during off hours (which admitedly vary by geography) so much the better for all.
If there’s support for the idea, then we need to kick around the specification. How much of this (if any) might be added directly to RSS? How much to BitTorrent? Or should it be an entirely separate specification? Then again, perhaps it’s a lousy idea that I just haven’t fully thought out. I’m sure you’ll let me know. 🙂
Blogarithms 
You do have them online but usually many people will hit on you once you offer a new file. So offering a bittorrent for these file should take away a big part of traffic.
In your case, I would gladly not take the mp3 download but the bittorent because for most of the shows it does not matter whether or not it takes some hours. :o)
(why is the address field suddely so small?)
LikeLike
You say “First, I currently have 260 programs on line, and to use BT effectively, I’d have to run 260 seed processes.” Clients like Azureus can seed many files from one process. I regularly seed 5-10 files at once, and you could do more if you have the bandwidth. Also, *you* don’t necessarily need to seed all of those, rather you’d want to ensure that *somebody* seeds them. Fans of your site (like me!) would love to keep files seeded, and fans of a show would keep that show seeded. Also, as older shows lose current peers, one seeder could seed many more shows than he/she has the bandwidth for.
One minor problem that I’ve found with some sites is that older shows can be a bit slower to download, and while I expect that, I’m not sure if every BT user does.
All in all, I’d love to see you at least offer recent shows via BT, as it’d assuage my guilt at taking your bandwidth. (I try to at least seed to 110% of anything I take via BT…)
Regards,
Dave
LikeLike
There’s lots of lovely synergy between BT, Podcasting and RSS enclosures. http://www.voidstar.com/node.php?id=1975
Key to this is using podcasting and enclosures to encourage aggregators to build clients that leave a BT client running all the time. There’s several routes to this.
– Desktop aggregators that sit in the tray and run all the time
– Separating podcatcher from BT client so BT requests are just handed off to something like Azureus that runs in background
– Building a BT client as a Firefox browser extension. Whenever the browser is open it’s running BT in the background.
– Nods to DW, building a BT client into a screen saver. But this is really just the same as the first and second.
Of all these I like the second best. Looking at Azureus, a BT client is no small project and one that podcatcher authors and aggregator writers shouldn’t really get involved in. So we need the podcatcher writers to cooperate with the BT client writers and work together. Azureus is really close. We just need to be able to initiate a download with zero UI instead of popping up the Bt client. There’s also a need to expire and manage old shows so the hard disk doesn’t just fill up for no purpose if you subscribe to the whole of audio.weblogs.com And then some sort of auto-stop might be needed or auto-lowering of priority. So the sequence might be
– Start download
– maintain high priority until 100% shared
– drop to background low priority for another 500%
– kill the BT seeding
– one week later delete the local file
The other issue you raise is that currently, publishing torrents is a bit too hard. Again we need to work with the BT community to distill this down to a single click within our Blog publishing systems.
LikeLike
I’ve been working with taming BT for a bit, and I just came out with a MetaWeblog API client plugin for Azureus (at the site linked to on my comment here)… To go off of some of the main points:
You can run the Python scripts without any interface at all. Also, Azureus has a “headless” mode as well… There are a lot of ways to blow away the interfaces and rely on your automated scripts.
I don’t think BT should be bundled (ala Flash) into the browser. I think it would work best as a system service. People are, however, developing BT in other languages. Azureus is Java, there’s a few C++, I’ve got some code to manipulate .torrent files in C#, and of course there are PHP implementations as well as the original Python. This is all open-source, so you know, cut & paste your way to new software.
In a closed, controlled system, you can solve a lot of the other issues you guys have. If you’re working the public, for now, there’s as many ways to do it as there are Video and Music media file formats.
Best of luck! Let me know if I can be of help.
LikeLike
Doug:
Try generating RSS files for subscriptions based on your schedule. The RSS spec supports skip hours, or a times when a RSS feed won’t be updated. You could use skip hours and your schedule theory to force clients to update only during their time slot. For those that don’t want to wait, there’s always direct web download to satisfy their needs.
LikeLike