This content has been marked as final. Show 2 replies
in the "connection dropping for a moment" case, RTMFP caps retransmission timers to values reasonable for real-time communications, so when connectivity is restored, it doesn't take as long as TCP potentially would to notice. combined with partially reliable transmission of audio (when using Speex live and unbuffered), backlogs of data during the connectivity outage can be discarded, making your communication resume more quickly and keeping it more timely.
in addition, in many cases RTMFP can keep a session up when one end changes IP addresses. this can happen in many normal circumstances, such as when you switch from a wireless connection to wired, or if a wireless base station (or other NAT device) restarts or times out your translation, or if you are moving between wireless base stations connected to different networks or providers. in this case, the session never goes down, so your nearID doesn't change and there is no reconnection. at the current time, there are no events to tell you that this has happened. the IP address mobility function can't always recover a session (typically when certain kinds of firewalls or NATs are in the middle), but it can recover in many cases, and in way more than the zero cases that TCP handles. :)
to clarify about IP address mobility: an RTMFP connection to a server (such as Adobe Stratus) will almost certainly survive any address change, but peer-to-peer connections may not always survive depending on the NATs and firewalls between the peers.
also, only one end of an RTMFP session can change its address at a time. if both ends change addresses simultaneously, neither will be able to find the other anymore. however, both ends should still retain their connections to the server, so they would be able to re-establish their peer-to-peer connection again after the original one times out.