This chapter covers features that are specific to the operating system, such as allowing users to view the source code of SMIL files and media clips, as well as reserving IP addresses for RealServer's use, running RealServer on the same system as a Web server, and working with firewalls.
Just as users can right-click an HTML file and view the HTML code that was used to create a Web presentation, RealServer contains a feature that enables users of RealPlayer 7 and later to view the source code for SMIL presentations or information about media clips. When a user right-clicks on a presentation or selects View>Clip Source, RealServer sends a Web page that contains the text of the SMIL file, or data about the clip, to the user's browser.
Users can then "learn by example" and understand how to create their own SMIL files. Content creators will find this feature useful when they troubleshoot SMIL files.
The HTML page that displays the text of the SMIL file also links to information about each clip referenced by the SMIL file. The information shown on these pages describes the contents of the entire file, including information such as file size, buffer time, and bit rate.
RealServer sends the text of the SMIL file to the browser using an automatically generated Web page. In the browser's address box, the URL shown is:
http://realserver.example.com:8080/viewsource/template.html?ABcdlkj293847
By default, the name and path of the SMIL file are not shown; random numbers and letters are displayed instead. (You can make the SMIL path and file name appear; use the instructions in "Allowing Users to See Complete Paths in SMIL Files".)
Within the text of the SMIL file in the browser, all references to other files are shown as hyperlinks. Clicking these links displays another Web page, with detailed information about each referenced file.
This feature is especially helpful for content creators, as it also enables them to see detailed information about the components of the SMIL file.
To protect the location of your content, this feature is initially configured to omit the full path of the clips referenced in the SMIL file, showing an ellipses (...) instead. You can also disable this feature for some or all paths.
 |
Note |
|---|
| For content on your local computer, paths are always shown. They cannot be hidden. |
The content browsing feature creates a Web-based directory with links to all on-demand content available on to your RealServer. By clicking View Source>Browse Content Now in RealSystem Administrator, you generate the index. Only other administrators who know the correct URL, user name, and password for RealSystem Administrator can view on-demand content available to this RealServer.
Although it is not the preferred delivery method, some content creators serve SMIL and media from Web servers. When a user selects View Source for content delivered by a Web server, the paths that appear in the SMIL file are hidden. Source information is available for all other media clips delivered by the Web server. Since RealServer has no control of Web servers, settings used for the View Source feature in RealServer have no effect on how the source code is displayed for content served by Web servers.
The view source feature interacts with other RealServer features.
The view source feature applies to both on-demand and live content.
The browse content feature applies only to on-demand content.
The browse content feature is a good way to take inventory of your Archive directory.
On-demand files that are converted to live files through the use of G2SLTA show the same information as any other live files.
View source is disabled for users who are receiving a broadcast through a backup push splitting source.
The view source feature is automatically disabled for all secure content.
A record is created in the access log when a user makes a view source request. See the "Summary of GET Statements" table.
In RealSystem Administrator, click View Source, then click Source Access. At installation, the settings are:
The view source feature has these options that you can customize:
You can choose to enable the view source feature for a limited number of paths, or, conversely, to enable it for most paths but disable it for only a few.
No.
Yes.
Use Settings Above is selected.
Yes.
No.
Use Settings Above is selected.
In the Master Settings area, the settings for View Source and Hide Paths are normally Use Settings Above. By selecting one of the other two options, Disable View Source or Enable View Source, or Show All Paths or Hide All Paths, you can leave the settings of the individual paths intact, but supersede them with the new values. This can be useful for temporary troubleshooting, or for disabling the feature quickly and globally.
Of course, these settings do not have to be temporary. They stay in effect until you change them.
At installation, view source is configured to "hide" the paths of the clips referenced in SMIL files. This protects the privacy of the content creators, and enables the user to focus on the syntax used within the SMIL file.
For example, the following tag within a SMIL file:
<video src="rtsp://realserver.example.com/presentation/presentation.rm" region="VideoRegion">
<video src="rtsp://.../presentation.rm" region="VideoRegion">
Identifying information is removed, and only the protocol and file name are shown.
No.
The content browsing feature creates a Web-based list of all on-demand content that your RealServer can stream.
If the clips are stored on your hard drive, full paths are always shown.
In RealSystem Administrator, click View Source. Click Browse Content Now.
A new browser window appears, containing two columns. Along the left column, labelled Info, the word "Directory", "MountPoint", or a file size appears. The next column shows a file name. The third column contains a link to the file.
In RealSystem Administrator, click View Source, then click Content Access. At installation, the settings are:
* (all file types will be browsable)
smi and smil.
RealProxy is software that stores streamed media. While it is not part of RealServer 8, it can work with RealServer to share the distribution load, thereby conserving bandwidth over an intranet and allowing RealServers to send streams to a wider audience. It is generally installed on an intranet or on a large Internet Service Provider (ISP). When a client on the intranet or hosted by the ISP requests a streamed media file, RealProxy intercepts the request and sends it on behalf of the client. RealProxy then stores the requested media and streams it to any other clients who subsequently request the same material.
RealServer is designed to work with RealProxy. RealServer is configured at installation to allow all content to be cached by RealProxy. This ensures that clients whose requests are sent via RealProxy will be able to view your content. Also, because more than one RealProxy is now rebroadcasting some of your content, your RealServer now has more connections available.
Only on-demand content can be cached by RealProxy.
This section describes how RealServer interacts with RealProxy software.
All on-demand clips are automatically available to media caching software. If there is content served by your RealServer that you do not want to be cached by a media cache, you can mark it as non-cacheable, on a per-file or per-folder basis.
Live clips are not available to media caching software; RealProxy will still proxy the live broadcasts for clients. RealServer acts as a source for pull splitting, and RealProxy acts as a receiver.
RealServer does not see the IP addresses of the individual clients that request content; instead, it sees the IP address of the RealProxy. You can prevent specific RealProxys from requesting material on behalf of clients (see "Preventing Certain RealProxys from Accessing Your RealServer"). But if you do, you will also prevent all those clients from accessing your clips.
Before allowing clips to be cached, RealServer verifies whether the client's IP address is valid. If the requested material is marked as secured, it then performs any necessary authentication checks.
Authenticated material can be stored in a RealProxy cache, but the client will be authenticated with the source RealServer every time it tries to access the stored clip.
All on-demand material served on behalf of ISP-hosted customers can be cached, unless you mark those directories as non-cacheable (see "Preventing Some Paths and Files from Being Cached").
The Java Monitor will show the IP address of the caching software as it plays a clip. The caching software is not identified as such; rather, it appears to be a client.
All client requests for streaming media are recorded in RealServer's access log, as if they were made directly by clients and not sent through RealProxy. In addition, a separate log file, cache.log, records all clips that were accessed by RealProxy. The cache.log file can give you an idea of which content is most requested by media caches.
The access log will show a record for the request made by the cache software, and for every client request.
The access log and the cache log are independent of each other.
 |
Additional Information |
|---|
| The cache log is explained in Chapter 19, "Reporting RealServer Activity". |
All material served through the ad streaming feature is cacheable, unless you mark those directories as non-cacheable (see "Preventing Some Paths and Files from Being Cached").
On the Cache page (located by clicking General Setup), the Cache Port number 7802 is shown. RealProxys will send their requests to this RealServer port.
If you change this value, requests by RealProxy will not be accepted by RealServer, and therefore will not be cached unless you share the new port number with the administrators of all RealProxys that are accessing your streams.
Unless you specify otherwise, all material on your RealServer is available to RealProxy. RealServer has these options for restricting which RealProxys can cache streams:
You can restrict the paths and files RealProxys can store. If RealServer receives a request for material included in the No-Cache Paths list, it streams the file directly to the client rather than allowing it to be cached and re-transmitted. As always, RealServer records the transaction in the access log, and reports a download size of 0 bytes in the cached requests log file.
For example, you might choose to prevent material in authenticated content locations from being cached. Or, you might put the path to time-sensitive clips on this list so that it cannot be stored by RealProxy.
|
|
Note |
|---|
| Media caching software makes more streams available on your RealServer. If you limit which clips can be cached, you also limit how many clients you can serve. |
For example, if a subdirectory of the Content directory contained a directory named News, you would add /News to the No-Cache Directory box. If you only wanted to prevent the late-breaking news clip from being cached, you would add that to this list instead: /News/breaking.rm.
You can indicate that certain RealProxys are not allowed to cache any of your material. To do this, you must know the IP address of the machine on which RealProxy is installed.
 |
Tip |
|---|
Look in the cache.log file to find the IP addresses of
cache software that is accessing your content.
|
Create an access rule for the RealProxy you want to restrict. In addition to specifying the IP address, indicate the port number to which access should be denied (usually 7802).
|
|
Additional Information |
|---|
| To learn about limiting access to your RealServer according to the IP address of any other computer, see "Limiting Access with the IP Address". |
The distributed licensing feature enables you to purchase a single license to be used by multiple RealServers on your network, that share a pool of streams to be used for specific features. The authentication and ad streaming features can both use this feature.
The RealServers that share a license are called a license group. Clients are not denied service unless the entire pool of connections in the group is in use.
When you use this feature, you place the main license file on the main RealServer (called the publisher). You configure the publisher RealServer, then configure corresponding RealServers (called subscribers). The subscribers can be set up to look for a primary publisher RealServer, and if that RealServer is not available or has too few connections available for use, a secondary RealServer publisher can be called upon.
|
|
Note |
|---|
| Within a given network or organization, you can have multiple groups, but you should not use this feature outside of a network or across a firewall. |
Each RealServer maintains its own configuration file, and can be configured independently using RealSystem Administrator. The features available to each subscriber depend on the features permitted by the shared license, but can be configured independently to use different values.
To use this feature for the first time requires three steps:
Once you have configured both publisher and subscribers, you must remember to start the publisher before starting the subscribers. If you start the subscribers first, they will operate with minimum settings until the publisher comes online. For a list of these settings, see "Minimum Licensed Features".
In addition to the steps shown below, you must tell the person who is setting up the subscriber what value you are using for Admin Port.
You'll need to know the value for each publisher's Admin Port, as well as each publisher's IP address.
Distributed licensing is now active; RealServers can pool their stream count and feature availability.
On the publisher, you can use a license group monitor to view the number of connections currently in use by the subscribers.
On the publisher, in RealSystem Administrator, click License Group. Click Monitor.
The Monitor page appears, and shows the number of publishers, subscribers, and connections currently in use.
When RealServer starts, it uses the IP address assigned to the machine's host name.
You can configure RealServer to always use a specific IP addresses by setting up the IP Binding list. Within this list, you cite individual addresses to use, or you can bind to all the IP addresses available on the RealServer machine.
To capture all addresses for RealServer's use, add the IP address of 0.0.0.0, and delete any other addresses. RealServer will automatically bind to all addresses and to localhost (127.0.0.1).
|
|
Tip |
|---|
Binding to all addresses, by using 0.0.0.0, is
recommended for most administrators.
|
If you type a specific address, RealServer will bind to the specified address only; it will not bind to localhost.
 |
Warning |
|---|
Use either 0.0.0.0 or a specific address, but not both. If
you use both, RealServer will not start.
|
If you leave the IP Address box blank, RealServer binds to the host IP address and localhost. It does not bind to any other addresses.
If you install RealServer on the same system as your Web server, you may need to complete additional steps. Most Web servers use port 80 for HTTP requests. At installation, RealServer's default HTTP Port is 8080, but if you configure RealServer to use port 80 (the same port as the Web server), problems may ensue. You may have to perform the following steps:
Because RealServer can serve requests for HTML pages sent via HTTP (such as RealSystem Administrator), if RealServer is on the same system as a Web server, requests that begin with http:// may be misdirected. When a user clicks a link that begins with http:// and it does not contain a port number, the client supplies a port number of 80. When the Web server and RealServer are on the same machine, the Web server will attempt to serve the file. If the link points to what's meant to be a RealSystem presentation, the Web server will not find the file and will display the error message "File not found".
To prevent this problem from occurring, make sure the HTTP Port value is not the same as the port number your Web server is using. The default value is 8080. Most Web servers use port 80. Be sure that you include RealServer's HTTP Port number in the URL.
You may need to reserve at least one IP address for RealServer's use. Assign RealServer and the Web server to individual addresses, so that they can both use port 80. See the "Distributed Licensing" section earlier in this chapter.
Client software (such as RealPlayer) always tries to receive RealServer content via the RTSP or PNM protocols. But if it cannot use either of these (for example, if a firewall does not permit those types of traffic), it will signal RealServer to send the data by wrapping it in the HTTP protocol. This method is known as "HTTP cloaking". While this method does not provide the best possible user experience, it does allow users to receive streamed media who would otherwise be blocked.
The new port hinting feature enables the content creator to specify ports to use when the client requests a cloaked stream, or to automatically send the port information when ramgen is included in the link. Thus a content creator can add any of the following lines to an URL:
?cloakport="port1"
?cloakport="port1 port2 port3"?cloakport="port1, port2, port3"
where port1, port2, and port3 are ports that your RealServer uses (generally 554, 7070, and 8080). The ports will be tried in the order they're listed.
Add the cloakport switch to the full URL:
http://www.example.com:8080/ramgen/clip.rm?cloakport="554, 7070, 8080"
A user who clicks this link will now be able to receive a cloaked stream (should one be needed) more quickly than in previous versions of RealServer.
Or, the content creator can omit this information, and RealServer will include it automatically if ramgen is used in the link.
This feature is used only by RealPlayer 8.
RealServer is configured for port hinting by default. To inspect the settings it uses, click General Setup>Ports. The following setting is used:
A single variable controls this feature in the configuration file:
<Var CloakingHint="1"/>
where 1 means enabled, and 0 means disabled.
While RealServer functions nearly identically on both Windows NT and UNIX platforms, there are a few differences that allow you to take advantage of unique characteristics of each operating system. These features and settings are optional.
This section describes features unique to RealServer running on a Windows NT system.
When you install RealServer, you have the option to install it as a service. You can also configure this later. Several RealServers can be run from the same machine, with different configuration files.
|
|
Additional Information |
|---|
| See "Setting Up RealServer as a Service Under Windows NT". |
RealServer comes with a file to use with the Windows NT Performance Monitor, so that you can use the Windows NT method of monitoring RealServer performance.
|
|
Additional Information |
|---|
| See "Optional Java Monitor Features". |
RealServer information and errors are displayed in the Windows NT Event Viewer.
This section describes features unique to RealServer running on a UNIX system.
The User setting indicates the user name under which RealServer runs. The user name must exist on the computer on which RealServer is running; otherwise, RealServer will not start.
If you do not specify a user name when installing RealServer, the user name defaults to the user name of the user who first logs in and starts RealServer; this is accomplished with the default value of %-1.
The Group variable gives the group name under which RealServer runs. The group name must already exist on the computer on which RealServer is running; otherwise, RealServer will not start.
If you do not specify a group name, this variable defaults to the group name of the user who first starts RealServer.
|
|
Note |
|---|
Be sure that the user or group name you assign has
write permissions for the Logs and Secure directories.
|
%-1, which means RealServer uses the user name of the user who logged in and started RealServer.
%-1, which means RealServer uses the group name of the user who logged in and started RealServer.
RealServer creates a text file that stores the current value of the process ID of the parent RealServer process, rmserver. The file is stored in the directory indicated by the PidPath variable, and is named rmserver.pid at installation. If PidPath is omitted from the configuration file, RealServer stores the information in the directory specified by the LogPath variable.
Some changes that you make to RealServer require that RealServer re-read the changes while still running. Other changes require that RealServer be restarted. If you use RealSystem Administrator to change settings, it will either force RealServer to re-read the configuration file while RealServer is still running (thus preserving all connections), or it will display a message instructing you to restart the Server at your convenience.
If you make changes to the configuration file manually, you will need to instruct RealServer to re-read the configuration file. This is possible for RealServer running on a UNIX platform with the SIGHUP command. Use the following command at a command prompt:
kill -HUP processID
where processID is the RealServer process number, as shown in the Logs/rmserver.pid file.