Internet services (i.e. TCP/IP based network services) are programs that respond to connections made to them over a TCP/IP network. Leaving low-level IP and UDP based services aside, these are TCP services (transaction based). The client host connects to a network port on a server host, where a program answers, a connection is established, communication is performed, and the connection is closed.

The program answering the call must contain networking code to accept and establish the connection. Also, it is expected to be able to handle multiple connections concurrently, which on Unix is usually done by fork()ing a new copy to handle this particular connection. And you typically want the capability of access control and logging such as provided with TCP wrappers.

There are two basic approaches to implementing this. One is to build it into the server program itself: in that case, it is a standalone daemon.

Another option is to use the generic Internet networking daemon, inetd. This daemon listens for incoming network requests and upon receiving a request, invokes a dedicated handler program, passing input and output along. This way, the dedicated program only needs to handle a single connection.

In the past, most Unix Internet services relied on inetd, for example, in.ftpd for FTP service, and in.telnetd and in.rlogind for remote command line sessions. The advantage is clear: the daemons themselves are simpler to code; the general Unix toolbox philosophy of tying small programs together using I/O pipes is usefully applied.

Every Unix variant comes with an inetd, and they differ, but they are generally characterized by the following:

  • configuration is done in a single file, usually /etc/inetd.conf, with one line per service;
  • a few command line options are available to control timeouts, logging, etcetera;
  • features required for modern-day use, such as the ability to distinguish virtual hosts, are lacking

inetd's lack of features and flexibility are resolved in xinetd.

However, there is a more fundamental issue with using a generic Internet daemon.

Starting up an executable on Unix is typically an expensive operation; often, more expensive than actually running the program once it has been started! Therefore, it is important to consider the type of traffic you're going to get. If connections are relatively infrequent, but take a long time or much effort to process, then an inetd-based implementation is appropriate: if the frequency is high (or very high, think "webserver") a standalone implementation is better.

For example, sshd offers both an inetd and a standalone mode, but the inetd mode is rarely used; webservers such as Apache do not offer an inetd mode at all.

Log in or register to write something here or to contact authors.