1 person found this helpful
the peerID does not contain any network address information about the peer. it is a cryptographic hash (based on its length you can probably guess which one) of the cryptographic credentials that peers use to talk to each other. the nature of the cryptographic credentials and handshakes used by peers makes the peerIDs unique and unforgeable.
an RTMFP server such as Stratus translates, at the RTMFP level (invisible to ActionScript) peerIDs to network addresses (one or more IP address and UDP port number pairs), and also performs an introduction step for NAT/firewall traversal (so the destination peer can do "UDP hole punching" to create a return path for the originating peer).
there are several practical reasons why a peer remains connected to Stratus after a P2P conversation has started. among them:
1) to receive introductions for NAT/firewall hole punching for new peers wishing to communicate
2) (re)connecting to the server is expensive, in cryptographic operations, vs the relatively light load of managing/maintaining the state of a quiescent connection. memory is cheaper than CPU.
3) it is more efficient to rely on the RTMFP session semantics and low-level keepalives to maintain registration state vs explicitly refreshing registrations periodically (à la SIP)
4) IP address changes can be recognized earlier and automatically accounted for in the registration information
note that the load we have been seeing recently would have been significantly worse with intermittent connections, as the load was caused by peerID lookups, not concurrent users or connection churn.
Thank you, makes it all much clearer now. Certainly having a central server assist clients, with hole punching for instance, is a good decision.