Section 3.5. Testing and Debugging Network Connections

3.5. Testing and Debugging Network Connections

Networked applications present some additional difficulties when testing or debugging programs, as more than one system is always involved. A connection attempt may fail for many reasons, including the following:

• The target URI may be incorrect (watch for typos).

• A username or password may be wrong.

• The maximum number of licensed clients or maximum licensed bandwidth of the server may have been exceeded.

• The network may be down or unreliable.

• A connection that worked fine in a test environment may fail because of a firewall or proxy server.

Often, the best way to understand why a network connection fails is to display all the properties of the information object returned to the onStatus( ) method. In addition, at least until the target URI is proven to be correct, the return value of the connect( ) method should always be checked. If it is false , the URI was malformed and should be corrected. It is a good idea to begin building a movie by always creating a default, diagnostic onStatus( ) handler as in Example 3-1. When the connection has been tested , you can replace the onStatus( ) handler with one more appropriate for your needs. Unfortunately, problems aren't limited to the beginning of development. As both client- and server-side scripts evolve , diagnosing the cause of a sudden loss of connectivity is difficult. To help diagnose the problem, build simple test movies that can be run outside the development environment. In fact, this is an important technique for testing much more than basic connectivity.

3.5.1. Test Client Movies

An excellent way to help debug connections is to write a test movie that includes a few basic components , such as:

• A large scrolling text field with scrollbar

• Connect and Close buttons

• Fields for a target URI and other connect( ) method parameters, such as username and password

Instead of using trace( ) statements, use a writeln ( ) function such as the one in Example 3-2 to output information to the scrolling text field. A sample test movie is supplied on the book's web site (http://flash-communications.net).

3.5.2. Using the NetConnection Debugger

Separate from the Flash MX 2004 ActionScript debugger, Macromedia supplies a NetConnection Debugger with the FlashCom Server (and with Flash Remoting). The NetConnection Debugger can display client- and server-side connection- related events such as connect requests and remote method calls and their results. To obtain the NetConnection Debugger, download and install the Macromedia Flash Remoting MX Components from:

http://www.macromedia.com/software/flashremoting/downloads/components

Once installed, to use the NetConnection Debugger, place the following include instruction on the first frame of the Scripts layer of your main timeline:

 #include "NetDebug.as" 

Then select Window NetConnection Debugger from Flash's menu bar to start the debugger. To see server-side events, you must log into the administration server (Admin Service) using an administrator username and password, as described in Chapter 1. If the Filters section of the NetConnection Debugger, shown in the bottom half of Figure 3-3, is not open, click on the small triangle to open it. Enter the administrator's username and password; make sure the Flashcom_server, RTMP, and Trace checkboxes are all selected; and run your movie in the Flash development environment. Figure 3-3 shows the NetConnection Debugger after a failed attempt to connect to the server.

Figure 3-3. The NetConnection Debugger after a failed connection attempt

Click on an event in the Events list and select the Details tab to see the full details about each event. Client-side events are indicated by the Flash logo, and server-side events are indicated by the FlashCom logo. In Figure 3-3, the Close event details are shown. Following it in the Events list is a server-side event that reports that the application was eventually unloaded because no other clients were connected to it. Provided a .swf was compiled with the NetDebug.as file included, it can be run outside the authoring environment and its connection-related events will still be displayed in the NetConnection Debugger. As your projects evolve and you are debugging increasingly complex scripts, this is another good reason to keep around some simple test movies.

Remove the ActionScript to include NetDebug.as in your final movie after you no longer need the debugging features. It adds unnecessary file size to the published .swf .