IIS 7 and Above
Bitrate throttling model should use Content Type Header
Last post Jul 25, 2008 02:03 PM by skumar2003
Jul 24, 2008 10:30 PM|skumar2003|LINK
All of the documentation on the bitrate throttling model uses the term MIME type. But in fact the module only responds when a url has a certain file extension (*.wmv, *.mov etc.)
This design foraces us to have to implement our own handlers/module and the logic for throttling is media files are issued using dynamic urls such as a url to an aspx/ashx page.
Now when responding with media files we do set the content type header. If the bitrate module actually looked at this header and applied its rules to these responses we wouldn't have to do it ourselves.
In the real world, I've never designed a system that produced a url such that links or users had direct access to media files. These file are frequently stored elsewhere and are not under the application root folder, and so throttling using a file extension
in the url makes no sense in the real world.
I'd love to see the bitrate throttling model respond to the content type header instead of the file extension in the url.
Content Type Header
Jul 25, 2008 04:14 AM|JackFree|LINK
Could you provide more detail on the specific version of bitrate throttling that you are using? The RTW release does indeed support throttling based on content-type. However, file extension rules take precedence over rules based on content-type.
A single mime-type may apply to several file extensions, so a throttling rule based on mime-type must supply the exact throttle rate and initial burst size because there is no guarantee that the response corresponds to a specific file format.
If you peek inside applicationHost.config (or web.config depending on your set up) you'll see a section for <bitrateThrottling>, under which there may exist a section each for file extension rules and mime-type rules:
<add mimeType="text/xml" initialSendSizeKBytes="250" throttleRateKbps="500">
As mentioned earlier, file extension rules take precedence because they are more granular. Also, your URLs don't have to point directly to files, as long as your response contains as its sole entity a file handle then the bitrate module can check its extension
and apply the appropriate throttling logic.
Jul 25, 2008 05:27 AM|skumar2003|LINK
Downloaded the bitrate throttling module a couple of days back from here. Not sure what version it is.
I first tested it by browsing to a media file in a folder under the app root and I was able to set the rates in the IIS config manager. All worked as expected. What I see in the manager is a column for File Type, listing one file type in each item. These
are the various video file types.
In our system each request for a video file is handled by a handler. After we authenticate the request is coming from our video player, we set the content type (as per the file type) and write the file out to the Output stream. This sent the file at full
throttle, so I implemented my own logic using the video and audio bitrates to determine the throttle rates and set the server variables accordingly. All works as expected.
Note: Yesterday, as per Anil's suggestion, I changed the code such that the handler uses Response.TransmitFile instead of writing to the OutputStream.
The request url has a .aspx extension (yes, we simply use the .aspx extension and configure a handler by that path and name).
I'll try it again by removing our throttling logic to see what happens.
When you say "file handle" I assume one *has* to use transmitFile for the bitrate throttling to work automatically then? Also does the built in logic account for both audio and video bit rates?
This is what my applicationHost.config looks like
Jul 25, 2008 05:52 AM|JackFree|LINK
Bitrate throttling favors throttling by file extension because it is so much more specific than mime-type. But, it can only do so much to determine the file extension associated with a response. If the response contains exactly one entity chunk, and if
that entity is a disk-based file handle then we can use that handle to get the file name, and consequently its extension. Calling TransmitFile
should result in precisely this scenario.
The bitrate rules in the config above determine whether audio and/or video rates are accounted for. If you look at the example for .flv, there are two different search patterns to identify both the audio and video bitrates. The bitrate throttling module
will parse the .FLV file according to the search pattern, add up these rates and use the sum as the overall bitrate that is used when determing throttle rate.
Hope that helps!
Jul 25, 2008 11:55 AM|vsood|LINK
In addition what we also have is a server variable. If you want to change the throttling rate programmatically you could use server variables (details
- refer section "Throttling with Server Variables").
Also Scott Hanselman blogged about how to do this
And as Jack mentioned you could add rules based on MIME types but those will have to data rules (i.e., fixed bit rate and you cannot use percentages). This would work great if you have most of the videos at a fixed bit-rate on your site.
Jul 25, 2008 01:34 PM|skumar2003|LINK
I've confirmed that using TransmitFile did the trick. That is using TransmitFile help kick in the built in throttling. I can comment out my logic and it then uses the settings for the file extension.
Thank you for clarifications/explanations on the Mime type/file type.
Jul 25, 2008 02:03 PM|skumar2003|LINK
Yes, I've been doing the bitrate throttling myself using the server variables. It works as expeceted. The waveform (network usage graph) looks very much like what one would see when designing/testing a Switch Mode Power Supply :).
The documentation was clear enough I thought.