Whether local or over the Internet, network-based debugging has changed the way applications are developed and tested. Changes were first necessary to accommodate PC-based network applications. Now they're needed to address the plethora of embedded network products, from Internet appliances to control networks.
Unfortunately, in general, network-based debugging support doesn't address a wide array of communication mechanisms. Ethernet is the remote debugging transport mechanism of choice due to its wide use. TCP/IP is the preferred transport protocol for most remote debugging tools. This typically eliminates restrictions on the client side because the standard TCP/IP stack is employed. But things are different on the device under test (DUT), depending on the type of debugging methodology used.
There are 3 basic debugging methods. One is the conventional debugging interface that's transparent to the application. With a remote debugger, a stub controls the application. Breakpoints can be set and data can be read or changed. The stub also may communicate with the remote debugging application through a special Ethernet device driver. This assumes that the debugger stub can halt the operating system and the application so that the operating-system's device driver can't be utilized. A more limited, application debugging environment might not require a customized device driver if the debugger couldn't breakpoint the operating system or device driver code.
Microware's Hawk IDE debugging services take the first approach with Microware's OS-9 operating system. OS-9 uses the SoftStax architecture. The SoftStax architecture works with a variety of protocol stacks, including TCP/IP. Its low-level support integrates with the debugger stub.
The Hawk IDE debugger support includes run-time audit trails for time stamping that are helpful for multiple device debugging and for addressing time-oriented problems.
The OS-9 debugging stub can handle multiple applications and multiple debug sessions when dealing at the application level. This allows multiple users to perform application debugging simultaneously on the same hardware platform without disruption. Multiple-user and application debugging means the operation cannot be stopped.
As with many embedded debugging tools, the Hawk IDE debugger platform, the target, and the development platforms can be different. This can be a significant advantage for developers since they can choose the tools and environments that provide the capabilities necessary for developing and debugging an application or device driver.
Java's debugging support uses the second approach. In this case, the debugging support is implemented within the Java virtual machine (VM). This is reasonable because the Java environment sits atop an operating system and a Java application-level debugger doesn't get to the underlying operating system. Java debuggers that do cross this boundary may require additional support.
Embedded Debugging Tools Another debugging methodology involves modification to the application under test. Products such as NextNine's graphical monitoring and logging system, SurroundView, use this method.SurroundView adds an embedded debug interface to the application that can be accessed by the matching monitoring application. Both implement standard network protocols, and control is restricted to the application, so this approach doesn't require specialized network drivers.
Of course, any invasive tools such as SurroundView can cause unwanted problems due to interaction with the application and the remote debugging tool, but this is true for most remote debugging approaches. For example, a timing-critical network application can be affected by the amount of information that the monitoring program sends across the network. Monitoring a small number of relatively static variables utilizes minimal network bandwidth, but monitoring real-time counters or packet contents can easily generate more network traffic than the data being processed by the application. As with any debugging tool, developers need to be aware of the implications of monitoring an application.
Although invasive embedded debugging tools increase the size of an application and possibly induce unwanted interactions between the application and the outside world, the approach often provides a more efficient interface for viewing or controlling specific aspects of an application compared to a more conventional debugger.
The last debugging methodology employs an application's own network interface. By definition, a networked device will have some sort of interface. For example, an Internet appliance that is managed via a Web browser will have a Web server to deliver information requested by the browser. In this instance, standard Internet protocols are used, allowing other debugging applications to be used to access this information.
Debugging the application by using this technique involves either the matching application designed to interact with the application on the DUT, or else an application specifically designed for testing.
The advantage to this approach is that there's no change to the application. Yet this technique has the disadvantage that the interface provided by the application frequently supplies limited insight to the application. A typical application interface usually lacks debugging and monitoring support.
This method offers an advantage for some network application inter-faces.For example, Vita Nouva's Inferno uses Styx, a file-system-oriented interface to all services, local or remote. Accessing a remote application is the same as accessing a local application once the remote directory tree is mounted on the computer where the debug application resides.
Styx is used throughout Inferno, so you can move portions of an application to another node on the network. This can allow de-bugging of a portion of an application on a local PC.
Inferno is not unique in its ability to transparently move components from one network node to another, although that feature is uncommon. Most environments have local and remote communication methods that are distinct.
A mix of debugging meth-odologies is becoming the norm instead of the exception. While remote debugging offers many advantages, there are other concerns that must be ad-dressed. Security is at the top of this list.
Sending debug information and commands over the Internet can compromise a network if the link isn't secure. Basic protocols like TCP/IP don't provide much security. Higher-level protocols, like Inferno's Styx, incorporate secure authentication and encrypted data transmission.
On the one hand, protocol analyzers and packet-capture programs will be of limited use because debug information will often appear as binary data. Unfortunately, text will be sent in the clear.
On the other hand, a debug interface can be a significant problem because it typically bypasses application and even operating-system security measures. Access to registers, breakpoints, and any memory location leaves a system, and subsequently its network, open.
Good firewalls and virtual private network (VPN) support should be part of any Internet debugging plan. A VPN between the debugger and the DUT will encrypt all traffic flowing through unsecure networks.
