1 Reply Latest reply on Jun 10, 2009 1:08 AM by Michael Thornburgh

    Why must stay connected to Stratus during the p2p session timelife?


      It says this in a documentation.


      "Flash Player endpoints must stay             connected to Adobe Stratus during the entire time of communication. In order             to access Stratus, you will need a developer key that is generated when you             create your Adobe Developer ID."


      I know basic details of NAT and firewall terminology, altought not an expert. In order two peers able to send directly data we must find out UDP addr:port being used. Most home office (A)DSL NAT routers map incoming UDP packets to the internal client, only if client machine had sent udp packet through that external addr:port.


      Client1 sends packet to dAddr1:port7 destination server, this opens up an active translation through NAT router. Internal address (192.*) is mapped to external address that is visible to the outside world.

         client1 UDP iAddr1:port1  ->  NAT eAddr1:port6  ->  dest1 dAddr1:port7


      Server cand send packets to eAddr1:port6 address which is internally routed to the originating client1.

         client1 UDP iAddr1:port1  <-  NAT eAddr1:port6  <-  dest1


      Peer-to-peer enabled NATs allow _any host_ to send packets to eAddr1:port6 address. Only requirement was client1 had sent first packet to some server activating this way a translation pipe.


      My Stratus related questions:

      What is Stratus server actually doing and why must stay connected to Stratus server after a valid P2P end-to-end connection is established. p2p connection should work fine after it was established?


      Is Stratus a sort of eAddr* sharing database, clients send first packet to Stratus so enabling an active translation, Stratus stores an external addr:port and share it to other parties, parties can lookup eAddr* and use it for direct connections?

        • 1. Re: Why must stay connected to Stratus during the p2p session timelife?
          Michael Thornburgh Adobe Employee

          P2P connections happen in the context of a NetStream, which is connected to a NetConnection.  for traditional client-server NetStreams, if the controlling NetConnection closes, the NetStreams must also close.  for Flash Player 10, we wanted to maintain as much of the programming paradigm and semantics as possible for the new P2P connections.  while it would have been technically possible to continue P2P NetStreams after the controlling NetConnection was closed, we felt that that behavior would have been too drastic a departure from the previously-understood operation of NetStreams and NetConnections, and would have complicated the programming model.  additionally, properties of your connection, such as your peerID, belong to the NetConnection, and allowing the peerID to continue beyond the life of the NetConnection's connection to a server (and especially allowing the same peerID to be re-used if you connected to a new server or reconnected to the old one) could compromise the strong uniqueness property that peerIDs have.


          for purposes of peer-to-peer connections, an RTMFP server such as Stratus acts as a kind of name service and UDP hole punch helper for NAT traversal.  specifically, it translates a peerID to one or more IP address+port for all of your directly attached network interfaces (IPv4 and IPv6), your NAT-translated address, and (if configured) your TURN proxy address, and forwards introduction packets to a destination peer to cause it to send UDP traffic toward the source peer (UDP hole punching).  the RTMFP source peer then tries all available paths (directly connected interfaces, translated address, TURN proxy address, and UDP punched-hole) in parallel to try to bring up the best possible P2P session.