Section 1.3. Real-Time Messaging Protocol

1.3. Real-Time Messaging Protocol

The Flash Player communicates with FlashCom using Macromedia's proprietary Real-Time Messaging Protocol (RTMP). RTMP uses TCP (transmission control protocol) for transmission of packets between the Flash Player and the server. TCP is a reliable protocol that guarantees delivery of every packet of information. RTMP can transport audio encoded in MP3 and Nellymoser (http://www.nellymoser.com) formats, video encoded in the Flash Video format (FLV), and data encoded using Macromedia's Action Message Format (AMF). AMF provides an efficient way to serialize/ deserialize data so that both primitive and complex ActionScript data can be transferred between client and server without needing to manually encode or decode the data. AMF is briefly described in Chapter 11, but for full details, see Flash Remoting: The Definitive Guide (O'Reilly).

1.3.1. FlashCom Versus Traditional Media Servers

Using TCP as the foundation protocol for Flash communications simplifies managing the transfer of audio, video, and ActionScript data flowing between the client and server. However, TCP is a point-to-point protocol, which means each client requires a separate client/server TCP connection; consequently, it cannot broadcast or multicast packets from the server to multiple clients at the network level. If a live audio stream must be sent simultaneously to multiple clients , the server must send duplicate copies of the audio data to each client over discrete connections. Traditional media servers, designed primarily to distribute media streams from server to client, normally provide the option to send the stream using UDP ( user datagram protocol) as well as TCP. UDP can be used to multicast or unicast a stream. When multicast is enabled, a single copy of the stream is transmitted, and any client that subscribes to the multicast can receive it. Multicasting has two tremendous advantages: it reduces the load on the server and the bandwidth required to send streams to large numbers of clients. Unfortunately, the vast majority of Internet service providers (ISPs) have disabled multicast on their networks because of security concerns. Consequently, media servers provide a fallback to unicast streaming over UDP. Unicasting means the server must duplicate the stream data and send it in a separate stream to every client. If for some reason the client does not accept the unicast stream, UDP media servers typically fall back to sending duplicate stream data to each client over TCP in much the same way FlashCom does.

Even without multicast, UDP has some advantages for traditional media servers. UDP is not a "reliable" protocol. It does not guarantee that every packet sent from the server to the client will arrive . For audio and video streams, some missing packets may not make any noticeable difference in perceived quality. The network overhead of sending UDP is lower than TCP, so UDP often delivers data faster than TCP. The more congested a network, the more packets will be dropped, so that the stream quality may degrade without dramatically slowing down delivery of the stream. In contrast, TCP will adjust to network congestion and bandwidth limits by slowing the transfer of data and by resending lost packets. To support the streaming of media data over TCP, the amount of data being sent must be dynamically adjusted in response to network bandwidth and congestion. RTMP is designed to adjust the amount of video and audio being transmitted by dropping audio messages and video frames in response to inadequate network bandwidth. On congested networks, it is not as effective as UDP-based protocols for delivering streaming media, but on modern networks it delivers very good performance.

RTMP supports more than the streaming media protocols of traditional media servers. It supports dynamic transmission of multiple streams that can contain audio, video, and ActionScript data both from server to client and from client to server. RTMP manages sending audio, video, and ActionScript data separately. ActionScript data is never dropped, because any loss could have catastrophic effects on an application. Audio and video data is buffered separately on the server. If audio data in the audio buffer grows to a certain threshold, all the data in the buffer is dropped, and newly arrived data is allowed to start collecting in the buffer to be sent on to each client. Video data is managed in a similar manner except that the data in the buffer is dropped when a new keyframe arrives. Dropping video data when a keyframe arrives ensures that the client never receives partial frame updates for the wrong keyframe. If the client did, the video image would be made up of a mosaic of 8 x 8 pixel blocks from two different frames. RTMP also prioritizes data. Audio is given the highest priority because it is so essential for real-time conversations. Video is given the lowest priority, and ActionScript is given a priority in between audio and video.



Programming Flash Communication Server
Programming Flash Communication Server
ISBN: 0596005040
EAN: 2147483647
Year: 2003
Pages: 203

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