Streaming Media Supplement sa2150 and sa2250

27
Chapter 3 Understanding Media-IXT and RealNetworks
About RealProxy and hierarchy
RealNetworks documentation discusses chaining, which is a way of implementing a hierarchical deployment
with RealProxy. Do not use the technique of chaining. It is unnecessary, and conflicts with Media-IXT’s means
of configuring hierarchical proxy caching. Avoiding chaining means that you:
• should not edit RealProxy’s rmserver.cfg file to implement a hierarchy
• should not use the RealProxy Administrator’s chaining features
RealProxy maintains its own logs. Errors may show up in either the RealProxy or Traffic Server components,
so both RealProxy and Media-IXT logs must be monitored closely to diagnose failures. The network analysis
utilities tcpdump
or
snoop may be used to verify correct content routing.
The RealProxy and Media-IXT logs handle the same connections differently.
For on-demand content:
• RealProxy’s proxy.log on a child cache shows a demand cache hit; on a parent cache proxy.log
shows demand passthrough.
• Media-IXT logs show correct information.
For live content:
• RealProxy’s proxy.log on a child cache shows live split, provided that the origin RealServer allows
splitting for that content; on a parent cache proxy.log shows live passthrough.
• Media-IXT does not log live RealNetworks content.
See RealProxy documentation for RealNetworks’ definitions of demand cache hit, demand passthrough, live
split, and live passthrough.
Understanding live passthrough, live splitting, and
hierarchical live splitting for RealNetworks
The RealProxy component of Media-IXT passes the live stream through to the client without involving the
Traffic Server component. Because RealProxy bypasses Traffic Server entirely for live requests, Media-IXT
logs do not record these requests. RealProxy has its own logs, and does log live streams. See RealProxy
documentation for details.
In a reverse proxy deployment, Media-IXT rewrites the URL requested by the client. RealProxy then streams
the live content invoked by the remapped URL from the origin server.
Understanding live splitting and RealNetworks
The RealProxy component of Media-IXT splits a single live stream from the origin RealServer into multiple
live streams to client RealPlayers.
Forward proxy deployments require no special configuration for live splitting.
By default, TCP is the underlying transport protocol in RealNetworks live splitting from the origin RealServer
to the RealProxy and anything in between. Keep in mind that between RealProxy and a client RealPlayer, UDP
is the default underlying transport protocol for the data channel.
When Media-IXT must send its live split streams, or receive its live feed, through a firewall, it is necessary to
use TCP as the underlying transport protocol, because most firewalls do not let UDP packets through.
About using multicast between Media-IXT and RealPlayer clients
Using multicast, rather than unicast, to stream media data between Media-IXT and clients achieves even greater
efficiency than normal live splitting. Here is why: