This chapter describes how RealProxy works, and demonstrates the benefits of using RealProxy.
RealProxy is software you install on a network or ISP gateway that aggregates and handles client requests for media streamed from RealServer. RealProxy reduces network traffic by eliminating redundant requests for streaming media.
RealProxy provides four main benefits:
The first step in the RealProxy process happens when clients, such as RealPlayer, request streamed media files via RealProxy.
Next, RealProxy forwards the requests to the RealServer where the requested streamed media files are stored (called the "source RealServer").
RealServer verifies the file's existence, and that the clients are authorized through IP addresses or content authentication. If RealServer denies the request, it does not stream the requested file, and neither does RealProxy. Clients receive an error message.
This initial transaction, in which RealServer examines and authorizes individual client requests, is called an "accounting connection", as shown in the following diagram.
Depending on the nature of the streaming media, RealProxy uses different features to deliver the content to the client.
If the stream is live, RealProxy replicates the live stream for each client requesting the stream. The source RealServer sends only a single stream to RealProxy.
If the live stream is not available for replicating, RealProxy delivers the data separately for each client.
If the stream is on-demand, RealProxy first tries to fill the request from the media cache.
If the content is not yet stored in the cache, RealProxy will pull the content from the source RealServer, simultaneously serving the client and filling the cache.
If the stream is on-demand, and the clip is not cachable, RealProxy passes a data stream for each client that requested it, as shown in the following diagram.
A media cache file lowers network traffic by reducing the number of connections to the source of the requested material, and improves quality by distributing the streaming content closer to the user. Clients receive improved quality of service because media streams travel a shorter distance from the cache to clients, reducing the possibility of network congestion or packet loss.
RealProxy has three different ways of sending data to clients. RealProxy automatically chooses the most efficient feature possible, based on the type of content requested and the network configuration. The three methods are:
In addition, you can configure passthrough and pull splitting to transmit to clients via multicast. Regardless of the feature in use, RealProxy always opens an accounting connection between the client and the source RealServer.
This is RealProxy's simplest method of operation. In addition to the usual accounting connection opened between the client and the source RealServer, RealProxy creates a data connection for each client. No bandwidth conservation is appreciated.
Pull splitting conserves bandwidth for live material. The first time a client requests a particular stream, RealProxy contacts the source RealServer on the client's behalf and then sends the stream to the client. The second client to request a live stream will receive it directly from RealProxy, and RealProxy will not have to obtain another stream from the source RealServer.
The advantage to the client is that the material is delivered from a nearby RealProxy. As long as the quality of reception for the single split channel between RealProxy and the source RealServer is sustained, RealProxy will receive a high-quality live stream, as well.
Cache software stores on-demand content from source RealServers. Since cached files are stored in a proprietary format and cannot be accessed directly, RealProxy interfaces with the cache to redistribute the stored media to clients.
When caching is enabled, the media cache acquires and stores media files when requested by the first client. When a second client makes a request for a stream, RealProxy checks with the cache to see if a stored version is already present. To ensure that the stored version is the most up-to-date version available, RealProxy checks with the source RealServer to see if a newer version exists. After determining that the stored copy is the latest version, RealProxy streams the stored copy to the second client, and to subsequent clients that request the same material.
Only on-demand files streamed by RealServer 7.0 or later can be cached. Live material is handled as in the most efficient mode suitable—pull splitting or passthrough (and sent via multicast, if available on the network).
To ensure high-quality data at all times, RealProxy monitors the quality of both the cached media it is streaming and the connection between the source RealServer and the client. Should the media in the cache become impaired in some way, the stream halts and clients receive an error message. Or, if the accounting connection between the client and the source RealServer is interrupted, RealProxy terminates the stream, and the client receives an error message.
If a source RealServer has been configured to prevent caching, RealProxy will use the passthrough feature to deliver content to clients, without caching the media. When RealServer is installed, all its streams are cachable by default. Since RealServers can reach more clients if caching is allowed, operators are encouraged to leave all content cachable.
The following table outlines the configuration requirements for each aspect of RealProxy operation. In addition, RealProxy can be configured to use multicasting (where available) for those clips delivered in pull splitting mode. For more information, see Chapter 11, "Multicasting Live Streams".
The method that RealProxy uses to distribute streams can depend on the version of the RealServer where the streaming media originates. For more details, refer to the table below.
RealProxy contains additional features that make it easy to configure, administer, and maintain.
RealSystem Administrator is a web-based console for customizing RealProxy features. You can access via a browser anywhere on your network, using either Netscape Navigator version 4.06 or higher, or Internet Explorer version 4.0 or higher.
Changes you make using RealSystem Administrator are stored in the RealProxy configuration file. This text file is based on Extensible Markup Language (XML) and can be edited directly. Because the structure of this file is complex, RealSystem Administrator is the recommended tool for making changes.
See Chapter 4, "Configuring RealProxy Features" for specific instructions on customizing RealProxy.
Once you have configured RealProxy, you will need to arrange for clients (such as RealPlayer) to send their requests to RealProxy.
There are two ways you can do this:
To limit the amount of bandwidth used by RealProxy, several features allow you to restrict the number of requests or amount of bandwidth it uses. Clients that attempt to contact RealServers after RealProxy's limits have been reached receive an error message.
 |
Additional Information |
|---|---|
| See Chapter 8, "Managing Bandwidth". |
For organizations that use strict rules to regulate Internet traffic, proxy routing allows you to further control network traffic. With this feature, you can configure RealProxy to direct its clients' requests to yet another RealProxy.
|
|
Additional Information |
|---|---|
| See Chapter 10, "Proxy Routing". |
RealSystem Administrator includes a Monitor which dynamically displays the status of your RealProxy.
|
|
Additional Information |
|---|---|
| Refer to Chapter 13, "Monitoring RealProxy Activity". |
RealProxy records information in the access log about all clips it has served. Errors are noted in the error log.
RealProxy error logs use the same format as RealServer error logs. Access logs are similar to RealServer logs, but include additional information about the address of the source RealServer and the RealProxy operational mode (pull splitting, caching, and so on).
Log files on the source RealServer do not show that a RealProxy is in use; only the client data is gathered.
|
|
Additional Information |
|---|---|
| Access and error log information is described in depth in Chapter 14, "Tracking RealProxy Activity". |
This section describes what happens on the source RealServer when RealProxy forwards a client request.
|
|
Additional Information |
|---|---|
| If you are working with both RealProxy and RealServer, you may be interested in "Administering Both RealProxy and RealServer". |
Each time it receives a request, RealServer determines whether it can allow a particular client to receive streams, based on the number of available streams and bandwidth. In addition, RealServer may be configured to require a user name and password for certain material. If the requested material requires a password, the user will be prompted for the password. RealServer does not begin streaming until it receives the correct password.
Only after RealServer has authorized the client's request will RealServer begin streaming. Restrictions imposed by the source RealServer's administrator on client access are always honored by RealProxy. The same is true when a cache is in use—RealProxy waits for RealServer approval of each request before streaming it from the cache.
A source RealServer may deny a request for the following reasons:
The client receives a message if it is denied access for any reason.
To the source RealServer, requests made via RealProxy appear identical to requests made by any other client, and information about quality of service is logged in the log file, just as it is for any other type of connection. Information about quality of service comes from the accounting connection.
RealProxy only streams media from the cache after opening an accounting connection to the source RealServer. If the accounting connection cannot be established, or if it is disrupted, RealProxy will not stream from the cache to the client.
RealProxy cannot cache content which a source RealServer administrator has configured as non-cacheable. Instead, it will use passthrough mode to deliver the material to the client.
Under the following circumstances, RealProxy will be unable to conserve bandwidth:
In all cases, however, using RealProxy on your network serves to collect all streaming media traffic at a single point, so that you can better monitor activity and maintain security.
RealProxy handles client requests and proxies RealServer streams by using the Real Time Streaming Protocol (RTSP), an Internet standard control protocol for streaming multimedia, and PNA, the RealNetworks legacy protocol. Although RealServer can stream via HTTP, RealProxy is not an HTTP protocol proxy and thus does not handle any streaming media requests made via HTTP between clients and a source RealServer.
RealProxy works with connecting RealPlayers to determine the best transport to use for a given stream: IP multicast (for live broadcasts), or UDP and TCP (for both live and on-demand content).
Data types streamed by RealServer and RealProxy use two primary packet formats: RDT, a proprietary packet format native to RealSystem, and RTP, an Internet standard data type packet format.
The following table outlines the protocols, transports, and packet formats supported by RealProxy.
|
|
Additional Information |
|---|---|
| For details on the control transports and data packet transports allowed on each port, see Chapter 7, "Firewalls and RealProxy". |
