previous next

Chapter 8: Splitting and Multicasting

RealServer has two methods that reduce the number of streams while distributing high-quality live streams: splitting and multicasting.

Overview

In delivering clips, RealServer sends one stream to each client that requests a clip. This method is called unicasting. A server can easily become overloaded when many clients connect to a single server to receive a presentation. Also, the network can easily become saturated with media data being sent from RealServer to many clients.

Splitting makes efficient use of RealServer networking and resources by redirecting one live stream to another RealServer, which in turn serves the stream to other clients. The load on the original RealServer is thus reduced.

Multicasting is an efficient way of broadcasting a live event over a multicast-enabled network. Multicasting uses less network bandwidth since data packets are sent to all clients via a single transmission. There is no point-to-point connection made between the client and server for the data stream.

Splitting and multicasting are used only for live content.

Splitting

Splitting solves the problem of one server getting overloaded by stream requests for live material. In splitting, one or more RealServer servers join the main RealServer to distribute the number of streams. Rather than having all the requests come to one server, the RealServer to which the encoder is attached (also called the source splitter, or just the RealServer) sends one stream to the other RealServer (called the splitter). The splitter can also serve the content, thus multiplying the number of available streams.

For example, a concert from Japan can be broadcast over the Internet to RealServers in Australia and North America. Users in those cities connect to the RealServer closest to them, thereby getting better media quality and performance. While serving content that originated on another computer, a RealServer can simultaneously stream its own content.

Splitting

Web pages listing the event would have different links for different locations:

Sample Web Page

RealServer Splitting Methods

There are two types of splitting: push splitting and pull splitting.

In pull splitting, the link to split material includes the locations of both the source and the splitter. It requires few changes to the configuration file on either computer.

Just as in unicasting, both splitting methods support bandwidth-negotiated files (such as SureStream).

Push Splitting requires more setup time, but it can mean faster connections to the first client requesting a split stream.

Comparison of Push Splitting and Pull Splitting
Push Splitting Pull Splitting
Pre-establishes a connection, so when first client connects there's no wait time Does not pre-establish a connection. After the first client connects, the connection remains until the encoder stops the session.
Uses bandwidth while waiting for someone to listen. The first client to request split material has to wait 30 seconds or so while a splitter connection is built. May use small amount of bandwidth even if no clients are playing streams.

Push Splitting

In push splitting, RealServer and the splitter are in constant communication. When a client requests a file from the splitter, a connection has already been established between the splitter and RealServer and the file is delivered to the client almost immediately. If there is already a connection between splitter and RealServer and a new encoder hooks up, RealServer will immediately feed that stream to the splitter.

You can limit which directories are split by setting a variable in the relevant directory section.

Pull Splitting

In pull splitting, the link on the Web page lists the splitter and the RealServer where the streamed file originates.

When the splitter gets a request for the live file, it opens a stream to the RealServer, and the RealServer streams the file to the splitter, which, in turn, streams it to the client.

This method only uses bandwidth when a client requests a split stream. In addition, the only configuration steps are to make certain that both the RealServer and the splitter have a splitter file system listed.

Controlling Splitter Access to Your RealServer

You can specify the splitters that are allowed to query your RealServer for live streams by adding their IP addresses to the Access Control list. In this list, you indicate the ports to which they can send their requests.

If you do not limit the splitters, any splitter can access your server.

Using Both Push Splitting and Pull Splitting

You can combine these methods to make the best use of your bandwidth.

Setting Up Push Splitting

To set up push splitting, make changes in three places:

  1. Edit the source RealServer settings.

  2. Edit the splitter's settings.

  3. Add splitter URLs to a SMIL file or Ram file, which in turn is linked to the Web pages.

    Additional Information
    Information on editing the configuration file is found in Chapter 4: Customizing RealServer Features.

To set up the source RealServer for push splitting:

  1. In RealSystem Administrator, click Splitting. Click Push.

  2. In the Splitter Description section, click Add. A new browser window appears.

  3. Type a name for this splitter configuration in the Description box.

  4. In the Mount Point box, type the mount point you want to use in the URLs.

  5. Type the name of the machine on which this RealServer is running in the Host Name box. RealServer uses this value to identify itself in the resource URL when it feeds a live stream to a splitter.

  6. Click Add.

    You are returned to RealSystem Administrator. Look in the Options for Splitting Settings area.

  7. If you want all live streams originating from this RealSystem Administrator to be sent to other splitters, select Yes in the Split All Streams list.

  8. If you want to split only specific live streams, click Add to add the virtual path names to the configuration file.

  9. In the new browser window that appears, type the name of the virtual path in the Source Name box.

  10. From the Splitting list, select Enabled or Disabled.

  11. Click Add to return to RealSystem Administrator.

  12. In the Splitter Resend Buffer box, type the size of the buffer (in seconds) for UDP resends. It can range from 0 to 32767; the default value is 30.

  13. If you want to limit how many seconds RealServer will wait before it stops sending data to a splitter that is not responding, type a value in the Splitter Source Timeout box. The default value is 30.

  14. List the splitters that are allowed to obtain content from this RealServer by adding their IP addresses to the Access Control list. Add one rule for each IP address or range of addresses. List the port or ports to which the receive splitters can direct their requests. See "Limiting Access Via IP Address" for instructions.

To set up the splitter for push splitting:

  1. In RealSystem Administrator, click Splitting. Click Push.

  2. In the Splitter Description section, click Add.

  3. In the new browser window that appears, type a name for this splitter configuration in the Description box.

  4. In the Mount Point box, type the mount point you want to use in the URLs.

  5. In the Port box, type a port number to which the source RealServer will send its streams. In other words, the value for refers to the port number on the receive splitter. The default value is 11001.

  6. Type the name of the machine on which this RealServer is running in the Splitter Host Name box. RealServer uses this value to identify itself in the resource URL when it feeds a live stream to a splitter.

  7. Indicate where the encnet.dll (Windows) or encnet.so.6.0 (UNIX) file is located by typing its location in the SupportPathDirectory box. This is usually the RealServer Lib directory.

  8. Click Add.

    You are returned to RealSystem Administrator. Look in the Options for Splitters area.

  9. Define how many seconds of data to store in the buffer by typing a number in the Splitter Buffer Delay box. This helps reduce packet losses (dropouts) over a splitter connection. The recommended value is 30 seconds; a minimum of at least 10 seconds should be used.

  10. Define how long the splitter will wait before considering a stream inactive. Type the number of seconds, from 0 to 32767 in the Splitter Timeout box. The default value is 30.

  11. Set how often the splitter will request a stream. Type this number in the Splitter Source Probe Interval box. This value is given in seconds, and can range from 0 to 32767. The default value is 30.

  12. List the RealServer or RealServers that the splitter should contact for live material to split. In the Splitter Sources area, click Add.

  13. In the new browser window that appears, type a name for the source in the Description box.

  14. In the Address box, type the name of the source RealServer. This splitter will contact the RealServer and request its streams. This splitter will, in turn, split those.

  15. In the Port box, type the port number of the source RealServer to which this splitter will send its requests.

  16. Click Apply to return to RealSystem Administrator. Click Apply again.

To create the link for push splitting within a SMIL file or Ram file:


rtsp://domain_name:RTSPPort/Splitter_MountPoint/SplitterHostName/Live_MountPoint/Virtual_Directory/filename.xxx

RealServer URL Components
Component Meaning
rtsp The protocol used for streaming.
domain_name Domain name of this RealServer. IP address may be substituted.
RTSPPort Port number where RealServer listens for requests sent via RTSP. This value is usually 554; see "Port Variables".
Splitter_MountPoint The push splitting mount point used on this RealServer, usually /farm/.
SplitterHostName The source RealServer's SplitterHostName value.
To allow the client to receive streams which differ only by the source server's SplitterHostName, use an asterisk (*). If multiple connections exist which match the query, this splitter decides which stream the client will receive.
Live_MountPoint Mount point for live content on the source.
Virtual_Directory The virtual directory, as defined by the encoder.
filename.xxx The name of the live stream.

This URL can be used on both the source RealServer and the splitter. Be sure to use the domain name for the system where the link is located: on the source, use the source domain name, and on the splitter, use the splitter domain name.

Setting Up Pull Splitting

Like push splitting, pull splitting has three steps:

  1. Edit the source RealServer settings.

  2. Edit the splitter settings.

  3. Add splitter URLs to the Web pages.

Configuring the source and the splitter is a quick matter; setting up the URL is more complicated.

To set up the source RealServer for pull splitting:

  1. In RealSystem Administrator, click Splitting. Click Pull.

  2. Click Add. A new browser window appears.

  3. In the Splitter Description box, type the name for this splitting configuration.

  4. In the Port box, list the port to which the source RealServer will listen for splitter requests. A typical value is 3030.

  5. Click Add.

    You are returned to RealSystem Administrator.

To set up the receive splitter for pull splitting:

  1. In RealSystem Administrator, click Splitting. Click Pull.

  2. Click Add. A new browser window appears.

  3. In the Splitter Description box, type the name for this splitting configuration.

  4. In the Mount Point box, type the mount point you want to use in the URL. A typical value is /split/.

  5. Click Add.

    You are returned to RealSystem Administrator.

To create the link for pull splitting:

The link that appears on the Web page that points to the receive splitter looks like this:


protocol://splitter[:protocol_port]/splitter_MountPoint/source:[source_port]/source_MountPoint/filename

RealServer URL Components
Component Meaning
protocol The protocol used in streaming. For example, rtsp.
splitter Domain name where the receive splitter is installed. IP address may be substituted.
protocol_port The protocol port on the splitter, as specified in the splitter's RTSP Port or PNA Port setting. For example, if the streaming method is RTSP, then the port value must match the splitter's RTSP Port setting. The protocol_port is optional, and need only be used if you have changed the port setting from its default value.
splitter_MountPoint The receive splitter's Pull Splitting mount point, usually /split/.
source Domain name where the source RealServer is installed.
source_port The source RealServer's port number as specified by the Port value in the Pull Splitting list, usually 3030. This number is optional, and need only be supplied if you have changed the port value on the source. If you omit it, the splitter will use the default value of 3030.
source_MountPoint The source RealServer's mount point that is appropriate to the material you're splitting, such as /encoder/.
filename Name of the file being split.

For example, links in the sample shown at the beginning of this chapter would look like the following (note that the direct link to the Japan server is not in pull splitting format):


...we hope you enjoy the concert! Choose the link nearest you:

<a HREF="http://Japan.company.com.ja/concert.rm">Japan</a></p>
<a href="http://Australia.company.com.au:8080/split/
Japan.company.com:3030/encoder/concert.rm">Australia</a></p>
<a href="http://NorthAmerica.company.com:8080/split/
Japan.company.com:3030/encoder/concert.rm">North America
</a></p>

Multicasting

Multicasting is a way of sending a single live stream to multiple clients, rather than sending a stream to each of them.

Multicasting

In contrast, regular unicasting transmission sends a stream to each client who requests it:

Unicasting

To take advantage of multicasting, both RealServer and clients, as well as the routers between them, must be multicast-enabled. For this reason, multicasting is mostly used with intranets where routers can be configured for multicasts. Multicast delivery can be done over the Internet where intermediary network devices have been multicast-enabled, such as UUNET and the Internet Multicast Backbone (Mbone).

RealServer Multicasting Methods

RealServer includes two methods of multicasting: back-channel multicast, which has methods for RTSP and PNA multicast, and scalable multicast. You can use all methods at once.

Back-channel multicast maintains a TCP control channel between the client and RealServer. RealServer uses this channel to provide information about the presentation and to query the client for a user name and password, if authentication is in use. The client uses the TCP channel to send password information and commands such as "play" and "stop". With this information, RealServer can track how many clients are viewing a presentation. Monitoring tools such as the monitoring graph in RealSystem Administrator will show client activity.

Scalable multicast does not use this TCP control channel. It thus takes up far less bandwidth and administrative overhead. Monitoring tools such as G2 Java Monitor will not track client activity.

Back-Channel Multicast

In both RTSP and PNA multicast, authenticated material and client statistics can be sent because the exchange between the client and RealServer is bi-directional.

RTSP Multicast

This method of multicasting uses RTSP to send control information over a TCP channel. RealServer maintains a control connection for each client. The data channel is multicast to all clients.

RTSP multicast provides the following features:

RTSP multicasting works only with RealSystem G2 clients.

RTSP Multicasting

PNA Multicast

PNA multicast uses the PNA protocol over a TCP connection to exchange information between the client and RealServer.

PNA multicast is used when transmitting to older clients (pre-G2). RealServer maintains a control connection for each client. The data channel is multicast to all clients.

PNA multicast supports the following features:

PNA Multicasting

Scalable Multicasting

Scalable multicasting allows you to transmit to an unlimited number of clients because the transmission from the RealServer is completely one-way; there is no connection from each client to RealServer at all. All data is multicast on the network once. Each client connected to this multicast receives all data packets.

It is thus suitable for situations that would otherwise consume much bandwidth.

Scalable multicasting uses a different URL format than either RTSP multicast or PNA multicast.

This methods supports G2 clients only; clients version 5.0 and older will not receive any presentations.

Scalable Multicasting

Summary of Multicast Methods

The following table summarizes the benefits of each multicast method.

Multicast Methods
Back-Channel Multicast Scalable Multicast
Feature RTSP PNA
Control channel · ·
Authentication · · ·
Client statistics · ·
Minimal RealServer resource use ·
RTP enabled ·
SureStream support ·
Live bandwidth negotiation · ·

The following table shows the features of the three multicast methods, as they apply to clients

Back-Channel Multicast Scalable Multicast
Feature RTSP PNA
RealSystem G2 clients only ·
Older clients ·
RealSystem G2 clients or any RTP-enabled clients ·

Logging Multicasts

Material served via back-channel multicast appears in the access log just like unicast material. The access log shows which method was used to transmit the stream.

Scalable multicasts may be identified in the access log by their mount point in the GET statement.

Because the communication between the RealServer and client during scalable multicast is the client's initial request for the multicast, the only statistics RealServer can track are the number of initial requests for the presentation. Information about the client is not available to RealServer. Statistics normally shown by Stats Mask will not appear for scalable multicasts. (See "StatsMask Results" for more information.)

Setting Up Multicasting

To take advantage of multicasting, both RealServer and clients, as well as the routers between them, must be multicast-enabled. For details, consult your network administrator. This section describes only what is required to enable RealServer for multicast broadcasting.

In addition to setting up RealServer, verify with your network administrator that the routers in your network are multicast-enabled and that the system running RealServer is correctly configured for multicast support. Also, ensure that clients are configured to request multicast transmission of live material.

Each type of multicast requires an address range. Values can range from 224.0.0.0 (the lowest usable address) to 239.255.255.255. The network administrator should know which multicast addresses are available on the intranet. On the Internet, certain ranges are reserved for other uses; see RFC 1700, "Assigned Numbers" for a complete list of restricted addresses.

Additional Information
Information on modifying RealServer features is found in "Customizing RealServer".

Back-Channel Multicasting

Follow the instructions below to set up back-channel multicasting.

To set up back-channel multicasting:

  1. In RealSystem Administrator, click Multicasting. Click Back-Channel.

  2. In the PNA Port box, type the port number to which RealServer will direct its PNA multicast streams. The value in this box refers to the client's port number. A typical value is 7070.

  3. In the RTSP Port box, type the port number to which RealServer will direct its RTSP multicast streams. The value in this box refers to the client's port number. A typical value is 554.

  4. Specify the range of addresses to which you want to multicast streams by filling in the Address Range box. RealServer uses the first available address in this range. If you are using other types of multicast, be sure that the address ranges are different and do not overlap. If your multicast streams are referenced in SMIL files, you will need one address for each stream.

  5. In the IP Address section, click Add.

  6. In the new window that appears, type a description for this list in the Rule Number box.

  7. In the IP Address box, type an address to the domain address of the client computer or network for whom RealServer will permit multicast transmissions.

  8. In the Netmask box, type a netmask that limits the range to a particular subnet.

  9. Click Add.

  10. To require that clients whose addresses you just listed use multicast only, and not unicast, select Yes from the Delivery Only list. To remove this restriction and permit unicast, set it to No.

  11. To allow clients to request that missing UDP packets be resent, select True from the Resend list.

  12. Indicate how far multicast packets can travel over a network by typing a value in the Time to Live box. Each time a multicast data packet passes through a multicast-enabled router, its Time to Live is decreased by 1. When the value is decremented to 0, the router discards the data packet.

    The value for Time to Live can range from 0 to 255. The larger the Time to Live, the greater the distance a data packet will travel.

    The default value of 16 is enough to keep multicast packets within a typical internal network.

    Time to Live Values
    TTL Value Packet Range
    0 Local host
    1 Local network (subnet)
    32 Site
    64 Region
    128 Continent
    255 World

  13. Click Apply.

Linking to Back-Channel Multicasts from a Web Page

Links to both RTSP and PNA multicast are identical to links for live unicast transmissions.

A single link can serve clients that are multicast-enabled and those that can only receive unicast transmissions.

Most clients on a multicast-enabled network are usually configured to request material via multicast first.

Links to back-channel multicasts are the same as for links to individual files. Because multicasts are done with live streams, use the live mount point in the URL. See "Linking a Web Page to a SMIL File or Individual Clip" for instructions on creating links to individual files.

Scalable Multicasting

After you set up scalable multicasting, be sure to set up special URLs for links to scalable multicast presentations.

To set up scalable multicasting:

  1. In RealSystem Administrator, click Multicasting. Click Scalable.

Set up the general scalable multicasting information. In the first section on this page, do the following:

  1. Type the IP address of this RealServer host computer in the Host Address box.

  2. Give the mount point that will be included in the links to all scalable multicasts. The default value mount point is /scalable/.

The following instructions describe how to configure certain live sources to be multicast.

  1. In the Live Sources section, click Add.

  2. In the new browser window that appears, type a descriptive name for this multicast session in the Name box.

  3. Turn on scalable multicasting for this virtual path by selecting True from the Enabled list.

  4. Type the name of the virtual directory in the Virtual Path box. The virtual directory is the path typed in the production tool that's encoding the live file. The information you enter here, in addition to the scalable mount point, will be included in the link for scalable multicast.

    To make all live broadcasts available via scalable multicast, type an asterisk (*) here.

  5. Clients listen to a specific range of ports. Indicate this range, to which RealServer will direct its multicasts, by typing port numbers in the Port Range boxes. Any valid port numbers are acceptable, in the format port1-port2.The first port number must be an even number, and must be followed by the consecutive port number. (RTP is used to send the data; the RTP standard requires this format.)

  6. Specify the range of addresses to which RealServer can send a multicast stream by typing in the AddressRange box. RealServer uses the first available address in this range. When typing in this box, use the form address1-address2. To use a single address instead of a range, type the address in the form address1-address1.

    Valid ranges are between 224.0.0.0 and 239.255.255.255. However, the addresses between 224.0.0.0 and 224.0.0.255 are reserved; in addition, RFC 1700 ("Assigned Numbers") lists additional numbers which are restricted.

  7. Indicate how far multicast packets can travel on your network in the Time to Live box. Use the values in the "Time to Live Values" table for TTL.

  8. Click Add. Click Apply.

Linking to Scalable Multicasts from a Web Page, Ram File, or SMIL File

Scalable multicasts use a different URL format than other material; when RealServer receives a request in this format, it sends the material differently and does not expect to establish or maintain a TCP connection.

All links to scalable multicast content use the same format. Note that they always begin with http://and always ends with the .sdp extension:


http://realserver.company.com:HTTPPort/MountPoint/virtual_path/filename.xxx.sdp

RealServer URL Components
Component Meaning
http The protocol used for streaming. Always use http in Web pages.
realserver.company.com Machine and domain name of RealServer
HTTPPort Port number where RealServer listens for requests sent via HTTP. This value is usually 80 or 8080; see "Port Variables".
MountPoint Scalable mountpoint, usually scalable.
virtual_path The virtual path is any actual directory, relevant to the base path of the mount point. If the file is located in the base path itself, omit virtual_path.
filename The file name itself.
xxx The file type, such as ra, rm, or rt.
sdp The final letters are required for scalable multicast. These are not part of the actual live file name; they only appear in the link.
.

Using the example in the example for RTSP and PNA multicast, a link would look like the following:


<a HREF="http://realserver.company.com:8080/scalable/vivaldi.ra.sdp">
Click here to listen to today's Vivaldi selection</a>

Combining Splitting and Multicasting

To reach large audiences across a network that includes both Internet and intranet connections, use splitters to send data across the Internet to intranet sites, and then use multicast delivery within each target intranet. This can be a powerful method of distributing a live stream while still conserving bandwidth.


Copyright © 1998 RealNetworks
This file last updated on 11/13/98 at 13:48:45.
previous next