Streaming Media Supplement sa2150 and sa2250

19
This chapter assumes that you understand the elements of a proxy caching deployment, which are explained
in Chapter 2‚ Media-IXT Deployment Scenarios.
In this chapter, we explain feature implementation for RealNetworks media streaming.
We discuss each possible element of a deployment in turn, following the same order as the previous chapters:
• “Understanding forward proxy, reverse proxy, and transparency for RealNetworks” below
• “Understanding multi-bitrate clips and RealNetworks” on page 26
• “Understanding hierarchy and RealNetworks” on page 26
• “Understanding live passthrough, live splitting, and hierarchical live splitting for RealNetworks” on
page 27
• “Understanding clustering and RealNetworks” on page 28
• “Understanding VIP failover and RealNetworks” on page 28
• “Understanding selective caching and RealNetworks” on page 29
• “Understanding CDS preload and RealNetworks” on page 29
• “Understanding authentication and RealNetworks” on page 30
• “Understanding firewalls and RealNetworks” on page 30
• “Understanding the limitations of RealProxy and of the PNA protocol” on page 32
Understanding forward proxy, reverse proxy, and
transparency for RealNetworks
In all proxy caching of RealNetworks content, Media-IXT opens an accounting connection with the origin
RealServer during every client-cache transaction. Media-IXT uses the accounting connection to ask the origin
RealServer for permission to serve a client’s request and to inform the origin RealServer whenever Media-IXT
sends cached content to a client player. For accounting, copyright, and client authentication reasons, the origin
RealServer must first approve and then record every transaction between the client and the cache.
Media-IXT also uses the accounting connection for freshness checking. The streaming protocol headers and
some object metadata associated with RealNetworks content are retrieved through the accounting connection
as part of freshness checking, rather than being served from cache. This means that no clip is ever served
completely from cache. Media-IXT’s logs reflect this; see Chapter 10‚ Logging and Monitoring.
On the origin RealServer, inktpln, the cache plugin, handles communication with Media-IXT. This plugin
allows Media-IXT to obtain, and populate its cache with, streaming media data from the origin RealServer.
While all on-demand content is cacheable by default, the RealServer administrator can specify which
multimedia content on the server is non-cacheable.
When RealPlayer uses UDP as an underlying transport protocol for the data channel, performance is much
better than with TCP. The total number of streams that Media-IXT can serve simultaneously is much higher
when RealPlayer is using UDP.
3 Understanding Media-IXT and RealNetworks