Updating NCManager order of Connection Attempts

January 30, 2008 at 23:18 · Filed under Streaming

I’ve been working a lot lately with Akamai for streaming content. Minus many problems I’ve encountered, and having to write an AS3 AkamaiNCManager class. It’s pretty straight forward.

For a quick background on the what I’m going to show you – checkout the FLVPlayback documentation and look at the ncMgr property. Then read about the INCManager and NCManager. If you read the source code of the NCManager class, it’s pretty straightforward, and you can see that attempts to connect to your streaming application are made numerous times, first to port 1935, then to port 443, then to port 80 over RTMPT (http tunneling), then to port 443, over RTMPS.

That’s quite a few connection attempts to go through, which can cause delays in streams playing. Generally it’s not really a big deal. But in this case – a pretty serious application, I don’t want my apps attempting all of those, or just in that order.

Preferably I’d rather have it first check RTMPT over port 80, because port 80 is always open. Then check port 1935, then 443. It was pretty straight forward after diving into it a bit. I thought I’d share how to re-order the way that the NetConnection’s are attempted in the default NCManager class.

First thing, we need to update the AS3 source NCManager class. Find that source file, and open it up. There is a variable declared like so:


//ORIGINAL:
flvplayback_internal static const RTMP_CONN:Array = [
{ protocol: "rtmp:/", port:"1935" }
,{ protocol: "rtmp:/", port:"443" }
,{ protocol: "rtmpt:/", port:"80" }
,{ protocol: "rtmps:/", port:"443" }
];

//UPDATED:
flvplayback_internal static var RTMP_CONN:Array = [
{ protocol: "rtmp:/", port:"1935" }
,{ protocol: "rtmp:/", port:"443" }
,{ protocol: "rtmpt:/", port:"80" }
,{ protocol: "rtmps:/", port:"443" }
];

All I did here is update it so that it’s not constant, it’s now a var. Note that instead of changing the value of the variable in your class, just change it from const to var. So that in other flash applications, you don’t inherit something in the AS3 codebase you forgot about.

So now to update the variable:

package
{

  use namespace flvplayback_internal;

  public class MySomething
  {
     public function MySomething()
     {
         //change the values.
         NCManager.flvplayback_internal::RTMP_CONN = [
           {protocol: "rtmpt:/", port:"80" },
           {protocol: "rtmp:/", port:"1935"},
           {protocol: "rtmp:/", port:"443"}
         ]
     }
  }
}

Now you can successfully change the order of connection attempts.

CarnageBlood said,

January 31, 2008 @ 06:40

Sorry to bother you but where can I find a tutorial or some documentation about ClassMaping and ValueObject in RubyAMF RAils. In a controller PeopleController i have : format.amf { render :amf => @people } where @people = Person.find(:all).
In my Flash app the ResultEvent returns a Object type and i can’t get the data i need.
I know i have to edit the rubyamf_config.rb but dunno how.
I need some documentation or tut to get started as I am noob both in Rails and RubyAMF.
Please help and again sorry for disturbing!

David B. said,

January 31, 2008 @ 07:21

I would suggest using RTMPT only has a fallback method since RTMP is more efficient than RTMPT.

In fact, the default order is pretty logic in my sense. It first attempts an RTMP connection on port 1935. This makes sense since port 1935 is the default port assigned to FMS and since RTMP is more efficient than RTMPT.

Second, an attempt is made on port 443 in case port 1935 is blocked. This will sometimes happen in companies (though this is less and less frequent all the time). So an RTMP conenction that can’t go through port 1935 might go through port 443 if RTMP traffic is allowed on that port. And that port is open for sure.

Then, if all else fails, we fallback on port 80 (which we know is open) using RTMPT streaming. This is less efficient than RTMP but, when used that way, will almost always go through unless there is a packet sniffer that detects that this is in fact RTMP packets wrapped inside regular HTTP packets. This will almost never happen. To do this, a network administrator means he REALLY WANTS to block all RTMP traffic on his network.

Just my 2 cents…

aaron said,

January 31, 2008 @ 12:33

@carnageBlood,

hey no worries. I’ll reply to your post on the mailing list later today.

-A

aaron said,

January 31, 2008 @ 12:45

@David,

Yeah I see your point. I guess I’ll be a little bit smarter about it. If the users’ bandwidth is medium or low, default to 1935,443,80, etc. But if they’re on a high speed connection, use rtmpt because it will always go through. Really what I’m trying to accomplish is getting a connection as soon as possible to the stream. Which I think happens altering the order this way. And I guess overall it’s not something that’s “critical”, but I’d rather know that port 80 is always open, and should connect the first attempt.

Do you have any insights into how much less efficient it is?

Thanks man.

RSS feed for comments on this post · TrackBack URI

Leave a Comment