Why SWILL?

Have you ever written a C/C++ program and later asked yourself, "gee, wouldn't it be cool if this had some kind of web interface?" If not, please stop right now and cruise on over to an XML Java Beano site or something. Otherwise, please continue...

Simply stated, SWILL is a solution to one of those nagging programming problems---namely that of making programs easier to use. Specifically, SWILL is a library that focuses on the problem of adding remote accessibility to an application.

To better understand this problem, it might be useful to have a little background. In a past life (well, before joining a CS department), I spent most of my time hanging out with computational physicists working on scientific simulation sofware. One of the problems with writing scientific software is that a lot of the applications seem to run for a very long time (tens to hundreds of hours). Obviously, this type of computing takes a certain amount of patience and faith. Well, faith that your 50 hour batch job is actually going to produce the answer that you were expecting. Needless to say, whenever we ran a long program like this, my colleagues and I would almost always try and monitor its progress. For instance, we would periodically check on log files or we might FTP a data file to a local machine in order to take a look at it (to make sure the simulation hadn't blown up or something). The only problem with this kind of monitoring is that it is often clumsy and inconvenient. For instance, if I'm at home, I'm certainly not going to download a big data file over a modem onto my PC. Similarly, if all I want to do is make a quick status check, there ought to be a better way to do it than having to log into the compute server, search for data files, and inspect their contents (okay, so I'm lazy).

One solution to the monitoring problem is to add some kind of simple remote access feature. The only catch is that last person you want to implement "remote access" has got to be a computer scientist. This is because their "simple" solution to the problem will undoubtedly turn into a peta-scalable peer-to-peer collaborative virtual immersive problem solving environment involving 12 network services, 3 middleware layers, 2 million dollars in special purpose hardware (i.e., a "demo lair"), 8 full-time sysadmins, 13 postdocs, 52 graduate students, and a scruffy cocker-spaniel named "boochie." Believe me, it's not pretty--I know.

Perhaps a more attractive solution to this problem would be to modify an application so that it can behave like a simple web server. For instance, if a scientific program had a web server embedded in it, you could just point your browser at it and get real-time status information--including plots and the results of data analysis. Since web browsers work everywhere, there would be no need to write any kind of special user client program. Furthermore, since the browser would be connecting directly to the application, there would be no need for special middleware or a complicated software configuration. Clearly, this kind of approach has its benefits. The only problem is where would you find an embeddable server to do this?

Well, the answer to that question is SWILL. SWILL is minimalistic web server in the form of a programming library. Bits and pieces of SWILL have actually been floating around for the last 6 years. An early proof of concept is briefly mentioned in an article that appeared in Computers in Physics [1]. A few years after that, I had a couple of students (Mike Sliczniak and Hasan Baran Kovuk) look at the idea of having a more generic C implementation. Although they have long since moved on, I have continued to work on their C implementation and to use it in a variety of personal projects. For example, the bug tracking database for my book was written using SWILL in 1999. I also used SWILL to write the software for reviewing papers in the 8th International Python Conference (mostly as a test of the library---little did others know that it wasn't written in Python). SWILL has even been used to implement a parse-tree browser for the SWIG project and to implement a hidden monitoring tool for the student kernel project in my operating systems class. It is only recently that Terry Lampoudi and I cleaned up the library and decided to make a public release.

A bare-bones web server

SWILL turns this situation on its head and approaches the problem from a slightly different angle---maybe it would be easier to add a web server to the application instead. To do this, SWILL makes it possible to activate a web server with about the same simplicity as opening a file. For instance, here is a simple "Hello World" example in SWILL:

#include <stdio.h>
#include "swill.h"

void hello(FILE *f) {
   fprintf(f,"Hello World\n");
}

int main() {
    swill_init(8080);                       /* Initialize the server */
    swill_handle("hello.txt", hello, 0);    /* Add a document */
    while (1) {
        swill_serve();                      /* Look for a connection */
    }
}

As you can see, there's very little in the way of server configuration. Not only that, you don't have to do any special I/O nor do you have to mess around with aspects of the underlying network protocol. You just write some functions using fprintf() and it just "works." This kind of stripped down functionality is the primary design objective of SWILL. In fact, the library only contains about 25 functions (most of which are simple utility functions). Furthermore, the library intentionally omits support for a variety of advanced features such as concurrency, threading, Unicode, secure sockets, and so forth.

Given that SWILL is so minimal, it's probably not something that you would use to write a new internet application. Therefore, why would you want to use it? The next few sections provide a few examples.

Remote monitoring and control

void main() {
    swill_init(8080);
    swill_handle(...);          /* Register some documents */
    swill_handle(...);          /* Register some documents */
    swill_handle(...);          /* Register some documents */
    ...
    while (1) {
       swill_poll();            /* Connection? */
       ...
       do other useful work
       ...
    }
}

Diagnostics and Debugging

Using SWILL, you can build a debugging tool that is not substantially different than using print statements, but which allows you to have obtain diagnostics using a browser. For instance, various debugging functions can simply be registered as web documents. Then, as an optional application feature, you can turn on the web interface and use it as a mechanism for accessing application data. This turns out to be a very interesting way to examine complex data structures like trees and graphs. For instance, each node in a tree might be displayed in its own web page. On that page, pointers to other nodes would simply be represented as hyperlinks. Then, if you wanted to go pointer chasing, you could simply click your way through the data structures of an application as a collection of pages. This is pretty cool.

Web based debugging is also an interesting way to detect more transient types of programming problems such as memory leaks. For instance, suppose that you instrumented a memory allocator with an optional web interface. Using this, you might be able to monitor free memory lists, in use memory blocks, and so forth as a program ran. Since such monitoring would be dynamic, you might be able to get a much more interesting view of the situation than you would from a debugging trace file.

Security, Reliability, and other Concerns

Bottom line

References

[1] D.M. Beazley and P.S. Lomdahl, "Controlling the Data Glut in Large-Scale Molecular Dynamics Simulations", Computers in Physics, Vol. 11, No. 3. (1997), p. 230-238.

[2] S. Lampoudi, D.M. Beazley, "SWILL: A Simple Embedded Web Server Library", To appear in the Freenix track of the USENIX technical conference, Monterey, CA, June 13, (2002).