Visualizing the Fabrikam eCDN


Though many products and solutions can be used, the Fabrikam eCDN will be based on remote servers running Windows Media Services and a cache/proxy plug-in. The cache/proxy plug-ins can be created by using the Windows Media Services SDK. The plug-in works directly with the server, and can be administered from the Windows Media Services snap-in or Windows Media Services Administrator for the Web.

Because the cache/proxy plug-in works with an existing server, Fabrikam will have the flexibility of using the same Windows Media server to host on-demand content, live content, and playlists, to distribute streams from other servers, and to perform the functions of a cache/proxy server. For example, an edge server in Mexico City that is configured with a cache/proxy plug-in can proxy client requests, cache content, and host content produced locally. If it were not possible to receive a multicast stream from Toronto, the edge server could also be configured for unicast distribution or stream-splitting.

The Fabrikam cache/proxy plug-in is based on the sample provided with the Windows Media Services SDK. The SDK provides developers with the tools and information to build custom plug-ins or complete content management and distribution systems. You may choose a solution that uses the cache/proxy plug-in architecture or any other edge server solution, but the basic concepts still apply.

The Fabrikam eCDN will enable the company to manage on-demand and live content.

To manage on-demand content, the Fabrikam staff must know which files exist on all remote servers, and they must make sure the sites have the correct content. Technicians can find out which files exist on a remote server by either opening the remote server WMRoot folder in Windows Explorer, or by viewing the Source tab of the server’s default publishing point. They can see which files exist in remote caches by using the content management solution. If producers know that a file is likely to receive a high number of hits, they can prestuff the file on all remote sites. Alternatively, they can rely on the cache/proxy plug-in to cache files as they are requested.

To manage live streams, the goal is to make sure all sites can receive a broadcast. The plan is to have the majority of the network multicast-enabled, so most users will be able to connect to a broadcast with a multicast stream originating from Toronto. On areas of the network that cannot handle multicast traffic, Fabrikam will use unicast distribution or stream splitting. When a large number of concurrent hits are expected for some on-demand content, scheduled delivery can be used.

The following summarizes the strategies that Fabrikam will use to manage content:

  • Pull content. Content management is handled automatically with a cache/proxy plug-in.

  • Push content. Certain content is prestuffed on remote servers. Third-party tools are available to handle the automatic replication of files, system management, usage reporting, and other tasks. Fabrikam can also simply push on-demand files manually.

  • Broadcast multicast. The majority of sites receive broadcasts with a multicast connection. To make multicast delivery viable, Fabrikam first needs to make sure that most of their network devices can pass multicast traffic. Routers and switches must have multicasting enabled. Devices that cannot be enabled, such as simple hubs, may need to be replaced.

  • Unicast distribution. At remote sites and certain areas of the network that cannot receive multicast packets, unicast distribution is used. To distribute a stream, the remote server can connect directly to the origin server farm by using the RTSP protocol, which supports the resending of packets. RTSP supports both TCP and UDP protocols. If TCP is used, data reception is guaranteed. With UDP, the data is not guaranteed, but packets can be resent.

  • Stream-splitting. At remote sites and areas of the network where multicast packets cannot be received, stream-splitting is used. The cache/proxy plug-in that is installed for the remote servers at these sites will intercept requests from users, and then establish a connection with the origin server. The remote server delivers a unicast stream to the first client and any additional clients that request the content, but will not need to establish any additional streams with the origin server.

  • Scheduled delivery. Windows Media files that are expected to receive a large number of concurrent hits can be broadcast on a schedule. The broadcast can be looped, or scheduled to start at regular times. Scheduled delivery can be nearly as convenient for end users as on-demand delivery because you can broadcast the content continuously. For example, you can start a 30-minute program at 2:00 PM and set it to loop. An end user can then view the program from the beginning by tuning in at the hour or thirty minutes after the hour.




Microsoft Windows Media Resource Kit
Microsoft Windows Media Resource Kit (Pro-Resource Kit)
ISBN: 0735618070
EAN: 2147483647
Year: 2005
Pages: 258

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net