FMES4 benchmark / RTMFP fallback to other Server instance

RTMFP peer-to-peer connections don't put any load on the server once they're established. The server and the two peers have to do a little bit of work in the introduction process, but once that's done the FMS is out of the picture. The only ongoing overhead at the server for these clients is very light-weight periodic keep-alive pings. The keep-alive frequency is defined in the FMS Adaptor.xml config file; defaults should be fine and are in the neighborhood of a ping once every 15 to 20 seconds (depending on whether the client appears to be behind a NAT or not).

Also, because RTMFP is UDP based rather than TCP based, the FMS can accept large numbers of connections without requiring a socket handle per connection in the OS kernel. Without going into the weeds, this means that you can have thousands to tens of thousands of RTMFP client connections to a single FMS server on commodity hardware without issues.

For clients who can't establish a UDP-based RTMFP connection to the FMS (or are behind problematic NAT/firewall that interferes with introductions to prospective peers), you'll want to provide an application-level fall-back that uses the RTMP protocol and a common FMS that acts as a relay point between cooperating clients. So, I'd say yes, that's the right way to handle it.

Best,
Seth