May 23, 2006

Ask an FMS Guru #7: How can I playback more than one recorded streams in synchronization?

A good question, unfortunately no good answer :(

The question: How can I playback more than one recorded streams in synchronization?

The answer:

This is definitely something that has been requested a billion times to the FMS team. Hopefully they are working hard on getting this going. To put it in a short sentence, "you can't". It sucks..

But what you can do is try to start playing them both at the same time with a low buffer. Like .5 of a second or something. Then when they are playing, up the buffer a bit to keep things in line. While the videos are playing, you also can keep a watch on the time that the videos are at and if the difference get's too high, just pause one and let the other catch up.

This requires quite a bit of coding and calculation because you have to figure out how much is buffered, how long it took to buffer, the difference in times of the videos, if the videos are staggered that will add even more trouble.

It's not that it can't be done, progressively it would be reasonably easy, just preload lots :) Streaming is a bit hard as you have to always buffer. On the flip side, using seek() to get to a point in the stream is good because you don't need to preload that part of the video to start playing it.

So, in conclusion, it can be done I guess, but it's your best calculations that are going to run it. This kind of feature is not built into FMS.

Posted by Graeme at 10:58 PM | Comments (0)

Ask an FMS Guru #6: What's with ping(), and how do I use it?

Another FMS guru question :) Getting quite a few of these, sorry I've been a bit slow to respond.

Anyways...

The question: What's with client.ping(), and how do I use it?

The answer:

Well, I guess to start off, the question is in reality a bit more advanced than what I've wrote above, but more or less it's "what the heck do I do with ping() and why doesn't work as I expect for what I want to do".

So, the first thing I will start off with is what ping() is all about. Ping in the normal network world is used to find a node on a network and how long it takes to get there and back. These packets are sent at high priority so there is less delay etc. I'm not going into too much detail on this of course, but what I can say is that FMS's client.ping() on the server side is just about the same.

What is happening behind the scenes when you call ping() on the client is the server is sending out some packets to the client at a high priority. Higher than all the other data that could be going back and forth. If it gets a response, true comes back. Not quite the same as the "normal" ping that we all know and love, but more or less you are knocking on the door and seeing if somebody answers. ping() doesn't really care how long that takes.

So, the next part of this question is "what would you use this for?". Well, a lot of people want to use it to see if a client is alive on the server. Why would you use ping for that? Well, supposedly it's the fastest way to tell. You're probably wondering "compared to what?".

Which leads us to the next question, "why would you want to know if somebody was connected up to the server if the client object still exists?"

Aha! now that is the key question here I think. In FCS1.0 and 1.5 (throughout all the updates too) there was the problem of "ghost clients". These clients would sit in the application objects that the server had yet to figure out they are gone. There are a few reasons for this of course, there could be a stay-alive going on here, where a router or something is just keeping the connection there. There is also the problem with IE in where even if you close the window, the connection to the server stays open. You can even still be sending your video and audio to the application if you didn't close it first and just closed the browser window!! Imagine that! I heard a story about how one guy's connection stayed up for over an hour with his vid and aud being broadcasted to a chat. I'm sure there are other instances of this.. It gets solved by closing ALL of the browser windows you have open of IE. Odd bug.. not sure who to blame, I guess Microsoft.

There was also the problem in where if you were doing nothing on the application, the app would disconnect you, although you'd still be there.. it's a really weird problem and it sucked, so you had to make your own "stay-alive" code to keep users connected when there was no data going back and forth in the application. Some people used ping() in this instance.

So, what does this mean to a developer of FMS apps? Well, you need to know if users are actually there and if they are going to stay there when nothing is going on. In FMS2, I've actually yet to see the problem of the user getting disconnected when nothing is going on in the app. This is a good thing :) Nice to see it fixed. There are less instances of ghost users, but they are there, especially in busier applications.

What do you do? Do you use ping() to see if they are there? My answer is to suggest "no". The reason is that ping() can return true even when the client is no longer connected. The router or something in the middle actually returns that the client is there (I don't actually know exactly what is happening here, I do know that ping() will return true even though the client isn't there).

So, this makes ping() a bit crappy. My suggestion to solve not only the worry to make sure clients stay alive in the app, and also to check if they are there is to call a function in the SWF file.

This is reasonably simple because all you need to do is create a function on the netConnection object.

myNC = new NetConnection();

myNC.checkForOnline = function(){
return "yes, I'm still here";
}

Then on the server side you just call that on all clients every 30 seconds or so (this will depend on your app of course). If the call returns an error, or nothing, or the wrong string then you know that either the client is not there or is a rogue user that has connected up to your application. The good side effect here is that you are adding a bit of security to your application. Security is always good :) Once you have discovered that the call failed or returned no string or the wrong string, you disconnect them and delete the client object.

That's about it. All about ping() and why it's not really that beneficial to use it :)

Posted by Graeme at 10:46 PM | Comments (0)

May 10, 2006

Ask an FMS Guru #5: How do I test the server after a fresh install of FMS2?

So here we are with another question about FMS that can hopefully be answered below :)

The question: How do I test the server after a fresh install of FMS2?

The answer:
OK, so you've installed the server, whether it's windows or linux it doesn't really matter at this point, and you want to see if it's working. The first step is to find your way to the applications directory. If you installed by default, then this will be in the install directory. As a best practice though, I recommend moving it to a different drive than the boot drive, as it's not much different than a web server in a way that you will be placing lots of files in there and also making video/audio and data files that could potentially take up a lot of space.

So, the server is installed, the service is running and you can login to the admin console that comes with it. You're in the applications directory, so go ahead and create a directory called "myfirstapp". Notice that I have kept the application name all lowercase. If you're on a Windows server it doesn't matter, but for linux it's important which case you have the letters in when you try to connect up to it from a SWF. It's just easier and a better practice to keep it all lowercase.

Anyways, you've created the application folder in the applications directory. This now allows you to connect up to the server to this specific application. You'll do this with the following script in an FLA.

We'll do this in AS2 because it's also a good practice. Copy and paste if you want:

//create the net connection object
var nc:NetConnection = new NetConnection();

//set up the onStatus information object so we can see what is happening
nc.onStatus = function(info){
//trace the code object in the information object that is passed into the onStatus event
trace(info.code);
}

//connect up to the server. Put in your own IP address for your server in place of the IP number below. Or the domain name of the server
nc.connect("rtmp://111.111.111.111/myfirstapp/first_instance");

If all is well, the trace should return back in the output panel in flash that there was success.

If not, and this is the part that isn't documented so well in some places, then you need to debug what is happening. The first place to start is the onStatus event. If you get back that the connection was rejected, the first place to look is the application name that you put in the connect method. If that application does not exist on the server, as you created in the applications directory, then the server will automatically reject the connection. If it just fails then there are a couple of other items to look at. The first would be to make sure that the port is open that the server is trying to connect up on.

FMS by default uses port 1935. You can set it up to use any port really, but it's best to use port 80 (works out of the box with no web server on the same machine) and port 443 because a lot of firewalls won't block this port either so it has a high rate of success for connection. If you are sure the service is running, don't have the port blocked on the server or client side, then the next step would be to force the flash player to connect up over a specific port to see if it works. something like this:

nc.connect("rtmp://111.111.111.111:1935/myfirstapp/first_instance");

As you can see, I added :1935 on the end of the IP number. Just put in the port that you want to connect up on and are sure the server is listening on.

Now, on a quick side note that was also sent in the email, there is a way to create instances for applications from the admin panel. This is especially useful if you have code that needs to run on the server side before anybody connects up. Perhaps an initialization piece or a timer of some sorts. If you don't have an ASC files in the application directory, you might find this feature a bit useless and it may seem like it does nothing. It's doing something, but all it's doing is starting an instance of an application and running it. There aren't any connections to it and no code is running. By connecting up from an SWF file, you are doing the same thing really and the server will automatically create that instance for you. There aren't too many reasons why you would want to create an instance of an application before anybody connects up to it, but there are a few I guess.

That's about it for now I think. Hopefully that answers the question on how to figure out if the server is working as it should or not :)

Posted by Graeme at 01:32 PM | Comments (0)

May 05, 2006

Had to take some time off for a bit..

Just wanted to quickly note on here that it's not like I've been ignoring this blog or any of the forums etc I generally visit, but with the combination of a rather large family tragedy and before that insanely busy work, it's been tough to get some good online time.

That should change from here on as things have settled down and there is a pattern forming once again which should get me back in the action.

First up will actually be an "Ask an FMS guru" question and answer, and then a quick posting on a new site we put together a month or so ago that turned out amazing. Of course it runs on FMS2.0 :)

Thanks for reading.

Posted by Graeme at 02:10 AM | Comments (0)