"Linux Gazette...making Linux just a little more fun!"

BACKGROUND

This article evolved from my frustration in developing and debugging CGI programs written for the AuctionBot, a multi-purpose auction server. I found that the available C libraries, C++ class libraries and web server extensions did not fit my needs so I decided to implement a different approach based on debugging over TCP sockets. Using this approach, I have successfully implemented and debugged most of the CGI's for this project.

My development machine at work is a Sun Ultra 1 running Solaris 2.5. At home I have a Linux box running RedHat 5.0. I developed all my debugging code under Linux. Linux provides a very stable development environment that allowed me to develop, test and experiment locally, without requiring remote login to the Sun. Once the code was running, I simply moved it over to the Sun, built it and started using it.

OVERVIEW

A common CGI debugging technique involves capturing the environment that a CGI is run under (usually to a disk file), restoring the environment on a local machine and running the CGI locally within the restored environment. Using this technique, CGI's can be run from the command-line, or from within a debugger (gdb for example) and debugged using familiar debugging techniques. This technique is straight forward, but requires the developer to perform the extra work of capturing and restoring the CGI runtime environment.

Another problem in debugging CGI's is viewing the output of a CGI that fails to run correctly. If you are using Apache 1.2 or later, this can be addressed by configuring the web server to log error messages to a error log file. This approach works for some classes of problems, but does not provide the granularity I wanted.

One could write debugging/status information to log files and use tail -f logfile to view the file. This works, but can produce deadlock conditions if multiple copies of your CGI are running and they attempt to use the same shared resource (the log file) and do not use file locking. Developers must provide file locking code and handle possible deadlock conditions, including cases where a CGI crashes before it releases its file lock [1]. In addition, all writes must be atomic to ensure correct output.

Ideally, one would like to debug the CGI in its natural surroundings, i.e. from within environment created by the web server, without any extra setup work.

MY SOCKET-BASED SOLUTION

class SocketDB
{
private:
  int mSD;
  ErrorTypes mErrorType;
  int mConnected;
  
public:
  SocketDB();
  SocketDB(char *name, int port);
  ~SocketDB();

  int Connected() { return mConnected; }      
  int ErorType() { return mErrorType; }      
  int Connect(char *name, int port);
  
  int Print(char *format,...);
  int Println(char *format,...);
};

THE CLIENT

The program attempts to connect to the debug server program specified by the command-line arguments host and port (see source code). If it fails to connect, it prints a message, and the error code and exits. If it connects, it prints the test string, writes the same string over a TCP socket to debug server and reports the result of the debug server write.

A DEBUG SERVER

USING THE PROGRAMS

In another shell cd to the directory containing the example programs and type DebugClient [host] [port] where host is the host name of the machine the server is running on (get this by typing hostname at the command prompt) and the port is the port were the server to listening (4000 for example).

You should see a text string written to the server and to the shell.

CONCLUSIONS

RESOURCES

Code: http://groucho.eecs.umich.edu/~omalley/software/socket_debug-1.0.tar.gz