Test 3: Multicasting | Microsoft Windows Media Resource Kit (Pro-Resource Kit)

Test #3: Multicasting

The whole point of setting up a multicast broadcast was merely educational. There is no real need to run a load simulation because multicast client connections do not place a load on the server. For example, no clients, one client, or 4,000 clients all have the same impact on server load and bandwidth usage. For this reason, Windows Media Load Simulator is not designed to stream a multicast broadcast.

To test multicasting, the Fabrikam technicians will receive the broadcast with a Player on the client computer, and another Player on the encoding computer. After they see how multicast streaming works, they can run Windows Media Load Simulator to see how the server handles a mix of multicast and unicast on-demand streaming, which will provide a more realistic picture of the servers in production.

When a client connects to a unicast stream, the server sends header information before it starts sending the content. The header is a small package of information that tells Windows Media Player about the stream, such as what codecs will be needed to decompress the stream, how large the video frame will be, how data packets are laid out, and so forth. The Player uses this information to prepare for the data that follows. For example, the Player downloads and installs codecs if necessary, and then loads them into memory. Without header information, a stream cannot be played because the data cannot be interpreted.

With a multicast stream, the Player does not connect to the server to receive the stream, so it must get header information from another source. That source is the multicast information file. To connect to a multicast stream, the Player first opens the announcement file, which is typically hosted on a Web server with a URL such as http://WebServer/Multicast.asx. Then, rather than connect to a file or publishing point, the Player connects to the multicast information file by using the address contained in the announcement file. For example, the following announcement file points to the information file Multicast.nsc.

<asx version = "3.0">     <entry>         <ref href = "http://WebServer/Multicast.nsc"/>     </entry> </asx>

The Player then opens the multicast information file to retrieve the header information and the IP address and port of the multicast. The Player makes a request for the stream over the network, which is received by routers and other network devices. If the stream is available, the multicast traffic is routed to the Player. Unlike an announcement file, the multicast information file contains binary information that can be read by the Player, but cannot be read or edited using a text editor. The only way to make a multicast information file is by using the wizard on the server.

For Fabrikam’s test, they will host the announcement and multicast information files on the LAN01 Web server.

Enabling Multicast Logging

Only one server, LAN01, will be set up for delivering the multicast stream. All three servers in the Fabrikam cluster will continue to host unicast streams. Before setting up our test scenario, the Fabrikam technicians will set up LAN01 for logging multicast clients. They will enable multicast logging on the publishing point and check the log after completing the test, but they won’t necessarily use the test log results for anything.

Client logging for unicast streaming is fairly straightforward because the server maintains a connection with every client. Detailed information about clients, such as how long a client plays a stream and the name of the content, is readily available. Logging multicast clients, on the other hand, requires a more complex system because the server makes no connections with clients. In order to log client activity for a multicast, the client sends usage data to a multicast logging URL. The URL points to a logging file on a Web server. Fabrikam will use the logging file wmsiislog.dll, which they installed with Windows Media Services. The Windows Media Services SDK can be used by developers to create custom logging files that may handle the logging data differently.

Here is how the logging system works for multicast: The Player opens a multicast information file (.nsc), which contains configuration information, including the logging URL. When the Player stops receiving the multicast stream, such as when the end user clicks Stop, the Player sends a string of client data to the logging file specified in the URL. The data contains usage data for the entire session, such as the player IP address, the start time, and playback duration. This information is then added to a multicast log on the server. To minimize data on the network, the Player only sends logging data when it stops receiving the multicast.

To set up the server to receive multicast usage information from clients, make sure IIS is running and then do the following:

Locate the folder containing the logging file, wmsiislog.dll, which is installed by default in the %systemdrive%\Wmpub\Wmsiislog folder.
Right-click the folder, and then click Sharing and Security.
On the Web Sharing tab, share the folder on the default Web site, and enter an alias, such as “WmLog.” Then assign executable permissions to the directory.

This creates a virtual directory. The URL of the directory is now the logging URL, which can be used by any broadcast publishing point that uses multicast streaming and requires client logging.

Other necessary settings were added to IIS and the system registry when the Multicast and Logging Agent was installed. If you find that logging is not working when you run a multicasting test, try reinstalling the agent.

After the server goes into production on the corporate network, the logging file can be moved from the Windows Media server to a Web server. Logging does require some CPU time and memory to perform, and this is one task that can be offloaded to another computer.

Encoding a Live Stream

This test uses the same setup as described in test #2. Make sure the capture devices are configured and video is being received. You can use the same encoder configuration, but select only one bit rate to encode. A stream that contains multiple bit rates cannot be delivered using multicast because MBR streams require a direct connection between the client and the server.

In practice, when a multicast broadcast is produced by the Fabrikam Media department, they will use two or three encoding computers, or two or three instances of the encoder on one computer, each set up for a different bit rate. The encoders will then feed two or three multicast publishing points, and end users can choose the bit rate that is appropriate.

After the encoder is configured, start encoding.

Configuring the Server

The Fabrikam technicians test the encoded stream, and then configure a broadcast publishing point for multicast delivery.

On the server (LAN01), open the Player and connect directly to the encoder to make sure the server is receiving the stream. You can skip this step if nothing has changed from the previous test.
On the encoding computer, open the Windows Media Services MMC snap-in with the cluster group, and start the Add Publishing Point Wizard on LAN01. Then enter the following information:
- For Publishing Point Name, enter LiveMulticast.
- For Content Type, select Encoder (a live stream).
- For Publishing Point Type, select Broadcast publishing point.
- For Delivery Options, select Multicast.
- For Encoder URL, enter the same URL that was used in test #2 (for example, http://encoder:9090).
- After the wizard finishes, choose to create an .nsc file. The Multicast Announcement Wizard starts.
In the Multicast Announcement Wizard, enter the following information:
- For Files to create, select Multicast information file (.nsc) and announcement file (.asx).
- For Retrieve stream format information, choose for the server to automatically retrieve stream formats from the encoder.
On the next wizard screen, the wizard will attempt to connect to the encoder and download the header information from the live stream. Make sure the encoder is configured and streaming before going to the next page of the wizard.
Enable client logging for the publishing point, and then enter the URL of the logging file (such as http://LAN01/WmLog/wmsiislog.dll).
Save the multicast information file and the announcement file on the default Web site. For example, you could create ASX and NSC folders within the Home folder. In production, the metafiles will be hosted on the intranet Web servers.
Specify the URL of the multicast information file. If the Fabrikam technicians placed the multicast information file in a folder called NSC, the URL would be http://LAN01/NSC/LiveMulticast.nsc.
Enter any necessary metadata, then finish the wizard.

The wizard creates the files, retrieves stream format information from the encoder, and automatically configures and enables the multicast plug-in with default values. Before testing the stream, let’s look at how the plug-in was configured.

To see the configuration information, click the Properties tab for the new publishing point, then click the Multicast streaming category. The wizard has already enabled the WMS Multicast Data Writer plug-in. Now, open the properties page for the plug-in.

An IP address and port number have been assigned to the publishing point automatically. You can use these settings. After setting up a broadcast system, you may want to explicitly assign a multicast IP address. The standard class D IP addresses range from 224.0.0.0 to 239.255.255.255. Addresses 239.0.0.0 to 239.255.255.255 are defined as administrative addresses and are used for private networks.

If you select the Enable unicast rollover check box, a client can connect to the publishing point by using unicast streaming if it cannot locate the multicast stream. This is useful if a stream must be available to all clients on a network, but devices like routers and firewalls are configured to stop multicast packets. If you do not select the Enable unicast rollover check box, it will force clients to connect to the multicast stream only.

The properties dialog for the plug-in also enables you to enter a Time-to-live (TTL) value. This setting affects how routers handle multicast traffic. For more information, see the Understanding Time-to-live sidebar.

If you change any settings in the multicast plug-in, you must create a new multicast information file.

Now start the publishing point. If all information was entered correctly and the publishing point is receiving the stream specified as the source on the Source tab and in the multicast information file, the publishing point will start streaming.

Playing the Live Stream

To test the live stream, a Fabrikam technician opens the Player on a client computer, and then opens the URL of the announcement file (http://LAN01/ASX/LiveMulticast.asx). The Player will follow the path in the announcement file to the multicast information file, which it will use to locate and play the multicast stream.

On the server Monitor tab, the technicians will see that there are no connected unicast clients. You can connect as many clients to the stream as you like and no load will be added to the server. Except for the multicast client usage log, there is no way of knowing how many clients are connected to a multicast.

Now the technician opens the Player on the encoding computer and connects to the multicast, if the CPU can handle the extra load. At this point they have two Players connected to the stream, and no additional load on the server.

Next, the technician clicks the Monitor tab, and then clicks the Allow new unicast connections button. Then he stops the Player on the client computer and re-connects to the publishing point using unicast streaming, with a URL such as mms://LAN01/LiveMulticast. Even if a publishing point is configured for multicast, you can still connect using unicast streaming.

Understanding Time-to-live

Routers on a network play an important role in delivering multicast streams. When a unicast stream is requested by a client, one connection is established between the server and a client. With multicast, on the other hand, there is no connection between client and server. When a multicast publishing point is started, the network routers and switches handle client requests and direct the multicast packets. The server merely sends the stream. Without routers to control the stream, multicast packets would flood every part of the network.

You can control where the stream goes by configuring the devices and the multicast stream. Using TTL, you can restrict the scope of a multicast. For example, you can restrict the scope to a building or a plant, or, as in the case of Fabrikam, to headquarters. The TTL value determines how many router hops a multicast packet can pass through. Every time a packet passes through a router, the TTL value is decremented by one. When a packet has a TTL of 0, the router stops forwarding the packet. For example, with a value of 32, the packets will pass through 32 routers. When it hits the router 33, the packets go no further.

The routers themselves can also be configured or enabled to control the traffic. One way to control traffic is to configure the router to pass only multicast packets with certain IP addresses. This allows you to restrict multicasts to given network segments. We will cover configuring routers and switches for multicasting in chapter 22.

In the Fabrikam scenario, however, the IT department may want to allow multicasting only. If that is the case, they can click the Deny new unicast connections button on the Monitor tab. With multicasting enabled and new unicast connections denied, clients will only be able to connect through multicast. With new unicast connections denied, the technician can try connecting using the unicast URL, and then try connecting to the multicast.

You can check which protocol and method Windows Media Player is connected with by opening the Statistics dialog box in the Player, and then clicking the Advanced tab. If the Player is using multicast streaming, the Protocol box will show MMS (Multicast). It will display a protocol, such as RTSP (UDP), if it is streaming unicast. This Statistics dialog box is very useful for seeing how the Player is receiving a stream. If Protocol shows CACHE, for example, you know the Player has downloaded a file and is playing it from the local cache.

If you plan to offer both unicast and multicast, you can set up the multicast plug-in so that a client will automatically roll over to unicast stream if it is unable to connect to the multicast stream. Rollover is currently turned off in the Fabrikam scenario.

To disable multicast in the Player, a Fabrikam technician does the following:

On the publishing point, click the Allow new unicast connections button.
In the Option dialog box in the Player, click the Network tab, and clear the Multicast check box.
Open the announcement file in the Player (for example, http://WMServer01/ASX/LiveMulticast.asx). The Player will not be able to connect to the stream from the publishing point. This is similar to the experience of an end user who is behind a firewall or network device that does not pass multicast traffic.

Now the Fabrikam technician can enable unicast rollover:

Go back to the server and open up the properties for the Multicast Data Writer plug-in.
Enable unicast rollover and make sure Use this publishing point is selected.
Close the properties dialog box, stop the publishing point, create and save new announcement and multicast information files, and then restart the publishing point.
Attempt to connect with the Player. The Player will open the announcement file, then the multicast information file. Because it cannot stream multicast, the Player will roll over to a unicast stream.
Check the Statistics dialog box in the Player. It should indicate RTSP (UDP). The Monitor tab on the server will also indicate one unicast client connection.

The following table summarizes the basic procedures needed to configure unicast and multicast broadcasts, or both with rollover enabled or disabled.

Broadcast Type	Procedure
Unicast only	Make sure the Allow new unicast connections button is selected, and disable the Multicast Data Writer plug-in. Connect using a unicast URL, such as MMS://Server/PubPoint.
Multicast only	Make sure the Deny new unicast connections button is selected. Enable and configure the Multicast Data Writer plug-in. Create an announcement file and a multicast information file.
Both, without rollover	Make sure the Allow new unicast connections button is selected. Enable and configure the Multicast Data Writer plug-in. Create an announcement file and a multicast information file.
Both, with rollover	Make sure the Allow new unicast connections button is selected. Enable and configure the Multicast Data Writer plug-in. Enable unicast rollover. Create an announcement file and a multicast information file.

If you want, run Windows Media Load Simulator with a modest number of clients. Connect to a publishing point using unicast streaming with the RTSPU, RTSPT, MMSU, and MMST protocols. Then connect to the multicast stream with Windows Media Player. Windows Media Load Simulator is not designed to connect using multicast streaming, but you can test the effect on the server of providing unicast and multicast streams at the same time. You can also create broadcast unicast publishing points on the other servers in the cluster, and source each from the encoder. Then run Windows Media Load Simulator against the cluster.

You will see that adding a multicast broadcast has almost no negative effect. The multicast requires so few system resources it is hardly noticed. The multicast stream is more likely to be affected by a congested network before there is a problem from an overloaded server.

With unicast streaming, a client is guaranteed to receive all or most of the data packets intact. This is because there is a connection between the client and server, so the client can request that packets be resent by the server if they do not arrive or they arrive with data errors. With multicast, on the other hand, there is no client/server connection. If packets do not arrive intact, there will be a hole in the stream because the Player cannot request new packets. For this reason, multicast streaming always works best on reliable, uncongested networks.

Stop the multicast stream on Windows Media Player and locate the multicast client log on the server. After the Player stops, it sends usage information to the multicast logging file indicated by the logging URL it received from the multicast information file. If you have followed the steps in this section, there should be a multicast log file on the server, which will contain the usage information sent from the clients.

By default, the multicast logging files are created in the %systemroot%\system32 \LogFiles\WMS_ISAPI folder. A new file is generated every day and whenever a multicast publishing point is created or changed. If the log is empty, wait a few minutes and try again. There is a delay between the time when a client stops and the time when information gets logged. For more information about how to read the log, see Windows Media Services Help.