Prerequisite knowledge    Required products   Sample files
This article assumes you have experience
with developing applications for the Adobe 
Flash Platform, a solidunderstanding of 
Adobe ActionScript 3,and familiarity with 
P2P networkingconcepts.
Flash Builder (Download trial)
p2p_rtmfp_groups.zip (314 KB)
User level    
Adobe Flash Player 10.1, Adobe Cirrus 2, and Real-Time Media Flow Protocol (RTMFP) are setting a firm foundation for peer-to-peer (P2P) with peer-assisted networking. Using the capabilities of groups and the new features around them, you can make deployments of nearly any scale and take advantage of multiuser interactive applications for data and media. Everything from application-level video multicasting to swarming file delivery and multiuser games are within easy reach of developers, without the heavy burden being laid upon a server infrastructure.
This is the first in a series of articles that focus on P2P capabilities of the Adobe Flash Platform, Adobe Cirrus, and RTMFP. Future articles will dive deeper and provide a hands-on approach to utilizing the new groups and peer-assisted network topologies to make corporate enterprise, social media, and entertainment applications.

Brief history of RTMFP

Adobe introduced the Real-Time Media Flow Protocol (RTMFP) with Flash Player 10 (November 2008), which is deployed on over 90% of Internet-connected PCs. Using RTMFP and a managed peer-to-peer (P2P) solution such as Adobe Cirrus, Flash Player can now send data directly to its destination without sending it through a server. P2P communication with Flash Player has become a reality.
A key difference between the newer RTMFP and the older RTMP is that RTMFP is built on top of UDP rather than TCP. UDP is one of the key ingredients to building practical and scalable P2P application for Internet-connected peers. Unlike TCP, UDP is a lossy, partial reliability transport protocol. RTMFP is often lower latency than RTMP thanks to RTMFP transmission-time prioritization coupled with UDP lossiness. Another key difference is that, unlike RTMP, RTMFP is encrypted over the wire using an 128-bit AES encryption, helping to position Adobe managed P2P as a trusted solution to use for P2P applications.
You should keep in mind the following considerations when using RTMFP with Flash Player 10:
  • Peer-assisted networking with Flash Player utilizes a managed P2P solution from Adobe such as Adobe Cirrus for rendezvous services.
  • Developers are responsible for exchanging peer IDs to create P2P applications. For instance, you might need to store the peer ID in an external tracking database and use that to allow additional Flash Player instances to make connections.
  • To exchange audio, video, and data using a P2P application running on Flash Player 10, you are limited to using NetStream in a point-to-point topology. Data needs to be transmitted from the publishing peer once for each connected peer, making the solution good for one- or two-way conferencing or collaboration applications (see Figure 1).
P2P point-to-point topology
Figure 1. P2P point-to-point topology
Taking Figure 1 into account, if one publishing player had nine connected clients, the publisher would need to transmit all audio, video, and data nine times.

What's new with RTMFP, Flash Player 10.1, and Cirrus 2

Flash Player 10.1 and Cirrus 2 introduce a host of new features and enhancements to make P2P data flow in Flash Player more efficient and, therefore, more useful in more scenarios. The addition of groups is one of the main foundation items that will improve P2P capabilities on the Flash Platform.
Groups offer the capability to create virtual groups of multiple Flash Player 10.1 (or Adobe AIR 2) clients communicating efficiently with one another in a number of different ways. A key benefit of all the aforementioned features is true scalability in a P2P scenario without the need for a server, other than helping to establish the proper connections and authorization for group individuals. The following sections outline other key advantages offered by Flash Player 10.1 and Cirrus 2.
Network efficiency
Using a rendezvous server such as Cirrus 2 enables clients to connect to the P2P overlay network and groups automatically via a server channel. This effectively eliminates the need to pass around peer IDs using an external data service or manual ID exchange.
Peer-assisted networking in Flash Player utilizes a self-managed topology where peers will try to establish communication links based on response time metrics. In other words, lowest latency peers are preferred, increasing the possibility of decreased traffic over slower links within the network and saving bandwidth costs.
Secure communications
Peer-assisted networking through Flash Player is a managed solution. For Internet-based applications, a server such as Cirrus 2 is required to connect and authenticate clients for any communication to take place. (RTMFP can use LAN discovery to detect other clients on the same LAN and participate in groups without needing a server.) Once the clients have been authorized, data is transmitted between peers via RTMFP, which is encrypted to ensure that content is protected when it traverses the network.
RTMFP groups can be configured to require authentication before posting content. As another layer of security, Flash Player will prompt a user before participating in peer-assisted networking, giving the user the option to accept or decline their participation in the peer-assisted network.
New ways to distribute data
You can still use NetStream to transfer audio, video, and data from a smaller number of publishers effectively. Flash Player 10.1 has a new class called NetGroup that has been optimized for transferring data from many publishers at a lower bit rate. This is done through group posting, directed routing, and object replication:
Group posting
Posting is used to send and receive ActionScript objects. Events will be dispatched at each peer as postings are received. Group posting opens the door to creating highly scalable and interactive applications such as group chat applications, team whiteboard applications, or even monitoring applications where a large number of nodes report their status on a frequent basis. One thing to note about posting is that objects sent are subject to transmit timeouts. If the application requires reliable transmission, use the new object replication feature mentioned later.
Directed routing
Flash Player 10.1 introduces directed routing, a feature that allows peers to route messages through the P2P mesh. For instance, messages can be routed to all neighbors, the neighbor nearest a specific group address, or even a specific neighbor. The main benefit of directed routing is that it enables a publisher to send data to specific peers within a group. Directed routing can be used to build applications that take advantage of distributed hash tables (DHT). DHT applications take full advantage of the scalability of a peer-assisted application by utilizing the resources of every connected peer vs. the traditional hub and spoke model in a client-server architecture.
Object replication
Object replication is used to replicate data to all peers participating in the P2P mesh. Object replication is managed automatically by the nodes within the peer-assisted network. The benefit to using object replication is that any data replication request will eventually make it to all the clients in the P2P mesh. This feature is a perfect candidate for situations where shared data needs to be distributed to many clients. Businesses can leverage this feature to take advantage of Adobe managed peer-assisted networking to distribute data reliably to all the connected clients in their enterprise, reducing hardware costs and decreasing the reliance on centralized data centers.
Several new P2P topologies are also supported:
Managed data delivery using peer-assisted networking
RTMFP and Cirrus 2 enable you to build applications that take advantage of the peers within a group. Rather than pulling files from one server source, you can source files via the overlay network created by the group. A benefit to this is reducing the amount of bandwidth required to retrieve files from one particular host. Another benefit is the ability to deliver files to more peers simultaneously due to the increased bandwidth gained by having multiple peers to source data for delivery (see Figure 2).
Managed data delivery using peer-assisted networking
Figure 2. Managed data delivery using peer-assisted networking
In this scenario, businesses can take advantage of otherwise unused space available on the devices within their networks to store corporate documents in a highly available and redundant scenario. Also, thanks to the way the nodes in an Adobe-managed P2P cloud self-manage their topology, business managers don't need to worry about highly complicated configuration and maintenance to implement this solution, saving them money when it comes to deployment, development, and management.
Live application-level multicast
Utilizing live application-level multicast, businesses can leverage Adobe-managed P2P to host useful corporate webcasts such as "State of the Company" addresses, corporate newscasts, and other live events. All connected devices will establish a connection to the rendezvous service, which is used only to provide authentication and a directory of connected devices. From that point forward, all data will be routed through the P2P mesh as efficiently as possible (see Figure 3). The other benefit to this topology is that bandwidth is used more efficiently, since P2P peers will opt to retrieve content from peers that respond quickly, rather than from the publisher.
Application-level multicast
Figure 3. Application-level multicast
Distributed data storage
Rather than having to deploy a central database system, businesses can take advantage of Adobe-managed P2P to implement distributed hash tables (see Figure 4). Utilizing directed routing to build DHT applications, corporate knowledge-sharing can scale and even increase in availability and speed as the number of connected peers grow.
Distributed data storage
Figure 4. Distributed data storage
Often, businesses have implemented caching servers to store frequently used information locally to their networks. With a solution built on the Flash Platform and taking advantage of directed routing, businesses can decrease the need to deploy caching servers for particular use cases such as search tools, company directories, and other data directory applications.

Peer-assisted networking in Flash Player 10.1 with RTMFP

The new features in Flash player 10.1 significantly reduce the need for large server infrastructure and empower you to create highly scalable applications that make use of the distributed processing and storage that exists in your managed peer-assisted network. Also, thanks to the way that the technology has been implemented in Flash Player 10.1, the P2P mesh manages its own topology, meaning that your applications can survive the ephemeral nature of clients connected to a P2P group.
Following are some of the key items that you will use when building your P2P applications with Flash Player 10.1.
Cirrus 2: Connecting to the Rendezvous service
Before any P2P communication can take place, Flash Player 10.1 instances need to connect to the Adobe Cirrus service. At the moment, it's a beta service to be used for non-commercial applications, but future releases of Flash Media Server will also support this functionality for commercial applications. The service is considered a rendezvous service, and what that means is that each Flash Player instance can connect to it and utilize Cirrus to locate other Flash Player instances. Cirrus accomplishes this by translating the peer ID of the nodes in the mesh to network address/port combinations and forwarding connection requests from one peer to another. Another benefit to using the Cirrus service is that it has the ability to assist with UDP hole punching enabling the P2P mesh to traverse many NATs and firewalls. Before using Adobe Cirrus, you will need to acquire a developer key from Adobe Labs.
Note:P2P nodes can communicate with one another without using Cirrus. Accomplishing this requires the nodes to be on a Local Area Network, since connecting in this manner requires LAN discovery. This is a very small use case and would probably be worthwhile only on a restricted network.
To connect to the Adobe Cirrus service, you need to create a NetConnection. When you connect, you pass in a string representing the Adobe Cirrus URL and your developer key, as shown:
// Cirrus connect info private const SERVER:String = "rtmfp://p2p.rtmfp.net/"; private const DEVKEY:String = "{YOUR_DEVELOPER_KEY}"; // Used to connect to the Cirrus service private var _netConnection:NetConnection; _netConnection = new NetConnection(); // Listen for status info _netConnection.addEventListener( NetStatusEvent.NET_STATUS, onNetStatus ); // Connect to Cirrus using our unique URI _netConnection.connect( SERVER + DEVKEY );
As you can see, we added a listener to hear the NetStatusEvent.NET_STATUS events being dispatched off the NetConnection. If a successful connection is made to Cirrus, a NetStatusEvent.NET_STATUS will have its info.code property set to the string "NetConnection.Connect.Success".

Note: Currently there is no support for the NetConnection.call() method when using Cirrus. Any NetConnection.call() made will be ignored by Cirrus. We highly advise you not to use the NetConnection.call() method for any purpose when using RTMFP with Cirrus, as it will be detrimental to memory consumption on the client and have no functional effect.

Once a Flash Player instance has successfully connected to the Cirrus service, it will receive a peer ID that the Cirrus service can then use to match to the instance's IP address and port number when other Flash Player instances would like to communicate with it.
The key thing to note about Cirrus is it does not have the typical server-side features you would find in a fully featured server platform such as Flash Media Server, such as streaming, application logic, and shared objects. Instead, Cirrus is used solely for helping Flash Player instances find each other.
Also, with the new Cirrus 2 server channel and Flash Player 10.1, the Cirrus service can now also be used to help form self-managed P2P groups without the need for manual peer ID exchange. These self-managed P2P groups are new and incredibly powerful. They enable multiple Flash Player instances to communicate directly with one another in an efficient and powerful manner. The following sections discuss the new features used with these groups.
GroupSpecifier: creating a P2P group
The new class in Flash Player 10.1, flash.net.GroupSpecifier, is used to create and manage P2P groups. It is used first to generate a groupspec string that can be passed to NetStream and NetGroup. It is also used to manage the capabilities and security of the P2P group with which it is associated.
Instantiating a GroupSpecifier
To take advantage of peer-assisted networking and create P2P groups, you need a groupspec string to share between peers in a P2P group. One approach would be to generate a groupspec string in a separate Flash Platform application or on a future version of Flash Media Server. Once the string is generated, it's up to you how to pass that groupspec string to each P2P client. The benefit of this method is hiding the capabilities and group name from people viewing the source code in the P2P client application, along with offering a little bit more obscurity when it comes to creating authorizations for password-protected group publishing and posting.
The other method is to instantiate a GroupSpecifier class in each of your Flash Player instances. Using this method allows for a more automatic approach to connecting to a P2P group since there is no manual or external exchange of the groupspec string. This method is detailed in the following code:
private var _groupSpecifier:GroupSpecifier; _groupSpecifier = new GroupSpecifier("GROUP_NAME_STRING");
Group name strings should be unique; otherwise you run the risk of connecting to a pre-existing group. We recommend using a naming scheme such as reversed-domain notation. For instance, we use the following group name string in the sample code:


For two player instances to be eligible to connect to the same P2P group, the string that's passed into the GroupSpecifier constructor will need to match, along with the group capabilities mentioned next.
Setting group capabilities
Once you've instantiated a GroupSpecifier, you can use it to decide which capabilities the group will support, such as server channel, posting, directed routing, object replication, and multicast:
_groupSpecifier.multicastEnabled = true; _groupSpecifier.objectReplicationEnabled = true; _groupSpecifier.postingEnabled = true; _groupSpecifier.routingEnabled = true; // When set to "true", Cirrus can help clients find each other. _groupSpecifier.serverChannelEnabled = true; // Additional GroupSpecifier Options // When set to "true", the Flash Player instance will send // membership updates on a LAN to inform other LAN-connected group // neighbors of their participation. //_groupSpecifier.ipMulticastMemberUpdatesEnabled = true; // When set to "true", it will disable the Peer-assisted Networking // dialog and P2P connections with other group members. Useful // for pure IP-multicast scenarios. //_groupSpecifier.peerToPeerDisabled = true;
Keep these things in mind when setting group capabilities:
  • P2P groups are defined by both the group name string passed in while instantiating the GroupSpecifier and the capabilities that are enabled. If the group name matches, but the capabilities don't, then the Flash Player instances will be considered to be in different P2P groups.
  • If the GroupSpecifier's peerToPeerDisabled property is set to false (the default value), Flash Player will display a security settings dialog box when your application attempts to connect with the group. This dialog box is displayed to inform the user that the computer will participate in peer-assisted networking and give the user the option to disallow the action. Also, the user can choose to have Flash Player remember that peer-assisted networking is allowed for the domain, preventing this dialog box from showing up the next time the user accesses peer-assisted networking in the same domain.

Note: If your P2P application is built to take advantage of receiving multicast streams using pure IP multicast, then it is beneficial to suppress the peer-assisted networking dialog box and disable P2P connections between group members by setting peerToPeerDisabled to true.

Managing group security
When you create a group, you have the option to secure posting and publishing. This is done with the following API calls:
  • setPostingPassword( password:String=null, salt:String=null )
  • setPublishPassword( password:String=null, salt:String=null )
Once the passwords have been set, you will need to append them to the groupspec string when posting and publishing to the group.
Retrieving the groupspec string
The groupspec string is what's needed to create peer-assisted network connections with NetStream and the new NetGroup. When you instantiate your NetStream or NetGroup, you will need to pass in the groupspec string to indicate that these communications will be facilitated through the P2P group.
You have two choices when it comes to retrieving the groupspec string. The first is to retrieve the string without authorizations. There are two use cases for this. The first is when you want to post or publish to the group and posting and publishing are not password-protected. The second is when group posting or publishing is password-protected and you want to prevent the client from posting or publishing:
The second choice when retrieving the groupspec string is to retrieve the string along with the authorizations. This would be used when you need to post or publish to groups with password-protected posting or publishing:
Once you retrieve the groupspec string, you can start utilizing NetStream and NetGroup with peer-assisted networking.
NetStream: Application-level multicast
Using NetStream, you can take advantage of peer-assisted networking to deliver your multimedia streams and data in one-to-many or few-to-many scenarios without relying on a Flash Media Server infrastructure. This powerful functionality is handled mostly for you with RTMFP and Cirrus. It enables a complex mesh of users with push and pull data chunking for streaming efficiency with reduced latency and high scalability. This functionality automatically handles optimizing the delivery of the data chunks for audio and video by mapping what users and their closely connected neighbors have and routing the appropriate chunks to the users that need them and sharing bidirectionally.
Creating a peer-assisted NetStream
To create a peer-assisted NetStream, you first have to connect to Cirrus and then create a groupspec string. Once you've done that, you can simply instantiate your NetStream with the groupspec and add it to the Cirrus-connected NetConnection:
private var _outgoingStream:NetStream; // We create a stream in our net connection for P2P outgoing _outgoingStream = new NetStream( _netConnection, _groupSpec ); // We add a net status listener to the NetStream _outgoingStream.addEventListener( NetStatusEvent.NET_STATUS, onNetStatus );
When the group stream has connected—or in the case of an error, not connected—the NetConnection will dispatch a NetStatusEvent of type NET_STATUS. In the case of a successful connection, the event listener you assigned to the NetConnection will execute due to a NetStatusEvent with the info.code property set to NetStream.Connect.Success. If the stream had not connected, info.code would have been set to something else, such as NetStream.Connect.Failed.

Note: The main reason for success or failure is the user's accepting or denying peer-assisted networking in the aforementioned security settings dialog box.

Publishing and playing a peer-assisted NetStream
Publishing to a group for application-level multicasting is no different than publishing to Flash Media Server. To prevent errors while working with NetStream, you wait for the NetStream to indicate a successful connection by dispatching a NetStatusEvent with the info.code property set to NetStream.Connect.Success. After the connection has been established successfully, you retrieve and assign your microphone and camera to the instantiated NetStream, and then call the publish method and pass in a stream name:
var camera:Camera = Camera.getCamera(); var mic:Microphone = Microphone.getMicrophone(); _outgoingStream.attachAudio(mic); _outgoingStream.attachCamera(camera); _outgoingStream.publish( "P2PVideo" );
For the time being, the only way to create video when using RTMFP and Cirrus is the built-in video publishing capabilities of Flash Player, as seen in the previous code snippet. That means that, for now, application-level multicasting can be used only for user-generated content, which will be at a lower quality compared to video created with such tools as Flash Media Live Encoder.

Note: When accessing your camera and microphone via their respective methods:
getCamera( name:String = null )
getMicrophone( name:String = null )
the default device returned is usually acceptable. However, in some cases it will return an undesired device. For best results, provide user interaction–based selection on the Camera.names and Microphone.names arrays.

To play a stream being published to a peer-assisted network group, use the simple and standard NetStream instance play() method, passing at least the stream name that matches the publishing stream name:

Note: Currently, there is no support for the play2() method in Flash Player 10 or the dynamic streaming capabilities it offers in RTMFP and Cirrus. The play2() method on NetStream and the associated DynamicStreaming feature are applicable only to streams played via a NetConnection to Flash Media Server. To play multicast streams when participating in a RTMFP group, be sure to use only the play() method as shown here.

The advanced data management that provides all the power of application-level multicast is done automatically. However, more advanced users may be interested in the following properties and events:
  • multicastPushNeighborLimit
  • multicastWindowDuration
  • multicastRelayMarginDuration
  • multicastAvailabilityUpdatePeriod
  • multicastFetchPeriod
  • multicastAvailabilitySendToAll
  • multicastInfo

Note: The multicastInfo property is type NetStreamMulticastInfo. The NetStreamMulticastInfo class contains a wealth of Quality of Service (QoS) statistics that can be analyzed to determine how well the NetStream's RTMFP P2P and IP Multicast stream transport is running.

  • NetStream.MulticastStream.Reset
  • NetGroup.MulticastStream.PublishNotify
  • NetGroup.MulticastStream.UnpublishNotify
As with NetStream instances connected to Flash Media Server, RTMFP connections to groups also have support for the NetStream.send() method for sending smaller amounts data to all subscribers of the stream. This can be useful for sending additional metadata about the contents of the stream or information on how to display the stream to connected users of the group. However, it is not meant for larger scale interactive data distribution or multi-way communication. Using the new NetGroup post() feature would be best for that—which we discuss later in this article.

Note: Using NetStream.send() to pass data, such as metadata or messages, is useful in one-to-many data distribution, but because the data is ephemeral if users are not currently connected to the stream, they will not receive the data messages unless the data is republished after those clients connect. If this data needs to get to clients whether or not they are connected, you should use object replication when the data is sent.

NetGroup: Taking Flash Player P2P to the next level
NetGroup is a new class provided with the release of Flash Player 10.1. Getting to know this class would be to your benefit, since the bulk of the new peer-assisted networking features are accessed through this class. You can post data, replicate objects, perform directed routing, and even manage and collect statistics using NetGroup.
Connecting to a NetGroup
Once you've connected to Cirrus and used the GroupSpecifier class to create a groupspec string, you can use the NetGroup class to connect to a P2P group. The process is very similar to connecting to the group using NetStream:
private var _netGroup:NetGroup; // Creating a NetGroup instance _netGroup = new NetGroup( _netConnection, _groupSpec ); // Adding a net status listener _netGroup.addEventListener( NetStatusEvent.NET_STATUS, onNetGroupStatus );
Like the NetStream, the associated NetConnection will dispatch NetStatusEvent of type NET_STATUS. The info.code property will be set either to NetGroup.Connect.Success if it was successful or to NetGroup.Connect.Failed if it was not.
Accessing group properties
Once you have a connected NetGroup instance, you can start accessing some very useful informational properties. Here are a couple of highlights:
This property is based on the neighbor density in the numeric region, also called a group address, closest to the peer. As peers connect and disconnect from the mesh the estimatedMemberCount is not guaranteed to change. However, it often will increment and decrement, providing a rough estimate on the number of members in the P2P group.
This property returns an object of type NetGroupInfo. Access this property when you'd like to find out Quality of Service (QOS) statistics on the P2P group. This object contains a number of properties of type Number that represent the rate in bytes per second that the local node is currently getting when using NetGroup features such as object replication, posting, and routing.
Posting content
Although you can use NetStream.send() to send data messages and objects, the NetGroup class was optimized to transfer data in a many-to-many scenario. Moving forward, you should think of NetStream in a one-to-many or a few-to-many application-level multicast scenario. For the cases of many-to-many data transfers, such as a chat application, you should use the NetGroup post() method.
To utilize post(), you first make sure that you have a connected NetGroup. At that point you call the post() method on the NetGroup instance using the following syntax:
Notice that you are not limited to just string messages but are also able to send any type of AMF object using post(). When you post() you will receive back the messageID, and although the sending node will not receive an event, a NetStatusEvent will be dispatched off the NetGroup instance in the application at all of the other P2P nodes in the group. So, don't forget to add a listener on your NetGroup:
In the case of NetGroup's post(), the NetStatus event's info.code property will be set to NetGroup.Posting.Notify.

Note: With the NetGroup post() method, all messages must be unique; so if a user of the application continues to send the same message, there is a chance that the duplicate messages will not be propagated through the P2P mesh.

Directed routing
With Flash Player 10.1 peer-assisted networking, all peers within the mesh are not directly connected. This is a good thing, however, since a full mesh would not be conducive to a highly scalable P2P application. In Flash Player 10.1, the primary P2P topology is implemented as a ring to allow for full connectivity among peers. There are additional links created between peers to keep communication efficient and scalable (see Figure 5).
Flash Player 10.1 P2P topology
Flash Player 10.1 P2P topology is a fully connected, self-managed topology and very efficient and scalable. Within the mesh, each Flash Player instance has a list of neighbors that it can contact. Using these neighbors, the Flash Player instance can use NetGroup to route or direct messages to its neighbors.
Here are some of the directed routing capabilities:
  • Send a message to all neighbors:
  • Send a message to a neighbor or local node nearest the specified group address:
  • Send a message to a neighbor based on a send mode argument NEXT_DECREASING or NEXT_INCREASING as defined in the NetGroupSendMode class:
_netGroup.sendToNeighbor(message:Object, sendMode:String):String

Each of these methods returns a string, which contains the result of the routing request and returns one of the constants defined in the NetGroupSendResult class: SENT, ERROR, or NO_ROUTE. In addition, during a routing request, the NetGroup instance in the receiving node dispatches a NetStatusEvent of type NET_STATUS if it receives the message. In this case, the info.code property is set to NetGroup.SendTo.Notify.

This feature enables you to create distributed hash tables (DHTs) with the Flash Platform. DHTs are used with very well-known P2P applications and take full advantage of the scalability of a peer-assisted application.

Object replication

P2P is known for its ability to distribute data in chunks throughout all connected clients and survive the ephemeral nature of the clients with little impact. With the NetGroup class, you can now utilize object replication within Flash Player to distribute data throughout the connected peers in your P2P mesh. The concept is to store indexed objects, and each peer initially acquires a different set of chunks of the whole. Over time, through replication, every peer eventually acquires all chunks.

The other significant benefit of using object replication over the NetStream send() or NetGroup post() is that those methods use best-effort techniques to transfer objects from one peer to another. With NetGroup object replication, the data transport mechanism uses a fully reliable transfer method.

When implementing object replication via NetGroup, you will need to implement your own object replication store in ActionScript, since it is not done for you automatically. However, from that point forward, NetGroup provides many useful API features to assist you with replication requests.

Once you've decided how you'll implement your replication store, you then have the option to set the replication strategy of your group. You do this by setting the replicationStrategy property of the NetGroup class to one of the two constants defined in the NetGroupReplicationStrategy class:

  • LOWEST_FIRST: To get the lowest index objects first
  • RAREST_FIRST: To get the object that have the least amount of replicas first

From there, you can perform replication by utilizing the following NetGroup methods:

  • addHaveObjects(startIndex:Number, endIndex:Number):void
  • addWantObjects(startIndex:Number, endIndex:Number):void
  • denyRequestedObject(requestID:int):void
  • removeHaveObjects(startIndex:Number, endIndex:Number):void
  • removeWantObjects(startIndex:Number, endIndex:Number):void
  • writeRequestedObject(requestID:int, object:Object):void

Once you start utilizing these methods, you will listen for replication events dispatched by your NetGroup class when peer nodes want or have the objects that your node has or wants. In these cases, the NetGroup will dispatch NetStatusEvent.

When using addHaveObjects(), there may be other peer nodes that want the objects that your node has. In that case, the other nodes will make a request for data and NetGroup will dispatch a NetStatus event with its info.code property set to NetGroup.Replication.Request. When using addWantObjects(), there may be other nodes that have the objects your node wants. In that case, the other nodes will offer to provide those objects and NetGroup will dispatch a NetStatusEvent with its info.code property set to NetGroup.Replication.Fetch.SendNotify followed by another NetStatusEvent with its info.code property set to NetGroup.Replication.Fetch.Failed or NetGroup.Replication.Fetch.Result.

Object replication via the NetGroup rounds up the new features available in Flash Player 10.1 and is a great example of the potential that the Flash Platform brings to the table when considering P2P application.

Where to go from here

You should now be ready to start working with the new peer-assisted networking features in Adobe Flash Player 10.1 and Adobe Cirrus 2. Here are some references to help further your knowledge of these new and exciting features:

  • For more API information, refer to the Adobe documentation, specifically to classes in the flash.net package such as: GroupSpecifer, NetStream, NetGroup, and the other NetGroup-related classes.
  • For a very detailed, deep dive into the technical details on RTMFP and P2P on the Flash Platform, watch the recorded session by Matthew Kaufman at MAX 2009, P2P on the Flash Platform with RTMFP.
  • For some use cases and additional code examples on implementing RTMFP and P2P on the Flash Platform, watch the recorded session by Tom Krcha at MAX 2009, Social media experiences with Flash Media and RTMFP.

The future of user-based collaboration and network sharing is here, and it's up to the next generation of applications to see where it leads the world of P2P applications on the Flash Platform.