Streaming Media Supplement sa2150 and sa2250 for HP Cache Server Appliance Administrator Guide Printed in July 2001
English Notice The information contained in this document is subject to change without notice. Hewlett-Packard makes no warranty of any kind with regard to this material, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Hewlett-Packard shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance, or use of this material.
Contents List of Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Who should read this manual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Conventions used in this manual . . . . . . . . . . . . . . . . . . . . . . . . .
Understanding hierarchy and RealNetworks . . . . . . . . . . . . . . . . . . . . . . . . . . About RealProxy and hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understanding live passthrough, live splitting, and hierarchical live splitting for RealNetworks Understanding live splitting and RealNetworks . . . . . . . . . . . . . . . . . . . . . . . Understanding hierarchical live splitting and RealNetworks . . . . . . . . . . . . . . . . . Understanding clustering and RealNetworks . .
Understanding selective caching and QuickTime . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Understanding CDS preload and QuickTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Understanding authentication and QuickTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 6 Configuring Media-IXT: an Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Media-IXT configuration . . . . . . . . . . . . . . . . . . . . . . . . . . .
Windows Media Player retransmission requests and transparency Configuring a layer 4 switch for transparency . . . . . . . . . . . Configuring a WCCP2-compatible router for transparency . . . . Configuring reverse proxy caching for WMT . . . . . . . . . . . . . Configuring hierarchical proxy caching for WMT . . . . . . . . . . . Configuring hierarchical live splitting for WMT . . . . . . . . . . . . Configuring selective caching for WMT. . . . . . . . . . . . . . . . Modifying the filter.
On cache hits, prob is always non-zero for QuickTime. Transaction logging fields . . . . . . . . . . . . . . . . About the prcb and prob fields and clustering . . . . . About the styp field. . . . . . . . . . . . . . . . . . . Transaction logging fields: table and illustrated examples Monitoring Media-IXT traffic . . . . . . . . . . . . . . . About MRTG and Media-IXT. . . . . . . . . . . . . . About live streams and Traffic Manager . . . . . . . . About Cache Transfers in Progress . . . . . . . . . .
English List of Procedures To configure RealPlayer to use a proxy: 62 To configure Media-IXT for streaming over HTTP: 64 To configure RealProxy to listen on selected interfaces: 65 To configure RealProxy to listen on all interfaces: 65 To configure RealProxy support of virtual IP addresses: 66 To configure reverse proxy caching for RealNetworks: 67 To configure reverse proxy for a RealNetworks server farm with a layer 4 switch: 67 To enable parent caching: 68 To set the child cache to redirect streaming me
Preface This manual describes how to use HP Traffic Server® Media-IXT™ as a proxy cache for streaming media content. Media-IXT performs proxy caching of streaming media content for RealPlayer®, Windows Media™ Player and QuickTime™ Player. Who should read this manual This manual is intended for Media-IXT system administrators who configure, run, and administer Traffic Server Media-IXT systems.
1 About Streaming Media This chapter explains where to find information about Media-IXT, tells you what you need to know about streaming media to use Media-IXT effectively, then outlines the specifics of a Media-IXT deployment.
Chapter 1 About Streaming Media This manual is a companion to: • The HP Cache Server Appliance sa2100/sa2150/sa2200/sa2250 Getting Started Guide • The HP Cache Server Appliance Administrator Guide, which explains more fully many of the topics this supplement only introduces. Keep the HP Cache Server Appliance Administrator Guide at hand while reading this manual. You should also consult: • RealNetworks documentation, if you are using Media-IXT for proxy caching of RealNetworks content.
Chapter 1 About Streaming Media Sometimes network conditions or design can make this default streaming strategy unworkable. The players for all three formats have the ability to fall back to or be configured to use alternative strategies.
Chapter 1 About Streaming Media NOTE The RTP data transfer protocol can use either TCP or UDP as an underlying transport protocol. Between origin QuickTime servers and itself, Media-IXT uses RTP with TCP as an underlying transport protocol. On the other hand, current QuickTime players can only receive streaming data over RTP with UDP as an underlying transport protocol. Another, proprietary RealNetworks protocol, PNA (Progressive Networks Audio), was replaced by RTSP.
Chapter 1 About Streaming Media Where to find a basic description HP Cache Server Appliance Administrator Guide Media-IXT deployment element Streaming Media Supplement sa2150 and sa2250 ServerLinks (integration with an HP Media Distribution Network) 8 4 CDS preload (preloading content to cache) 8 4 Authentication 4 8 Firewalls 4 4 You can think of the list of elements in the table as a framework for understanding what proxy caches do, the different scenarios in which proxy caches are deploy
2 Media-IXT Deployment Scenarios This chapter explains all the possible elements of a Media-IXT deployment. Read this chapter to understand what proxy caches do, the different scenarios in which proxy caches are deployed, and the relevant features of Media-IXT.
Chapter 2 Media-IXT Deployment Scenarios A l l co n t en t r eq u est ed b y sp eci f i c w eb cl i en t s Proxy Cache Client Origin Server Other Origin Servers Client Proxy Cache Origin Server Client Origin Server Figure 2-1. Forward proxy caching A l l req u est s f o r t h e co n t en t ser v ed b y sp eci f i c o r i g i n ser v er s Client Origin Server Other Web Clients Origin Server Client Proxy Cache Origin Server Client Figure 2-2.
Chapter 2 Media-IXT Deployment Scenarios Let’s look at how forward proxy, reverse proxy, and transparency are used: • A proxy cache is usually either a forward proxy cache or a reverse proxy cache, but can be both • A forward proxy cache is usually either transparent or explicit, but can be both • A reverse proxy cache is normally neither transparent nor explicit The HP Cache Server Appliance Administrator Guide explains the wealth of possibilities these three statements imply.
Chapter 2 Media-IXT Deployment Scenarios When the layer 4 switch provides transparency, there is a single connection from the client to Media-IXT. The layer 4 switch’s MAC-level redirection does not break this connection. NOTE The descriptions of layer 4 switches in this manual make no pretense of being complete: these switches’ capabilities are diverse, and evolving. This manual attempts to cover only the aspects of layer 4 switches most relevant to proxy caching with Media-IXT.
Chapter 2 Media-IXT Deployment Scenarios Sometimes a web client does not include origin server hostname information in its request, and you must be aware of this if you are using a layer 4 switch in proxy mode.
Chapter 2 Media-IXT Deployment Scenarios Reverse proxy of multiple origin servers When Media-IXT performs reverse proxy for several different origin servers, and should not service traffic for any other origin servers, reverse proxy configuration is combined with selective caching (see “Understanding selective caching” on page 15) in a special way. Configuration details appear in the configuration chapters for each streaming format.
Chapter 2 Media-IXT Deployment Scenarios Simultaneous forward and reverse proxy caching Media-IXT can perform forward proxy and reverse proxy simultaneously, and does so by default when configured for reverse proxy caching. Here is an example of where simultaneous forward and reverse proxy caching would be useful. There are many other possibilities, and this example is not intended to suggest that this is the only plausible scenario. • Access Provider X has a business alliance with Content Provider Y.
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.
Chapter 2 Media-IXT Deployment Scenarios M e d ia-IXT M edia- I XT Encoder Live Event Live Stream Client Origin Server Figure 2-5. Live passthrough M e d ia-IXT Encoder Live Event Live Stream Clients Origin Server Figure 2-6. Live splitting M e d i a-I XT M e d i a-IXT Encoder Live Event Live Stream Origin Server Clients Figure 2-7.
Chapter 2 Media-IXT Deployment Scenarios Understanding clustering Media-IXT supports management-only clustering. In management-only clustering mode, Media-IXT cluster nodes share configuration information, so that all nodes can be administered at once. A multicast management protocol allows you to work with a single system image of the Media-IXT cluster.
Chapter 2 Media-IXT Deployment Scenarios Understanding CDS preload Content Delivery Suite™ (CDS) is an application from Inktomi that permits administrators to replicate and synchronize the delivery of all types of content across network servers and caches. CDS provides a means to preload streaming media files and to make scheduled updates to the cache. Authenticated CDS Servers can preload streaming media content into Media-IXT caches on the same network.
Chapter 2 Media-IXT Deployment Scenarios • Application-level firewalls (such as proxies) • Network-level firewalls (such as packet filters) • SOCKS firewalls (considered an alternative network-level firewall) To allow any version of RealAudio® Player, RealPlayer, QuickTime player, or Windows Media Player to play correctly, the firewall must allow packets that are bound for certain ports to pass to the inner network.
Chapter 2 Media-IXT Deployment Scenarios SOCKS server using the SOCKS protocol. The SOCKS server proxies requests out to the origin servers and sends results back to Traffic Server, which then answers the client request. See the HP Cache Server Appliance Administrator Guide for details. When we discuss SOCKS, we talk about Traffic Server rather than Media-IXT, because RealProxy does not use the Traffic Server SOCKS feature; nor does RealProxy have its own SOCKS functionality.
3 Understanding Media-IXT and RealNetworks 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.
Chapter 3 Understanding Media-IXT and RealNetworks Understanding forward, explicit proxy caching for RealNetworks Media-IXT supports forward, explicit proxy caching for both RTSP and PNA content. In explicit caching, end users must configure their RealPlayers to send RTSP or PNA requests directly to a proxy cache, namely the Media-IXT host. Media-IXT receives these requests through its RealProxy component. Forward, explicit proxy caching works like this for RealNetworks RTSP content: 1.
Chapter 3 Understanding Media-IXT and RealNetworks For transparent PNA, clients can use any RealPlayer software; for transparent RTSP, clients must use RealPlayer version 6.0 or later (that is, RealPlayer G2). For an explanation of transparency devices (layer 4 switches and WCCP2 routers) see Chapter 2‚ Media-IXT Deployment Scenarios. Transparent, forward proxy caching for the HTTP, FTP and NNTP protocols is described in the HP Cache Server Appliance Administrator Guide.
Chapter 3 Understanding Media-IXT and RealNetworks port 9231 5 accounting PL U G IN rtsp 4 L4 Sw it ch udp 8 M e d ia-IXT tcp 6 M edi a- IXT Origin RealServer w it h cach e p l ugin 7 Client brow ser w it h RealPlayer 4 RealPlayer sends t he redirect ed RTSP request t o M edia-IXT on port 9231. 5 M edia-IXT opens an account ing connect ion t o t he origin RealServer. 6 This client is allow ed access, so Media-IXT opens a TCP connect ion t o t he origin RealServer.
Chapter 3 Understanding Media-IXT and RealNetworks 1. A RealPlayer client sends a PNA request on port 7070. 2. The layer 4 switch or WCCP2 router intercepts the port 7070 traffic and redirects it to Media-IXT. 3. Media-IXT issues the client a redirect to a port that is dynamically assigned for that particular request. 4. RealPlayer sends the redirected PNA request to the dynamically assigned port. 5.
Chapter 3 Understanding Media-IXT and RealNetworks You must configure the nodes so that: • the Media-IXT node answers to the advertised name of your RealNetworks streaming content website– precisely what the origin RealNetworks server would do if your Media-IXT did not exist • the remap.config file on the Media-IXT host contains the appropriate map and reverse_map rules • the proxy.config.reverse_proxy.enabled variable in Media-IXT’s records.
Chapter 3 Understanding Media-IXT and RealNetworks If the content is in cache and is fresh, Media-IXT streams content to RealPlayer, and does not need to pull the content from the origin server. media content URL rtsp://greatmovies.com:554/epic.rm/ + map rule: map rtsp://greatmovies.com/ rtsp://reallygreatmovies.com/RNI = rewritten URL: rtsp://reallygreatmovies.com:554/epic.rm/ ht t p :/ / w w w .greatmovies.co m/ 5 3 ht t p:/ / reallygreatmovies.
Chapter 3 Understanding Media-IXT and RealNetworks Where Media-IXT and the origin RealServers are owned by the same company, a content distribution network for example, and Media-IXT performs reverse proxy for the server farm, it is possible to fix the problem. For details see “Configuring reverse proxy for a RealNetworks server farm with a layer 4 switch” on page 67.
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.
Chapter 3 Understanding Media-IXT and RealNetworks Normally, when Media-IXT splits an incoming stream into multiple outgoing streams, the transport protocol is UDP, so Media-IXT must write UDP packets to the IP address of each client. If those clients can be reached via multicast, then Media-IXT need only send out one stream of multicast packets to the multicast address, rather than multiple streams of UDP packets (one stream to each client IP address).
Chapter 3 Understanding Media-IXT and RealNetworks Step 2 is necessary because RealProxy must be restarted before accepting packets addressed to the new virtual IP. RealProxy drops all client connections during restart. Understanding selective caching and RealNetworks Using selective caching, you specify criteria to determine whether to proxy certain content or not, and whether to cache certain content or not.
Chapter 3 Understanding Media-IXT and RealNetworks Understanding authentication and RealNetworks Recall that Media-IXT supports two types of authentication. Proxy authentication through to origin server. RealProxy passes authentication credentials from RealPlayer to origin RealServer, and passes any authentication responses from RealServer to RealPlayer. No configuration is necessary to make this happen. Content requiring authentication is cached and logged the same as any other content.
Chapter 3 • Understanding Media-IXT and RealNetworks one connection for the media streaming data protocol RDT, using UDP as its transport protocol When UDP is not allowed, there is an alternative: • two connections interleaved–the first being for the control protocol, RTSP, and the second for the media streaming data protocol, RDT–together using TCP as their transport protocol The second approach provides markedly inferior streaming performance.
Chapter 3 Understanding Media-IXT and RealNetworks Network-level firewalls and RealNetworks The main point to bear in mind when configuring a network-level firewall for use with Media-IXT is that the ports used by your deployment’s streaming protocols are open. How RealPlayer uses ports The RealPlayer uses both the TCP and UDP ports.
Chapter 3 Understanding Media-IXT and RealNetworks in cache.config should prevent a PNA clip from being cached on the host, but does not. (10.10.10.10 is an example IP address.) This is a bug, which can not be fixed, due to limitations of the PNA protocol. The proxyability part of the selective caching feature does work correctly for PNA (it is effected by editing filter.config). Authenticated PNA goes into passthrough.
4 Understanding Media-IXT and WMT 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 Windows Media Technologies (WMT) media streaming.
Chapter 4 • Understanding Media-IXT and WMT usually has a scheme of mms. MMS is a media-control protocol for opening, setting up, controlling, and logging of streaming media sessions. The Windows Media media streaming format includes headers (information about streams) and payloads (the actual media data). The figure below shows the components of a sample media content URL: mms://208.184.229.63/v2/onair/BBC/BBCworld_100k.asf scheme streaming media filename Figure 4-1.
Chapter 4 Understanding Media-IXT and WMT The figures below illustrate WMT media streaming with no proxy cache present. 3 to Windows Media Player from browser Windows Media Server WMT metafile 2 HTTP Client browser with Windows Media Player 1 Web Server 1 The web browser sends a request to the HTTP server for a WMT metafile. 2 The HTTP server serves the WMT metafile to the web browser. 3 The web browser receives the metafile and sends it to Windows Media Player.
Chapter 4 Understanding Media-IXT and WMT The example assumes that the user of a web browser equipped with Windows Media Player is viewing an HTML page containing links to movies. The story begins when the user clicks on a link to a movie.The URL invoked by the link is that of a WMT metafile. 1. The web browser passes the URL to Windows Media Player and instructs Windows Media Player to open the metafile. 2. Windows Media Player sends a request for the WMT metafile to the HTTP server. 3.
Chapter 4 Understanding Media-IXT and WMT metadata 6 5 mms Window s M edia Server udp 8 M e d ia-IXT Client brow ser w it h Window s Media Player 7 5 Window s Media Player cont act s M edia-IXT on the MM Sport , passing the rewritt en URL. 6 M edia-IXT obt ains met adat a about t he media content invoked by t he URL from the origin Window s Media Server. 7 M edia-IXT t ries t o f ind a match between t he origin Windows M edia Server's metadata and metadat a in M edia-IXT's cache.
Chapter 4 Understanding Media-IXT and WMT In rewriting the URL, Media-IXT places the prefix ink/rh before the HTTP server hostname. • ink/ serves as an indicator to Media-IXT that the URL has been rewritten. This is important in hierarchical deployments. • rh stands for HTTP Redirector Host. Understanding forward, transparent proxy caching for WMT For an explanation of transparency devices (layer 4 switches and WCCP2 routers) see Chapter 2‚ Media-IXT Deployment Scenarios.
Chapter 4 Understanding Media-IXT and WMT 4 2 http 1 Window s M edia Server 6 to WMPlayer from browser 5 M e d ia-IXT L4 Sw itch rewritten WMT metafile WMT metafile 3 Client brow ser w it h Window s M edia Player Web Server 1 The brow ser sends out an HTTP request addressed t o port 80 of a Window s M edia origin server. 2 A l ayer 4 sw it ch int ercept s t he HTTP request and redirect s it t o Media-IXT. 3 M ed ia-IXT o b t ains t h e WM T met af i l e f rom t h e HTTP server.
Chapter 4 Understanding Media-IXT and WMT Understanding reverse proxy caching for WMT In a sense, reverse proxy caching is simpler than forward proxy caching for WMT. The map and reverse_map rules used in reverse proxy save Media-IXT some URL-rewriting work, as you will see. Like forward proxy caching, reverse proxy caching of WMT content can be based on these three nodes: • a Windows Media server, where content resides in the form of files in WMT streaming formats: .asf, .wma or .
Chapter 4 Understanding Media-IXT and WMT 6. The browser hands the rewritten WMT metafile to Windows Media Player. 7. Windows Media Player requests the rewritten media content URL from Media-IXT. 8. Media-IXT finds the origin Windows Media server by using the map rule: map mms://www.pix.com/ mms://source.pix.com/ 9. Media-IXT opens a connection to the origin Windows Media server. 10. Media-IXT uses metadata to determine if the streaming content is in cache and fresh. 11. If funnymovie.
Chapter 4 Understanding Media-IXT and WMT map rule locating the origin server: map mms://ww w.pix.com/ mms://source.pix.com/ mms request for rewritten media content URL: mms://www.pix.com/funnymovie.asf 6 7 mms udp 9 Client brow ser w it h Window s M edia Player h t t p:/ / w w w .p i x.co m/ 10.10.10.10 metadata M ed i a-IXT Window s Media Server ht tp:/ /source.pix.com/ 11.11.11.11 8 7 Web Server htt p:/ / relay.pix.
Chapter 4 Understanding Media-IXT and WMT Beyond simple forward proxy, reverse proxy, and transparency for WMT This section describes three scenarios that have special configuration requirements for deployments which stream WMT content. About server farms There is no need for special treatment for servers behind a load-balancing switch.
Chapter 4 Understanding Media-IXT and WMT Understanding multi-bitrate clips and WMT Given the situation where an origin WMT server has got a multi-bitrate clip, say a movie encoded for streaming at three different bitrates (20kbps, 100kbps, and 300kbps), the question arises as to how Media-IXT handles caching of such a clip. The answer is that since a Windows Media Player client requests only one version (one bitrate) at a time, MediaIXT serves and caches only that bitrate in response to that request.
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.
Chapter 4 Understanding Media-IXT and WMT o If there is no match, the child Media-IXT makes a new tunnel to the parent Media-IXT which acts like the WMT origin server for the given pathname. In doing this, the child Media-IXT passes the information it extracted from the URL within the WMT metafile on to the parent Media-IXT. So, the parent Media-IXT has the means to repeat the process: 8. The parent Media-IXT checks its internal table of connections to unique paths on WMT origin servers, called tunnels.
Chapter 4 Understanding Media-IXT and WMT Understanding selective caching and WMT Using selective caching, you can specify criteria to determine whether content is proxyable or not, and cacheable or not. When content is not proxyable, Media-IXT denies the client connection, with an appropriate message to the client (if possible). When content is not cacheable, Media-IXT goes into passthrough mode and proxies, but does not cache, the content.
5 Understanding Media-IXT and QuickTime 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 QuickTime media streaming.
Chapter 5 Understanding Media-IXT and QuickTime Understanding forward, explicit proxy caching for QuickTime In explicit caching, end users must configure their QuickTime Players to send requests directly to a proxy cache, namely the Media-IXT host. Forward, explicit proxy caching works like this for QuickTime content: 1. A QuickTime Player client sends a request to Media-IXT, normally on port 1091. 2.
Chapter 5 Understanding Media-IXT and QuickTime • Traffic Server’s role is transparent readdressing, proxying, and caching. • QuickTime Players, like RealPlayers, use RTSP as the control protocol, so they direct RTSP requests to port 554. • With transparency enabled, Media-IXT redirects QuickTime traffic from port 554 to its QuickTime RTSP port, which is port 1091. Here is how forward, transparent proxy caching for QuickTime plays out step by step: 1.
Chapter 5 Understanding Media-IXT and QuickTime L4 Sw itch udp 6 M e d i a-IXT tcp 4 Origin QuickTime server 5 Client brow ser w ith QuickTime p layer 4 Media-IXT opens a TCP connect ion to the origin QuickTime server. 5 Media-IXT determines whether the requested cont ent is in cache, and whether it is fresh. The content is in cache and is fresh, so Media-IXT does not need to pull the content from the origin server. 6 Media-IXT streams cont ent to QuickTime player. Figure 5-3.
Chapter 5 Understanding Media-IXT and QuickTime 3. Media-IXT rewrites URLs in the client request, replacing the advertised site name with the hostname of the origin QuickTime server. Our example URL would be rewritten: rtsp://reallygreatmovies.com:554/epic.mov/ 4. Media-IXT opens a TCP connection to the origin QuickTime server at the rewritten URL, dedicating the connection to the client which sent the request. 5. Media-IXT determines whether the requested content is in cache, and whether it is fresh. 6.
Chapter 5 Understanding Media-IXT and QuickTime Beyond simple forward proxy, reverse proxy, and transparency for QuickTime This section describes scenarios that have special configuration requirements for deployments which stream QuickTime content. Understanding reverse proxy for QuickTime and RealNetworks simultaneously A single Media-IXT can perform reverse proxy for both RealNetworks and QuickTime origin servers simultaneously. By adding a designator to a reverse proxy remapping rule in the remap.
Chapter 5 Understanding Media-IXT and QuickTime Understanding live passthrough, live splitting, and hierarchical live splitting for QuickTime Media-IXT requires no special configuration to perform live passthrough for QuickTime. Live splitting depends on the connection speed of the client. The RTSP protocol contains information about the client connection speed, and not about the stream, so the stream’s bit rate is irrelevant.
Chapter 5 Understanding Media-IXT and QuickTime Understanding selective caching and QuickTime Using selective caching, you can specify criteria to determine whether content is proxyable or not, and cacheable or not. When content is not proxyable, Media-IXT denies the client connection, with an appropriate message to the client (if possible). When content is not cacheable, Media-IXT goes into passthrough mode and proxies, but does not cache, the content.
6 Configuring Media-IXT: an Overview This chapter assumes provides tables and notes that bring together configuration information about all three streaming formats. to serve as an introduction to Chapters 7, 8 and 9, which are each about one single streaming format.
Chapter 6 Configuring Media-IXT: an Overview From Media-IXT’s bin directory, run this command for a single Media-IXT host: ./traffic_line -b From Media-IXT’s bin directory, run this command for a Media-IXT cluster: ./traffic_line -B Features and configuration files For reverse proxy caching, you put rules in remap.config. For hierarchical proxy caching, you put rules in parent.config. For selective caching, you put rules in cache.config and filter.config. The rules used in these files differ in format.
Chapter 6 Configuring Media-IXT: an Overview Another difference between WMT remapping rules and those for RealNetworks and QuickTime, is the use of Media-IXT’s IP address for WMT remapping rules. Port numbers are only needed in remapping rules when a non-standard port is being used for the protocol in question. Example: map rtsp://mymixt.com:9090 rtsp://actual-real-server.com RNI RealNetworks notes • Do not modify rmserver.cfg to configure reverse proxy. This is an obsolete method.
Chapter 6 Configuring Media-IXT: an Overview Selective caching and the cache.config and filter.config files Using selective caching, you can specify criteria to determine whether content is proxyable or not, and cacheable or not. When content is not proxyable, Media-IXT denies the client connection, with an appropriate message to the client (if possible). When content is not cacheable, Media-IXT goes into passthrough mode and proxies, but does not cache, the content.
Chapter 6 Configuring Media-IXT: an Overview Media-IXT port usage It’s useful to know which ports are being used by which protocols. Here is a summary that provides the default ports as a point of reference--if you use non-standard ports, of course, you should keep a record of those. Note that which ports are used depend on whether Media-IXT is a forward or a reverse proxy.
7 Configuring Media-IXT for RealNetworks This chapter assumes that you understand the elements of a proxy caching deployment, which are explained in Chapter 3‚ Understanding Media-IXT and RealNetworks, and feature implementation for RealNetworks media streaming, which is explained in Chapter 4‚ Understanding Media-IXT and WMT.
Chapter 7 Configuring Media-IXT for RealNetworks 2. Click the Proxy tab to display the proxy options (shown below). 3. To send RTSP requests directly to the Media-IXT host, check the Use RTSP proxy check box. Enter the host name of the Media-IXT host and the port number that RealPlayer uses to communicate with the Media-IXT host in the boxes provided. For RTSP, HP recommends that you use port number 1091. 4. To send PNA requests directly to the Media-IXT host, check the Use PNA proxy check box.
Chapter 7 Configuring Media-IXT for RealNetworks Media-IXT configuration variables There are no configuration variable that apply exclusively to RealNetworks streaming. Configuring Media-IXT for streaming over HTTP NOTE This procedure affects all streaming formats: RealNetworks, WMT, and QuickTime. Streaming over HTTP is normally only a last-resort streaming strategy, chosen by a browser as a fallback after its preferred strategies fail.
Chapter 7 Configuring Media-IXT for RealNetworks Configuring RealProxy This section explains several issues in the administration of RealProxy. RealProxy port assignment changes. Unlike Traffic Manager, RealProxy does not respond to port assignment changes made to rmserver.cfg when it is sent a SIGHUP signal. Note that if you change port assignments in rmserver.cfg, the rmserver process must be stopped and restarted for the changes to take effect.
Chapter 7 Configuring Media-IXT for RealNetworks To configure RealProxy support of virtual IP addresses: 1. Create additional logical interfaces attached to the primary physical interface and configure IP addresses using operating system administration tools. 2. Add the reverse proxy mapping rules, if required. 3. Follow the procedure for adding IP Bindings using the RealProxy GUI (see “To configure RealProxy to listen on selected interfaces:” above). 4. Restart RealProxy.
Chapter 7 Configuring Media-IXT for RealNetworks For this configuration example we assume: • a Media-IXT host, whose IP address is 10.10.10.10, and which answers to front.myreality.com • an origin RealNetworks server where our RealNetworks streaming content resides; its IP address is 11.11.11.11, and it answers to back.myreality.com To configure reverse proxy caching for RealNetworks: 1. Set the proxy.config.reverse_proxy.enabled variable in the records.config file on the Media-IXT host to 1 (true).
Chapter 7 Configuring Media-IXT for RealNetworks If you see output, you have a VIP-capable cache plugin; if you see no output at all, you do not have a VIPcapable plugin. 3. Copy the patched plugin to the Plugins/ directory of every RealServer in the server farm. 4. Add this line to each RealServers' rmserver.cfg file, substituting the virtual IP address of the layer 4 switch for xxx.xxx.xxx.xxx: 5. Now, on your Media-IXT host, edit the RealProxy rmserver.
Chapter 7 Configuring Media-IXT for RealNetworks Next, you need to add a parent proxy rule to the Media-IXT parent.config file on the child cache to redirect streaming media traffic to a specific parent cache. (Adding a list of parent caches here is unsupported in Media-IXT 4.x). To set the child cache to redirect streaming media traffic to a specific parent cache: 1. In VI, open the Media-IXT parent.config file located in the Traffic Server config directory. Each line in the parent.
Chapter 7 Configuring Media-IXT for RealNetworks In both examples, if host2.domain.com is unavailable, then all requests go directly to the origin server. A hierarchical proxying workaround for PNA and firewalls Hierarchical proxying of PNA is not a supported feature, but there is a special case where it's possible to configure hierarchical proxying (not caching) of PNA. That is when Media-IXT is deployed in conjunction with firewalls in the following way: • The Real Player clients are on an intranet.
Chapter 7 Configuring Media-IXT for RealNetworks Configuring live passthrough in a reverse proxy deployment In a reverse proxy deployment, live passthrough has the same requirement as proxy caching of on-demand content: each origin RealServer for which Media-IXT provides reverse proxy must have its own RTSP rule in the remap.config file. See “Configuring reverse proxy caching for RealNetworks” on page 66.
Chapter 7 Configuring Media-IXT for RealNetworks Modifying the filter.config file to determine proxyability To add a new rule to filter.config, you need exactly one primary specifier, may add one or more secondary specifier, and must choose one of two possible actions. The primary specifier The primary specifier must be one of the following: • dest_domain, meaning domain suffix of sites. Example: where the desired domain suffix of sites is inktomi.com, the rule appears in filter.
Chapter 7 Configuring Media-IXT for RealNetworks The allow and deny actions For filter.config, you must assign one of the two following actions: action=allow action=deny (The other possible actions in filter.config have no effect on Media-IXT.) The example filter.config rules below deny proxy access to all deniedtome.com sites except for vetted.deniedtome.com: dest_host=vetted.deniedtome.com action=allow dest_domain=deniedtome.com action=deny Modifying the cache.
Chapter 7 Configuring Media-IXT for RealNetworks • Media-IXT answers requests for foo.bar.com • Media-IXT performs reverse proxy for the origin server back.door.com. What happens to make this rule work? 1. The RealPlayer client sends a request for content at the advertised website name, foo.bar.com; 2. Media-IXT answers the request, remapping foo.bar.com to back.door.com, the origin server according to its rules in remap.config; 3. Media-IXT applies cache.config to the request after remap.
Chapter 7 Configuring Media-IXT for RealNetworks Media-IXT supports LDAP authentication of RTSP streams using TCP as the underlying transport protocol for the data channel, but not for streams using UDP. The RTSP data channel is much more likely to use TCP than UDP as its underlying transport protocol. NOTE RealPlayer only works with LDAP authentication when configured to use TCP as an underlying transport protocol for the data channel.
Chapter 7 Configuring Media-IXT for RealNetworks To allow the media player to play through the firewall: 1.
8 Configuring Media-IXT for WMT This chapter assumes that you understand the elements of a proxy caching deployment, which are explained in Chapter 2‚ Media-IXT Deployment Scenarios, and feature implementation for Windows Media Technologies media streaming, which is explained in Chapter 4‚ Understanding Media-IXT and WMT.
Chapter 8 Configuring Media-IXT for WMT The Advanced playback settings tab appears: 5. Under Protocols, HTTP should be checked by default. Choose Use proxy and click Configure Proxy Settings. A smaller sub-tab appears: 6. In the Name text field, type the Fully Qualified Domain Name of the proxy host you wish to use (for example: www.anotherproxy.com). Normally you should not change what is in the Port field unless you are a system administrator. Click OK. 7. The sub-tab disappears.
Chapter 8 Configuring Media-IXT for WMT 2. Click Network. 3. Under Proxy Settings, double-click HTTP. The Configure Protocol window appears: 4. Under Proxy Settings, choose Use browser proxy settings. Click OK. 5. In the Internet Explorer Tools menu, choose Internet Options. 6. Click the Connections tab.
Chapter 8 Configuring Media-IXT for WMT 7. Click the LAN Settings button. 8. Under Proxy server, click Use a proxy server, and enter the Fully Qualified Domain Name of your proxy in the Address field. Normally you do not change the Port field. 9. Click OK. To configure Windows Media Player 7 to use a proxy for MMS: This configuration can be performed successfully from within Windows Media Player. 1. In Windows Media Player’s Tools menu, choose Options… 2. Click the Network tab.
Chapter 8 Configuring Media-IXT for WMT 3. Double-click MMS. The Configure Protocol windows comes up. 4. Choose Use the following proxy server: 5. In the Address field, enter the Fully Qualified Domain Name of the MMS proxy. Leave the port at the default, 1755. 6. Click OK. Configuration variables Configuration variables reside in the records.config configuration file.
Chapter 8 Configuring Media-IXT for WMT Media-IXT’s RAM cache The variable proxy.config.cache.ram_cache_mixt_cutoff controls the size of documents stored in Media-IXT's RAM cache. Its default value of zero (0) allows arbitrary size documents to be stored in cache, which is appropriate for streaming media. The only reason to change this value is a severe memory limitation that causes you to want to control the information stored in RAM cache. If you edit the value of proxy.config.cache.
Chapter 8 Configuring Media-IXT for WMT In a reverse proxy deployment: • the proxy.config.wmt.port variable is, correctly, ignored if it exists. • Media-IXT rewrites the WMT metafile using the port specified in the reverse_map rule. By default, the variable does not exist, and the WMT port for forward proxy deployments is port 1755. If you want to use proxy.config.wmt.port, you must edit the records.config file, and add the variable, giving it the desired value.
Chapter 8 Configuring Media-IXT for WMT NOTE Elsewhere in this manual, we say to restart Media-IXT after editing configuration variables. That rule is valid for configuration variables associated with streaming protocols. HTTP is not normally a streaming protocol, though, and after editing HTTP configuration variables, the command traffic_line -x is sufficient.
Chapter 8 Configuring Media-IXT for WMT The MMS protocol uses UDP for retransmission requests. WCCP2 routers do not have the capability to handle UDP retransmission requests. For more information about these issues, and sample WCCP2 router configurations providing transparency for streaming media protocols (RTSP and MMS) as well as HTTP, go to the HP Technical Support website: http://www.hp.
Chapter 8 Configuring Media-IXT for WMT Next, the mms map rule: map mms://10.10.10.10:1755/ mms://source.pix.com:1755/ The mms map rule can alternatively be in this form: map mms://10.10.10.10:1755/ mms://11.11.11.11:1755/ The reverse_map rules (naturally) reverse the terms of the map rules: reverse_map http://relay.pix.com/ http://www.pix.com/ reverse_map mms://11.11.11.11:1755/ mms://10.10.10.10:1755/ reverse_map mms://source.pix.com:1755/ mms://www.pix.
Chapter 8 Configuring Media-IXT for WMT Next, the mms map rule: map mms://10.10.10.10:1755/ mms://source.pix.com:1755/ The mms map rule can alternatively be in this form: map mms://10.10.10.10:1755/ mms://11.11.11.11:1755/ The reverse_map rules (naturally) reverse the terms of the map rules: reverse_map http://relay.pix.com/ http://www.pix.com/ reverse_map mms://11.11.11.11:1755/ mms://10.10.10.10:1755/ reverse_map mms://source.pix.com:1755/ mms://www.pix.
Chapter 8 Configuring Media-IXT for WMT 1. In VI, open the Media-IXT parent.config file located in the Traffic Server config directory. Each line in the parent.config file contains a parent proxy rule. Traffic Server recognizes three spacedelimited tags: = = = 2. Using the syntax below, add a rule to the Traffic Server parent.config file to specify protocol redirection. For Windows Media Players, specify MMS redirection.
Chapter 8 Configuring Media-IXT for WMT When content is not cacheable, Media-IXT goes into passthrough mode and proxies, but does not cache, the content. See the HP Cache Server Appliance Administrator Guide for more information about selective caching. Two configuration files control selective caching: • cache.config controls cacheability • filter.config controls proxyability You must edit cache.config and filter.config manually, adding selective caching rules to the files.
Chapter 8 Configuring Media-IXT for WMT For details, check a book or web site that discusses regular expressions. At this writing, one such site is: http://etext.lib.virginia.edu/helpsheets/regex.html For selective caching and filtering rules for RealNetworks that use url_regex, include the port number. For example, if you are filtering requests for a clip called clip.wvx at bad.content.com, the correct rule to use would be this: url_regex=bad.content.com:1755\/clip.
Chapter 8 Configuring Media-IXT for WMT See the description of url_regex in the section about filter.config above; use of url_regex with cache.config works the same way. In the example below, the rule allows WMT content from 11.11.11.11 to be cached. dest_ip=11.11.11.11 scheme=mms action=standard-cache Differences between forward and reverse proxy selective caching For a reverse proxy deployment, selective caching rules must be written differently than for a forward proxy deployment.
9 Configuring Media-IXT for QuickTime This chapter assumes that you understand the elements of a proxy caching deployment, which are explained in Chapter 2‚ Media-IXT Deployment Scenarios, and feature implementation for QuickTime media streaming, which is explained in Chapter 5‚ Understanding Media-IXT and QuickTime.
Chapter 9 Configuring Media-IXT for QuickTime 6. Change the drop-down menu in the QuickTime Settings window from Streaming Proxy to Streaming Transport (shown below). 7. Make sure that, on the left, Use UDP, RTSP is checked. 8. Make sure that, on the right, Port ID: 554 is checked. 9. Close the QuickTime Settings window. Configuration variables Configuration variables reside in the records.config configuration file.
Chapter 9 Configuring Media-IXT for QuickTime Configuring an origin QuickTime server for use with Media-IXT The Apple® Darwin Streaming Server, version 2.x, is currently the prevalent origin QuickTime server. The following procedure makes it possible for Media-IXT to cache the maximum percentage of QuickTime content served by Darwin 2.x. See “QuickTime Logging” on page 107. To configure an origin QuickTime server for use with Media-IXT: 1. Open the configuration file, streamingserver.conf, in an editor.
Chapter 9 Configuring Media-IXT for QuickTime CONFIG proxy.config.http.transaction_active_timeout_in INT 14520 CONFIG proxy.config.http.transaction_active_timeout_out INT 14520 3. Force Media-IXT to re-read its configuration files. From Media-IXT’s bin directory, run the command: ./traffic_line -x NOTE Elsewhere in this manual, we say to restart Media-IXT after editing configuration variables. That rule is valid for configuration variables associated with streaming protocols.
Chapter 9 Configuring Media-IXT for QuickTime Four principles apply to writing QuickTime map rules: • The map rules in remap.config. make QuickTime reverse proxy caching work by mapping the advertised site name and RTSP port to the URL representing RTSP traffic on the origin QuickTime server. • Use a scheme of rtsp for the URLs in the map rules. • The default port for RTSP is 554. Specify a port in your map rule only when a non-standard RTSP port is used.
Chapter 9 Configuring Media-IXT for QuickTime Assuming that this is so, and that the origin RealNetworks server answers to back.myreality.com, our rules would be: map rtsp://front.myreality.com/ rtsp://back.myquickness.com/ QT map rtsp://front.myreality.com/ rtsp://back.myreality.com/ RNI 4. After we modify the remap.config file, Traffic Manager must reread the configuration files.
Chapter 9 Configuring Media-IXT for QuickTime Two configuration files control selective caching: • cache.config controls cacheability • filter.config controls proxyability You must edit cache.config and filter.config manually, adding selective caching rules to the files. You can, optionally, add an RNI or QT tag to any selective caching rule. This permits you to apply one rule to QuickTime content and another for RealNetworks content.
Chapter 9 Configuring Media-IXT for QuickTime For selective caching and filtering rules for QuickTime that use url_regex, include the port number. For example, if you are filtering requests for a clip called clip.rm at bad.content.com, the correct rule to use would be this: url_regex=bad.content.com:554\/clip.rm action=deny Secondary specifiers Besides the single primary specifier, one or more secondary specifiers may also be added: • port, meaning port on the origin server.
Chapter 9 Configuring Media-IXT for QuickTime dest_host=music.com scheme=rtsp action=standard-cache tag=RNI dest_domain=. suffix=.rm action=never-cache Differences between forward and reverse proxy selective caching For a reverse proxy deployment, selective caching rules must be written differently than for a forward proxy deployment. That is because rules must be based on requested URLs after remapping has been applied. In a forward proxy clients request the origin server hostname.
10 Logging and Monitoring This chapter describes how Media-IXT logs, and allows you to monitor some statistics about, streaming media transactions.
Chapter 10 Logging and Monitoring By default, then, Squid logging is disabled in Media-IXT, but enabled in Traffic Server. In other words, Squid logging is disabled for streaming media protocols but enabled for HTTP. Squid logging is enabled for Traffic Server, when the configuration variable proxy.config.log2.squid_log_enabled in records.config is set to 1. You can also enable and disable Squid logging for Traffic Server through Traffic Manager.
Chapter 10 Logging and Monitoring Although SMIL is a standard, these files only exist in RealNetworks streaming, in our experience. With RealNetworks streaming of SMIL files, you also see a file whose suffix is .rp. The .rp file sits between the SMIL file and the invoked content files: one SMIL file may invoke several .rp files, and one .rp file may invoke several JPEG or GIF files, for example.
Chapter 10 Logging and Monitoring On each collation client: 4. Open the logs_xml.config file in VI. 5. Locate the log object which defines the summary-mixt.log file, which looks like this: 6. Add a CollationHosts parameter to the summary log object, after the Protocols parameter.
Chapter 10 • Logging and Monitoring Media-IXT logs show correct information. 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.
Chapter 10 Logging and Monitoring Although the entire file was originally not in cache, a relatively miniscule portion of the file is logged as coming from cache, because in the group of staggered connections, one connection caches part of the file, and another retrieves that part of the file from cache. NOTE The prcb value for Shockwave files (file extension .swf) can be as much as half of the total number of bytes transmitted because of idiosyncrasies in the Shockwave file format.
Chapter 10 Logging and Monitoring Forward proxy deployment Default behavior. (proxy.config.wmt.logging.origin_gets_original_url value is 0): The origin server records its own IP address as the IP address in the content URL that the client requested. Optional behavior. (proxy.config.wmt.logging.origin_gets_original_url value is 1): The origin server records the request with a content URL as it came from the Windows Media Player. Reverse proxy deployment Default behavior. (proxy.config.wmt.logging.
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 .
Chapter 10 Logging and Monitoring About the styp field The styp logging field first of all indicates whether a stream was live or on-demand content. On-demand content is potentially cacheable–but since not all on-demand content actually ends up being cached, styp also provides information about the circumstances under which the stream was or was not cached. RealNetworks and the styp field The styp logging field is supported for WMT and QuickTime.
Chapter 10 Logging and Monitoring For example: 00000000-0000-0000-0000-000000000000 is abbreviated as 000...000. One field in the example entry has a value of -, which means that no data was relevant for that field; you will see this value in logs from time to time. For more information about logging see the HP Cache Server Appliance Administrator Guide. Field name Present in band no caun no cgid no chi no cqtn yes cqts no cqtx no summarymixt.
Chapter 10 Logging and Monitoring Field name Present in pqsi summarymixt.log? Squid equivalent Usage Description yes used in both Traffic Server and MediaIXT logs The proxy request server IP (0 on cache hits, parent-ip for requests to parent proxies). pqsn no used in both Traffic Server and MediaIXT logs The proxy request server name. prcb yes used in both Traffic Server and MediaIXT logs The number of proxy response bytes to the client from the cache.
982204435 % The client request canonical URL; dif f ers f rom cqu in t hat blanks (and ot her charact ers t hat might not be parsed by log analysis tools) are replaced by escape sequences. The escape sequence is just t he ASCII code number. % 399 % The f ull t ext of t he client HTTP request , minus headers % The number of proxy response byt es t o t he client f rom t he cache.
14/Feb/2001:18:33:55 -0800 % The client request t imestamp; date and t ime of t he client 's request (in t he Net scape t imest amp f ormat ). 24597 % The t ransf er time; total t ransf er time in milliseconds. The corresponding field name in Netscape is in seconds, in Squid it is milliseconds.
Chapter 10 Logging and Monitoring Monitoring Media-IXT traffic Media-IXT lets you monitor streaming performance from the Monitor:Protocols page of Traffic Manager. The same statistics can be viewed from the command line using Traffic Line. The statistics monitored this way are not as accurate as those in Media-IXT’s log files. They are convenient, useful for verifying that Media-IXT is serving content, but the numbers they provide should not be considered authoritative.
Chapter 10 Logging and Monitoring About Cache Transfers in Progress In the Monitor:Node page, the Cache Transfers in Progress statistic behaves differently for RealNetworks than it does for other streaming formats. For RealNetworks, cache connections are kept open for only a fraction of a second. Unless you have very heavy load running against the Media-IXT host, you are unlikely to ever see a non-zero value for cache connections for RealNetworks traffic.
Chapter 10 Logging and Monitoring Summary of statistics Statistic Type and Name Description RealNetworks statistics RealNetworks general statistics Total Objects Served total number of 30 kilobyte chunks served Total Block Hits total number of 30 kilobyte chunks retrieved from cache Total Block Misses total number of 30 kilobyte chunks retrieved from the origin server(s) Total Bytes Hit total number of bytes retrieved from cache Total Bytes Missed total number of bytes retrieved from the origi
Glossary ASF. (Applies to WMT) ASF stands for Active Streaming Format. A container format for multiple streams of synchronized media; a Microsoft proprietary specification. ASF is the format for streaming media files with the extensions.asf,.wma and.wmv. ASX. (Applies to WMT) A Microsoft proprietary specification. The format of the WMT metafile, a text file which contains the URL for an ASF file on an origin Windows Media server. The WMT metafile (ASX file) may have the extension.asx,.wax or.wvx. Cache.
Chapter 1 Live passthrough. When Media-IXT simply passes live content through from the origin server to the client. See “Live content” . Live splitting. When Media-IXT splits one live stream from the origin server into several streams to different clients. See “Live content” . Lower level. Part of hierarchy closer to client. Management-only clustering. Media-IXT cluster nodes share configuration information, so that all nodes can be administered at once as a single system image of the cluster.
Chapter 1 TCP. Transmission Control Protocol; based on RFC 793. Used as the underlying transport protocol by the control channel, and sometimes by the data transfer channel. Based on the principle of a TCP connection between nodes (for example, between a Web client and a proxy cache, or between a proxy cache and an origin server). See “UDP” . Transparency.
English Index A accounting connection, 19 advertised route control, 10 application-level firewalls (proxy firewalls) configuration RealNetworks, 75 ARM interception of UDP packets, 84 ARM (Adaptive Redirection Module), 21 ARM enabled, 66, 84, 95 authentication, 16 C CDS (Content Delivery Suite), 16 CDS preload, 16 CDS preload configuration RealNetworks, 74 child caches, 12 clustering, 15 configuring Media-IXT QuickTime and, 100 WMT and, 91 RealPlayers, 92 D deployment scenarios, 4, 6 E explicit hierarchy,
N network-level firewalls configuration RealNetworks, 75 non-transparent proxy caching, 8 O on-demand content, 13 P parent caches, 12 passthrough mode, 13 PNA (Progressive Networks Audio), 4 Preferences dialog box, 92 RealPlayers configuration, 62, 77, 78 protocols for the data channel underlying transport, 117 proxy authentication, 16 proxy caches, 5, 6 proxy caching forward QuickTime and, 54 reverse QuickTime and, 54 selective caching RealNetworks and, 29 transparent layer 4 switches and, 8, 9, 66, 84, 11
RealServer logs client_GUID field, 105 redirects RealNetworks and, 23 related documents, 2 reverse proxy logging, 102 reverse proxy caching, 6, 9, 10 multiple origin servers, 11, 15 reverse proxy caching configuration QuickTime configuration, 95 RealNetworks, 66 reverse proxy configuration for QuickTime and RealNetworks simultaneously, 68 live passthrough, 71 QuickTime and RealNetworks simultaneously, 97 RealNetworks server farm with a layer 4 switch, 67 RTP (Real Time Protocol), 3 RTSP (Real Time Streaming
