mx.video.NCManager.nextConnect quirk

For those who aren’t aware, mx.video.NCManager is a class that is used by Flash’s FLVPlayback component. It’s a “chunky monkey” class in that it does everything under the sun including things that have nothing to do with it’s title, but at it’s core it manages connections to videos. With this management, it abstracts the love/hate relationship of connecting to an FMS server for streaming videos, which requires trying various protocols and ports.

You see, connecting to FMS is different than making a simple HTTP request. Since it is typically not a port 80 request and it is persistent, various factors can cause it to fail. The most often reason being a firewall. NCManager automagically handles this by cycling through all the port (443, 1935, 80) and protocol (rtmp, rtmpt, rtmps) combos attempting to create a successful and efficient connection.

The quirk that I speak of exists in the NCManager’s nextConnect method. The class cycles through the list of possible protocl/port connections in a defined sequence. However, it doesn’t take into account that if for some reason your default url used a protocol/port combo that is further in the sequence say rtmp over port 443 and it failed. In this case, it would try the 443 connection twice and never try 1935 (1935 preceds 443 in the sequence). This is because it doesn’t acknowledge that the first attempt was out of order and then reshuffle the potential connections before iterating through them. One might make the assumption that if you are passing it a url consisting of a port/protocol url further in the sequence that you are specifically saying the combos above it are not possible. However, that is an assumption. Even with that assumption, if you have a failure you are making a second call that wastes resources.

As I mentioned, I labeled this as a quirk since the method works, but it works incorrectly in rare instances.