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. 🙂