Handling Connection Failures

Connection failures come part and parcel with any technology that uses a remote connection. A Communication Server application is subject to temporary or sustained network interruptions. To build a stable Flash Communication application, you must be prepared to handle these outages and what happens when a client reconnects.

There are two considerations when handling connection failures. Routines must be developed for the server and the client to handle a connection failure independently. If the plug is pulled on a network connection, all messages and persistent data (streams) between the server and client are halted immediately. The NetConnection object on the client and the Application object on the server are your two tools for informing you that a connection has failed.

Both objects use built-in listeners to monitor the state of a connection. The NetConnection object returns an information object with the code NetConnection.connect.closed to the onStatus event if the connection has been lost. The application object will call the Application.onDisconnect event.

These two operations let you manage connection failures. On the client, monitor the code object in the NetConnection onStatus event. When the code is received, execute a script that will determine if the disconnect is expected or unexpected. Unless you have a specific call to the NetConnection.close() method, this status will always be unexpected. Here is a sample script:

 nc.onStatus = function(infoObj) {        if(infoObj.code == "NetConnection.connect.closed") {             trace("the server connection has terminated");             runCloseScript();       } }; 

When a client disconnects, the server handles it with the Application.onDisconnect event. The following script calls a custom function, runDisconnectScript() , when a Flash player disconnects:

 application.onDisconnect = function() {        trace("the Client has disconnected");       runDisconnectScript(); }; 

Connection failures must be a part of your application plan. They are a natural part of not only the Internet but a "feature" of hand-held devices. Building a strategy for connections and disconnections is imperative. When building your own strategy, consider some of these questions as they relate to both the Flash player application and the server:

• What happens on the client when the client disconnects?

• What happens on the server when the client disconnects?

• What is the synchronization process when a client reconnects?

• Will local SharedObjects proxy the remote SharedObject in case of connection failure?

• How will other Flash clients and the server respond when a client connects, disconnects, or reconnects?

These are just some questions you should ask about your application. Clearly there are many more, and you should consider compiling a list of these questions as a form of quality assurance. When designing future applications, test the architecture to ensure they satisfy each question appropriately.

This is just one step in ensuring the integrity of your application. Now, let's look at how you can apply security to your Communication application.