Category — application development

You can use the Server-Side Client object to grant read access to folders on the server that contain streams and shared objects. Because each client that connects to an FMS application has a unique Client object,  you can grant different permissions to each client. Check out the Client.readAccess property and the comment at the bottom of the following page for more information:

Server-Side ActionScript Language Reference — Client class

JOdy

Here’s something I see people get hung up on when defining functions in client-side ActionScript and calling them from the Server-Side ActionScript Client.call() method.

In ActionScript 2, you define the functions directly on the NetConnection object, like this:

nc = new NetConnection();
nc.onBWDone = function(){
    return true;
};
nc.onBWCheck = function(){
   return 0;
};
nc.connect("rtmp:/clientCall");

In ActionScript 3, you define the functions on an object assigned to the NetConnection.client property, like this:

var clientObj:Object = new Object();
clientObj.onBWDone = onBWDone;
clientObj.onBWCheck = onBWCheck;
nc.client = clientObj;

public function onBWDone(... rest):Boolean {
   return true;
}

public function onBWCheck(... rest):Number {
   return 0;
}

Note:The previous code includes the callback functions expected by the FMS “live” and “vod” applications.

The NetStream class works similarly to the NetConnection class. You can call NetStream.send() to send messages to other connected clients. Those clients need callback functions that handle the messages.

In AS2 you can define functions on a NetStream object and in AS3 you define functions on an object assigned to the NetStream.client property. See NetStream.client and NetStream.send().

There are several ways to handle callback methods–you can use the technique in this post, you can assign the client property to a new class, you can extend the NetStream or NetConnection class, or you can assign the client property to this. For good examples, see “Writing callback methods for metadata and cue points”.

Flash Player 10.1, which is available now on Adobe Labs, adds support for creating peer-to-peer groups. Flash Player 10 let you make peer-to-peer connections between 2 Flash Player clients, but now you can create an entire mesh. And share data, audio, and video streams directly between all peers in the mesh. Think scale… massive, massive scale, without thousands and thousands of Flash Media Server boxes or huge bandwidth pipes. Think cheap and big. Exciting, no?

All clients in the mesh must make a connection to Stratus (a hosted service available on Adobe Labs), but the data shared in the mesh doesn’t go through Stratus, it travels directly between the peers in the group. Stratus is a non-commercial server that lets Adobe preview technologies that will become available in future releases of Flash Media Server.  You can also use LiveCycle Collaboration Service to build commercial P2P apps. LCCS rolls the P2P functionality for you and falls back to hub and spoke if needed. Tom Krcha has a nice explanation of the difference between Stratus and LCCS.

The classes you need to build P2P apps are documented in the beta version of the unified ActionScript 3.0 Reference. (Yes, this means that from now on there will be one and only one version of the AS3R. No more special versions for Flex, AIR, etc etc. Get all your Flash Platform API information from a single source. Phew.) Where was I? Right… P2p…

• Use the GroupSpecifier class to define a group and its options. This class creates the groupspec string which is the immutable identity of the group.
• Use the NetGroup class to manage a group and get statistics about a group.
• Use the NetStream class to multicast audio, video, and data. Just like you do with hub and spoke apps.
• Use the NetConnection class to connect to Stratus (and in the future, FMS). For P2P apps, use the RTMFP protocol.

I’ll be writing more about P2P Flash apps (here and for the Adobe docs), but meanwhile, check out Tom’s MAX 2009 session.