Matthew Kaufman Future Of Communication With Rtmfp Final Revised

24,249 views
24,152 views

Published on

Presentation by Matthew Kaufman of Adobe from MAX North America 2008.

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
24,249
On SlideShare
0
From Embeds
0
Number of Embeds
3,379
Actions
Shares
0
Downloads
107
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

Matthew Kaufman Future Of Communication With Rtmfp Final Revised

  1. 1. Future of Communication with RTMFP Matthew Kaufman 17 November 2008 ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  2. 2. Introduction  Who  Matthew Kaufman  Background: software + Internet  Joined Adobe in 2006 from amicima  What  RTMFP  Secure Real-Time Media Flow Protocol ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  3. 3. Background: RTMP  How the Flash Player talks to Flash Media Server  TCP/IP  NetConnection / NetStream classes  Audio, Video, Shared Objects, Call, Send  Flash Media Server streams or relays media, runs server-side applications  Streaming of pre-recorded content  Audio/Video playback (with seeking) Flash  Real-time Communication Media Server  Audio/Video communication  Microphone / Camera classes  One-to-many or one-to-one Flash Flash Player Player ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  4. 4. Background: RTMP flavors  RTMP  TCP (typically on port 1935)  RTMPT  “Tunneled”  Encapsulated in HTTP requests  RTMPS  RTMPT-over-HTTPS  SSL for security  RTMPE  RTMP plus lighter-weight encryption for stream protection  RTMPTE  RTMPE-over-HTTP ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  5. 5. Background: RTMP Limitations  Based on TCP  Reliable (lossless) in-order stream of bytes  Retransmission when there is loss (and delivery is held)  Unavoidable latency  Allows for (relatively) simple RTMP protocol stack above TCP layer  Client-Server only  TCP and direct peer-to-peer connections not compatible with NAT  Other interesting things also impossible ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  6. 6. RTMFP: Introduction  Based on UDP  Allows direct access to what is received and transmitted at the packet level  Compatible with NAT and Firewall devices  Sophisticated network protocol stack on top of UDP  Rapid session establishment (2 RTT)  anti-DOS and anti-port-scanning protection, client-side load balancing  Multiple parallel media flows of messages  Prioritized  Variable reliability (full TCP-like, partial, none) controls retransmission  In-order or as-received delivery at receiver  TCP-friendly congestion control with variable congestion response (backoff)  Congestion avoidance by 3rd-party sessions  Integrated NAT traversal for peer-to-peer applications (“parallel-open” capability)  IP address mobility (session stays up if address changes)  Fast recovery from brief outages ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  7. 7. RTMFP: Security  RTMFP is secured at the protocol level  Security “plugs in” to the protocol stack implementation, Flash Media uses a specific plug-in  Every packet encrypted with block cipher  AES-128 for Flash Media  New block cipher key negotiated in first two round trips  Diffie-Hellman key exchange (static-static or ephemeral-static keys) for Flash Media  SSL-like authentication (e.g., RSA signing) is supported at connection establishment  Not used for Flash Media at this time  Secure nonce exchange  Values chosen by each party, protected against MITM tampering  Saves round trips when implementing upper-layer security (authentication, continuity)  Developers have access at ActionScript level  Secure peer IDs (infeasible to guess or forge), nearNonce and farNonce properties ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  8. 8. Using RTMFP with FMS  Minimal changes for developer  Substitute “rtmfp://” for “rtmp://” when connecting to FMS  Use Flash Player 10.0 or later, AIR 1.5 or later with a (future) RTMFP-capable FMS  Everything works the same except:  Live (unbuffered) Speex audio will be sent with partial reliability for lower latency  Plus all other advantages of RTMFP  Encryption  Mobility Flash  etc. Media Server Flash Flash Player Player ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  9. 9. RTMFP and Firewalls  RTMP and RTMPE requires TCP port 1935  RTMPT and RTMPTE uses TCP port 80 (HTTP)  RTMPS uses TCP port 443 (HTTPS)  RTMFP is more complicated  UDP port 1935 to establish connection  Multiple high UDP ports (one per FMS application core)  Does have NAT/Firewall traversal (additional ports used will be initiated from inside)  Can use an IT-provided TURN proxy (manually configured)  RTMFP has no tunneled counterpart, must fall back to RTMP ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  10. 10. Demo: RTMFP and FMS Demo ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  11. 11. RTMFP: Direct Peer-to-Peer Communication  Two use cases for real-time communication  One-to-many  One-to-one  Both have scaling issues for popular services  Direct peer-to-peer communication addresses the one-to-one case  Or one-to-few  Media bypasses FMS and travels directly between Flash Players / AIR  Uses RTMFP’s NAT/Firewall traversal capability and FMS to “introduce”  Lower latency  (Almost) No media load on server  Better scalability  Server still available to relay if firewall blocks or RTMFP connection cannot be made ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  12. 12. RTMFP: Direct P2P Communication – How it works  Flash Media Server introduces peers  ActionScript API talks only about Peer IDs, never IP addresses  FMS gives the originating peer one or more IP addresses for destination  FMS tells destination peer that originating peer is attempting contact  NAT traversal  Destination peer can respond as result of originator’s packet(s) or FMS message  “UDP hole punching” Flash Media Server  IP mobility helps establish in certain NAT configurations, maintain if NAT mapping changes  Not all NAT-NAT combinations work Flash Flash Player Player ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  13. 13. Using RTMFP Direct Peer-to-Peer Communication  API Changes  Peer IDs  Available from the NetConnection and Client objects  Must exchange via FMS or other means (web service, XMPP, etc.)  Slight modification to publishing and subscribing API  To publish nc = new NetConnection(); nc.connect(“rtmfp://my.fms/application”); ns = new NetStream(nc, NetStream.DIRECT_CONNECTIONS); ns.publish(“streamName”);  To play nc = new NetConnection(); nc.connect(“rtmfp://my.fms/application”); ns = new NetStream(nc, <peerID of publishing peer>); ns.play(“streamName”); ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  14. 14. Demo: RTMFP Direct Communication Demo ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  15. 15. Using RTMFP: NetConnection API  NetConnection  farID  farNonce  maxPeerConnections  nearID  nearNonce  Protocol  unconnectedPeerStreams array ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  16. 16. Using RTMFP: NetStream API  NetStream  New constructor (NetStream.DIRECT_CONNECTIONS or peerID as second argument)  farID  farNonce  nearNonce  peerStreams array  onPeerConnect() ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  17. 17. Adobe Stratus  Stratus is a (Beta) hosted rendezvous service for RTMFP  For any 1:1 or 1:few audio/video application that does not require FMS  No recording  No FMS application logic  No FMS shared objects  Requires external web service to exchange Peer IDs  To use Stratus  Open NetConnection to Stratus Stratus rtmfp://stratus.adobe.com/<dev-key>/<app-name>  Exchange Peer IDs  Open direct peer-to-peer NetStreams  More info on labs.adobe.com Flash Flash Player Player ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  18. 18. Future Possibilities  Flash Player 10.0 and AIR 1.5 are just the first step  RTMFP protocol stack as foundation  Use peer-to-peer technology for the one-to-many cases  “Groups”  A dynamic, self-organizing overlay network of RTMFP peers  Full transitive connectivity with only O(log n) sessions between peers  Described by a “Groupspec”  Application-Level Multicast  Send a stream to all members of a group (multiple senders supported)  Use Groupspec (instead of peerID) when constructing a NetStream  Posting  Directed routing ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.
  19. 19. End Don’t miss the Sneak Peeks ® Copyright 2008 Adobe Systems Incorporated. All rights reserved.

×