Program requirements

This wrapper implementation, called ProtoWrap is meant to run with Unix or Unix-like systems. This is mainly because of their robustness and stability, specially when compared to other popular operating systems, and their adherence to open standards. This implementation was programmed and tested on Linux machines, but porting it to other Unix platforms should prove a trivial task.

The program will obviously have to deal constantly with sockets - network services. While designing ProtoWrap, we faced two ways of opening a server process --a daemon in Unix jargon-- and two ways of communicating with a client process depending on our needs.

As for the communication with the client, for services that are seldom called and do not have a big initialization overhead (either in time or in system resources), the best strategy is to call them from the inetd super-daemon, a program that listens on every port and, when an incoming connection requires it, calls the predefined program that should take care of that particular service. Services whose daemons are typically called from inetd usually include telnet, ftp, pop3, finger and other such protocols. When calling the specific program for the service type requested, inetd redirects its stdin and stdout to the already opened socket. The second strategy --the standalone mode-- is to have the daemon always active. This is the case with heavily used services, such as http, or with services that require performing lengthy initializations, as the strong random number generation performed by ssh. Such programs must be always alive, listening at their ports and waiting for a connection. Daemons, however, use constantly a portion of the RAM and CPU cycles of the system, besides occupying a slot in its process table.

As for communicating to a server, a similar choice is presented. The server may be a program executable from the local machine, handling communication with its client via the standard input and output (stdin and stdout) file descriptors, or it can be executing at an arbitrary location --including the same computer-- and communicating via a TCP/IP socket. The first strategy should be chosen if the server can be called from inetd, as it will improve performance not having to go twice through a TCP/IP stack, and security, not being able to be called without going through the wrapper or having local access to the computer. The second strategy should be used if ProtoWrap will work from a firewall or if the service being wrapped can not use stdin/stdout for its communication. Of course, if the second strategy has to be chosen, the system administrator can still limit --using ipchains or an equivalent program-- the connectionsto the server to a specific computer.

ProtoWrap is compatible with all those strategies. Of course, when deciding which one to use, the user must evaluate how his system will be used, do a maximum expected load calculation, and not discard switching to other strategies should the usage patterns of the server change.