There has been a lot of great excitement around RTMFP (Real Time Media Flow Protocol), especially because of the peer to peer (P2P) communication that is enabled in Flash Player 10 beta. This is a natural time to speculate about what cool applications you will build with new technology, so I’d like to give you some more information for you to work with.

Since I have been frequently been asked about details on this, a frequently asked questions format somehow seemed appropriate ;). For those that want to start working with RTMFP, make sure to read to the end, there is a goody for you!

Does Flash Player 10 beta support Peer to Peer (P2P) communication?
Flash Player 10 beta has new methods on the NetConnection and NetStream objects that allow communication through peer connections that are managed by a future Adobe server technology. The server will maintain a list of potential peers that can be connected to. If the NetConnection to the server is lost or closed, any peer connection that was initiated through the same NetConnection will also be closed.

How will I make a P2P connection through Flash Player 10 beta?
Connections from a SWF through a future Adobe server release will be assigned a temporary unique ID that is infeasible to guess or forge. Other SWFs connected to the same server can subscribe to the streams and events from that ID once the broadcasting SWF agrees to the connection.

On the server level, these IDs can be mapped to application-specific information such as presence. For a chat application, the ID can be linked to the nickname the user gave when connecting to the application. While the end-user may select the person that they want to chat with, Flash Player will use the ID to establish the connection with that user.

What can I send through the P2P connection?
In a similar way that you would stream local microphone and webcam media up to a server, you will also be able to stream it directly to another Flash Player client that has connected as a peer.

Through NetStream.send you can also send data which is useful for shared experiences in real-time applications. Any data format can be sent through this method though there are size limitations to the packet which may make certain data types less useful.

How does the peer connection work?
RTMFP UDP packets are sent directly from one Flash Player to another. The server translates the peer IDs to network addresses, and also assists in setting up the connection if one or both ends is behind a Network Address Translation (NAT) device. If UDP is blocked by a firewall or if RTMFP is blocked through a configuration of mms.cfg, the peer connection will not go through.

Can I choose between UDP and TCP?
No, RTMFP is a UDP-based protocol while RTMP is a TCP-based protocol. You will automatically use UDP by calling the methods that work over RTMFP.

Will RTMFP enable massive file-sharing applications through Flash Player 10 beta?
No. Large-scale file-sharing network applications rely on the ability to read from and write to the hard drive constantly to only load parts of files into memory when needed. In Flash Player 10 beta you can load files from the desktop to the Flash Player runtime, but the file would need to be loaded manually by the end-user and remain in memory for the entire time the file would be needed. The drain on system resources would make this style of application impractical.

Can I get started with RTMFP now?
While the support for RTMFP is built in to Flash Player 10 beta, there is no publicly available server technology to manage the connection process. If you would like to be considered for access to private beta programs around RTMFP, please send an email to fmsprerelease@adobe.com