Its interesting to see how Adobe has been evolving the protocols required for collaborative apps. In recent years Real Time Messaging Protocol (RTMP) has dominated live content delivery product markets. Flash Media Server and other open source media servers relied on RTMP for streaming audio and video content, and also to create collaborative apps. But there was a constraint while using RTMP protocol for collaborative apps, all clients involved in the conversation had to fetch feeds from the streaming server, they couldn’t directly connect to each other to interact. The answer to this concern again came out from Adobe, they released the Real Time Media Flow Protocol (RTMFP) specification for Peer to Peer communication (P2P).

As I was discussing with my team at office today about collaborative apps, and when I asked “Does someone know here about RTMFP ?”, SOMEONE popped up “Its an upcoming extension to the RTMP protocol”. I had to hold on and say “Vinay I don’t think its an extension to RTMP but instead its a communication standard for a whole different breed of apps”. So after getting back to home, I thought it would be interesting if I could put up a blog post that differentiates out RTMP and RTMFP. So here is what I feel are the differences :

1. Looking at the specifications of RTMP and RTMFP (as they are open source now), the first observation is in the underlying transport layer protocols that RTMP and RTMFP use. RTMP uses the Transmission Control Protocol (TCP), where as the RTMFP uses the User Datagram Protocol (UDP). With the above highlight, it would be necessary to look at TCP and UDP to understand the what RTMP and RTMFP offers.

As we know TCP is the most commonly used protocol on the Internet. The reason for this is because TCP offers error correction. When the TCP protocol is used there is a “guaranteed delivery.” This is due largely in part to a method called “flow control.” Flow control determines when data needs to be re-sent, and stops the flow of data until previous packets are successfully transferred. This works because if a packet of data is sent, a collision may occur. When this happens, the client re-requests the packet from the server until the whole packet is complete and is identical to its original.

On other side UDP (User Datagram Protocol) is another commonly used protocol on the Internet. However, UDP is never used to send important data such as webpages, database information, etc; UDP is commonly used for streaming audio and video. Streaming media such as Windows Media audio files (.WMA) , Real Player (.RM), and others use UDP because it offers speed! The reason UDP is faster than TCP is because there is no form of flow control or error correction. The data sent over the Internet is affected by collisions, and errors will be present. Remember that UDP is only concerned with speed. This is the main reason why streaming media is not high quality.

Well if UDP is not suitable for streaming media, then why is chosen for RTMFP ? To answer this lets look at a scenario, if I am gonna use the TCP protocol for streaming audio and during transmission a 300ms audio was lost, then as per the mechanism, the media server will reinitiate the streaming from start. This would get painful if each time some data is lost. This is reason why UDP is used, even if I loose the 300ms audio, the gap is not that large that I have to start over again, so the drop packets are compromised and I get the whole data packet.

2. Communication model when using RTMP and RTMFP is different, when using RTMP, clients when needed to interact with each other has to route messages through the Flash Media Server, which means that a direct connection between the user’s flash players cannot be made. But with RTMFP the scenario is different, because the protocol has been designed to build collaborative apps, Adobe made it possible for individual Flash Player clients to connect with each other and pass messages while maintaining the session with the media server or the Adobe Stratus service. Below figures, illustrate the two different communication models.

RTMFP Communication Model

RTMFP Communication Model

RTMP Communication Model

RTMP Communication Model

3. Bandwidth consumption is much better when using RTMFP as it avoids much of the client-server communication for inter-client communications as it prevails in the RTMP implementation.

4. Security and firewall restrictions are always part of the application design considerations, RTMFP fails to impress at this point, because most of the firewalls implemented in corporates are not UDP port friendly. So when RTMFP and RTMP are to be considered, the implementation considerations are always different for both the protocols.

5. RTMFP cannot be used for broadcasting high quality live video or swarming, it can only connect and stream live audio and webcam, whereas the RTMP can be used to stream high quality video, audio and webcam (from different sources).

In coming time the RTMFP protocol, I feel would evolve the way P2P or C2C applications are built using a common communication framework.


One Comment on “Comparing RTMP and RTMFP protocols”

You can track this conversation through its atom feed.

  1. Developing a Chat Application with Adobe Stratus | The Pixel Code says:

    [...] continuation to my previous blog,I was eager to test the Adobe Stratus service. Unlike Adobe Flash Collaboration Service (AFCS) aka [...]

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>