When planning to serve richer media—such as streaming audio or video files—on your Web pages, you need to be sure your servers and network are ready to handle the additional overhead. You must consider such things as bandwidth usage, security, and server location. You also need to decide which service you will use to stream the audio and video files across your network. In Windows 2000, you can quickly set up Windows Media Services to handle that task. I’ll show you how to configure your network and server to support Windows Media Services.
Why use Windows Media Services?
Windows Media Services is a feature of Windows 2000 that can stream video or audio files across your network to end users. Beyond the obvious entertainment value, streaming media can be useful for such things as:
- Video conferencing
Windows Media Services streams files in the Advanced Streaming Format (ASF). ASF files have a higher compression ratio than standard MPG files and are a better choice for streaming video than MPG. However, the ASF file format is proprietary to Microsoft, so your users will only be able use ASF streams with the Windows Media Player.
When people think of streaming media, they often think of RealPlayer. RealNetworks helped begin the streaming media revolution with the introduction of RealPlayer and the RealMedia (RM) format. RealPlayer runs on more operating systems than Windows Media Player, so it’s a popular choice for organizations with mixed platforms. Because the RM format is proprietary to RealNetworks, you won’t be able to use Windows Media Services to stream RM files to workstations running RealPlayer.
While RealPlayer does provide RealSystem Server Basic for free, the price of the RealPlayer server products start at $1,995 for RealSystem Server Plus. However, RealSystem Server Basic is limited to 25 concurrent connections; Windows Media Services doesn't have a limit. If you’re using Windows 2000, you don’t have to worry about downloading and then installing RealSystem on your server. You can use Windows Media Services.
Should I multicast or unicast?
You can configure your servers to stream media two ways: multicast or unicast. Most streaming traffic is unicast, where the server sends a copy of the data to each client. If you have 10 clients requesting the stream, the server sends 10 full copies. In a multicasting scenario, multiple client requests are all handled by the same stream.
Because there’s only one copy of the data going across the network, multicast is more efficient than unicast. Hundreds of clients can access the stream without impacting the network. The main problem with multicast streams is that users have less control over the streams. They can’t pause or rewind them, and when they stop the media player, the stream will restart at the current point in the stream, not at the point where it was stopped. Also, you must schedule multicast streams to run at certain times. Unicast streams are available on demand. If you want to stream data outside of your network, you’ll need to unicast them, because multicast streams aren’t currently supported over the Internet. The multicast Internet backbone, Mbone, is in development but hasn't been implemented.
Take a look at your organization's needs before you decide which type of stream you’ll use, because the type of stream ultimately dictates how you’ll configure your network.
Configuring your network to support streaming media
Once you’ve decided which streaming mode you’ll be using, you can configure your network. Because Windows Media Services only works with TCP/IP, you'll need to completely migrate to TCP/IP on your network. If you still have parts of your network exclusively running NetBEUI or IPX, you’ll need to add TCP/IP to those segments.
If you're going to multicast your streams, you should make sure your routers can handle multicast streams. Some older routers can't support them, so if you’re going to multicast across your WAN, you’ll need to upgrade or replace them.
Take a look at your network hubs and switches. If you’re still running 10-Mbps Ethernet, it may be time to think about replacing your hubs and switches, because streaming media can quickly fill 10 Mbps. At a minimum, you should deploy Fast Ethernet (100 Mbps) and use switches to increase overall efficiency between your servers and workstations.
When you implement streaming media, you must also consider the following:
- Network capacity
- Media server location
- Server load balancing
Before you configure your network, you need to get an idea of how streaming media will affect your network. This will depend on the number of available streams users can access and the likelihood of users to actually use the streaming media, so it’s difficult to estimate. After users get accustomed to the technology, they may find new uses for it, which could throw off your estimates.
However, you shouldn’t just make a wild guess. Microsoft provides a simple formula you can use to judge how much bandwidth a particular stream will consume:
Bandwidth = Number of users * Encoding rate
For example, if you have 50 users all accessing a 50-Kbps stream, you wind up with a total consumption of 2.5 Mbps, so the formula for that would look like this:
50*50 Kbps = 2500 Kbps or 2.5 Mbps
Windows Media Services includes the Windows Media Encoder to build data streams. When you encode files using the Windows Media Encoder, you can set the target stream rate. The Windows Media Encoder includes templates to help you pick the proper stream rate. In my example, 50 Kbps is the rate the Windows Media Encoder sets if you choose the stream rate for a 56-Kbps dial-up modem.
When you copy files from your server to your workstation, the actual network utilization can go through peaks and valleys of activity as the data goes across the network. However, streaming media affects a network differently than simply copying files. It raises the overall network utilization by a flat amount, which doesn’t drop until the stream ends. So you may want to use a network analyzer to get a view of the current bandwidth consumption on your network before adding streams to it.
If you’re concerned that streaming media is going to flood your network, you can throttle back the amount of data that a streaming server will put out. Windows Media Services includes a Maximum File Bit Rate parameter, which limits the total amount of bandwidth at which any single file can be streamed. I’ll cover this and other fine-tuning issues in upcoming Daily Drill Downs.
Media server location
Think about your general network layout and where to locate the streaming servers on your network. If you only have a simple LAN, there’s not much to worry about. Just connect your streaming server using a Fast Ethernet switch, and you’re done.
Streaming media in a multisite environment is more complicated. In a multisite environment you can take advantage of Windows Media Services’ multiple bit-rate encoding feature. With it, you can encode streams with a higher bit rate for local users and then a lower bit rate for remote users, whether the remote user is coming in over a WAN or via dial up. The only difference between the higher and lower bit-rate encodings is the quality of the streams the users receive, with higher rates resulting in better-quality images.
Another option in multisite environment is to simply locate the streaming server on one site and force users to pull information across the WAN. From a cost perspective, this may be a good choice if you’re not using streaming media much or if you're in a multicasting scenario. However, unicast streams can quickly flood your WAN and slow your entire network down. The speed of the WAN will also limit the number of users that can access the streams.
Therefore, you may want to have servers configured at remote sites to handle unicast streams. You’ll locate a streaming server at each remote site and then use replication to send the data from streaming server to streaming server. This ensures that the data only travels once across the WAN. After you’ve placed the streams at the remote sites, you’ll use redirection to send clients to the media server closest to them.
You can handle the redirection by configuring your network’s DNS servers at the remote sites to resolve to the local media servers. You can also handle redirection through the use of ASX files, which are scripting files that can be quite complicated but powerful. They work by using CGI or ASP page checks to check the user’s TCP/IP address when the user requests a data stream. Based on the IP address checked, the ASX file redirects the user to the media server you specify.
Network load balancing
If you’re going to be streaming files to a lot of users, you may need to implement load balancing on your servers. The exact number of users a particular server can handle will vary, but you should have some strategy to keep the individual servers from becoming overwhelmed. If you implement load balancing, your Windows servers will work together to see which server has the greatest capacity to handle the additional requests. For more information about load balancing, see the Daily Drill Down “Understanding Windows 2000 network load balancing.”
Securing the network
Only certain people should view some streaming files. For example, if you’ve created a video file that contains the record of a recent management board meeting, you may not want it to be accessible to everyone in the company but rather to only the senior management team.
To ensure such security, you can base access to streams based on a user’s TCP/IP address. You can also force users to validate against your network before they can access a particular stream. If you do this, you can then set permissions for each streaming file based on user or group object just like you do any other file on your network.
Another point of security to consider is your network’s firewall ports. If you’ve implemented a firewall, you'll need to close Windows Media Services’ ports to prevent access from outside your network. Conversely, you’ll need to open these ports if you want remote users to access the streams from over the network. The Windows Media Services ports you need to configure on your router will depend on the types of streaming you’ll be doing. Some of the most important ports include the following:
You probably recognize port 80 as being the standard port for Web services. You’ll use this if you’re going to be streaming media using HTTP. If you don’t want to open ports 7007 and 1755, you can just use port 80. You’ll just need to reconfigure Windows Media Services to use HTTP as its transport protocol rather than its default protocol of MMS. You’ll probably recognize port 135 as being a popular target for hackers. Windows Media Services uses port 135 to establish server-to-client and server-to-encoder communications. Unfortunately, you can’t turn off this port if you want to use Windows Media Services, so you should be sure to log and monitor its usage.
Configuring your server
After you’ve made sure your network is ready, you can focus on the server. You may be tempted to spend a ton of money on the newest, fastest, largest server you can get and stream media from there. But that’s not the best idea. Microsoft recommends that to get the best performance, you deploy greater quantities of slower servers rather than one extremely fast server. The main reason is that the bottleneck in streaming media occurs in bandwidth, not in CPU capacity. Many slow servers can send out data faster than one extremely fast one. Adding additional servers also allows you to create fault tolerance in your network.
Streaming media affects almost every component in your server. To get the best performance, consider key components such as memory, disk drives, network cards, and CPU speed. To effectively use Windows Media Services, Microsoft makes the following recommendations:
- CPU—A Pentium II 266-MHz minimum with a Pentium III or IV is recommended. Your server should have no more than two CPUs. Additional CPUs won’t improve system performance enough to justify the additional cost.
- RAM—256 MB is recommended with 512 MB considered to be the optimal amount. The more RAM you place in your server, the more clients you can simultaneously serve. However, adding RAM beyond 512 MB won’t help Windows Media Services because Windows Media Services doesn’t use the RAM to cache file system data. It may help your server in general, but it won’t specifically help Windows Media Services.
- Network card—A single 10/100 Ethernet card with at least two 10/100 cards is recommended. If you install dual network cards in your server, you can dedicate one card to outgoing data streams while using the second card for administration, replication with other streaming servers, and creating media files. This will ensure that the outgoing data streams don’t have to compete with other data going in and out of the media server.
- Disk drives—21 MB is recommended for Windows Media Services plus space for data storage. For best performance, you should use SCSI RAID drives. Microsoft suggests you use RAID configurations that include three drives configured for data striping rather than mirroring. It also recommends that the disk controller unit include dedicated caching memory on the controller rather than relying solely on system RAM for caching.
One of the biggest challenges you’ll face in configuring your server is ensuring that you have sufficient disk space for the data you plan to stream. Media files, even those stored in a tightly compressed file format such as ASF, can take up a lot of disk space.
Similar to the formula used to estimate network overhead associated with streaming media, Microsoft provides the following formula you can use to determine data size:
ASF file size =(Encoded Rate * Number of seconds of data)/8192
So if you have a video file approximately 15 minutes in length and plan to encode it for a 56-Kbps dial-up modem (50 Kbps), you’ll wind up with a file size of approximately 5.5 MB. The formula would look like this:
When you encode a data file to support multiple bit rates, the formula changes somewhat. In this case, you must add up all of the bit rates before plugging them in to the formula. In multiple bit-rate files, you must also add an additional value of two-thirds of the lowest bit rate that Microsoft adds as a buffer. So a data file encoded to run for 30 minutes at multiple bit rates of 100 Kbps, 50 Kbps, and 22 Kbps will generate a file size of approximately 39 MB:
The formula may sound complicated, but using it will help you ensure you have enough disk space on your media server for the files you need to stream. Make sure you leave enough room for current needs and future growth.
Enabling Windows Media Services
Once you’ve prepared your network and your server, you’re ready to enable Windows Media Services. Installing Windows Media Services on a Windows 2000 Server is as easy as clicking Start | Settings | Control Panel | Add/Remove Programs. When the Add/Remove Programs window appears, click Add/Remove Windows Components. Next, you’ll see the Windows Components Wizard. Select Windows Media Services from the Components window and click Next.
The wizard will reconfigure your network components and add Windows Media Services to your server. Once the installation is complete, you’ll notice three new programs available on your Start Menu:
- Windows Media | Windows Media Encoder—This is used to create a media stream from an input source. I will discuss this utility in the next two articles.
- Administrative Tools | Windows Media—This is the general configuration utility for Windows Media Services.
- Administrative Tools | Windows Media Performance—This loads a set of performance monitor variables that monitor the performance of the Windows Media Services software and related services.
Windows Media Services gives you the ability to stream video and audio across your network from your Windows 2000 server without having to purchase additional software. Before you install and use the service, make sure your server and network are capable of handling the additional streaming media load. Look for more articles on Windows Media Services in the coming weeks.