Streaming Media Supplement sa2150 and sa2250

108
Chapter 10 Logging and Monitoring
The origin QuickTime server packetizes each live stream differently for different player's bandwidths. So, for
each client connecting at a different speed, Media-IXT pulls another instance of a given live stream from the
origin QuickTime server. Each instance is called a live splitter, and Media-IXT maintains a table of the live
splitters it has open at any given time.
Although the suffix .sdp usually indicates a live stream, this is not an absolutely reliable way of knowing
whether a QuickTime stream is live or not.
Given this background, Media-IXT does this when a QuickTime player requests a URL:
• Media-IXT opens a connection to the origin QuickTime server, obtaining metadata that tells whether the
stream is live or on-demand
• If the stream is live, Media-IXT looks in its table of live splitters, then
o If the requested stream matches a live splitter, Media-IXT attaches the client to the appropriate live
splitter after closing the connection it used to obtain metadata
o If the requested stream does not match a live splitter, Media-IXT closes the connection it used to obtain
metadata, then opens another, setting up a new live splitter for the client.
This series of transactions between Media-IXT and a QuickTime player is the same as what happens between
a parent Media-IXT and a child Media-IXT in hierarchical live splitting. Likewise, in live streaming,
• a Media-IXT connected to a QuickTime player only writes a log entry if the player sends a PLAY command
• a parent Media-IXT connected to a child Media-IXT only writes a log entry if the child Media-IXT relays
a PLAY command after receiving one from the player
In hierarchical live splitting, when the child Media-IXT closes the connection it used to request metadata from
the parent Media-IXT, the parent does not write out a log entry. The parent knows it is dealing with a live stream
and has not received a PLAY command.
Only one entry per live split stream is logged on the parent, while as many entries as there are client players for
that stream are logged on the child Media-IXT.
Streams accessed by a QuickTime player do not appear in RealProxy’s proxy.log file. Media-IXT’s
RealProxy component is unaware of, and does not log, QuickTime streams.
The band field and Quick Time
The value for band is computed in the same way for QuickTime as it is for WMT.
On cache hits, prob is always non-zero for QuickTime.
Media-IXT 4.x tracks both the control and data bytes obtained from the origin QuickTime server. The control
bytes are the product of RTSP control commands such as DESCRIBE, SETUP and PLAY, and are typically on
the order of 2-3 kilobytes per transaction. These result in a non-zero value for prob even when streaming
content data is served completely from Media-IXT’s cache.
Transaction logging fields
This section details characteristics of some logging fields that have not been explained earlier in this chapter.
See “Transaction logging fields” on page 108 for a summary of all the fields and examples of their use in
logfile entries.
About the prcb and prob fields and clustering
In a clustered deployment of Media-IXT, you can see the effects of a cache node failure in the logs. The relevant
statistics are bytes from cache (prcb) and bytes from origin server (prob).