Introducing the Flash Communication Server - FlashCom Versus Traditional Media Servers
(Page 4 of 4 )
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. Action-Script 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.
The Communication Classes While RTMP conveniently manages the flow of multiple streams of data across a network, the real power of Flash and FlashCom for developers is realized in the high-level classes that make connecting to the server, sharing information, and streaming audio and video so easy and flexible. I’ll briefly review the major classes, which will be explored in more detail and used in examples throughout the remainder of the book.
Connecting to the Server
The NetConnection class connects a client to an application instance on a server. In the simplest case, you can create a connection by invoking NetConnection.connect( ) with the URI of the remote application:
nc = new NetConnection();
nc.connect("rtmp://echo.ryerson.ca/ campusCameras/connector");
To determine if the connection was established successfully, define an onStatus( ) method on the NetConnection object before invoking connect( ):
nc = new NetConnection();
nc.onStatus = function (info) {
trace("The connection code is: " + info.code);
};
nc.connect("rtmp://echo.ryerson.ca/campusCameras/ connector");
In this example, the RTMP address includes the host (echo.ryerson.ca), the application name (campusCameras), and the instance name (connector). If you’ve ever developed network applications using other application programming interfaces, you’ll likely agree that creating a network connection between Flash and FlashCom is ridiculously easy. Chapter 3 goes into greater detail on the NetConnection class and how to use NetConnection objects.
Please check back next week for the continuation of this article.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
|
 This article is excerpted from the book Programming Flash Communication Server, written by Brian Lesser, Giacomo Guilizzoni, Robert Reinhardt, Joey Lott, and Justin Watkins (O'Reilly, 2005; ISBN: 0596005040). Check it out today at your favorite bookstore. Buy this book now.
|
|
/ 7 
