Several primary goals were the basis to write my suite of public internet services. One consisted of a challenge to learn UNIX APIs deeply at the time I decided to write my own. This is no longer the case, but probably that the most driving factor still has to do with my need to run such services.

Of course there exists a variety of solutions for each of the standard protocols. However, most of them seemed historical, based on code which made it though the years through extreme amounts of patching and kludges. This generally results in solutions which are hard to configure, and have gone though a long history of security-related issues. Most of them even support obsolete protocols, or experimental ones which never have been widely used.

Moreover, several of them were subject to strict licensing issues. Writing my own software I have the full rights to do whatever I want with it, as well as eventually distribute closed-source special editions commercially. But I didn't want to be the only one to be able to do this, hence I decided to release my software under a BSD-style license (Berkeley Source Distribution license), allowing others to modify it and distribute it under source or binary form as wanted, only requireing them to add an aknowledgement to their product documentation:

  This product includes software written by Matthew Mondor.

It however obviously is encouraged to report to me the various bug fixes or enhancement patch so that the main publicly available tree also evolve.

Considering security aspects, most traditional UNIX internet services software ran as the superuser, and required standard UNIX users to be added for each remote user. I strongly beleive that most administrators enjoy being able to only create virtual users rather than real UNIX shell ones for each of their users. My daemons therefore only allow virtual users. Moreover, none of them require to run as the superuser after their initial startup. Most of them have support for chroot(2) as well, for administrators who need it.

These are public services afterall. I personally use them to contribute software and services which are often free of charge, and would find it quite discouraging if my services were exploited and servers virtually destroyed. I think that many administrators are in the same position and would like to run safe services.

Special care is taken when writing this software to avoid memory leaks (which could be a threat to service uptime and autonomy), and to check every error condition possible. As the services should remain up, system resources error conditions are treated in a safe way; The current operation is cancelled to not execute code which requires these new resources to be allocated, previous allocated ones are released if any (but not all) were obtained for the current operation as well, and the service keeps running as usual. This also implies using I/O operations which can timeout where required. Also, libc functions with uncertain delay periods get executed by an asynchroneous parallel system when userspace threading systems are used, to prevent locking the main process, allowing service to remain fluid among the multiple simultaneous connections being served. Some effort was also made to keep the code clean.

C was chosen to write these for several reasons. I am well used to it, having used it for many years, was a primary one. A second worthwhile reason is that the UNIX, POSIX and BSD APIs are intended for C programs. It is also possible for the programmer to optimize C code decently rather than only relying on compiler effeciency to do it, gaining speed advantage without having to use less maintainable and unportable assembly. When well written, C programs are also portable. C++ could have suited, but would result in generally less efficient code. I also like to control my own use of memory useage, object allocation and garbage collection, hence it was not worth it to use C++. Where possible, ANSI-C compliance is observed.

Matthew Mondor