2 Replies Latest reply on Dec 9, 2010 11:38 PM by Michael Thornburgh

    Cirrus RTMFP traffic. Why?




      I've created a simple videochat app and have noticed there is some small traffic between a client machine and the Cirrus server. If it is P2P, why does app need to be connected to Cirrus during video call? What kind of data are transfered between the Cirrus and a client machine? I've tried to disable access to the Cirrus during a test video call and connection dropped. I thought the Cirrus is necessary only for the first time to connect clients, and its job is done. But my understanding of these things seems wrong. Could someone please explain how actually it works?


      Thank you.

        • 1. Re: Cirrus RTMFP traffic. Why?

          I'm just guessing here but there might be a couple of reasons.

          1. RTMFP protocol maintains a connection in case it needs to reestablish a connection (e.g. switching network interface from wired to wifi networks)
          2. RTMFP requires a connection to handle group connections and also when new peers join the network the "host" needs to be connected to start the P2P rendevous
          3. Adobe wants to control the usage of their P2P technology (Cirrus is beta and not to be used for commercial products so maybe they're using it as a "backdoor" to manage that access)
          1 person found this helpful
          • 2. Re: Cirrus RTMFP traffic. Why?
            Michael Thornburgh Adobe Employee

            the traffic you're seeing between you and Cirrus is just keepalive pings, which keep any NAT/firewall translations/holes open and fresh.  this mechanism can also signal your application if (for whatever reason) your connection to the server is abruptly lost.  the keepalive mechanism is also leveraged to help Cirrus notice any IP address change your client might have (example: switching from wireless to wired) in a timely manner.


            your connection to the server must be kept up in order to make the semantics of the API and networking model make sense.  your peerID is only reachable with help from your server.  the NetConnection is where your RTMFP endpoint lives, and NetStreams and NetGroups operate over/within it.  closing the NetConnection destroys the network endpoint, so any resources using it must also be destroyed.  additionally, exactly the same thing happens if you close an RTMP NetConnection; we decided that maintaining consistency would make the most sense to developers.