Streaming Media Supplement sa2150 and sa2250

Chapter 2 Media-IXT Deployment Scenarios

The options available in writing parent.config rules affect different protocols differently.

Every kind of streaming that happens in a hierarchy–for on-demand content, live content, or live split content–

is controlled by the rules in parent.config.

The basic questions in designing a hierarchical deployment are: which proxy cache is to be a child and which a

parent? Which child caches will belong to which parents?

When you have made these decisions, you put the hierarchy into effect by editing configuration files on the

child. No changes need be made on the parent cache.

In Media-IXT hierarchies, there are two types of failover:

• Failover to origin server, where the parent goes down, and the child then contacts the origin server directly

to obtain content requested by a client

• Failover to another parent, where one of at least two parents goes down, and the child then contacts another

parent in the hierarchy directly, to obtain content requested by a client

There is also a type of failover that applies to clustered, as opposed to hierarchical, deployments of Media-IXT.

That is VIP failover, and it is described later in this chapter, in the section Understanding VIP failover.

Note that when requested content is not already in cache, each level of hierarchy may incur a delay from play

request to start of delivery.

Understanding live passthrough, live splitting, and

hierarchical live splitting

When an origin server begins playing a clip in response to a client request, we say that the content being

streamed is on-demand content.

Live content, on the other hand, is the term that applies in these situations:

• if the origin server has its own internal playlist, and begins playing clips according to times determined by

that playlist (in which case the client request falls somewhere in the middle of a clip)

• if the origin server is streaming content as the content is being encoded (whether the encoder’s source is

really live, like a video camera, or prerecorded, like a video clip being played by another system)

Live content is not usually cacheable. Media-IXT handles live content in three situations:

• when Media-IXT simply passes live content through from the origin server to the client, we call this live

passthrough or passthrough mode. Figure 2-5, below, illustrates live passthrough.

• when Media-IXT splits one live stream from the origin server into several streams to different clients, we

call this live splitting. Figure 2-6, on the next page, depicts live splitting.

• when a hierarchical deployment of Media-IXT performs live splitting, we call this hierarchical live

splitting. Figure 2-7, on the next page, shows hierarchical live splitting.

The origin server either allows a proxy cache to perform live splitting or restricts the proxy cache to live

passthrough. If the origin server is not configured to allow splitting of a live stream, Media-IXT can only handle

that live stream in live passthrough mode. This is true for both hierarchical and non-hierarchical deployments.

(Refer to the previous section of this manual

for an explanation of hierarchical proxy caching.)

Live splitting (including hierarchical live splitting) is attractive because it saves network bandwidth, and saves

work for both the origin server and Media-IXT. Having one stream from the origin server to Media-IXT provide

the content for multiple streams from Media-IXT to clients makes efficient use of network resources.

NOTE For RealNetworks, there are two types of live splitting: unicast and multicast. See

Chapter 3‚ Understanding Media-IXT and RealNetworks.