Streaming Media Supplement sa2150 and sa2250

29
Chapter 3 Understanding Media-IXT and RealNetworks
Step 2 is necessary because RealProxy must be restarted before accepting packets addressed to the new virtual
IP. RealProxy drops all client connections during restart.
Understanding selective caching and RealNetworks
Using selective caching, you specify criteria to determine whether to proxy certain content or not, and whether
to cache certain content or not.
When content is not proxyable, Media-IXT denies the client connection, with an appropriate message to the
client (if possible).
When content is not cacheable, Media-IXT goes into passthrough mode and proxies, but does not cache, the
content.
See the HP Cache Server Appliance Administrator Guide for more information about selective caching.
Two configuration files control selective caching:
• cache.config controls cacheability
• filter.config controls proxyability
You must edit cache.config and filter.config manually, adding selective caching rules to the files.
You can, optionally, add an RNI or QT tag to any selective caching rule. This permits you to apply one rule to
QuickTime content and another for RealNetworks content. The format for the tag is to add tag= to the end of
the rule, followed by the tag value of RNI or QT. See the HP Cache Server Appliance Administrator Guide for
details how rules are applied in situations where there is no tag added to a rule, or when conflicting rules apply
to the same request.
The kinds of selective caching rules you can write for RealNetworks and QuickTime differ from those you can
write for WMT. For RealNetworks and QuickTime, always use hostnames (in Fully Qualified Domain Name
form), not IP addresses, in selective caching rules.
Non-proxyable content does not create log entries. Non-cacheable content does create log entries both in the
RealProxy and the Media-IXT logs.
Understanding CDS preload and RealNetworks
Content Delivery Suite (CDS) is an application from Inktomi that permits administrators to replicate and
synchronize the delivery of all types of content across network servers and caches. CDS provides a means to
preload streaming media files and to make scheduled updates to the cache.
Functionality built into Media-IXT enables authenticated CDS Servers to push (preload) streaming media
content into Traffic Server caches on the same network. Preloading Traffic Server caches ensures that data is
available at the edge of the network even before the client requests it.
CDS preloads the content of URLs in series; if there are multiple caches, CDS preloads the caches in series.
Because media files tend to be large, this can be a time-consuming process.
Like all other content, preloaded content can never be served completely from cache, because of the small
amount of data retrieved from the origin server as part of freshness checking.
In the case of a multi-bitrate clip, the origin server treats the multi-bitrate clip as one file; so CDS preload pulls
all of its constituent bitrates over at once.
CDS preload support is enabled in Media-IXT by default.
NOTE For more information about CDS, see:
http://www.inktomi.com