5.9. Stream Enhancements and Limitations

5.9.1. Server-Side send( ) Enhancements

FlashCom 1.5.2 fixed a problem with adding send( ) methods to a stream on the server. Whenever a server-side Stream object was used to send a method request within a stream, any subscribers to the live stream received the request just after it was sent. However, when a recorded stream was played back, any messages generated on the server all played back either at the beginning of the stream or in blocks during playback. The reason for the requests being received out of sync was that the stream time was determined by the publishing client and not by the server-side Stream object. The publishing client's NetStream sent a timestamp when audio or video was attached to the stream and whenever send( ) was called. The server-side Stream object could not determine the precise stream time when it inserted a method request, so the time of the request was set to the timestamp of the last message in the stream. The problem was resolved in FlashCom 1.5.2 by having the server keep track of stream time and adjusting the time difference for each send( ) method added to the stream. While the change may seem like a small one, it makes possible developing server-side recordings of chats and other applications. See Chapter 15 for more information.

Prior to FlashCom 1.5.2, remote methods defined on a server-side Stream object were never called. As of FlashCom 1.5.2, methods can be defined on a server-side Stream just as they can be defined on a client-side NetStream instance. When ActionScript data is played, the server-side Stream object's method will be called.

5.9.2. Sound Performance

FlashCom 1.5.2 also reduced the load on the server caused by sending audio to multiple subscribers. CPU load is often a determining factor in how many streams a server can manage. During live streams, the server does not immediately send each packet of sound information on to each subscriber as it arrives. Instead, the server waits until it has collected a small batch of sound samples and sends them at once. The result is a significant decrease in CPU usage when there are a large number of subscribers.

5.9.3. ActionScript 2.0

ActionScript 2.0 introduced strong typing to client-side ActionScript. In Flash MX 2004 and Flash Pro, the NetStream class is not defined as being a dynamic class. As a result, predefined methods such as onStatus( ) can be dynamically redefined without the compiler complaining, but new methodssuch as those required to receive remote method callscannot be added using the dot operator. The following short snippet will produce the compiler error "There is no property with the name `showMessage'":

var nc = new NetConnection( );
var ns:NetStream = new NetStream(nc);
ns.onStatus = function (info) {
  trace(info.code);
};
ns.showMessage = function (msg) { // Compiler error!
  trace(msg);
};

One way around the problem is to simply not use strong typingdo not declare the ns variable as being a NetStream. Instead, simply use:

var ns = new NetStream(nc);

If you want to use strong typing, an alternative solution is to use the [] operator:

nc = new NetConnection(  );
var ns:NetStream = new NetStream(nc);
ns.onStatus = function (info) {
  trace(info.code);
};
ns["showMessage"] = function (msg) {
  trace(msg);
};

5.9.4. Synchronization Limitations

In FlashCom 1.5.2 and earlier, each stream can carry only one audio and one video channel. Consequently, to play multiple video and audio channels at the same time requires more than one stream. However, there is no way to prebuffer and queue multiple streams to begin playing at the same time or to keep them synchronized while they play. Consequently, accurate synchronization of multiple streams is not currently possible.