A Domain Analysis of Network Daemon Design Dimensions Douglas C. Schmidt [email protected] Department of Information and Computer Science University of California, Irvine, CA 92717, (714) 856-4105 An earlier version of this paper appeared in theC++Report, March/April, 1994. PRINTER WORK STATION 1 Introduction FILE CD ROM SYSTEM Applicationsthat effectively utilizemulti-processingand net- work services are able to deliver increased system through- (1) STAND-ALONE APPLICATION ARCHITECTURE put, reliability, scalability, and cost effectiveness. Designing CYCLE and implementing such applications is a challenging task, DISPLAY SERVER however. This article is part of a continuing series that de- SERVER scribes object-oriented techniques that may be used to sim- FI LE plify the development of reliable, robust, and extensible dis- SERVER tributed applications. Previous articles in this series have PRINT NETWORK examined C++ wrappers that encapsulate the socket interpro- SERVER cess communication (IPC) interface [1] and the event demul- tiplexing mechanisms provided by the select and poll PRINTER CD ROM system calls [2, 3]. This article presents an object-oriented FILE SYSTEM domain analysis of key design dimensions for network server daemons. Subsequent articles will describe a framework (2) DISTRIBUTED APPLICATION ARCHITECTURE called the ADAPTIVE Service eXecutive (ASX) [4] that pro- Figure 1: Stand-alone vs. Distributed Application Architec- vides¯exibility acrossthedesign dimensionsidenti®ed in this tures article. The ASX framework combines C++ features (such as parameterized types, inheritance, and dynamic binding) and advanced OS mechanisms (such as multi-threading and port multiple services via one or more processes or threads. dynamic linking) to provide a highly extensible environment for developing and con®guring a wide variety of network daemons. 2 Background Material A daemon is an operating system (OS) process that exe- cutes services on a host machine in the ªbackgroundº (i.e., In contrast to stand-alone applications, the components in a disassociated from any controlling terminal) [5]. A service distributed application reside in a number of loosely coupled is a portion of a daemon that offers a single processing ca- host machines connected together by a network. Figure 1 de- pability to communicating entities. Server daemons com- picts the basic differences between the two approaches. The monly available in the UNIX environment provide clients stand-alone application architecture illustrated Figure 1 (1) with communication-related services that resolve distributed consolidates the interactive graphical user interface (GUI), name binding queries (named and rpcbind), access net- instruction processing, and persistent data resources within work ®le systems (nfsd), manage routing tables (gated a single machine and the peripherals directly attached to it. and routed), perform local system services such as log- The ¯ow of control in a stand-alone application is localized ging (syslogd) and printing (lpd), and integrate multi- to the individual machine where it began executing. ple remote services such as terminal access (rlogin and The distributed application architecture portrayed by Fig- telnet) and ®le transfer (ftp) together into a single ªsu- ure 1 (2) partitions the interactive GUI, instruction process- perserverº framework (inetd). In this series of articles,par- ing, and persistent data resources among a number of other- ticular emphasis is given to network server daemons that sup- wise independent machines in a network. The ¯ow of control 1 in a distributed application migrates between different ma- determining how to partition an application into separate ser- chines during run-time. This allows certain application ser- vices and where to distribute these services throughout a vices (e.g., database access, high-resolution graphics) to be network are also inherently complex development issues. delegated to run on hosts that possess specialized processing In recent years, a number of approaches have been devel- attributes such as high-speed disk controllers, large amounts oped to alleviate the dual problems of accidental and inher- of memory, or enhanced ¯oating point performance. This ent complexity mentioned above. Two generally successful delegation of responsibilities is bene®cial since it permits the techniques that have been widely employed to reduce the sharing of expensive peripherals (such as high-capacity ®le complexity of network daemon implementation, con®gura- servers and high-volume printers) by a number of users and tion, and use are (1) the development of reusable component applications. libraries and (2) the development of automated daemon con- A network of diskless X-terminals is a relatively common ®guration tools. example of a distributed architecture. In this environment RPC-based toolkits and daemon control frameworks are a number of decentralized components collaborate to pro- notable examples of reusable component libraries and au- vide GUI-based computing services to end-users. The in- tomated daemon con®guration tools, respectively. RPC- teractive GUI is typically managed by the X server on based toolkits include the OSF Distributed Computing En- each X-terminal; the instruction processing capabilities are vironment (DCE), the Open Network Computing (ONC+) provided by the client host(s) where all or part of an ap- transport-independent RPC facility, and the Common Ob- plication's services run; and access to persistent resources ject Request Broker Architecture (CORBA). Daemon con- (such as databases and object managers) is mediated by one trol frameworks include the inetd superserver that origi- or more ®le servers. Interoperability is possible as long as nated with BSD UNIX, the listen port monitoring facil- the protocols used to inter-communicate between these sep- ity available with System V Release 4 (SVR4) UNIX, and arate components are compatible. Therefore, the networks, the Service Control Manager from the Windows NT operating systems, hardware platforms, and programming operating system. languages in an X-terminal environment may be completely RPC-based toolkits and daemon control frameworks au- heterogeneous. tomate many tedious and error-prone activities associated Although distributing services among machines in a net- with developing distributed applications. These activities work offers many potential advantages, distributed applica- include de®ning service interfaces, performing presentation tions are often signi®cantly more dif®cult to design, imple- layer conversions, registering services with endpoint port ment, debug, optimize, and monitor than their stand-alone mappers, locating and selecting remote services, authenticat- counterparts. To handle the requirements of distributed ap- ing and authorizing clients, ensuring data security, demul- plications, developers must address many topics (such as tiplexing packets, and dispatching client requests to service service partitioning and load balancing across process and providers.1 host boundaries) that are either irrelevant or are less prob- Although they have proven to be quite useful in practice, lematic for stand-alone applications. Object-oriented design many RPC-based toolkits and daemon control frameworks and implementation techniques offer a variety of principles, were developed without adequate consideration of object- methods, and tools that may help to alleviate much of the oriented techniques and advanced OS mechanisms. This complexity related to developing and con®guring distributed fact complicates component reuse and limits functionality. applications, in particular accidental complexity [6]. For example, the standard version of inetd is written in Accidental complexity is an artifact of limitations with C and its implementation is characterized by a proliferation tools and techniques used to develop software systems within of global variables, a lack of information hiding, and an an application domain. One common example of accidental algorithmic decomposition that deters ®ne-grained reuse of complexity is the lack of type-safe, portable, and extensible its internal components. Likewise, inetd, listen,and system call interfaces and reusable component libraries. De- the Service Control Manager do not provide fully buggers are another source of accidental complexity. Many automated support for (1) dynamically linking services into debuggers do not function properly when used on multi- the daemon controller's process address space at run-time threaded programs containing IPC calls. Yet another source and (2) executing these services concurrently via one or of accidentally complexity arises from the widespread use of more threads. Therefore, developers who want to bene®t algorithmic decomposition. Many distributed applications from these advanced OS mechanisms must manually pro- are developed using algorithmic decomposition techniques gram them into their applications. that frequently result in non-extensible system architectures. Inherent complexity, on theother hand, is a consequence of fundamental properties of a domain that complicate applica- 3 Network Daemon Design Dimensions tion development. For example, inherently complex aspects of developing reliable and ef®cient distributed application The increased availability of advanced OS mechanisms services involve detecting and recovering from transient net- (such as multi-threading and explicit dynamic linking), cou- work and host failures and minimizing