by Thomas Gagné
The smaller a program is, the easier it is to maintain and enhance. This statement is generally accepted as true, but very little software is designed to exploit this axiom. In fact, because each project is perceived with requirements unlike any other, programming modules are often re-invented with interfaces nearly identical, but different from other modules designed for similar purposes.
One of the major design philosophies of isectd is to advocate software reusability, but in a larger sense than simply source code. Using the common interfaces available from isectd, entire processes designed for specific purposes can be reused inside a system.
Firstly, isectd provides a mechanism for sending messages between processes. The isectd library functions relieve applications from having to know specifics about inter-process communication (are we using named-pipes or Berkeley sockets?). Because the interface is simple there are fewer barriers to developing distributed applications.
Next, isectd provides the ability to distribute processes across a heterogeneous network, allowing programs on one machine to request services on another, without regard to locality (and to some extent operating system or CPU type).
isectd is also capable of monitoring processes on the network. isectd defines the services available, the number of processes providing those services, and a mechanism for starting and stopping those processes.
It's not totally accurate to call the design of the system client-server. Typically, when people think client-server they think of a single server process, like a database manager, handling requests from multiple clients. The server exists as a single process running on a single machine, supporting clients scattered across the network.
isectd handles scattered clients all right, but the concept of a server is slightly different. isectd's design allows server processes to be implemented with little regard for re-entrancy or multitasking like traditional servers require. Instead, simpler processes written with as event-loops are combined into a service. Processes capable of understanding a kind of service requests are called workers. Together, the workers providing a service appear to a client as a server, in the traditional client-server sense.
isectd itself, although a single process, is not a typical server, because it doesn't provide a service. It's as transparent to the process of transaction processing as the operating system is for file IO.
Incidentally, nothing forbids a worker from becoming a client to another worker providing a service the first can not.
The ability to have multiple workers for a single service provides an opportunity for scalability not available in conventional client-server designs. Scalability is a common problem for database servers. isectd's design allows scalability beyond the limitations of a single computer, since workers may be distributed across the network. If the resources the workers are using (cpu, disk, database, memory) are similarly unrestricted, throughput of the system is only limited by the client's speed and isectd's ability to shuttle messages between them.
The best designs for workers focus on a single task the worker can do very well. The better-defined a worker's task is the better it can be coded, giving special attention to error detection, recovery, and reporting. With less code written, there is less code to debug.
Additionally, since all like-code has been concentrated in a single program, duplicate code is removed from applications.
Error reporting to clients is consistent, because isectd defines a mechanism for reporting worker errors, as well as communication errors detected by isectd. This simplifies application code (in the client) because error-handling for different kinds of services is identical.
Basic worker functionality is simple, as demonstrated by the worker code below. The name of the program is isdecho. It's job is to return to the client the same message it received.
Let's look at another worker called, isdeat. It basically sends any message it receives to the bit bucket.
In the program below, each line the user types on the keyboard is sent to isectd service "echo." After sending the message the client prints the reply.
Copyright © 1997, Isect