2 Replies Latest reply on Mar 11, 2011 1:40 AM by amoywolfxm

    life cycle of Cirrus server peer id


      After netConnection.connect to Cirrus server and get a nearID, is there life cycle (or session timeout) for this peer id?


      My scenario is, when one member on my web site has a Cirrus peer id at the begining, he can video chat with others. Then, next time when he logs into my web site again, is his  previous peer id available, or he has to get a new peer id?



        • 1. Re: life cycle of Cirrus server peer id
          Michael Thornburgh Adobe Employee

          the peerID persists for the duration of the connected NetConnection.  as soon as it disconnects, the peerID is destroyed and is never re-used.  this is a feature.


          the peerID is derived in part from (Diffie-Hellman) cryptographic key information that's used to encrypt RTMFP communications with the server and other peers.  the relationship of the peerID to the cryptographic keying information makes the peerID unforgeable (you can pretend to have someone else's peerID, but you can't have successful RTMFP communications with anyone else unless you possess the secret private key that goes with the Diffie-Hellman public key).  the Diffie-Hellman private key is randomly chosen for each NetConnection.connect() and destroyed when the NetConnection is closed.

          1 person found this helpful
          • 2. Re: life cycle of Cirrus server peer id
            amoywolfxm Level 1

            Hi Michael,


            Thanks for your quick reply. Now I understand that both peers must have connected to Cirrus server and got peer ids before they can chat to each other.


            I purpose to add a simple IM to integrate with P2P chat application on my web site. The scenario is,


            1) assuming that both member A and B have logged in and surf on the web site.

            2) B clicks on A's icon to send a P2P chat invitation to A.

            3) No matter what web page on which A  is visiting, A should get the invitation immediately.

            4) If A accepts,  both A and B will be forwarded to the rtfmp P2P chat page to start the  chat.


            This simple IM can be implemented by AJAX to enquery a web service page periodly (e.g. every 1 seconds), but it's not a good solution, consuming more bandwidth and web server resource. So I am wondering if there is any solution by using rtfmp technology, but has no idea yet.


            Any advice from you would be greatly appreciated.