Macromedia Flash Media Server 2.0.5 Release Notes
Welcome to the Macromedia Flash Media Server 2.0.5 release! This document contains latebreaking product information and updates concerning this release. About Flash Media Server 2.0.5 System requirements What's New in Flash Media Server 2.0.5 Known Issues Documentation Updates Reporting a bug to the Flash Media Server team Notices, Terms, Conditions, and Attribution
About Flash Media Server 2.0.5 This update to Flash Media Server 2.0 provides a number of key bug fixes. Adobe recommends that you install this update if you are currently using Flash Media Server 2.x. You can also check out the many resources available for learning about Flash Media Server at the Flash Media Server Developer Center. Find inspiration with tips, articles, tutorials, and resources, or steer your project to success with forums, code examples, exchanges, and reference materials. System Requirements Flash Media Server 2.0.5 is supported on Microsoft Windows 2003 Server, Microsoft Windows 2000 Server, Linux Red Hat Enterprise 3.0, and Linux Red Hat Enterprise 4.0. For more information, please see the Flash Media Server 2 system requirements. What's New in this Release The following bugs have been fixed in this release: 1481331 A deadlock could occur when performing garbage collection of live streams. A deadlock could occur when generating thumbnails with live streams. A DOS attack caused by sending bad data to the server which resulted in huge memory allocations has been prevented. When garbage data sent to the server it could result in a buffer overrun. This has been prevented. The performance of disk caching on Edge servers has been improved. The server could get into an infinite loop when playing large (~900 MB) MP3 files. On Linux, the FMS Edge process could crash when making an RTMP connection to a secure port.
Known Issues The following issues were known to exist at the time of the release. These issues are in addition to any listed elsewhere.

1453454 1440015

1437150

1431369

Edge process memory can grow significantly when using RTMPT or RTMPS (tunneled), resulting in a crash. Status is set as NetStream.Clear.Success when Streams.clear() method is invoked on a pre-recorded.flv file that has read-only permissions. The <OutChunkSize> configuration does not result in the same performance gains for On2 live video as it does for Sorenson live video. In server-side ActionScript, NetConnection.onStatus always returns NetConnection.Connect.Success when attempting a remoting connection (i.e., an HTTP url instead of RTMP), even if the url is invalid. When xml.sendAndLoad() is used the xml.loaded stays false even when XML is downloaded successfully and the onLoad event handler is invoked. The workaround is to set this to true in the onLoad handler when you know it has been loaded. unloadApp admin API takes a long time to return when the specified application instance doesn't exist. When true is passed as the parameter for the FileObject.remove method it does not recursively remove all the files in the folder. Streams greater than 2 GB are not supported.
Documentation Updates In the Flash Media Server 2 Server Management ActionScript Language Reference manual, on page 37, the properties for the getLicenseInfo() data object have changed. The key, type, family, and edition properties are no longer available. A new license_files object containing information about license files has been added. In the Flash Media Server 2 Server Management ActionScript Language Reference manual, on page 42, the properties for the getNetStreamStats() data object have changed. A new client_type property has been added. Different types of clients include the following: normal clients (clients connected directly to the origin server through Flash player), group clients (edge servers connected to the origin), virtual clients (clients connected through an edge to the origin) and service clients (clients connected to the service application). In the Flash Media Server 2 Server-Side ActionScript Language Reference manual, on page 115116, one of the methods used to invoke setInterval() is no longer valid. The first method, setInterval(function, interval[, p1, , pN]) is correct and should be used. The second method, setInterval (object, methodName, interval[, p1, , pN]) is not valid. In the Flash Media Server 2 Server-Side ActionScript Language Reference manual, the usage description for Stream.setVirtualPath() on page 158 is incorrect. The statement should read: Stream.setVirtualPath(virtual Path, directory, virtualKey). Viewing documentation updates using LiveDocs In addition to accessing Flash Media Server documentation in the Flash Help panel, you can access the same documentation online in the LiveDocs format. One of the advantages of LiveDocs is the ability to see comments that clarify the documentation. Macromedia recommends reviewing LiveDocs to see if any errata or issues relating to the Flash Media Server features you are using have been reported. To find the equivalent page on the LiveDocs website, click the View Comments on LiveDocs link at the bottom of any help page in the Flash Help panel. Your web browser will launch, and take you to the specified LiveDocs page.

The Flash Media Server LiveDocs are available at: http://www.adobe.com/go/flashmediaserver_help_en Reporting a bug to the Flash Media Server Team Found a bug? Your first step should be to contact Macromedia Technical Support. They can help you resolve issues and they can also log bugs. If you are no longer eligible for support, please use the Software Feature Request and Bug Report form. In order for us to understand the issue being reported please include every detail possible, including the operating system details, CPU, memory, crash log (if applicable). We will get back to you when the issue you reported has been verified. Thank you for using Macromedia Flash Media Server, and for taking the time to send us your feedback Notices, Terms, Conditions, and Attribution Copyright 1993-2008 Adobe Systems Incorporated and its licensors. All Rights Reserved. Macromedia, the Macromedia logo and Flash are trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Other marks are the property of their respective owners. Protected by U.S. Patents. Patents pending in the U.S. and/or other countries. This computer program is protected by copyright law and international treaties. Unauthorized use, reproduction, or distribution of this program, or any portion of it, may result in severe civil and criminal penalties, and will be prosecuted to the maximum extent possible under the law. Notices, terms and conditions pertaining to third party software are located at http://www.adobe.com/go/thirdparty/ and incorporated by reference herein.

Features Flash Media Interactive Server 3 Flash Media Streaming Server 3 Flash Media Development Server 3
HD video support (H.264/AAC) Real-time encrypted streaming Robust logging SWF verification Live video streaming Recorded video streaming Network efficiencies Maximized hardware capacity Enhanced cache 2GB file support Built-in bandwidth detection IPv6 support Adobe Media Player support Flash Lite 3 mobile support Data keyframes Stream data access Simultaneous connections

Unlimited

Features
Flash Media Interactive Server 3
Flash Media Streaming Server 3
Flash Media Development Server 3

Bandwidth limitations

Processor limit Flash Media Server services (live and VOD) Process scopes and distributed cores

8-way SMP (cores)

4-way SMP (cores)

(Not customizable)
Archive (record) video on server Custom server-side applications (server-side ActionScript) Edge server configuration

C++ plug-in support

Server-side playlists (Internet TV)
Multipoint publish/redirect

Remote shared objects

AMF3 support
Server redirection Plug-in architecture used for authentication from external sources (i.e. LDAP)
Flash Media Server system requirements

Windows

Microsoft Windows Server 2003 with Service Pack 1 (all 32-bit editions) Microsoft Windows XP (Flash Media Development Server only)
Linux Red Hat 4 (32-bit only)

Hardware requirements

3.2GHz Intel Pentium 4 processor (dual Intel Xeon or faster recommended) 2GB of RAM (4GB RAM recommended) 1GB Ethernet card For the most up-to-date requirements, see www.adobe.com/go/learn_fms_sysreqs_en.
Flash Media Server upgrades Upgrading from Macromedia Flash Media Server 2 The guidelines for upgrading from Flash Media Server 2 vary depending on your current license and when it was purchased: If you own any version of Flash Media Server 2 including Professional, Origin, or Edge, you can purchase an upgrade to Flash Media Interactive Server 3. Education licenses are not upgradable. If you purchased Flash Media Server 2 between December 4 through January 25, 2007, you will be eligible for a free upgrade to Flash Media Interactive Server 3. You must contact Adobe by March 31, 2008 to receive your license. Owners of Flash Communication Server 1.x (Personal and Professional Editions) are not eligible for upgrade licenses for version 3.0. There are no upgrade licenses available for Flash Media Streaming Server 3.

Why streaming is better Progressive download is a simple method of video delivery with very little controlits basically a simple HTTP download call. Streaming is a method that allows the publisher to control every aspect of the video experience. The advantages of streaming video from Flash Media Server are numerous: Fast startStreaming video is the fastest way to start playing any video on the web. Advanced video controlFeatures such as bandwidth detection, quality-of-service monitoring, automatic thumbnail creation, server-side playlists, and more. Efficient use of network resourcesCustomers who pay for their video hosting or bandwidth by the number of bits that are transferred can reduce their costs by using streaming video, since only the bits that the client actually views are transferred. More secure, protected media deliveryBecause the media data is not saved to the clients cache when streamed, viewers cant retrieve the video or audio file from their temporary Internet files folder. There are also additional security features in Flash Media Server 3 that prevent stream ripping and other risks to your files security. For more details, see the Securing content with Flash Media Server 3 section. Minimal use of client resourcesResources such as memory and disk space are significantly reduced with streaming, because the clients do not need to download and store the entire file. Tracking, reporting, and logging capabilitiesBecause progressive download is a simple download of a file, you cant easily log specific relevant statistics such as how long the video was viewed, if the user navigated forward, backward, or paused the video, how many times the viewer played the video, if the viewer left the web page before the video completed playing, and so on. Streaming enables you to easily capture this important data. Full seek and navigationUsers can immediately seek to any point in the video and have it start playing immediately from that point. This makes streaming a great solution for longer playing videos or applications such as video blogging, classroom lectures, and conference sessions, where you may want to jump into the video at a specific point rather than requiring the viewer to watch it from the beginning. Deep interactivityThe precise control found in streaming enables developers to create extensive interaction in their video applications. For example, the ability to switch camera angles, have one video spawn another video, or the ability to seamlessly switch to alternate endings, are all enabled by streaming. Live videoStreaming provides the ability to deliver live video and audio from any connected webcam or DV camera, and even directly from some video cards, natively in Flash Player. Video capture and record (Flash Media Interactive Server only)In addition to live streaming, Flash Media Server also gives you the ability to record video either in conjunction with the live stream (for example, archiving an event) or on its own (for example, video messaging). Multiuser capabilities (Flash Media Interactive Server only)In addition to live one-to-many streaming, Flash Media Server also enables multiuser streaming of audio, video, and data for the creation of video communication applications. While streaming may be perceived as being more difficult than progressive download, theyre actually extremely similarthey both use the same components and the same ActionScript commands. Streaming just gives the developer more power to create rich, interactive video applications. The only potential downside to streaming is that it requires special server software. Just as a robust data application would require you to install an application server in addition to your web server, robust media delivery applications require a streaming server in addition to the web server.

Illustration of process scopes
Distributed cores New feature in Flash Media Interactive Server; requires Flash Player 6 or later. To further increase the capacity and reliability of your server, you can distribute connections across multiple processes for a specific scope. For example, if your scope was set to adaptor, you could have connections spread across any number of core processes for each virtual host. Like process scopes, the distributed core feature lets you increase the capacity of your server. Distributed cores will let you engage more RAM for caching and more threading for the process-intensive connection routine. They cannot be used when deploying a multiway hybrid or live solution because connections need to be on the same core process to share communication. Security features SWF verification New feature in Flash Media Streaming Server and Flash Media Interactive Server; requires Flash Player 9,0,115,0 or later. SWF verification is a new security feature in Flash Media Server 3 that allows you to directly control which SWF files can connect to your server. Without implementing this feature, any SWF with the proper connection Uniform Resource Identifier (URI) and application name could freely connect, potentially accessing your streams and using server resources. With SWF verification, you can configure the server to check that the SWF file attempting to access a certain application or application instance belongs to a group of preapproved SWF files. Enabling this feature is easy. You simply store a copy of the approved SWF in the application directory and turn on the feature in the Application.xml file. When a SWF file connects to the server, the server verifies that the file exactly matches the SWF file in your application directory, and then accepts the connection. To approve a SWF for any instance of a certain application, youd place it in the SWFs directory in that applications folder; to approve a SWF for a specific instance, youd place it in the SWFs directory inside that instance folder.
Note: If youre deploying an Adobe AIR application, copy the SWF file that you compiled into the Adobe AIR package, to the server to make it available for SWF verification.
Standardized server redirection handling New feature in Flash Media Interactive Server; requires Flash Player 6 or later. Flash Media Server 3 now supports stream redirection in RTMP, which behaves much like HTTP 302 redirection. This feature can be enabled by using an access adaptor server-side plug-in, or in server-side ActionScript. For example, while using an access adaptor running on an Edge server, you could use this redirect method to notify a client that a requested video does not exist in the expected location, and pass them a new URI for the stream. It could also be useful for other Flash Media Server load-balancing schemes, as well as content organization. There is a revised server-side and client-side API that allows you to manage server redirection data. Note that you will need to use the updated FLVPlayback component to be able to take advantage of this feature. For more information, refer to the Flash Media Server 3 documentation, Extending Flash Media Server. Server-side plug-in architecture New feature in Flash Media Interactive Server; requires Flash Player 6 or later. Adobe Flash Media Interactive Server 3 supports plug-ins written in C++ that you can customize to extend the servers functionality. There are three plug-in classifications: File, Authorization, and Access. Each of these plug-ins can be used as-is, or customized to your specific needs; sample or skeleton API examples are provided that can be extended to meet your functional requirements. There can be more than one version of each plug-in. For detailed information, see the Adobe Flash Media Server Plug-in API Reference. File plug-in The File plug-in allows developers to write custom asynchronous functionality allowing complete control over where and how Flash Media Server reads content from any file system or service. The file system could be local or remote; it can be over any protocol, such as HTTP or even FTP. Asynchronous read and write is a major new enhancement to Flash Media Server 3. Previous versions of Flash Media Server supported only synchronous access to a localized file system. Each request for a read operation on a file had to wait for the previous requests in the queue to be completed. The File plug-in builds on this new asynchronous access, making it easier to implement network-based and remote file I/O. For example, you could retrieve files from a remote location over HTTP and serve them to clients via Flash Media Server. If you are about to read a file from the disk to stream, you can now read that file from any mapped location, rather than only from the streams folder of your current Flash Media Server application. This feature is only applicable to VOD content. Authorization plug-in The Authorization plug-in allows you to tightly control client access to server NetConnection and NetStream events. You can use this plug-in to perform tasks such as: Authorize connections to the server Authorize publishing, playback, or seeking within a stream Map logical stream requests to physical stream requests Apply rights management policies to stream requests Disconnect clients from the server Deliver content to clients according to their geographic location, subscription level, time, and duration of a specific users access to specific streams, and so on

Each profile is further organized into three levels, as shown in the following table.
LT level 1 LT level 2 LT level 3 SD level 1 SD level 2 SD level 3 HD level 1 HD level 2 HD level 3
VP6 Mobile VP6 Mobile VP6 Mobile On2 VP6 and H.264 On2 VP6 and H.264 On2 VP6 and H.264 On2 VP6 and H.264 On2 VP6 and H.264 On2 VP6 and H.264
Target resolution/data rate
GSM 3G 3G-high 160x112 320x240 640x480 640x480 1,280x720 1,920x1,080
(Source: www.adobe.com/products/hdvideo/supported_technologies/h264.html)
Typical frame rates range from 5 fps to 30 fps. Higher frame rates and screen resolutions require more computing power to play back. Flash Player 9 supports hardware-accelerated full-screen video playback. H.264 video codec New feature in Flash Media Streaming Server and Flash Media Interactive Server; requires Flash Player 9,0,115,0 or later. The H.264 codec delivers excellent quality video, and is now supported by Flash Media Server 3. The video streaming-related subsets of the MPEG-4 part 10 standard supported by Flash technologies are: BaselineWidely used in videoconferencing and mobile applications running on devices with limited computing power. Main Profile (MP)The original profile intended for broadcast and storage applications, MP has been largely overshadowed by High Profile. High Profile (HiP)The primary profile for broadcast and disk storage applications. HiP is the profile adopted by both high-definition DVD formats: HD DVD and Blu-ray disc. High 10 Profile (Hi10P)A profile that increases decoded picture precision of HiP to 10 bits per sample. In addition to FLV, Flash Player 9 supports streaming or progressive playback of MPEG-4 container formats such as MP4, M4A, MOV, MP4V, 3GP, and 3G2 if they contain H.264 video and/or HE-AAC audio. For more information about H.264 implementation, visit www.adobe.com/products/hdvideo/ supported_technologies/h264.html. For full system requirements for rendering HD content in Flash player, visit www.adobe.com/ products/hdvideo/systemreqs.html. HE-AAC audio codec New feature in Flash Media Streaming Server and Flash Media Interactive Server; requires Flash Player 9,0,115,0 or later. Flash Media Server 3 now supports streaming of HE-AAC audio. The codec profiles defined by the ISO/IEC 14496-3 (MPEG-4 part 3) standard are supported: Advanced Audio Coding (AAC) MainAdds perceptual noise shaping to the MPEG-2 version of AAC, improving quality at lower bitrates. Can handle up to five channels plus one subwoofer channel (5.1) in a single audio object.
AAC Low Complexity (LC)Slightly less efficient than AAC Main and requires less CPU power to encode and decode. AAC LC is optimized for low-bitrate applications such as streaming. High Efficiency AAC v2 (also known as HE-AAC+, eAAC, and aacPlus v2)A superset of the AAC core codec that combines spectral band replication (SBR) and parametric stereo (PS) techniques to enhance coding , especially for low-bitrate stereo signals. HE-AAC v2 supports up to 48 audio channels and enables 5.1 and 7.1 surround sound. For more information about HE-AAC implementation, visit www.adobe.com/products/hdvideo/ supported_technologies/heaacv2.html. On2 VP6-S support New feature in Flash Media Streaming Server and Flash Media Interactive Server; requires Flash Player 9,0,115,0 or later. Flash Media Server 3 introduces streaming support for the new VP6-S codec profile available in Flash Player 9,0,115,0. VP6-S features greater simplicity in encoding/decoding of high-resolution, full-screen video, which allows high-definition video to be streamed and played back smoothly on mass-market computers with limited processor speeds. VP6-S is recommended for video delivered at or above 500Kbps at high resolutions when targeting these slower machines. For more information on this codec, visit www.on2.com. Smart buffering (player fix) New feature in Flash Media Streaming Server and Flash Media Interactive Server; requires Flash Player 9,0,115,0 or later. Flash Player 9,0,115,0 introduced an enhancement to the playback engine to sustain the buffer of a Flash Media Server stream when you pause playback of a recorded stream. This means that Flash Media Server will no longer flush the buffer when a video is paused. When resumed, playback will be immediate and not need to be rebuffered. This feature will allow you to prebuffer video and create seamless video switching among playlist items. Live video features Flash Media Server 3 introduces several powerful new features to enhance your live video publishing applications. Live instant-on Video streaming through Flash Media Server starts playing instantly when a page is loaded or the play button is selected. This is a distinct benefit over other streaming technologies, as well as progressive delivery, and is compatible with both live and on-demand streams. Multipoint publish New feature in Flash Media Interactive Server; only requires Flash Player 6 or later. A new feature multipoint publish gives flexibility and scalability to your streaming applications. Previously, if you were using a content delivery network (CDN) to deliver your streaming content, you were unable to implement any custom server-side code or inject any data messages into the outbound stream. Now, with multipoint publishing, you can use your own Flash Media Server (or Flash Media Encoder) to control the feed to the CDN, which then broadcasts it to your clients (as shown in the following figure). (The free development edition can actually be used in commercial applications as this local live publishing point.)

You can configure Flash Media Server to spawn FMSCore processes by configuring the scope node in the global Application.xml file. Valid scopes include adaptor, vhost, app, inst. The adaptor scope is a new feature in Flash Media Server 3. Depending on the scope you choose, you can configure each core process separately. For example, if you configure the system to scope adaptors to different core processes, each setting in the specific adaptor.xml file and all subsequent xml files would be used to configure that core process. In this configuration, you could set each core process to listen on a different port, or change the SSL or HTTP tunneling settings. In another example, if you set scope to app, each core process could be configured with bandwidth limitsprovided you had a separate application.xml file for each application running on your system. The following process configuration is the default. <Process> <Scope></Scope> <Distribute numprocs=1></Distribute> <LifeTime> <RollOver></RollOver> <MaxCores></MaxCores> </LifeTime> <MaxFailures>2</MaxFailures> <RecoveryTime>300</RecoveryTime> </Process> Lets look at how changing the scope setting affects your system. The following figures illustrate the effect of changing your scope configuration. All of these settings are optimal for stateful applications where clients need to communicate with each other (chat, live video, gaming, or data sharing solutions).
<scope></scope>
No process scope (default setting). All clients connect to a single scope.
<scope>adaptor</scope>
Process scope adaptor. Each adaptor has its own core process. Virtual hosts and applications running on different adaptors will not interfere.
<scope>vhost</scope>
Process scope vhost. Useful for applying unique settings for users in different subdomains.
<scope>app</scope>
Process scope app. Each application running can be run within its own process. This would be useful if you have lots of memory, and heavy connection requests from different applications.
<scope>inst</scope>

Process scope inst. Depends on your customer provision.
For a CDN customer (VOD profiles), selection of a scope depends upon how you provision your customer accounts. Consider that each customer is provisioned as an application within Flash Media Server. If there are a lot of customers, the app scope may not be the best option. Each process scope can use a maximum of 4GB of RAM, so too many processes may not be the best choice. Alternatively, if you have only a few large customers in your deployment, then the app scope may be your best choice. Distributed cores New feature in Flash Media Interactive Server; requires Flash Player 6 or later. To further increase the capacity and reliability of your server, you can distribute connections across multiple processes for a specific scope. For example, if your scope was set to adaptor, you could have connections spread across any number of core processes for each virtual host. In the following figure, there are four core processes for each virtual host. All connections on the single virtual host could be evenly distributed over three processes. If there were two virtual hosts, connections could be distributed across six core processes.
Distributed process scopes
There are three processes, each able to accept connections. Users connected to the same application may not be able to communicate or share RAM because they connected to a different process. Useful for stateless deployments.
Like process scopes, the distributed core feature lets you increase the capacity of your server. Distributed cores will let you engage more RAM for the cache and more threading for the process-intensive connection routine. Distributed cores are best used for VOD applications (commercial or social). They cannot be used when deploying a multiway hybrid or live solution because connections need to be on the same core process to share communication. Inside the Application.xml configuration file, the default settings disable distributed process scopes. <Process> <Scope></Scope> <Distribute numprocs=0></Distribute> <LifeTime> <RollOver></RollOver> <MaxCores></MaxCores>
</LifeTime> </Process> You can distribute connections to scopes in <Scope>. The following figure shows your options for process distributions. The left column shows the settings for <Scope> and the top row is the settings for <Distribute>. As you can see, if you set <Scope>vhost</Scope>, your options for <Distribute> are app, inst, and clients.

Distributed process scope options
The following example shows process distribution with a single virtual host. The figure shows how the configuration would be implemented over a 5-hour time frame given a 1-hour (3,600 second) rollover. <Process> <Scope>adaptor</Scope> <Distribute numprocs=1>vhost</Distribute> <LifeTime> <RollOver>3600</RollOver> <MaxCores>4</MaxCores>
</LifeTime> </Process>
The maximum connection time using the above configuration is 4 hours. After 4 hours the core process will be closed and all connections will be dropped. At this stage, the client SWF should initiate a reconnect routine that will reestablish the stream playback. Changing the number of processes (numprocs) configures the number of processes in which connections are distributed. Changing the numprocs setting to 2 given the same settings as before will reduce the maximum connection time from 4 hours to 2 hours. After the second hour, the MaxCores limit of 4 will be reached. To spawn two more processes, the first two processes will be killed and connections will be closed. <Process> <Scope>adaptor</Scope> <Distribute numprocs=2>vhost</Distribute> <LifeTime> <RollOver>3600</RollOver> <MaxCores>4</MaxCores> </LifeTime> </Process>
Example of distributed process configuration
The maximum lifetime for connections in this configuration is 2 hours because the MaxCore limit is set to 4 and the numProcs is set to 2. To calculate the maximum connection time for clients, use this formula: (MaxCore DIV NumProcs) x Rollover Example: (4 DIV 2) X 3600 = 7200 seconds (2 hours)
To calculate the total number of processes, use this formula: Number of Scopes X NumProcs X MaxCores
Example using <Distribute>adaptor</Distribute> with two adaptors: 2 X 2 X 4 = 16 Core processes To calculate the amount of RAM required to support the distributed processes, multiply the total processes by 4. Each core process can use up to 4GB of RAM; therefore the previous example with 16 cores could consume up to 64GB of RAM. Close idle connections New feature in Flash Media Streaming Server and Flash Media Interactive Server; requires Flash Player 6 or later. When clients leave an application, their connection is often left open. Flash Media Server 3 can now detect these idle connections and reclaim their resources for new and active clients. When a client has been idle longer than the maximum specified idle time, (the default is 10 minutes), the server will close the connection. To enable this feature, you must set AutoCloseIdleClients to true in the Server.xml file. Once it is enabled in the Server.xml file, you can disable it for individual virtual hosts or individual applications in the Vhost.xml and Application.xml files. Limit connection requests New feature in Flash Media Streaming Server and Flash Media Interactive Server; requires Flash Player 6 or later. In some cases, if many clients are attempting to connect to the server, the quality of service can be diminished for those clients who are already connected. By setting the MaxConnection Rate in the Server.xml file, you can limit the number of connection requests per second that are accepted.

Send aggregate messages New feature in Flash Media Streaming Server and Flash Media Interactive Server; requires Flash Player 9,0,115,0 or later. By default, applications break up aggregate messages into individual messages before delivering them to clients. By default, aggregate messages are enabled. Applications can be configured not to deliver aggregate messages by setting the AggregateMessages parameter to false in the Application.xml file. Sending aggregate messages reduces CPU usage and increases server capacity. However, it can introduce some latency, so it is not recommended for real-time one-to-one communication. It is recommended for on-demand and live broadcast applications where latency will have little effect. Configure content storage New feature in Flash Media Streaming Server and Flash Media Interactive Server; requires Flash Player 6 or later. Storage configuration is important to server performance. If your hard disk access is not fast enough to keep up with the bitrate of your content, your clients will receive buffer empty messages and the overall quality of service will suffer. The server can use local or network storage to serve media files. In the Application.xml file, you can change the default location where streams and shared objects are stored, and map virtual directories to physical directories on local or network storage to manage your content. This can be very convenient in team environments, when you may not always want content creators to have direct access to your Flash Media Server, or if you have a large library of media files that you dont want to copy to your Flash Media Server. Configuring security features Flash Media Server 3 has several security features that you can easily set in the configuration files. (For more information about securing your server and content, refer to the Security features section.) Verify SWF files New feature in Flash Media Streaming Server and Flash Media Interactive Server; requires Flash Player 9,0,115,0 or later. The server can be configured to verify client SWF files before allowing them to connect to an application. Verifying SWF files prevents someone from creating their own SWF files that attempt to stream your content, or using your server resources. The server compares the connecting SWF with existing SWF files on your Flash Media Server, and allows the connection if there is a match. In the Application.xml file, you can specify one or more folders on the server to hold these SWF verification files. This is done within the node, <SWFVerification>. You can also configure the versions to check the length of time the verification data is held in cache, and any exceptions (such as Flash Media Encoder). You can also configure how often the server should check for updated SWF verification files. Here is a sample from the Application.xml file. By default SWFVerification is turned off.

<SWFVerification enabled=true> <SWFFolder /> <MinGoodVersion /> <UserAgentExceptions> <Exception from= to= />
</UserAgentExceptions> <Cache> <TTL>1440</TTL> <UpdateInterval>5</UpdateInterval>

</Cache>

</SWFVerification> Allow domains to connect to a virtual host New feature in Flash Media Streaming Server and Flash Media Interactive Server; requires Flash Player 6 or later. You can specify a list of domains that are allowed to connect to a particular virtual host. By default, connections are allowed from all domains. Set the VHOST.ALLOW parameter in the fms.ini file to a comma-delimited list of host names, domain names, and full or partial IP addresses you wish to allow access to the virtual host. Limit access to Flash Media Administration Server New feature in Flash Media Streaming Server and Flash Media Interactive Server; requires Flash Player 6 or later. By default, a client can connect to Flash Media Administration Server from any domain or IP address, which can be a security risk. You can change this by editing the AdminServer parameter in the Server.xml file. Simply add a comma-delimited list of host names, domain names, and full or partial IP addresses you want to allow. The default value is all. Administration API via HTTP Feature available in Flash Media Streaming Server and Flash Media Interactive Server; requires Flash Player 6 or later. You can monitor Flash Media Server via simple HTTP commands. The Flash Media Administration API methods can be called over HTTP connections. In the fms.ini file, set the USERS.HTTPCOMMAND_ALLOW parameter to a comma-delimited list of APIs. You can also specify methods on a more granular user-based level, in the Users.xml file. Most users leverage this feature to write custom monitoring applications. You can monitor the capacity of the server including the number of connections, bandwidth used, number of streams in cache, and even restart the server. Encrypted RTMP (RTMPE) New feature in Flash Media Streaming Server and Flash Media Interactive Server; requires Flash Player 9,0,115,0 or later. By default, the encrypted RTMP (RTMPE) is enabled in the servers Adaptor.xml file, and offers 128-bit encryption. If you wish to disable RTMPE, simply change the ADAPTOR. RTMPE_ENABLED parameter to off. You should only turn off encrypted RTMP if you do not want it to be available to developers deploying applications on your server. (RTMPE does require more CPU power compared to standard RTMP). Otherwise, you should leave it enabled so it is available when you want to use it.
Secure Sockets Layer (SSL) Feature available in Flash Media Streaming Server and Flash Media Interactive Server; requires Flash Player 6 or later. Like RTMPE, SSL is a protocol that enables more secure communication. Unlike RTMPE, SSL requires a certificate signed by an intermediate Certificate Authority, and requires configuration to enable. SSL must first be configured in the Server.xml file; certificates can also be set up to secure independent adaptors or independent virtual hosts. For more details about security settings for Flash Media Server, refer to the Securing content with Flash Media Server 3 section. Configuring general settings There are a number of helpful settings, that dont necessarily directly affect security or performance, but can streamline and customize your application deployment. Allow application debugging connections Feature available in Flash Media Streaming Server and Flash Media Interactive Server; requires Flash Player 6 or later. The Flash Media Administration Console and the API can actually connect and listen to SharedObjects and Streams. This feature makes it easier to debug complex server-side applications. By default, the server does not allow debugging connections. However, the Flash Media Server Administration Console must make this special debugging connection to the server to play back streams and access shared object data. To allow debugging connections, edit the Application.xml file of the virtual host or application youd like to access. You will edit the node shown below to enable debug connections. After setting, you will need to restart both the Flash Media Server and Flash Media Server Administration service and reload the Administration Console. <Debug> <MaxPendingDebugConnections>50</MaxPendingDebugConnections> <AllowDebugDefault>true</AllowDebugDefault>

Locking down your content Regardless of the sensitivity or ownership of your content, youll want to implement some level of security when deploying to the web. Its best to begin by securing your server, then securing your content. Lets examine each of the security measures you can take in more detail. Restrict access from domains By default, a client can connect to Flash Media Server from any domain or IP address, which can be a security risk. You can create a whitelist of allowed domains (or a blacklist of banned domains) to ensure that only authorized clients can connect to your applications or services. You can add a comma-delimited list of domains and/or IP-address blocks in the Adaptor.xml or vHost.xml configuration files to add this level of security. This is usually the first step in locking down your server; it prevents malicious or unauthorized domains from freely accessing your applications and streams. User authentication There are several methods of user authentication available with Flash Media Server 3. We will discuss the server-side ActionScript method. Server-side ActionScript The next step to increase security would be to implement a user authentication scheme to validate the connecting client. For example, using variables passed in through the client NetConnection method, you could implement a simple username/password, an encrypted token (MD5 Hash), or a unique key: User credentials (login/password): NetConnection.connect(rtmp., username, password);
Encrypted token (MD5 Hash): NetConnection.connect(rtmp., 6aef79f07bc8f23c38e8979f3630f436);
Unique key: NetConnection.connect(rtmp., 349jh3k4324h9.234234098);
Then, on the server-side, Flash Media Server would be able to integrate with web services (SOAP), Flash Remoting, XML, HTTP Post (loadVars) or simple file access, to validate the client based on the data sent. This authentication scheme could be as simple as checking login information against a database, or as complex as creating an SSL-based token system using ColdFusion. Access adaptor plug-in Improved feature in Flash Media Interactive Server; requires Flash Player 6 or later. An access adaptor is a server plug-in written in C++ that intercepts connections to the server, and determines whether requests should be accepted, rejected, or redirected before the requests reach the servers script layer. You can create custom logic in the access adaptor to handle client connection requests. For example, you could query your account database upon client login, and then update the database record after the client connection was accepted. The access adaptor can be configured to accept or reject requests based on the number of clients currently connected or the amount of bandwidth currently being consumed. You can also set read and write access for files and folders on the server, set permissions to access audio and video bitmap data, and inspect client properties through the access adaptor. When you use the access adaptor, you are actually catching the connection before it is processed by Flash Media Server. For this reason, you are limited to trapping only the connection events. If you want to apply additional rules after the connection is established, you would need to configure an authorization adaptor.

Note: There can only be one Access plug-in per Flash Media Interactive Server installation.
Authorization adaptor plug-in New feature in Flash Media Interactive Server; requires Flash Player 6 or later. The next line of defense is the authorization adaptor. A server plug-in written in C++, the authorization adaptor authorizes client access to server events. Once the connection has been established, but before it is accepted, the authorization adaptor comes into play. Authorization adaptors can: Authorize connections to the server Authorize playing a stream or seeking in a stream Authorize publishing a stream Disconnect clients from the server Call a method in server-side ActionScript Deliver content to clients according to their geographic location, subscription level, and stream origin Limit time and duration of a users access to specific streams Map a logical stream path to a physical stream path. For example, a client requests the stream foo.flv, but since he is not a premium member of the service, he should only receive the low-quality version of that content, so he is actually served bar.flv. Unlike the access adaptor, you can use multiple authorization adaptors to sequentially perform actions on the incoming event. For example, auth1.dll (or auth1.so) could authorize the client connection; auth2.dll (or auth2.so) could then authorize that client to publish a stream, and so on. The server applies the adaptors in alphabetical order. As you can see, authorization adaptors can be very powerful for stream security and access control at a granular level. They can be configured to implement custom functionality ranging from rights management to logging. Dynamic access control When clients access the server, they have full access to all streams and shared objects by default. Access control is possible, however, using server-side ActionScript. You can create a dynamic access control list (ACL) which controls who has access to read, create, or update shared objects or streams. In server-side ActionScript, each client that connects is assigned to a Client object. Each Client object has readAccess and writeAccess properties. These properties can accept multiple comma-delimited values. By setting these values when you accept the client connection, you can control which streams and shared objects any given client can access. Stream encryption Flash Media Server 3 offers two options for encrypting your streams: SSL and RTMPE. SSL Feature available in Flash Media Streaming Server and Flash Media Interactive Server; requires Flash Player 8 or later. In earlier versions of Flash Media Server, encrypted streaming was available using SSL delivery, through RTMPS. This form of encryption is still supported in Flash Media Server 3. Implementation requires the use of a third-party certificate with some server-side configuration. Flash Media Server 3 now offers an easier, optimized way to implement an encryption solution, using encrypted RTMP (RTMPE).

RTMPE New feature in Flash Media Streaming Server and Flash Media Interactive Server; requires Flash Player 9,0,115,0 or later. Encrypted RTMP (RTMPE) is enabled on Flash Media Server by default, and allows you to send streams over an encrypted connection without requiring certificate management. Offering secure 128-bit encryption, RTMPE is only supported in Flash Player 9 or later, with the updated FLVPlayback component and NetConnection classes. Both SSL and RTMPE can also be tunneled to ensure connectivity through network firewalls. RTMPE is the recommended form of encryption, as it is easier to deploy and is much faster than SSL. Implementing stream encryption in your applications is easy. Simply specify the protocol when you connect to your application: SSL NetConnection.connect(rtmps://yourFMSserver.com); Tunneled SSL NetConnection.connect(rtmpts://yourFMSserver.com);
Enhanced RTMP NetConnection.connect(rtmpe://yourFMSserver.com);
Tunneled enhanced RTMP NetConnection.connect(rtmpte://yourFMSserver.com);
Defend against replay technologies Replay technologies or stream ripping has been a difficult security issue to solve because it allows the viewer to directly access and record the data of a stream. Stream encryption prevents stream ripping. In the past, SSL was the only choice, and it was too slow for most applications. Flash Media Server 3 uses RTMPE, which is much more efficient and easier to implement. Another method of defense against stream ripping is to insert intelligence into your server-client communications. By adding additional code to your video player, you could require your SWF to respond to a request from Flash Media Server to verify a unique string sent from the server, for example. This interrupts the flow of data to the stream ripping software, as it cannot respond with the correct data, and will be denied access. Digital Rights Management support New feature in Flash Media Streaming Server and Flash Media Interactive Server; requires Flash Player 6 or later. RTMPE/SWF verification requires Flash Player 9,0,115,0 or later. DRM has two key elements: encryption and access control. There are two ways to deliver video to a consumer: streaming or downloading. When you stream video from Flash Media Server, you immediately increase your protection. Encryption with Flash Media Server is done in real-time with RTMPS (SSL) or with RTMPE in Flash Media Server 3. Access control with Flash Media Server is done simply with SWF verification. Access control is much more powerful with Flash Media Interactive Server because of its new plug-in architecture, along with the server-side application layer. Using web services (SOAP), Flash Remoting, or XML you can create a system with secure tokens that provide access control over your content. These are the basic principles of DRM for streaming. For the download use case, Adobe will be releasing new technology with the Adobe Media Player in early 2008.

Adobe Systems Incorporated 345 Park Avenue San Jose, CA 95110-2704 USA www.adobe.com
Adobe, the Adobe logo, ActionScript, Adobe AIR, ColdFusion, Flash, Flash Lite, Flex, Flex Builder, Macromedia, and Flash On are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries. Mac is a trademark of Apple Inc., registered in the U.S. and other countries. HP is a registered trademark of Hewlett-Packard Company. Intel, Intel Xeon, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Microsoft, Windows, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Red Hat is a trademark or registered trademark of Red Hat, Inc. in the United States and other countries. All other trademarks are the property of their respective owners. 2008 Adobe Systems Incorporated. All rights reserved. Printed in the USA.

95010395 5/08