RTMFP groups

Flash Player 10.1, AIR 2, Flash Media Server 4

Adobe recommends

P2P on the Flash Platform with RTMFP

Mathew Kaufman
Hear an introduction to peer-to-peer (P2P) communication and the Real Time Media Flow Protocol (RTMFP), used to create real-time social media applications that leverage the Adobe Flash Platform. Learn how the technology works from the engineer who created it.

Have a tutorial you would like to share?

Flash Player 10.1, AIR 2, and Flash Media Server 4 support RTMFP groups. Clients make an RTMFP connection to Flash Media Server and join a group.

A member of a group, also called a “node”. A peer is a Flash Player or AIR client that connects to Flash Media Server over RTMFP and joins a group.

A group is a collection of one or more RTMFP nodes who agree on certain parameters and capabilities. There is a path between every peer in a group that forms a peer-to-peer mesh. There may not be a direct connection between two peers, but there is a always a path through other peers. A group is also called a “peer group” an “RTMFP group” and a “NetGroup”.

Connecting to at least one member of a group in order to join the group. You can write application logic to bootstrap a client to a group, or you can ask Flash Media Server to bootstrap clients automatically. There is no random probing for peers and the server does not flood the network looking for peers.

Flash Media Server handles introducing a client to a group. Flash Player handles peer communication within a group, organizing and optimizing a group for latency, and maintaining the full-connectedness of a group.

The group maintains the connections between peers automatically. Once peers are fully meshed into a group, then they can pass data within the group. Data does not need to be sent to the server to be distributed to each client. Peers can share data such as audio, video, and ActionScript objects. RTMFP and groups allow you to build peer-to-peer applications that can scale to millions of clients.

Use the ActionScript 3.0 GroupSpecifier class to define the parameters and capabilities of a group in a string called a “groupspec”. Pass the groupspec to the NetGroup and NetStream constructors. Use the NetGroup class to manage a group and send ActionScript data within a group. Use the NetStream class to multicast audio and video data within a group.

Groupspecs are Strings that start with “G:” followed by hexadecimal digits, for example “G:01010b...”. The first part of the string is the unchangeable identity of the group and contains the group permissions. If a peer changes any permissions or properties of the group, they start a new group. The string is case-sensitive.

Groups allow you to do the following things:

To multicast streams and post messages, call ActionScript methods and pass them the data to send. The data arrives at the other nodes in the group.

To route messages directly to a peer and replicate an object within a group, you must write ActionScript code to help deliver the data.

Create a group

  1. Connect to Flash Media Server. Pass an “rtmfp” URL to the NetConnection.connect() method:;

    Note: If RTMFP is disabled in the Adaptor.xml file, it can take up to 2 minutes for the client to receive the "NetConnection.Connect.Failed" status. To prevent this delay, verify that <RTMFP enable="true"> in the Adpator.xml file. It is enabled by default.
  2. On "NetConnection.Connect.Success", use the GroupSpecifier class to create a groupspec. Pass the groupspec to the NetGroup constructor.

     // Called in the "NetConnection.Connect.Success" case in the NetStatusEvent handler. 
    private function OnConnect():void{ 
        connected = true; 
        // Create a GroupSpecifier object to pass to the NetGroup constructor. 
        // The GroupSpecifier determines the properties of the group 
        var groupSpecifier:GroupSpecifier; 
        groupSpecifier = new GroupSpecifier("com.example.p2papp"); 
        groupSpecifier.postingEnabled = true; 
        groupSpecifier.multicastEnabled = true; 
        // The serverChannel lets the server do auto-bootstrapping 
        groupSpecifier.serverChannelEnabled = true; 
        netGroup = new NetGroup(netConnection, groupSpecifier.groupspecWithAuthorizations()); 
        netGroup.addEventListener(NetStatusEvent.NET_STATUS, NetStatusHandler); 
  3. On "NetGroup.Connect.Success", you can manually bootstrap or automatically bootstrap peers to the group. The example enables the server channel to perform automatic bootstrapping. There are several additional options for bootstrapping described in the next section.

Additional information

Bootstrap a peer to a group

After the initial connection to the server, a peer must be introduced to one or more peers of the same group, this technique is called “bootstrapping”. Bootstrapping allows members of the same group to see each another. After bootstrapping, the peer self-organizes into the group and meshes with the other members.

To join a group, a client must know the GroupSpecifier that defines the group. If two sets of clients use the same GroupSpecifier, and never touch, they are in separate groups. If the two groups touch, they merge into a single larger group.

Each client has a peer ID, and the peer ID space is server-specific. The peer ID is the SHA256 of the client's Diffie-Hellman public key. Both client-side and server-side ActionScript can access the peer ID as a property of each RTMFP client. Peer IDs are available in the ActionScript 3.0 NetConnection.nearID and NetConnection.farID properties. Peer IDs are also available in the Server-Side ActionScript Client.nearID and farID properties. Client-side NetConnection.nearID and server-side Client.farID share the same value. Client-side NetConnection.farID and server-side Client.nearID share the same value.

Peers within an RTMFP group can be bootstrapped in the following ways:

  • Server channel automatic bootstrapping.

    When clients connect over an RTMFP connection, the server bootstraps them with peers who are members of the same NetGroup. To enable automatic bootstrapping on the client-side, set GroupSpecifier.serverChannelEnabled to true.

  • Manual bootstrapping.

    To manually bootstrap peers into a mesh, call the NetGroup.addNeighbor() method.

  • LAN peer discovery

    Use the GroupSpecifier class to enable LAN peer discovery. LAN peer discovery allows an RTMFP NetConnection and its NetStream and NetGroup objects to automatically locate peers and join a group on the current subnet. Peers cannot discover each other unless they’re in the same group on the same subnet of the LAN. If peers with matching groupspecs are on different subnets, no error or other event is dispatched if they fail to discover each other.

    The following code shows how to enable LAN peer discovery:

    var nc = new NetConnection(); 
    // Protocol must be RTMFP 
    var gs = new GroupSpecifier("com.example.discovery-test"); 
    // Must be enabled for LAN peer discovery to work 
    gs.ipMulticastMemberUpdatesEnabled = true; 
    // Multicast address over which to exchange peer discovery. 
    // Additional GroupSpecifier configuration... 
    var ns = new NetStream(nc, gs.toString());
Note: Call the Administration API getServerStats() command to get RTMFP peer lookup statistics.

Server-side RTMFP groups

Use Server-Side ActionScript to create an RTMFP NetConnection. You can connect to an application on the same server or to an application on another Flash Media Server. After you create an RTMFP NetConnection, define a GroupSpecifier to create a NetGroup and a NetStream. The server application joins the group and becomes a peer in the group mesh. A single client can join multiple groups. Once connected, you can interact with other peers in the RTMFP group. You can also publish streams into the group.

A server-side netConnection is a virtual Flash client. It has its own RTMFP stack. As far as the server is concerned, a server-side script that joins a group is the same as any client.

Note: Server-Side ActionScript doesn't support creating a connection directly between peers.

Flash Player peer-assisted networking security dialog

When a NetStream or NetGroup object is constructed with a groupspec, Flash Player displays a “Peer-assisted Networking” dialog. The dialog asks users if Flash Player can use their connection to share data with their peers.

If the user clicks “Allow for this domain”, the dialog is not displayed the next time the user connects to this application. If a user does not allow peer-assisted networking, all peer features within the group (posting, directed routing, and object replication, and multicast) are disabled. You can use RTMFP to subscribe to a pure native-IP multicast stream. In this case, the dialog is not displayed.

When using IP multicast with no peer-assisted functionality, you can disable the security dialog. Set the GroupSpecifier.peerToPeerDisabled property to true. By default, this property is false (peer-assisted connections are enabled). When peerToPeerDisabled is true, the security dialog does not appear.

ActionScript classes for working with RTMFP groups

Use the following ActionScript 3.0 classes and Server-Side ActionScript classes to create applications that use RTMFP groups:

  • NetConnection

    Use the NetConnection class to create a two-way RTMFP connection between a Flash Player or AIR application and a Flash Media Server application. Use the RTMFP protocol in the URL you pass to the NetConnection.connect() method.

  • GroupSpecifier

    Use the GroupSpecifier class to define the capabilities, restrictions, and authorizations of an RTMFP peer-to-peer group. After you define the capabilities, pass a groupspec string or a GroupSpecifier object to the NetStream and NetGroup constructors. A groupspec is an opaque string that you pass to the NetStream and NetGroup constructors.

    In server-side code, you can pass the GroupSpecifier object or a groupspec string.

    In client-side code, you can only pass a groupspec string. To generate a groupspec string, call one of the following methods: toString(), groupSpecWithAuthorizations(), and groupSpecWithoutAuthorizations().

  • NetGroup

    Use the NetGroup class to manage an RTMFP group. The class properties provide information about group members. Call the class methods to post messages to the group, route messages to a group member, and to replicate objects among the group. To create a NetGroup, pass a GroupSpecifier object to the NetGroup constructor.

  • NetGroupInfo

    The NetGroupInfo class specifies Quality of Service (QoS) statistics about a NetGroup object's RTMFP peer-to-peer data transport. The NetGroup.info property returns a NetGroupInfo object which is a snapshot of the current QoS state.

  • NetStream

    Use the NetStream class to multicast audio and video data over a group. Pass a groupspec to the NetStream constructor and use the standard publish() and play() methods.

  • NetStreamMulticastInfo

    The NetStreamMulticastInfo class specifies Quality of Service (QoS) statistics about a NetStream object's RTMFP peer-to-peer and IP multicast stream transport. The NetStream.multicastInfo property returns a NetStreamMulticastInfo object which is a snapshot of the current QoS state.

Post messages to a group

Call the NetGroup.post() method to broadcast an ActionScript message to all members of a NetGroup (also called a “group”). Use the "NetGroup.Posting.Notify" code to do something when a post has been received.

You can post messages to a group from the client-side ActionScript 3.0 NetGroup.post() method or from the Server-Side ActionScript NetGroup.post() method.

Use the post() method to broadcast non-stateful data. For example, use posting for text chat, opinion polls, and sensor reporting. Use posting to allow many clients to send small amounts of data.

This method is similar to the Server-Side ActionScript Application.broadcastMsg() method, but the post() method propagates messages from node to node in a group. Posting is not similar to using shared objects. Unlike shared objects, posting does not manage changes.

Understand the following about posting messages:

  • The GroupSpecifier.postingEnabled property must be true in the groupspec passed to the NetGroup constructor.

  • Receive a NetGroup.Neighbor.Connect event before you call post().

  • Messages are serialized in AMF. A message can be any AMF object. A message cannot be a MovieClip.

  • Messages must be unique to be considered new. Use a sequence number to make messages unique.

  • Message delivery is not ordered. Message delivery is not guaranteed.

  • The post() method returns the messageID for this message, or null on error. The messageID is the hexadecimal of the SHA256 of the raw bytes of the serialization of the message.

  • The post() method sends a NetStatusEvent to the NetGroup's event listener with "NetGroup.Posting.Notify" in the info.code property.

The NetGroup.post() entry in the ActionScript 3.0 Reference contains a chat application example. The following is an excerpt from that example:
private function OnConnect():void{ 
    connected = true; 
    // Create a GroupSpecifier object to pass to the NetGroup constructor. 
    // The GroupSpecifier determines the properties of the group 
    var groupSpecifier:GroupSpecifier; 
    groupSpecifier = new GroupSpecifier("com.aslrexample/" + groupNameText.text); 
    groupSpecifier.postingEnabled = true; 
    groupSpecifier.serverChannelEnabled = true; 
    netGroup = new NetGroup(netConnection, groupSpecifier.groupspecWithAuthorizations()); 
    netGroup.addEventListener(NetStatusEvent.NET_STATUS, NetStatusHandler); 
    StatusMessage("Join \"" + groupSpecifier.groupspecWithAuthorizations() + "\"\n"); 
// Called when you the chatText field has focus and you press Enter. 
private function DoPost(e:ComponentEvent):void{ 
    // Build the message to post. 
        var message:Object = new Object; 
        message.user = userNameText.text; 
        message.text = chatText.text; 
        message.sequence = sequenceNumber++; 
        message.sender = netConnection.nearID; 
    // Post the message to the group. 
        StatusMessage("==> " + chatText.text + "\n") 
    } else { 
        StatusMessage("Click Connect before sending a chat message"); 

Route messages directly to a peer

A client can send short ActionScript messages directly to a member of a peer-to-peer group without having a direct connection to that member. This feature is called directed routing. Directed routing leverages the full transitive connectivity and the geometric properties of the Group's self-organized structure to route messages through the group.

Use directed routing to send a message to a specific client, or to construct a DHT (distributed hash table).

Successful routing of the message requires the direct participation of all peers along the dynamic path between the sender and intended recipient. Each peer acts as a relay point for the message. Peers do not automatically relay received messages. Use ActionScript to handle the receipt and local processing or forwarding of a message. Message delivery is not guaranteed.

The bandwidth load of message routing is distributed among the members of the group, it is not concentrated at the server.

The following are the Server-Side ActionScript directed routing APIs:

The following are the client-side ActionScript 3.0 directed routing APIs:

Replicate an object within a group

Clients can send ActionScript objects through the peer group reliably. This feature is called object replication. Object replication allows all members of an RTMFP group to have a consistent view of a set of objects. Use it to replicate workspaces, create whiteboards, and transfer files, synchronize nodes with a log of operations, and so on.

Object replication uses the full transitive connectivity of the group’s self-organized structure. It replicates objects through the group from nodes that have the objects to nodes that need the objects. Each object is indexed by a number that must be unique across the entire group. The objects must remain immutable.

Use the following client-side ActionScript 3.0 APIs to replicate an object within a group:

Use the following Server-Side ActionScript APIs for object replication and other RTMFP group features:


To complete a tutorial before learning more about the details of multicasting, see Multicast media (RTMFP).

Multicasting is distributing audio and video data among members of a group. The server doesn’t send data to each client—the data is distributed among peers. Multicasting allows few publishers to send a large amount of data. To multicast media, pass a groupspec to the NetStream constructor. Call NetStream.publish() or NetStream.play() to multicast the data. You can use the client-side NetStream class and the server-side NetStream class to multicast data.

Flash Media Server supports both application-level multicast and IP multicast. You can also use application-level multicast and IP multicast cooperatively for a single stream, this use case is called multicast fusion. Multicast fusion combines both broadcast techniques to support higher quality of service. Within a firewall, use IP multicast. Outside the firewall, or on networks that don’t support IP multicast, use application-level multicast. Multicast fusion lets your neighbor outside the firewall receive fragments of video that it cannot receive via IP multicast.

Flash Media Server can multicast streams delivered to it over RTMP connections. For example, Flash Media Live Encoder can deliver a stream to Flash Media Server over RTMP and Flash Media Server can multicast it to groups over RTMFP.

Understand the following about multicast:

  • Any number of streams can be published into a group. However, this practice is not recommended because each group member consumes and relays all streams, even if the streams aren’t playing at that specific client.

  • Streams of the same name can be published into a group.

    When a client requests to play the stream name, it plays the first stream with that name that it can find. If the publisher for that instance of the named stream stops, the playing client resets to another instance of the named stream and a "NetStream.MulticastStream.Reset" event is dispatched. Within an RTMFP group, there is no single arbiter of stream state that prevents multiple clients from publishing streams with the same name. (In traditional, unicast stream publishing, Flash Media Server is aware of stream state.) This is a significant reason for the improved scalability of multicast streams. However, to protect against stream name collisions or hijacking, define a publish password for the group and providing the groupspec with authorizations to trusted publishers only. Pass a groupspec without authorization to all other clients to prevent them from publishing competing streams under the same name.

  • Publishers can call NetStream.send() to inject data into a group.

  • When a client is in an RTMFP group in which a live multicast stream is playing, the client may act as a relay point for that stream to some number of direct neighbors. To control this number, use the NetStream.multicastPushNeighborLimit property. The default value is to 4. All the peers within a group work co-operatively to get the stream to each other. Each client is not pulling the stream from the server independently. For this reason, consider the expected average client uplink capacity when selecting the bitrate for the multicast stream you publish. Choosing a bitrate that's too high may result in peers not being able to relay the stream smoothly.
    Note: This requirement is specific to P2P multicast. IP multicast, which can be used simultaneously with P2P multicast, can be used for higher bitrate, live multicast streams in a local area network.

Additional information

Application-level multicast

By default, the peer-to-peer mesh distributes streams published into an RTMFP group. This technology is known as “application-level multicast”.

IP multicast

IP multicast uses routers to send data to a specified IP address. The routers send the data to any client registered to an IP multicast group. To set up IP multicast, work with your IT department. Ask them to set up an address to publish to and to configure the enterprise multicast routers to forward the traffic appropriately.

To publish streams to a IP multicast address, call the Server-Side ActionScript NetStream.setIPMulticastPublishAddress() method before you start publishing.

All subscribing (playing) peers in the group must add the IP multicast address to their GroupSpecifier. Call GroupSpecifier.addIPMulticastAddress()when you create a groupspec. Adding a IP multicast address allows a client to listen for and receive the IP multicast traffic.

By default, application-level multicast runs concurrently with IP multicast. This technology is called “fusion multicast”. To run IP multicast without application-level multicast, set up the following in the GroupSpecifier:

  • GroupSpecifier.peerToPeerDisabled=true

    This setting turns off peer-to-peer multicast.

  • GroupSpecifier.multicastEnabled=true

  • Call GroupSpecifier.addIPMulticastAddress()

    Call this method in the client-side application only. To publish from the server, the stream publishes to the address you passed to the Server-Side ActionScript NetStream.setIPMulticastPublishAddress()method. That address is the same address the clients are using.

Source-specific IP multicast

Source-specific multicast (SSM) allows the client to specify an IP address from which it wants to receive data. The client receives data only from this source. SSM reduces the burden on the network. To configure SSM, use the Multicast Config tool installed at rootinstall/tools/multicast/configurator. The tutorial Multicast media (RTMFP) uses the Multicast Config tool.

Source-specific multicast limits receipt of IP multicast data to data coming from the “source”. On a multi-homed system (a system with multiple IP addresses), the server-side publisher can use the following API to bind to the desired local interface IP address:

netConn.rtmfpBindAddresses = [""];

At the subscriber, indicate the desired source address when you add the IP multicast address to the GroupSpecifier:

gs.addIPMulticastAddress("{mcastAddr}", {port}, "");

Not all host operating systems support SSM (for example, pre-Lion Mac OS). If the operating system doesn’t support SSL, the client does not receive data.

Create a client-side serverless RTMFP connection

You can create a network endpoint for RTMFP group and IP multicast communication without connecting to a server, but the functionality is limited. This mode is called “serverless mode”. Use severless mode to receive a pure IP multicast stream from a publisher without requiring clients to connect to a server or bootstrap into the peer-to-peer mesh.

Note: In Server-Side ActionScript, use serverless mode to create a robust server-only group for distributing peer introductions. See Distribute peer introductions across servers.

Because clients don’t connect to a server, there is no automatic bootstrapping. In serverless mode, configure peers to discover each other on a LAN using IP multicast. After they discover each other, they can communicate within the group. In serverless mode, clients can do the following:

  • Use IP multicast to discover peers on the LAN.

  • Receive streams over IP multicast.

  • Send and receive streams in a NetGroup. (The NetGroup consists only of peers discovered over IP multicast on the LAN.)

The following code creates a connection in serverless mode:

var nc:NetConnection = new NetConnection; 

The NetConnection instance nc is a serverless RTMFP NetConnection. The following code uses the NetConnection to make a NetStream that can receive a pure IP multicast. It also suppresses the peer-assisted networking permission dialog

var gs:GroupSpecifier = new GroupSpecifier("com.adobe.pureIPMulticastGroup"); 
gs.multicastEnabled = true; 
// Prevents the P2P permission dialog from appearing. 
gs.peerToPeerDisabled = true; 
// Receive multicast stream on port 30000 
var ns:NetStream = new NetStream(nc, gs.groupspecWithAuthorizations());

Wait for the "NetStream.Connect.Success" message, which is required before you can use a group NetStream. Attach the NetStream to a video display object and call ns.play(streamName). Or, you can create an group on your LAN for any of the RTMFP group modes (including peer-to-peer multicast), as in the following:

var gs:GroupSpecifier = new GroupSpecifier("com.adobe.myAdHocGroup"); 
gs.multicastEnabled = true; 
gs.postingEnabled = true; 
gs.ipMulticastMemberUpdatesEnabled = true; 
// Peers find each other on port 30001 
var ns:NetStream = new NetStream(nc, gs.groupspecWithAuthorizations()); 
var ng:NetGroup = new NetGroup(nc, gs.groupspecWithAuthorizations());

Wait for NetStream.Connect.Success and NetGroup.Connect.Success. After receiving them, you can publish or play a peer-to-peer multicast stream on the NetStream, and post on the NetGroup.

See Adobe Evangelist Tom Krcha’s video tutorial, Controlling the desktop with your mobile device via P2P.

Adobe recommends

Controlling the desktop with your mobile device via P2P

Tom Krcha
Platform Evangelist Tomas Krcha demonstrates the ability to control an application on your desktop with your mobile device using Flash Builder. This tutorial uses a serverless NetConnection and local peer-to-peer communication over a LAN.

Have a tutorial you would like to share?

Fusion multicast

By default, when you run IP multicast, you are also running application-level multicast. This technique is called “fusion multicast”. Both IP and application-level multicast run coordinated and concurrently. The application-level multicast runs slightly behind the IP multicast to take advantage of the greater efficiency of IP multicast.

Checking multicast quality of service

To check whether a client is multicasting, and to check on quality of service, use the ActionScript 3.0 NetStream.multicastInfo property. This property is an instance of the NetStreamMulticastInfo class which specifies various QoS metrics for statistics when multicasting. For example, the NetStreamMulticastInfo.bytesReceivedFromIPMulticast property tells much data a client is receiving over pure IP multicast (as opposed to application-level multicast).

In Server-Side ActionScript, use the NetStreamMulticastInfo class and the MulticastStreamIngest class.

Prevent the server from unloading an application

Flash Media Server considers an application with no inbound connections idle. Eventually, the server unloads the application. To prevent the server from unloading the application, define an Application.onAppStop() handler that returns false.

For example, consider the following scenario involving two Flash Media Server installations, Server A and Server B. Server A acts as the peer introducer and ingests live streams. An application on Server B pulls a stream from Server A and calls Stream.play() to publish it to an RTMFP group. The application on Server B has outbound connections to server A, but it doesn’t have inbound client connections. When an application doesn’t have incoming client connections, the server considers the application idle and unloads it.

Ingest, convert, and record a multicast stream

Use Server-Side ActionScript to ingest a multicast RTMFP stream. After the server ingests the multicast stream, write a script to do the following:

  • Convert the multicast stream to a Stream object.

  • Deliver the Stream to clients over HTTP.

    Connect to the livepkgr application and package the Stream for delivery using HTTP Dynamic Streaming and HTTP Live Streaming.

  • Deliver the Stream object to clients over RTMP/T/S/E.

  • Record the Stream object.

View full size graphic
Use multicast ingest to deliver live content across server tiers
Note: You cannot directly bridge an RTMFP multicast stream to another RTMFP group (by attaching the Stream to a multicast NetStream). You can bridge indirectly to another RTMFP group by publishing into the target group via a NetStream that has been attached to a MulticastStreamIngest created Stream.

Multicast Stream Ingest API

  • MulticastStreamIngest class

    Use the MulticastStreamIngest class to bind to a multicast stream in a group and transform the multicast messages to non-multicast messages. Use the class to access QoS information and to control the ingest.

  • MulticastStreamIngest.close()

    Stops ingesting the source multicast stream.

  • MulticastStreamIngest.ingesting

    Indicates whether the target multicast stream is bound and being ingested or not.

  • MulticastStreamIngest.multicastInfo

    A MulticastStreamInfo object whose properties contain statistics about the stream quality of service.

  • MulticastStreamIngest.multicastPushNeighborLimit

    The maximum number of peers to which to push multicast media.

  • MulticastStreamIngest.multicastWindowDuration

    The duration in seconds of the peer-to-peer multicast reassembly window.

  • NetGroup.getMulticastStreamIngest("livestream")

    A factory method that constructs and returns a MulticastStreamIngest object that is bound to the named stream being published into the group the NetGroup has joined.

  • Stream.playFromGroup(ingest)

    Sets the data source for a Stream object. The ingest parameter is a MulticastStreamIngest object that is ingesting a multicast stream from a group.

Use the MulticastStreamIngest API

To create a MulticastStreamIngest instance and ingest a live stream, call NetGroup.getMulticastStreamIngest(). To play the ingested stream, call Stream.playFromGroup(). Use the MulticastStreamIngest class to check QoS and publishing status, stop ingesting a stream, and configure ingest settings. For more information about these APIs, see Server-Side ActionScript Reference.

View full size graphic
Multicast ingest application flow

The following pseudocode provides a high-level description. First, set up a Stream instance that plays and records the multicast ingest:

var stream = Stream.get("mp4:multicast-ingest.f4v");

Next, set up a server-side NetConnection and NetGroup to join the group into which the multicast stream is being published:

var nc = new NetConnection(); 
nc.onStatus = function(info) { 
    if (info.code == "NetConnection.Connect.Success") { 
        ng = new NetGroup(nc, groupspec); 
        ng.onStatus = ngStatusHandler; 

Write code to handle NetGroup status events. When joining the group succeeds, indicated by a "NetGroup.Connect.Success" event, attempt to start ingesting the multicast stream.

function ngStatusHandler(info) { 
    if (info.code == "NetGroup.Connect.Success") { 
        ingest = ng.getMulticastStreamIngest(sourceStreamName); 

Play the ingested multicast stream, record the multicast stream, and stop playback:

// The stream can be recorded locally. 
stream.record(false); // And recording stopped. 
// To stop playback of a multicast stream, pass the Boolean false. 
Note: Server-side playlists aren’t supported. However, there is a workaround. Create a remote Stream playback from an ingested Stream to a second Stream object. Use the second Stream object as part of a playlist.

Peer-assisted networking application examples

The NetGroup entry in ActionScript 3.0 Reference contains a peer-assisted video and text chat example. The example is a Flex MXML file. To use Flash Pro instead of Flash Builder, see the example for the NetGroup.post() entry which is an AS file.

Adobe Evangelist Tom Krcha has several tutorials and video tutorials on his blog, FlashRealtime.com.

Adobe recommends

Multicast Streaming in Flash Player 10.1

Tom Krcha
Platform Evangelist Tom Krcha describes how to broadcast video to a group of participants using the peer-to-peer multicast streaming capabilities in Flash Player 10.1.

Peer-to-peer chat with NetGroup in Flash Player 10.1

Tom Krcha
In this video, Platform Evangelist Tom Krcha discusses how to create a simple peer-to-peer chat using group posting.

Seminar Recording: Advanced P2P – Object Replication

Tom Krcha
How to do peer-assisted object replication.

Have a tutorial you would like to share?