Apr 27, 2009

Using a Content Distribution Network

Content distribution networks (CDNs) are designed to deliver large volumes of traffic quickly and efficiently. Whereas a Web host may have hundreds of servers in a single location, a CDN has multiple data centers, and generally the data is replicated across each data center. This is done both for data integrity, so that if there's a power failure somewhere your files are still available, and also for speed. Most CDNs also rely on caching to make downloads happen faster.

Caching is a technique where the most popular files are stored at multiple locations so that when they are requested, the request doesn't have to go all the way back to the origin server. For example, let's say http://CNN.com has an extremely popular story on its home page. The origin servers are most likely in Atlanta, where CNN is based. The first time someone in Los Angeles requests the CNN home page, a copy, along with all the images, is sent from Atlanta to Los Angeles. Then a copy is stored in a cache somewhere on the west coast, so that the next time someone requests that page, it can be served directly from the local cache and not re-requested from the origin server in Atlanta.

CDNs offer premium delivery services, so you won't find pricing like you can with the Web hosting services. CDNs also like to deal in very large numbers, so if you're not expecting to spend hundreds of dollars a month, you shouldn't waste your time calling CDNs. However, when your podcast is at a stage where you have a large audience that demands quality service, a CDN is your best bet.

The CDN marketplace

The CDN market is often divided into the "tier 1" providers, who have the largest and fastest networks, and the "tier 2" providers, who may have slightly more aggressive pricing but may not offer the same service. CDNs are often graded in terms of their availability, which some brag about in terms of "five nines." This means that their network is available 99.999 percent of the time. Another metric used to grade CDNs is the response time, which is the average amount of time it takes for a CDN to respond to a request. A number of services grade CDNs from time to time on their performance. The CDN market has seen lots of consolidation in the last few years, and prices have dropped considerably. The performance of the tier 2 CDNs has come so close the tier 1 providers that the tier 1 providers have had to drop their prices to remain competitive. Some even question whether there is enough distinction between providers to classify them into separate tiers anymore. Be that as it may, these are some of the better-known CDNs:

CDN pricing

CDNs use two basic models for pricing. Traditionally, they have billed using what is known as the 95th percentile model; recently many are moving to a per megabyte/gigabyte model. One of the frustrating things about CDNs is that it is almost impossible to translate between these two pricing models, making it difficult for CDN customers to figure out their cost of delivery.

Using the 95th percentile model, your price is quoted as a dollar amount per megabit of concurrent throughput. For example, a CDN may offer you a price of $50 per megabit. The tricky part is how your concurrent traffic figure is arrived at over the course of a month. The CDN measures exactly how much throughput you are using many times over the course of each day. At the end of the month, the CDN tabulates all the measurements, discards the top 5 percent of the measurements, and uses the 95th percentile measurement as your billable amount.


Billing at the 95th percentile is measured in terms of megabits, not Megabytes. Be careful when you're doing your calculations!

Here's another way of looking at it. There are 720 hours in a 30-day month, so 5 percent of a month translates to 36 hours. So when you're billed at the 95th percentile, the busiest 36 hours of the month are discarded, and you're billed for the throughput your site used during the 37th busiest hour. Still confused? Don't worry, you're not alone. This model is frustrating to customers, because it is hard to understand and hard to budget for. In some ways, it's good because you don't pay for momentary spikes in your traffic. On the other hand, it's very hard to calculate your cost of delivery on a per-file basis because that varies depending on your traffic patterns.

For example, let's say you've got 1,000 subscribers, and you put up a new podcast each day. Over the course of that day, all 1,000 of them check the RSS feed and download the podcast. Assuming the same 5-minute, 5-MB file we talked about earlier in the chapter, and assuming folks are on an average broadband connection of about 300 Kbps, it's going to take the average listener about 2 minutes to download your file:

5 MB * 1024 MB/KB * 8 bits/byte = 40,960 Kbits
40,960 Kbits / 300 Kbps = roughly 136 seconds (fudging the
difference between K and k)

Given an ideal distribution, over the course of a day, just over 700 people could download your file, one at a time, and you'd never have more than one person at a time downloading. But given that most of your listeners probably will be from a limited number of time zones, and most folks will check their favorite feeds either at lunch time or early in the evening, you'll probably get the bulk of your downloads during three or four hours a day. That means you'll have around 5 to 10 people downloading at any given time. Let's say 10 for a liberal estimate. This means your concurrent throughput during these hours will be:

10 * 300 Kbps = 3 Mbps

This should end up being your 95th percentile number, because you're hitting this peak for 3 to 4 hours each day. If you're paying $50 per megabit, you can then do some math to figure out what your cost per delivery is per file:

3 Mbps * $50 = $150
1,000 subscribers * 20 podcasts/month = 20,000 podcasts
$150 / 20,000 podcasts = under a penny a podcast

So it's not impossible to get your cost of delivery, but it involves some calculation. And the calculations are highly dependent on your traffic patterns. Your bill depends on when people download the file, not how many. So it's very hard to figure out what your incremental cost per subscriber is, because it depends on when they download the file!

For this reason, some CDNs are now offering pricing on a per gigabyte basis. Using this model, customers are billed for the total amount of throughput they use. It doesn't matter when the throughput is used. This model is much simpler for customers to understand, because the math is straightforward. Using the previous example, let's calculate what the cost would be, assuming a cost of $1 a gigabyte:

20,000 podcasts * 5 MB/podcast = 100,000 MB = 100 GB
100 GB * $1 = $100
$100 / 20,000 podcasts = half a penny a podcast

Using this model, it appears that it's cheaper, and we know it's a hard cost that we can use in our calculations. Each podcast costs a half a penny to deliver. Contrast this with the 95th percentile where we know the cost is under a penny, but that could change depending on traffic patterns. However, don't let these numbers fool you. It's not quite this simple.

Let's say your podcast audience doubles in size. Using the cost-per-gig model, we know our costs would double. However, with the 95th percentile model, they may not. An audience that's twice as large quite probably would come from a much more dispersed geographical area and may distribute the load over more hours in the day. It's quite possible that you could double your audience size and not pay any more at all! That's the tricky part. If you make efficient use of your bandwidth, the 95th percentile model can be substantially cheaper.

Some companies put caps on bandwidth usage, so for example they're never using more than one megabit per second. This slows down file delivery for people if they're all trying to download at the same time, but keeps costs low. In fact, this is a tool that some hosting companies use to make sure they keep their costs low. (How else do you think they can offer so much bandwidth for free?) You may be able to do the same if you work with your CDN. This compromises performance for your listeners, but it can be a good cost-savings mechanism.

Apr 24, 2009

Using a Podcast Hosting Service

Podcast hosting services are very similar to Web hosting services, but with product offerings geared towards podcasters. You generally get a certain amount of storage space and throughput, and depending on the service, you may get a Web site or a blog, tools to author your RSS feed, and statistics regarding your podcast.

The tools that podcast hosting services offer make them a great bet for folks who are not technically savvy. Also, many of the podcast hosting services are using an interesting model where they charge for the amount of storage you use, but don't charge for throughput. This is an interesting approach and a great deal if your podcast becomes extremely popular. However, as mentioned in the preceding chapter, using a podcast hosting service means giving up some of your ownership, because you won't be able to use your own URL for the site.

However, you could use a hybrid approach where you host your Web site at a Web host and your media file at a podcast hosting service. You'd still have access to the RSS tools, and you could either host the RSS feed from your Web site or point to the RSS feed on the podcast hosting service. It's a little awkward in that you're using two separate services instead of one, but you may be able to get the best of both worlds this way.


Another benefit to some hosting services is that they may offer the possibility of advertising or sponsorship to help pay for your podcast. For example, Liberated Syndication is partnered with Kiptronic to offer ad placement and sponsorship opportunities. Granted, you don't have to be a LibSyn user to take advantage of Kiptronic's offering, but if you are, the integration is seamless and taken care of for you.

Apr 20, 2009

Using Your Web Server

The simplest case is to host your podcast media files right on your Web server. When you're starting out, this is probably the way to go. Most Web hosting agreements usually include a fair amount of bandwidth these days, which cover a fair amount of downloads. For example, here are a few of the better-known Web hosting companies and the deals they're currently offering:

As you can see, killer deals for cheap Web hosting abound. However, as the saying goes, there's no such thing as a free lunch. The only way they can offer these kinds of prices is by putting hundreds if not thousands of Web sites on each server. You'll be sharing resources with lots of other folks. In some cases, this may not be a problem. However, sometimes it can be problematic. Your listeners may have to wait longer for your pages and your podcast files to download.

When you're first starting off, prices like these with the amount of storage and throughput they're giving away are pretty hard to pass up. Many of these services also offer fairly comprehensive tool sets that allow you to build Web sites and create e-commerce pages, blogs, and forums, and they'll even host your e-mail.

If you're thinking of going this way, it's really important to comb the comparison sites and the forums of your potential partners. See what people are saying about them and whether their existing customers are happy. Don't just go by the testimonials they put on their home page; dig into their message boards if you can, and search them to death. It's not that the couple of dollars a month is going to break your budget; it's more that after you're settled into a Web host, changing can be a painful experience.


A number of sites out there regularly update the ratings for Web hosting services. Just search for "best web hosting" and you'll have a number to choose from.

Apr 17, 2009

Distributing Your Media File

Although the discussion was couched in somewhat general terms and assumed that your podcast and the Web site hosting your podcast were the same thing, they don't have to be. You can host your Web site using one solution and host your podcast media files somewhere completely different.

You may want to do this for several reasons, but they all generally boil down to the fact that MP3 files are much larger than Web pages, so you're going to use lots of bandwidth and lots of storage. This places unique demands on the server infrastructure, which may be a job handled by a trusted partner.

Understanding Distribution

One of the best things about podcasting is that it doesn't require any special serving software, like streaming media does. You just place the file on your Web server and update your RSS feed, and you're done. That's all fine and good when you're starting out and have a handful of faithful subscribers. But what happens when your podcast becomes wildly popular?

Several things happen. First, instead of downloading a handful of MP3 files to your listeners, you're suddenly sending out thousands of copies of your MP3 file. If your podcast is 5 minutes long and encoded at 128 Kbps, you're looking at a 5 MB file. A thousand downloads means you're talking about 5 GB of throughput. If you have a daily show, you're talking about over 150 GB per month. That's a pretty serious amount of traffic.

At this scale, things change significantly. Instead of sending out a few files when your friends check to see if you've updated your blog, your Web server is now running all day long. That means the disc drives are spinning, and much more wear and tear is being put on the machines. Servers have a much shorter shelf life than desktop computers for this reason. Most hosting companies plan on servers lasting approximately three years before they have to be replaced.

Of course, this is assuming that your podcast becomes popular enough to attract a large audience. That may not be your case. Your podcast may be niche content that is devoutly followed by a faithful few. Disregarding the size of your audience for the time being, your choices for hosting your media files break down as follows:

  • Host it on your Web server.

  • Host it on a content distribution network (CDN).

  • Host it on a podcast hosting service.

  • Use peer-to-peer distribution.

In the following sections, we talk about each of these possibilities in a little more detail.

Apr 14, 2009

Using Feed Icons to Publicize Your Feed

Chances are good that you'll get most of your subscribers from the larger directory services if you're diligent about listing your podcast. However, that's not the only way to get subscribers. Quite a few may find your Web page via a search engine, particularly if your topic is unique. In this case, it's important to showcase your podcast on your Web page. You want visitors to know in a split second that your Web page is more than just a blog. You want them to see that you have a podcast and that they can subscribe with a single, easy-to-find button.

Until recently, the problem was that there was no single universally accepted icon to indicate that a podcast was available. Different sites used different icons and different colors. Some folks took the original RSS icon, which was a small orange box with the letters "RSS" in white, and substituted the letters "POD." The good people at the Mozilla Foundation decided it would be best if a standardized icon were developed. The logic behind the development was that the icon should not include any abbreviations or acronyms, because people wouldn't necessarily understand what XML or RSS stood for, nor should they have to. They came up with the orange icon shown in Figure 1 (shown here in grayscale, obviously).

Figure 1: The "standardized" RSS icon

As with most things in the world of podcasting, the icon was loved by some and hated by others. There was plenty of lively discussion, which was pretty much brought to a halt when Microsoft decided to use the same icon for its upcoming Internet Explorer 7.0 release. Although you'll probably still see mavericks out there using their own iconography, most people will gravitate toward the Firefox/IE icon, and it will become the de facto standard.


The Mozilla Foundation has publicized usage guidelines for feed icons here:


In most cases, you'll want the RSS icon to link to your RSS feed. However, for those folks who subscribe to podcasts using iTunes, you can make their subscription easier by posting a link to your feed via the iTunes store. For example, the link to subscribe to the Dawn and Drew Show on iTunes looks like this:


When you click this link, it automatically opens iTunes and subscribes you to the Dawn and Drew show, with just one click. To find out what the direct link to your podcast in iTunes is, just Ctrl+click (right-click in Windows) the image you uploaded for your show. This opens a little window that lets you copy the URL for your show for linking purposes.

Now that you have the iTunes direct link, the question is what icon should you use to link to it? You don't want to use the standard RSS icon, because it doesn't work for folks who don't use iTunes to listen to podcasts. You want some way of letting people know that the link is specifically for iTunes users. Unfortunately, there's no right answer here. Folks have designed their own icons for this purpose, and there is no Apple-approved version.

Of course, if you're offering a special button for iTunes listeners, you may also want to offer a button for folks who use Yahoo! Podcasts, Odeo, Google, or any other number of podcast subscription services. And if you're offering your podcast in a number of different formats, you need to have an RSS feed for each format and ideally some sort of icon for each one. Again, there are no standards here. Peter Forret has created a nice set of icons that use a miniaturized version of the RSS feed icon along with wording indicating what the buttons specifically do. You can see his icons here:



If you want to tweak what Peter has done, he's kind and modest enough to admit that he used a cool online tool to create his buttons, and you can too — the Brilliant Button Maker:


Apr 4, 2009

Dedicated Podcast Hosting Services

Dedicated podcast services host your podcast files, provide statistics, and automatically generate your RSS. Some also include a Web site, which is usually a blog. Quite a few of these services are available at various price points and offering different services. For example, most offer some sort of Web site with your account. Some offer a free service, but place ads before your podcast. Many offer a trial period, which is a great way to see how well their tools work. Following are a few examples of podcast hosting services.


PodOMatic(http://www.podomatic.com), shown in Figure 1, is a complete podcast hosting solution, complete with a Web site for each member. PodOMatic offers both free and paid accounts. The free service gives you up to 15 GB of data transfer and 500 MB of storage per month. They also have two levels of paid service called Pro and Pro+. The Pro service upgrades your storage to 2 GB and upgrades the bandwidth to 100 GB per month, which they say is equivalent to 4,000 downloads per month for a 15-minute show. The Pro+ service upgrades the transfer to 200 GB per month or 8,000 downloads. PodOMatic Pro is $9.99 per month; PodOMatic Pro+ is $14.99 per month. The Pro services also offer enhanced statistics including what they call geo-ip maps showing where your listeners are on a map of the world.

Figure 1: PodOMatic is a dedicated podcast hosting solution.

Liberated Syndication (Libsyn)

Liberated Syndication, or as it's commonly called, Libsyn (http://www.libsyn.com), is another complete podcast hosting service, offering service at rates based on the amount of storage you use, with no limit on the number of downloads. Libsyn, shown in Figure 2, charges by the month for its services, which come in $5, $10, $20, and $30 levels with 100MB, 250MB, 525MB, and 800MB storage capacities respectively.

Figure 2: LibSyn charges only for storage, not for bandwidth used.

One of the nice things about Libsyn is that it gives you advanced statistics, shown in Figure 3 even with the lowest cost service.

Figure 3: LibSyn offers detailed statistics to all members.

Radio Userland

Userland (http://radio.userland.com), shown in Figure 4, was founded by Dave Winer, the inventor of RSS and co-inventor, along with Adam Curry, of podcasting. Radio Userland is the oldest blogging service and has had podcasting support built in since the very beginning. Radio Userland has both a Web and a desktop-based component to its service. A basic subscription is $40 per year. Radio Userland does not provide hosting support for your podcast files, but it does have one of the all-time best set of blogging features.

Figure 4: Radio Userland is the granddaddy of all podcast hosting services.

Blogging services with podcasting support

Many blogging services are starting to offer podcasting support. Some have integrated podcasting support, some have add-ins you can use to enable podcasting support, and some require the use of services such as Feedburner or can be used with a manually created RSS feed.

Here is a short list of some blogging services with different degrees of podcast support: