Flash Media Server Woes

We use the Flash Media Server 2 (FMS) to provide some of the following functionalities; Shoutbox, Instant Chat, Streaming Video, Strategy Whiteboards.



These features really allow a user to engage a user instantly and we owe it to the FMS server.

but

We purchased the FMS server last April, and as start-up, paying the $4500.00 USD + server expense was a needed but costly move. Recently we've been having a few occasional and random disconnects from users who are connected to our FMS. Let me state the problem in one breath/run-on-sentence: our user authentication is built on such a way that it reads the FMS, to see if a user is logged in, if he doesn't have an FMS connection he gets logged out, if he gets logged out we currently don't have a way to shift him back to the last viewed page since it's a flash site. So after research, it appears that one of the bugs in the FMS 2 server is random disconnects. The logical solution would be to release a patch for the FMS 2 server for this issue, otherwise, it makes it unusable, and annoying for users to be constantly logged out at random intervals.

On the other hand, the error logs don't really produce much information other than "Disconnect 200" which means that is was a 'normal' disconnect but after tracing the user in question's IP, we found that he was kicked from the server.

Are we forced to upgrade to the Flash Interactive Server 3? For an upgrade of $1995.00? I hope not. Here is a solution we're going to try and implement to see if we can crack the FMS 2 bug (or our own disconnect bug). We're going to hit it from three different angles:

1) Don't use the crutch of FMS to keep users logged into the site. So even if the FMS blows, then they can still finish whatever process they were working on. If they want to use the FMS we can always re-initiate a new connection either automatically (see step 3) or ask them to re-connect (easiest to implement).

2) Place a PHP trigger in the sign off button so that we know users actually hit the sign off button. This would be a change from disconnecting them from the FMS server.

3) To 'automatically'* re-initiate an FMS connection we would need to know if the disconnect were actual. If they closed the browser or genuinely hit the sign off button, then we shouldn't waste processes and resources trying to re-initiate the connection. Therefore, we would hold a php IP table of registered users who are logged in, with the screen open and run a validation to see if the disconnect was authentic or a hiccup, if it is a hiccup then the user would receive another FMS connection and the freedom to enjoy the entire feature set of Titanstrike.

* hmmm. Automatic, I should be careful using this word when relating it to our application. It's a paradox though, you want to make things as streamlined as possible (or automatic) for the user as possible, but at the same time this veil of automation takes lots of premeditation and arguably more development time. Nevertheless, it's well worth it only to involve the user when there is an interaction that builds value.