Building the eCDN Components

Now that you have an understanding of decentralized networks and eCDNs, we can see how Fabrikam builds the components for delivering content on the corporate network. The rest of this chapter covers the following implementation topics:

• Installing and running the cache/proxy plug-in. This also includes configuring and then testing the plug-in on the bench. The plug-in will enable content-management strategies such as pulling content and stream-splitting.

• Setting up unicast distribution. Walks through the process of creating a distribution publishing point that delivers a multicast stream.

• Creating a system for pushing content. Describes some ideas for creating a system that makes it easy to push content to many servers.

Using the Sample Cache/proxy Plug-in

The cache/proxy plug-in you use may have a different installation procedure and configuration, but the concepts will be similar. For testing cache/proxy functionality, you can use the sample provided with the Windows Media Services SDK. Keep in mind that the sample was designed as a starting point for developers to create complete cache/proxy solutions, and is not recommended for deployment in its current state.

To use the sample, first install the SDK from the link on the companion CD. After installing the SDK, you will need to use Microsoft Visual C# .NET or Visual Studio .NET to build the plug-in files from the sample C# project. The project file for the cache/proxy plug-in is installed by default in %systemdrive%\WMSDK\WMServices9\Samples\CacheProxy\Csharp\
CacheProxyPluginSample.sln. Follow the procedure in the SDK for building and registering the C# Cache Proxy Plug-in Sample on your computer.

To use the plug-in on another computer, copy all the files that were created in the %systemroot%\System32\Windows Media\Server folder, and use the command-line tool Regasm.exe to register the DLL files. The DLL files must be registered on the server for the plug-in to work.

After the plug-in has been registered, restart Windows Media Services. Open the Windows Media Services snap-in. To restart the service, click the server in the console tree, and then, on the Action menu, click Stop. After you see the server has stopped, click Start. When the service is restarted, it will add the cache/proxy plug-in.

To configure the cache/proxy plug-in, do the following:

1. With the Windows Media Services snap-in open, expand the server, and then expand Cache/Proxy Management.

   The Cache/Proxy Management node in the console tree, which had previously been empty, now contains additional items for monitoring and configuring the plug-in. The plug-in you use may have a different set of configurable parameters, and a different way of organizing them.

   The basic functions of a plug-in can be broken down into two areas: the functions it performs when end users access on-demand content, and the functions it performs when end users access a broadcast publishing point. In a typical plug-in, Cache/Proxy Management contains two items that correspond to these functions. The main on-demand function of a cache/proxy plug-in is the automatic caching of end user requests, as described previously. The main broadcast function is stream splitting.

   Figure 20.8 shows Cache/Proxy Management with the sample cache/proxy plug-in installed.

   
   Figure 20.8: Managing the sample cache/proxy plug-in.

2. Enable cache/proxy management. Click the server name in the console tree, and open Properties for the server. Click Cache/Proxy Management in the Category list, click the cache/proxy plug-in in the list, and then click the Enable button.

   Properties for the plug-in might contain global parameters that you can view and modify. In the sample plug-in, you can change how Windows Media Services loads the plug-in: in-process or out-of-process. Typically a cache/proxy plug-in runs in the same process as the server (in-process).

3. Allow new unicast connections. Click Cache/Proxy On-Demand and, on the Monitor tab, click Allow new unicast connections. Do the same for Cache/Proxy Broadcast. By default, your plug-in might be configured to deny new connections for security purposes.

To help you visualize how a cache/proxy plug-in works in Windows Media Services, you can think of the cache/proxy items in the console tree the same way you think of publishing points. A publishing point acts as an interface between the end user and the content, and has plug-ins and properties that enable you to modify how content is sourced and delivered. The Cache/Proxy Management items perform similar functions.

As you can see in figure 20.9, the tabs in the details pane of each node look similar to the tabs for publishing points. The difference is that a cache/proxy plug-in will have no tabs for Source, Advertising, and Announce because those details do not apply. However, you can apply plug-ins, properties, and limits to Cache/Proxy Management as you would to a publishing point. For example, you could apply logging, add authentication, and add authorization to cache/proxy requests. You can also monitor cache/proxy usage.

Figure 20.9: Usage information is displayed for the cache/proxy server.

With this in mind, you can see how Windows Media Services and a cache/proxy plug-in work together to provide a variety of services in one container. For example, the server represented in figure 20.9 acts as a cache/proxy server, and hosts on-demand content and broadcasts.

Enabling Cache/proxy Support on Origin Servers

Before a cache/proxy plug-in can cache content or split streams, those properties must be enabled on the publishing points of the origin servers.

For on-demand publishing points, caching options are set in the General category of the Properties tab. You can also set cache expiration in the Cache/Proxy category. This setting attaches an expiration time to files that are cached by a cache/proxy server. Before a cache/proxy server plays content from its cache, it checks the expiration value to determine whether the content is fresh. If the expiration time has passed, the cache/proxy server checks the content on the origin server. If the content has not changed, the cache/proxy server streams the file from its cache. Otherwise it streams fresh content from the origin server.

For broadcast publishing points, stream-splitting options are set in the General category of the Properties tab. In the Cache/Proxy category of the publishing point, you can also set an expiration policy.

Windows Media Services provides the ability to enable or disable cache/proxy support because many users, especially those on the Internet, do not want their content cached or broadcasts split. For example, a site offering copyrighted material can disable caching if the owners do not want the content to be stored by a cache/proxy server.

Testing Cache/proxy Functionality

To test the cache/proxy plug-in, the Fabrikam technicians will configure proxy settings in Windows Media Player. Once they have determined that the cache/proxy plug-in works as expected, a layer-4 switch can be added to the system. This switch will be configured to transparently send all client requests for Windows Media content to the cache/proxy plug-in.

To test the cache/proxy plug-in, the technicians connect the cache/proxy server to a network that provides access to another Windows Media server. This network also includes a client that can connect to the servers. They will perform the test on the bench in an isolated environment.

Once the test network has been built and configured, the technicians follow these steps to configure the Player:

1. On the client, open Windows Media Player.

2. On the Tools menu, click Options, and then the Network tab.

3. In the Streaming Settings area, click the MMS protocol, and then click Configure.

4. Select Use the following proxy server, and enter the address of the cache/proxy server and the port number for the protocol. Within a corporate intranet, the address is usually the name of the remote server, for example WMRemote01. The port for the MMS protocol is 1755.

5. Repeat step 4 for the RTSP protocol, using port 554. If the technicians have configured the origin and remote servers for HTTP streaming, they would repeat step 4 for that protocol.

6. Enter the URL of some on-demand content on the origin server, such as rtsp://WMOriginFarm/Test.wmv.

After entering the URL, the Player connects to the cache/proxy plug-in on the remote server (WMRemote01). If the content is not cached, the cache/proxy plug-in requests the content from the origin server. The technicians can see what is going on by viewing the default publishing point Monitor tab of the origin servers and the Cache/Proxy On-Demand Monitor tab of the remote server.

Assuming no other clients are accessing the servers, the first time users play the content, the Monitor tabs will show one client connection on each server: the end user connected to the Cache/Proxy On-Demand part of the plug-in on the remote server, and the remote server connected to the default publishing point on one of the origin servers. After users stop the stream, the cache/proxy plug-in continues streaming until the entire file is copied to the cache.

Figure 20.9 shows the on-demand Monitor tab on the cache/proxy server with one client connected receiving a 46 Kbps stream. Figure 20.10 shows the Monitor tab of the default publishing point on the origin server with the cache/proxy server connected receiving the stream.

Figure 20.10: Usage information displayed for the origin server.

The next time a technician attempts to access the content, the cache/proxy plug-in plays it from the cache. The technician should see only one client connection to the remote server, and no connections to the origin server farm. He can check the remote server to see the cached file.

The last step is to configure Windows Media Player on one or more additional computers, as in steps 4 and 5. Then, the technicians can enter the URL of a broadcast publishing point. For example, they could use the sample broadcast playlist that is installed with Windows Media server, rtsp://WMOriginServer01/Sample_Broadcast.

After a technician enters the URL, Windows Media Player connects to the cache/proxy plug-in on the remote server. The plug-in handles the request as a broadcast request. If the plug-in is not currently streaming the broadcast, it requests the stream from the origin server. In this scenario, all broadcasts use multicast streaming, so the origin server that is designated as the broadcast server (WMOriginServer01) is accessed directly rather than through the load-balancing cluster address. The technicians can see what is going on by viewing the Cache/Proxy Broadcast Monitor tab and the Sample_Broadcast publishing point Monitor tab. With one client connected, they should see one client on both Monitor tabs.

Now they can connect the additional Players that have been configured. The cache/proxy plug-in will split the stream to the clients. The Cache/Proxy Broadcast Monitor tab should reflect the total number of clients connected, but the origin server Monitor tab should still show one connection.

Adding a Layer 4 Switch

Details of configuring layer 4 switches are outside the scope of this book because every switch is different. The basic function of the switch is to intercept all traffic destined for the WANs of Fabrikam’s remote sites and send the traffic to a cache/proxy server. You have seen that a cache/proxy server is composed of a Windows Media server and cache/proxy plug-in, but cache/proxy servers and cache appliances come in many sizes and shapes. Most handle both streaming media and Web page requests.

Figure 20.11 shows how a layer 4 switch fits in to the remote site topology. Typically a layer 4 switch would operate in a transparent proxy scenario by reading the contents of URL requests, and then redirecting the client to the local cache. If you were to use a cache/proxy appliance that handled both streaming media and Web content, the switch would redirect all requests for these types of content.

Figure 20.11: Using a layer 4 switch in the network.

You can test configuration of the switch by configuring Windows Media Player to not use a proxy. Then enter the URL of an item or publishing point on the origin server. The request should be redirected to the remote server.