What RSS Bandwidth Problem?

01Feb05

The so-called RSS Bandwidth Problem is a meme that just won’t frickin’ die. I think Joel Spolsky started it way back in October of 2002, but it may be even older than that. The supposed problem was quickly resolved using Conditional GETs — a scheme that sends a simple 304 Not Modified message back to the client if the requested file has not changed since the last request. Every RSS reader and weblog publishing system that aren’t complete pieces of crap fully support this bandwidth-saving measure. Many also support Gzip encoding, allowing the RSS to be compressed before transmission to the client.

Yet every few months someone crunches their logs, see how much bandwidth is being used by RSS, and proclaims there to be a problem.

Invariably, someone proposes a solution.

Solving the blog bandwidth problem using Bittorrent.

This fails on every level. RSS Readers have to be modified to support BitTorrent as the transport. Somehow a .torrent file has to be created and registered with a BitTorrent Tracker — that issue can be skirted by sending a weblog “Ping” to the Tracker, but then you’ve centralized the .torrent files. There’s no skirting the fact that the Tracker server requires hardware and bandwidth to do it’s job of tracking the available torrents and directing clients to them.

How large does a file need to be to make up for the Tracker’s overhead? How big would the .torrent file be for a 15KB, 30KB, or 100KB RSS feed? How do you deal with the fact that RSS files frequently change? How well do Trackers scale, are how do we fund them?

I suspect that using BitTorrent to distribute relatively small RSS files would shift a greater bandwidth burden to the Trackers, that it won’t scale, won’t be able to fund itself, and ultimately won’t be supported by any mainstream RSS Readers.

Update: The BitTorrent RSS idea was already abandoned. My bad.


If there really are people losing cash money because of RSS bandwidth costs, then the solution is to centralize RSS distribution and charge the producers. Make them spend money to save money. Utilize low-cost bandwidth providers such as Cogent — they offer full racks with 100Mbps pipes for $3,000/monthly, and many hosting companies rent dedicated servers with 10Mbps or 20Mbps of Cogent bandwidth in the $200-$300 range. You can’t promise 99.99% availability when using a single low-cost provider, but RSS distribution doesn’t require it — RSS readers are machines, they will try again later.

There are costs in developing the technology behind this business — you have to spend money to make money. A “Ping” service, a scheduler, an RSS bot, tools to manage the HTTP and DNS services, a “Control Panel” for the customers, bandwidth tracking, billing, and probably a few things that I forgot. A good chunk of it probably already exists.

The fact that nobody is in this business ought to be proof that the problem does not exist.

1 Response to “What RSS Bandwidth Problem?”


  1. 1 Bryce Posted February 4th, 2005 - 8:19 pm

    Damnit, now I have RSS ads on my homepage. I’ve put so much effort into hiding my RSS from Google to prevent this sort of thing, and then I blow it by talking about RSS. Stuipd me.

Comments are currently closed.

Valid XHTML 1.0 Transitional

Advertisements

Plugging my Employer

 


Plugging my Employer

Advertisements

Flickr Photos