Bit Rate Throttling is 1 week old - some interesting thoughts and applications
Last week, we announced the release of Bit Rate Throttling (BRT) module and there has been a lot of positive feedback already. I love the way the world of media latches on to new things so fast.
Scott Guthrie posted about the release in his blog here. Thank you Scott! I really like how he captures the importance of this module in the entire eco-system.
Is there something about BRT that all Scott's seem like it?
I say this because Scott Hansleman also posted about BRT. In his post he covers a great scenario from the podcasting world. He wants to save bandwidth if the customer watches the podcast online and not throttle while they try to download. Great example of how excellent customer experience and savings can go hand in hand.
Podcasting is very relevant application area for BRT since the bit rates are low there and almost always all files will get downloaded pretty fast. Here is Scott in his words:
That's the problem this module tries to solve. If you think it's not a problem, talk to me or Carl. It costs a metric buttload to pay for bandwidth of my podcast and it's a harder problem to solve than you think. (Yes, every show has bittorrent as an option, but few Feed Readers use it). A surprising number of folks visit the site and just click on a show and start listening in whatever Media Player they dig. If someone starts streaming the first 20 seconds of a 45 minute show, decides they don't like it and stops, we may have to pay for the whole 45 minutes as it might already have been downloaded! This is also good for screencasts.Scott, in this blog implements a module on server-side to determine whether to throttle or not using URL distinctions. Read more about the scenario here. Also, since BRT is really format agnostic, it works really well for any media downloads.
To summarize, if you are Scott, you must try BRT. If you are not Scott, go beat the Scott's to it :)
In addition a very smart dev on our team Jack blogged about another great feature in BRT, connection limits. Here is an excerpt from Jack's blog:
The recent release of the Bit Rate Throttling Module for IIS provides some useful and compelling features for managing response rates for data and media files. One of the interesting features that is included is the notion of a connection limit group. While IIS (via HTTP.SYS) provides a mechanism for limiting the concurrent connections for an entire site (see Advanced Settings in the UI), our Bit Rate Throttling module goes a step further, allowing admins to define and configure their own connection limits, grouped according to file type (based on file extension) or mime-type (based on the content-type response header).
I blogged about Dynamic Throttling feature in BRT. Here is an excerpt from that post
In our earlier releases if we had Bit Rate Throttling enabled, we would just throttle the media/data file at the desired rate. This is very useful, however there are scenarios where you want to use throttling to plan bandwidth better, for example, you want to be able to support more simultaneous downloads. In these scenarios there might be conditions where the load on the server is lessDo you have any interesting ideas on how you used BRT? I am sure I am missing many more thoughts out there.