The Danosphere.

Recently while working on a project using Flash Media Server 2, I discovered a rather major issue with the server itself. If a user disconnects in a less-than-graceful manner, such as losing internet connection, or unplugging their LAN cable, or something of that nature, the server seems to think they are still connected! At first I didn’t believe it but after further testing, sure enough the connection were being left open in FMS2, and this led to all types of other problems when FMS2 tried to send data to clients that actually no longer exist!

I contacted Adobe about this issue, and they confirmed this was indeed a bug (of course I had to make a sample app to prove it to them first). While there is not immediate Adobe solution to this issue, with the help of some other FMS’ers I have come up with this temporary solution. It is basically a heartbeat on the server side which calls a function on each client and waits for a response. If no response is received within XX secs, it can be assumed the client is no longer connected. This solution works well except if you have an application that does a lot of data crunching. Because if the app is crunching data, it wont respond to the heartbeat until the data is processed, and this can lead to false disconnects, something to keep in mind.

Here is the file i sent to adobe, which both illustrates the issue, and has a workaround to detect the detected client faster than FMS2 does on its own.

Ghost Connection Workaround

This was a project for my Design of Graphical User Interface course in Spring of 2007. I really like this project because it uses alot of dynamic animation and tweening as well as heavy XML-based data for the content making it very customizable. This was a 10week project and involved lots of process work from raw sketches all the way to wire frames and finally to the result. Everything can be found on the site created for the piece, in pdf format.

Check it out: Ganondagan Interactive Timeline

Responsibilities: All design, development, and backend

This problem presented itself while workin on a project for class that required alot of dynamic loading, attachMovies, and so forth. So I’m attaching these movies but for some reason my movieclip.removeMovieClip() calls aren’t doing anything! This problem can be very frustrating as Macromedia / Adobe does little to nothing to document this. The issue is components and the depthManager.

If you have a component in the library (does not need to be on stage!) and try to use _root.getNextHighestDepth() you will get returned a depth in the reserved range. Then when you try to removeMovieClip() the command will fail silently because the clip is out of depth range. As far as I’ve seen this issue only applies to clips who get their depth from _root.getNextHighestDepth()… using getNextHighestDepth() on other clips seems to still work fine. Anyway here is an easy solution I found somewhere:

[actionscript]

function removemovieclip(removemovie:MovieClip) {

var scope = removemovie.parent;
var poorswappedmc = scope.getInstanceAtDepth(0);
poorswappedmc.swapDepths(scope.getNextHighestDepth());
removemovie.swapDepths(0);
removemovie.removeMovieClip();
poorswappedmc.swapDepths(0);

}

[/actionscript]

Simple really- swap the target mc back into the valid depth range and then remove! voila!

On yet another DL assignment I had to figure out how to get the browser to stop caching my swf’s. I tried using the Adobe/Macromedia Technote method of setting headers to force the refresh of content, but, big surprise, it didnt work.

So I searched for a different method. I needed the page to reload the swf regardless of if it was the latest or not, i wanted it to refresh every.single.time. The solution was simpler than I had expected. By simply appending an arbitrary random number variable onto the swf location the browser will force refresh the swf every time. Here is the code [using the IE activeX bypass]

[script language="javascript" type="text/javascript"]

var randNum = Math.round(100*Math.random());
AC_FL_RunContent(“src”, “myCachedSWF?cacheController=” + randNum);

[/script]

One of my latest projects for DecisionLens required me to use Flash 9 to upload and download files from a web server. In my case, a java servlet. Tink has written an excellent tutorial to get you started with FileReference, it can be found here:

Tink’s FileReference Tutorial + Source

His example is great, it covers all the basics of the FileReference class but in my working with the class, I discovered a few other nuances that may prove helpful..

Authorization

In my scenario it was necessary to authenticate the client BEFORE uploading the file. This required passing a username and password to the java servlet. Unfortunately the FileReference class can only pass variables to the script via HTTP_GET variables- this poses a security threat, exposing the username and password. To get around this I used LoadVars.sendAndLoad- passing the username and password via HTTP_POST to a server side script [java servlet in this case]. The script returns a unique sessionID that is passed back to the script via HTTP_GET with the FileReference.upload() command. If the passed sessionID matches the stored server-side sessionID the upload is allowed and the session is deleted, otherwise it is rejected and an HTTP error code is used to pass information back to the client [see next workaround]. This enabled the client to be verified and the username and password information to be secured.

.

Returning Information to the Client

Another downfall of the FileReference class is that it provides no method of retuning information to the client about the upload. Let me rephrase that- it can return infomation to the client, but only very simple HTTP error codes. So there is no way to return messages or variables from the script, to the client. To work around this we assigned certain http error codes to certain siutations- ie: HTTP401 = unathorized user, HTTP400 = File Already Exists, HTTP 500 = Java Exception / Server Error. Granted these are not the most ideal ways of returning information to the client but given the structure of the class, it is the only way to accomplish this goal.

Overall the FileReference class is a great tool for moving files to and from a server. While it certainly has its downfalls I really think the pros outweigh the cons. We can only hope that Macromedia/Adobe will address the many pertinent issues pointed out on livedocs.