Streaming Media Supplement sa2150 and sa2250

46
Chapter 4 Understanding Media-IXT and WMT
4. In the metafile script, Windows Media Player finds a pointer to the URL from which to obtain streaming
media content. Because Media-IXT rewrote the metafile, the URL directs Windows Media Player to obtain
streaming media content from Media-IXT.
5. Windows Media Player contacts Media-IXT on the MMS port, passing the rewritten URL.
6. Simultaneously with Steps 3 through 5, Media-IXT uses information from the URL within the WMT
metafile to uniquely identify a connection to the origin server.
7. Media-IXT checks its internal table of connections to unique paths on WMT origin servers, called tunnels.
o If there is no match, Media-IXT makes a new tunnel to the origin server host for the given pathname.
o If there is a match, Media-IXT simply attaches the client to the appropriate tunnel.
8. The client sends a request to start playing the content; Media-IXT sends content to the client within 5
seconds.
9. At some point, the client sends a request stop playing the content; Media-IXT detaches the client from the
tunnel, and content stops streaming to the client within 5 seconds.
10. On client disconnect, if no other clients are connected to the origin server, Media-IXT tears down the origin
server connection and removes the tunnel from the tunnel table.
Reverse proxy live-splitting operation works the same way. The connection to the origin server is controlled by
rewriting the URLs in WMT metafiles. Of course, Media-IXT must be configured to perform reverse proxy.
When Media-IXT splits a live WMT stream into n streams, the logs show bytes from the origin server for one
stream and zero bytes from the origin server for n-1 streams. After each session closes, the %<prob> field in
the logs shows the bytes transferred from the origin server since the last session closed.
Understanding hierarchical live splitting and WMT
Hierarchical live splitting for WMT works just like non-hierarchical live splitting, except that information about
the location of the WMT origin server must now be passed by the child Media-IXT on to the parent Media-IXT.
The scenario begins when the user of a web browser with Windows Media Player, viewing an HTML page
containing links to live content, clicks on one of the links.
1. The browser sends a request for the live content invoked by the link which the user clicked. This is a WMT
metafile.
2. The child Media-IXT receives the request, rewrites the contents of the metafile, then serves the metafile to
the browser.
3. The web browser receives the metafile and sends it to Windows Media Player.
4. Windows Media Player contacts Media-IXT on the MMS port, passing the rewritten URL
5. In the metafile script, Windows Media Player finds a pointer to the URL from which to obtain streaming
media content. Because Media-IXT rewrote the metafile, the URL directs Windows Media Player to obtain
streaming media content from Media-IXT.
6. Simultaneously with Steps 3 through 5, the child Media-IXT extracts information from the URL within the
WMT metafile.
7. The child Media-IXT checks its internal table of connections to unique paths on WMT origin servers, called
tunnels. These connections are actually to the parent Media-IXT. Both parent and child Media-IXT
differentiate tunnels based on WMT origin server as well as filename. For the child Media-IXT, connecting
to the parent Media-IXT is the same as connecting to the WMT origin server.
o If there is a match, the child Media-IXT simply attaches the client to the appropriate tunnel.