An Object-Oriented Framework forDeveloping Network Server Daemons

Douglas C. Schmidty and Paul Stephensonzschmidt@ics.uci.edu and ebupsn@ebu.ericsson.seyDepartment of Information and Computer Science, University of California, Irvine, CA 92717zEricsson Business Communications, Inc., Cypress, CA 90630

An earlier version of this paper appeared at the C++ WorldConference in Dallas, Texas, October 1993.

Abstract

Developing distributed applications that utilize multi-processing and network services is a promising techniquefor increasing system performance, scalability, and cost ef-fectiveness. However, designing and implementing efficient,robust, and extensible multi-threaded client/server applica-tions is a complex and challenging task. The ServiceConfigurator (SVC-CON) framework described in thispaper provides an object-oriented infrastructure that simpli-fies the development of dynamically configured, concurrent,multi-service network daemons. The framework integratesmechanisms for (1) local and remote interprocess communi-cation, (2) I/O-based and timer-based event multiplexing, (3)explicit dynamic linking, and (4) multi-threading and multi-processing to aid the creation of network servers that maybe updated and extended without modifying, recompiling,relinking, or restarting executing daemons.

1 Introduction

This paper describes the architectural design and func-tionality of an object-oriented (OO) framework called theService Configurator (SVC-CON). This frameworkprovides a collection of reusable C++ components that sim-plify the construction of network server daemons by en-hancing the modularity, extensibility, reusability, and porta-bility of their interprocess communication (IPC), I/O-basedand timer-based event multiplexing, service dispatching, andconcurrency mechanisms. The OO techniques and tools de-scribed in this paper are currently being applied on a familyof client/server applications as part of the Ericsson ExternalOperating Systems (EOS) project. This project employs theSVC-CON framework to enhance the configurationflexibilityand software component reuse of applications that monitorand manage MD110 [1] private-branch exchanges (PBXs) ef-ficiently and portably across multiple hardware and softwareplatforms.

In addition to describing the general structure and behav-

ior of the SVC-CON framework, this paper also exploresthe process by which the framework’s reusable C++ compo-nents “emerged” from careful analysis of the common objectsand abstractions that exist in the domain of network servers.Since most textbooks and network programming referenceguides present function-oriented models for designing net-work applications, it is not surprising that developers of-ten decompose their server daemons according to functionsrather than classes and objects. Therefore, the OO networkserver design perspective presented in this paper may appearsomewhat “counter-intuitive” at first. However, our experi-ence with the strategies and tactics underlying the SVC-CONframework offer compelling evidence that the long-term pay-offs of applying object-oriented techniques to network pro-gramming significantly improves application modularity, ex-tensibility, and component reuse.

This paper is organized in the following manner: Sec-tion 2 briefly summarizes the requirements and general ar-chitecture of the EOS PBX project; Section 3 describes theSVC-CON framework’s primary features and reviews relatedwork; Section 4 outlines the C++ design and implementationof the SVC-CON framework; Section 5 examines the struc-ture of several EOS applications built using the SVC-CONframework; and Section 6 presents concluding remarks.

2 Overview of the Ericsson EOS PBXProject

Ericsson is developing a family of applications that monitorand manage MD110 PBXs. These applications enhance thefunctionalityof a PBX (or cluster of PBXs) by providingend-users with directory management, call center management,and extension manager services. For example, the DirectoryManagement application allows a PBX operator to profileincoming calls diverted from subscriber extensions, handlesubscriber messages, and perform other general subscriberdatabase queries (such as accessing visitor information andrecording facility conference room location and availability).Likewise, the Call Center Management application allows thestaff of a call center (such as an airline reservation center) toassess the performance and quality of the call center by pro-viding real-time graphical displays of system resources such

1

DIRECTORY

MANAGEMENT

SERVICESCLIENT

NETWORK

CALL CENTER

MANAGEMENT

SERVICES

EXTENSION

MANAGEMENT

SERVICES

DATABASEPBXS

SERVER

CLIENTCLIENT

: DeviceAdapter

MODULE

OBJECT

DAEMON

PROCESS

: EventAnalyzer

: MulticastRouter

: Reactor

Figure 1: The EOS Client/Server Architecture

as agents and call queues. Finally, the Extension Manage-ment application allows a PBX administrator to view, add,modify, or delete PBX extensions interactively.

The architecture, design, and implementation of the Er-icsson EOS applications are influenced by several generalrequirements that necessitate support for (1) multiple appli-cation services, (2) platform independence, (3) configura-tion flexibility, and (4) efficient performance. For example,multiple EOS application services must be available simul-taneously to multiple remote users, potentially interactingwith one or more PBXs. A client/server architecture (illus-trated in Figure 1) was selected to support this distributedfunctionality in a scalable and relatively transparent manner.Each PBX is directly attached to a server host via a serialcommunication link, and one or more server daemons on thehost supply services required by the client applications. Thecurrent EOS applications provide MD110 PBX communica-tion services, database services, batch processing services,extension administration services, and asynchronous signalrouting services (described in Section refusage).

Platform independence is another key requirement of theEOS project. Applications are targeted for various config-urations of host and network platforms, including WindowsNT, UNIX, Windows 3.1, and OS/2 running over TCP/IP andNovell IPX/SPX networks. The project relies heavily uponobject-oriented design techniques and C++ language featuresto reduce the overall development effort and to improve soft-ware component reuse across platforms and among the familyof related applications. In particular, the encapsulation andflexibility offered by C++ classes, abstract base classes, andparameterized types are used extensively to localize platformdependencies.

Two additional system requirements involve configurationflexibility and service performance. Since not all customersrequire every EOS feature, applications may be deployedwith various combinations of services. It would be pos-

sible (although highly undesirable) to manually constructand deliver one or more client/server applications that are(1) customized for the services required by a customer and(2) optimized for the level of concurrency available on thehost platform [2]. However, such a “statically configured”system would require the application service combination,client/server division of labor, and host platform to be com-pletely fixed during product deployment. Our experiencewith earlier-generation EOS applications suggests that evenif this information is available at the time of deployment, itwill certainly change in the future, often upon short notice.Therefore, to maximize installation flexibility and to take ad-vantage of available multi-processing capabilities, the EOSfamily of applications utilize SVC-CON framework featuresthat defer decisions regarding both (1) the set of available ser-vices and (2) the partitioningof these services onto processesand/or threads until as late as possible – e.g., initial serverstartup-time or even during run-time. As described below,theSVC-CON framework provides several foundation classesthat support the deferred binding of services onto processesand/or threads. Other object-oriented components used bythe EOS applications are described elsewhere [3, 4, 5].

3 The Service Configurator Frame-work

The SVC-CON provides an object-oriented framework thatsimplifies the development, configuration, and reconfigura-tion of concurrent, multi-service network daemons. A dae-mon is a statically or dynamically configured process thatexecutes in the “background” (i.e., disassociated from anycontrolling terminal) on a host computer. The fundamen-tal unit of configuration in the SVC-CON framework is theservice. Network daemons provide communication-relatedservices that resolve distributed name lookups, access net-

2

work file systems, manage routing tables, and perform otherremote services such as printing, login, and file transfer. Inthe EOS system, network daemons orchestrate the server-sidedirectory management, call center management, and exten-sion administration services.

Depending on configuration policies specified during sys-tem installation, the EOS applications run as one or moremulti-service network daemons that simultaneously supportmultiple remote services via one or more OS processes and/orthreads. Explicit dynamic linking may be used to dynami-cally (re)configure (i.e., insert and remove) these servicesfrom a network daemon at run-time. Deferring the bindingof services to processes and threads until run-time increasesthe flexibility, extensibility, and performance of network dae-mons. Moreover, in certain cases, daemons that executewithin the SVC-CON framework may reconfigure their ser-vices without being terminated and restarted. In addition, theconcurrency level of a network daemon may be fine-tunedduring installation or run-time to match client application de-mands and available OS multi-processing capabilities moreefficiently.

The SVC-CON framework integrates C++ language fea-tures (such as inheritance, dynamic binding, and parame-terized types) and advanced OS mechanisms (such as thethreads and explicit dynamic linking facilities available inSVR4 UNIX [6] and Windows NT [7]) to facilitate the de-velopment of network clients and servers that may be updatedand extended without modifying, recompiling, relinking, orrestarting the running daemons. In addition, it provides asuite of reusable components that extend the functionality ofconventional port monitoring and service dispatching toolssuch as the UNIX System V Release 4 (SVR4) listenfacility [8] and BSD inetd superserver [9].

The framework’s components also reduce the effort re-quired to develop network daemons. For instance, theSVC-CON framework’s components simplify developmentby consolidating common server activities (such as I/O-based and timer-based event multiplexing, service dispatch-ing, subroutine tracing and status logging, daemonization,service directory functionality, and various process, thread,and linking strategies) into reusable C++ foundation classes.These classes include the IPC SAP object-oriented transportinterface [3] and the Reactor I/O-based and timer-basedevent multiplexing class library [4, 5] (both of which en-hance application robustness by accessing OS local and re-mote IPC mechanisms via type-secure interfaces, rather thanthe weakly-typed “descriptor-based” underlying system callinterfaces).

3.1 Conventional Port Monitoring and ServiceDispatching Frameworks

This section describes several conventional frameworks fordeveloping, configuring, and reconfiguring network dae-mons. Section 3.2 compares the features of these frameworkswith those of the SVC-CON framework.

3.1.1 Single-Service Daemons

In early versions of UNIX, standard network services suchas remote file transfer (ftp) and remote login (telnet andrlogin) ran as single-service daemons that were initiatedat OS boot-time [10]. The services offered by these daemonswere configured statically at compile-time and/or static link-time. As illustrated in Figure 2 (1), a separate program wastypically written to implement each service. Each service ranin a separate process, though a master daemon might spawnone or more slave processes to perform certain long-durationservices externally in a separate address space on behalf ofits clients.

As the number of system daemons grew steadily, however,this “statically configured, single-service per-process” designapproach revealed several significant limitations. First, OSprocess management overhead increased since each single-service daemon consumed a process table slot, even thoughit was often idle. Second, each daemon redundantly reim-plemented the same daemonization and transport endpointinitialization code. Third, the flexibility and extensibility ofstatically configured daemons was limited since adding ordeleting services required modifying, recompiling, and re-linking existing code. Moreover, running daemons had to beterminated and restarted explicitly after making any changes.Finally, administering and monitoring the security and per-formance aspects of each daemon was handled in an ad hocmanner [8].

3.1.2 Multi-Service Port Monitor and Service Dis-patcher Frameworks

Multi-service port monitor and service dispatcher frame-works were devised to alleviate the limitations with single-service daemons described above. Two widely availableframeworks are the Internet superserver inetd (which orig-inated with BSD UNIX [9]) and the listen port monitorfacility (distributed as part of the Service Access Facilitywith SVR4 UNIX [8]). Inetd and listen integrate manysingle-service daemons into one administrative framework inorder to (1) reduce unnecessary process overhead by spawn-ing daemons “on-demand,” (2) simplify daemon develop-ment by automatically performing daemonization and trans-port endpoint initialization, (3) allow external services to bechanged without modifying source code or terminating anexecuting daemon process, and (4) consolidate the adminis-tration of network services via a standard set of configurationfiles and command-line utilities.

Figure 2 (2) illustrates the general structure of daemon dis-patcher tools such as inetd and listen. Both tools useInternet-domain port numbers to demultiplex client requestsand dispatch them to either (1) statically named internal ser-vices or (2) statically and/or dynamically named externalservices (daemon-related terminology is defined more thor-oughly in a companion paper available in the 1993 C++ Worldconference proceedings [11]). For example, the inetd su-perserver operates in the following manner:

3

(2) MULTI-SERVICE DAEMON

SERVICE

INTERNAL

SERVICESERVICE

INTERNAL

SERVICE

EXTERNAL

SERVICE EXTERNAL

SERVICE EXTERNAL

SERVICE EXTERNAL

SERVICE

SERVICE

INTERNAL

SERVICE

(1) SINGLE-SERVICE DAEMONS

SERVICE

EXTERNAL

SERVICE

SERVICE

EXTERNAL

SERVICE

SERVICE

INTERNAL

SERVICE MASTER

SLAVES

Figure 2: Single-Service vs. Multi-Service Daemons

SERVICECONFIG

SERVICEREPOSITORY

Reactor

INTERNALSERVICES

(3) SERVICE CONFIGURATOR

EXTERNALSERVICES

STATICALLYLINKED SERVICE

DYNAMICALLYLINKED SERVICE

THREADPROCESS IS-PARENT-OFCOMM. PORTS

(1) INETD

EXTERNALSERVICES

select()

INTERNALSERVICES

(2) LISTEN

poll()

EXTERNALSERVICES

Figure 3: Alternative Port Monitoring and Daemon/Service Dispatching Frameworks

4

1. When invoked at OS boot-time, inetd reads serviceconfiguration information stored in the inetd.conffile.

2. For each service in the configuration file, inetd per-forms the “socket/bind/listen” socket initial-ization sequence to register the well-known port numberof the service with the OS.

3. Inetd then enters a select loop that waits for one ormore client connection requests or datagrams to arriveat the port of any registered services. Datagrams arriv-ing for statically named internal services (such as echoand daytime) are performed internally by the masterinetd process. Connection requests arriving for ex-ternal services (such as ftp or rlogin) are handledby accept’ing the connection, fork’ing a new pro-cess, and exec’ing the appropriate executable programto perform the service on behalf of the client.

Although inetd’s internal services (such as echoand daytime) are fixed at static link-time, the mas-ter inetd daemon permits dynamic reconfiguration of itsexternal services (such as ftp or telnet). For in-stance, when sent the SIGHUP signal, the inetd dae-mon re-reads its inetd.conf file and performs thesocket/bind/listen sequence for all services listed inthat file. However, since inetd does not support dynamicreconfiguration of internal services, any newly listed servicesmust still be processed by spawning slave daemons via forkand exec. Therefore, although inetd and listen1 over-come many limitations with single-service daemons, theystill possess several shortcomings that are addressed by theSVC-CON framework described below.

Another network service management facility that recentlybecome available is the Service Control Manager (SCM) dis-tributed with Windows NT [7]. Unlikeinetd and listen,SCM is not a port monitor i.e., it does not provide built-in sup-port for listening to a set of I/O ports and dispatching serverprocesses “on-demand” when client requests arrive. Instead,it provides an RPC-based interface that allows the masterSCMprocess to automatically initiate and control (i.e., pause, re-sume, terminate, etc.) administrator-installed services (suchas ftp and telnet) that typically run as separate threadswithin either a single-service or a multi-service daemon pro-cess. Each installed service is individually responsible forconfiguring the service and monitoring any communicationendpoints (which may be more general than I/O ports, e.g.,named pipes). Note that the SVC-CON framework may beutilized within the SCM environment to provide additionalsupport for dynamic daemon configuration, port monitoring,and service dispatching.

1The SVR4 listen port monitoring facility is similar to inetd,though it only supports connection-oriented protocols accessed via TLIand STREAMS, and does not provide internal services. However, unlikeinetd, listen supports “standing-daemons” by passing initialized filedescriptors via STREAM pipes from the listen process to a previously-registered standing-daemon.

3.2 Primary Features of the Service Configu-rator

This subsection outlines the primary features offered by theSVC-CON framework and compares these features with thoseprovided by inetd and listen. Figure 3 illustrates themajor architectural features of the three frameworks. In gen-eral, the features of the SVC-CON framework are designedto (1) increase configuration flexibility and daemon extensi-bility, (2) improve performance, and (3) reduce developmenteffort for concurrent, multi-service network daemons.

3.2.1 Increase Flexibility and Extensibility

The SVC-CON framework enhances configuration flexibilityand network daemon extensibility by decoupling and defer-ring the point at which services are bound to OS processesand/or threads. In particular, services may be configured intothe SVC-CON framework either (1) statically (at compile-time or link-time) or (2) dynamically (when a daemon firstbegins executing or even while it is running). Moreover, thechoice between these two alternatives may be deferred. Forexample, services may be partitioned and/or migrated be-tween clients and servers during or after installation, therebyenabling a flexible division of labor on the placement of ser-vices within a distributed application.

The SVC-CON framework provides an object-oriented in-terface to OS explicit dynamic linking features. As describedin Section 4.1, this interface facilitates the dynamic con-figuration and reconfiguration of network daemon services,often without requiring the modification, recompilation, orrelinking of existing code. Dynamic linking also provides anopportunity to reconfigure services without terminating andrestartinga daemon. Inetd andlisten, on the other hand,provide a more limited form of dynamic configuration thatdoes not support reconfiguration of internal services at run-time. Instead, adding new internal services requires modify-ing, recompiling, relinking, and restarting inetd (listendoes not support internal services).

3.2.2 Improve Performance

By deferring the binding of services to processes and threads,applications may postpone certain decisions until run-time,when additional information is available to guide the selec-tion of more efficient daemon configurations. For instance,customizing or reconfiguring daemons during or after startup-time helps to account for factors such as (1) the class ofservice required by applications (e.g., reliable vs. unreli-able and real-time vs. non-real-time), (2) the type of trafficgenerated by applications (e.g., bursty vs. continuous andshort-duration vs. long-duration), (3) the class of protocolthat implements the application services (e.g., connection-oriented vs. connectionless vs. request-response), (4) certainstatic and dynamic characteristics of the hardware and oper-ating system architecture (e.g., message passing vs. sharedmemory, process and thread management overhead, number

5

of CPUs, and current end-system load), and (5) the under-lying network environment (e.g., high-speed vs. low-speedand large frame size vs. small frame size) [12].

The SVC-CON framework automates many of the stepsrequired to (re)configure network daemons and helps de-velopers navigate through the diverse set of factors thataffect the configuration of network daemons. For ex-ample, a “concurrent/multi-service” daemon configurationmay be efficient for an OS that effectively utilizes multi-ple CPUs. In this case, each application service may bemapped onto a separate process or thread. On the other hand,an “iterative/single-service” configuration may be more suit-able for certain combinations of OS platform and applica-tion service characteristics. For instance, on a uni-processorplatform, daemon efficiency may be improved by executingshort-duration, request/response services in a single-threadedprocess, due to the reduction in scheduling and contextswitching overhead [13].

The SVC-CON framework also employs OS mecha-nisms such as dynamic linking, multi-threading, and multi-processing to improve performance. Explicit dynamic link-ing and threads support the (re)configuration of concurrentinternal services without spawning a new OS process. Thishelps improve the performance of multi-service daemonsthat perform short-duration, request-response services. Con-versely, inetd andlisten spawn a new process to achievesimilar dynamic service invocation functionality. However,this invocation technique may be too costly for short-durationservices, due to the overhead of fork and exec.

Dynamic linking also helps reduce overall host memoryutilization, which may improve aggregate end-system per-formance [14]. For example, dynamically linked servicesare not fully loaded, resolved, or relocated into the addressspace of an executing daemon until they are first referenced,which often reduces a daemon’s consumption of primary andsecondary storage resources. Moreover, to further reducerun-time memory utilization, a dynamically linked servicemay be shared between multiple network daemons runningsimultaneously [6]. In addition, services may be dynamicallyunlinked from daemons when they are no longer required,thereby releasing resources for subsequent use by other ap-plications and daemon services.

3.2.3 Reduce Development Effort via Reusable Compo-nents

The SVC-CON framework provides a collection of reusablecomponents that implement the following common founda-tion services used by network daemons and distributed ap-plications:� Event Multiplexing and Service Dispatching: Networkserver daemons often multiplex different types of I/O eventssent or received simultaneously from one or more clients onmultiple communication ports. The SVC-CON frameworkprovides port multiplexing and service dispatching function-ality via a C++ class library called the Reactor [4, 5]. The

Reactor provides a set of extensible, reusable, and type-secure C++ classes that portably encapsulate and enhancethe select and poll I/O multiplexing facilities. TheReactor integrates the multiplexing of synchronous andasynchronous I/O-based events together with timer-basedevents. When events occur, the Reactor automaticallydispatches “call-back” member functions of previously reg-istered objects to perform application-specified services. TheReactor enables developers to concentrate on higher-leveldaemon design and functionality issues, rather than reimple-menting the same lower-level event detection and dispatchingcode for each new network daemon.� Automatic Service Configuration: To help automatemany daemon configuration steps, the SVC-CON provides astandard model for installing application services into net-work daemons. This configuration model leverages off no-tations and tools that (1) identify the service(s) to activate,(2) statically or dynamically instantiate, link, and initializeC++ object(s) that implement the service(s), (3) notify the un-derlying OS transport provider to bind communication portsand network addresses for the object(s), (4) register the ob-ject(s) with an instance of the Reactor, and (5) arrangeto run the service via one or more processes and/or threads.The SVC-CON framework’s configuration model is flexibleenough to support dynamic and static configuration, as wellas hybrid approaches that provide both configuration meth-ods simultaneously. Section 4.3.1 examines the SVC-CONframework’s service configuration model in detail.� Process and Thread Generation Strategies: SeveralSVC-CON framework facilities implement on-demand, ea-ger, and lazy process and thread generation strategies. Ingeneral, these strategies help to further decouple the ser-vices offered by network daemons from the OS processesand threads that execute the services. In particular, theyenable daemons to adaptively tune their concurrency levelsto match client demands and available OS parallelism. Forexample, on-demand generation spawns a new process orthread in response to the arrival of client requests. Eagergeneration pre-spawns one or more OS processes or threadsat daemon creation time to reduce service startup overheadand improve response time. Conversely, lazy allocation doesnot immediately spawn a process when a client request isreceived. Instead, a timer is set and the request is handled“iteratively” by the daemon. Only if the timer expires isa new process spawned to continue processing the serviceconcurrently [13].� Distributed Logging: Network daemons are often dif-ficult to develop and debug since diagnostic output appearsin different windows and/or on remote host systems. Tosimplify network daemon debugging, the SVC-CON frame-work supports a distributed logging facility (described andimplemented in [4, 5]). This logging facility coalesces di-agnostic output (potentially sent from multiple daemons onmultiple hosts) at a designated location in a local and/or widearea network. The distributed logging facility utilizes several

6

levels of “many-to-one” multiplexing. For example, applica-tions send logging records via named pipes or messagequeues to a client logging daemon running on their localhost machine. Each client daemon timestamps and forwardsthe logging records via TCP/IP connections to a remote serverlogging daemon running on a designated server host. Thisconcurrent server daemon processes the logging records anddisplays them on one or more output devices (such as printers,persistent storage devices, and/or monitoring consoles).� Function-Call Tracing: To further aid debugging, theSVC-CON framework provides a function-call Trace classthat interoperates with the distributed logging facility. TheTrace class enables developers to monitor the calling se-quence of any or all stand-alone subroutines or member func-tions at run-time. A simple regular-expression-based filtertool automatically instruments application source code withTrace object definitions. At run-time, output from the con-structor and destructor of Trace objects visually indicatesthe function calling sequence. This output is indented ap-propriately to illustrate the current call-chain nesting levelas functions are entered and exited. The creation and termi-nation semantics of C++ simplify function-call tracing sinceTrace object destructors are automatically invoked regard-less of the point that the function returns. In addition, theSVC-CON framework enables tracing to be toggled on or offvia signals or other asynchronous notification events gener-ated by a user.� Daemonization: The daemonization utility provides net-work servers with robust capabilities to execute and surviveas daemon processes executing “in the background.” Thesedaemonized processes do not automatically receive eventsgenerated from a terminal nor do they receive hangup indica-tions if/when their parent process exits. As described in [10],daemonization under UNIX typically involves (1) dynam-ically spawning a new process, (2) closing all unnecessaryfile descriptors, (3) changing the current working directory tothe root directory, (4) resetting the file access creation mask,(5) disassociating from the controlling process group and thecontrolling terminal, and (6) ignoring terminal I/O-relatedsignals.

In general, component reuse in the SVC-CON frameworkis enhanced by (1) accessing framework services via exten-sible object-oriented interfaces written in C++ and (2) sep-arating higher-level application processing policies that per-form client requests from lower-level daemon mechanisms(such as event demultiplexing and dispatching, logging andtracing, daemonization, and various process and thread gen-eration strategies). In contrast, both inetd and listenallow only course-grain “black-box” reuse of their generalservice dispatching facilities, without encouraging more fine-grain reuse of their internal components. For example, thestandard BSD inetd implementation is written in C and ischaracterized by global variables, lack of information hiding,and a functional decomposition that complicates direct reuseof its internal components.

4 The Server Daemon Design and Im-plementation

This section outlines the object-oriented design and im-plementation of the SVC-CON framework’s primary com-ponents and describes the sequence of steps performed todevelop and configure a daemon’s services statically and/ordynamically. In addition to examining the interfaces andgeneral functionality of the framework’s components, thestrategic decisions that yielded the decomposition illustratedin Figure 4 are also discussed.2

The SVC-CON framework was developed using severalobject-oriented design techniques and C++ language fea-tures. Domain analysis on the typical attributes and oper-ations performed by network daemons yielded the followingclass components in the SVC-CON framework:� The Service Object inheritance hierarchy (Fig-

ure 4 (1)) – this hierarchy ensures that developers specifythe information necessary to automate dynamic linking,initialization, port multiplexing, and dispatching of anapplication service at run-time.� The Service Repository class (Figure 4 (2)) –this class provides an object manager that coordinatesindividual and/or collective access to active services ina daemon.� The Service Config class (Figure 4 (3)) – this“framework integration class” orchestrates the configu-ration and reconfiguration of statically/dynamically con-figured, iterative/concurrent, single/multi-service net-work daemons.

Though difficult to quantify precisely, it appears rather un-likely that a functional design approach would have yieldeda set of reusable components that offer such a high degree ofmodularity and extensibility to distributed applications.

4.1 The Service Object Class

The Service Object class (illustrated in Figure 4 (1))forms one part of a multi-level hierarchy of types relatedby inheritance. This hierarchy decouples the application-specific portions of a network service from the underlyingmechanisms provided by the framework that link, register,and dispatch the service at run-time. This separation of con-cerns minimizes the effort required to add and/or removeof services to and/or from a network daemon. Each classin this hierarchy performs a set of well-delineated tasks forapplication developers, as described below:� The Event Handler Abstract Base Class: The root ofthe inheritance hierarchy is defined by the Event Handler

2These components and their relationships are illustrated via Booch no-tation [15]. Dashed clouds indicate classes and directed edges indicateinheritance relationships between these classes. Solid clouds indicate one ormore class objects and undirected edges indicate composition relationshipsbetween these objects (cf. Figure 6).

7

1

1

1

1

ServiceConfig

svc_conf_file open() process_directives() load_service() suspend_service() resume_service() unload_service() run_event_loop() daemonize()

REACTOR

open() register_handler() remove_handler() schedule_timer() cancel_timer() handle_events()

nEvent

Handler

ServiceRepository

1

n

ServiceObject

(4) The Service_ConfigClass

1

SERVICE-SPECIFIC

(3) The Service_RepositoryClass

open()insert()find()remove ()resume()suspend()

ServiceRepository

open()reset()getnext()advance()

ServiceRepository

Iterator

F1

1

n

1

(1) Service_ObjectInheritance Hierarchy

SERVICE-SPECIFIC

INHERITSFROM

HAS-A(BY REFERENCE)

F FRIEND A ABSTRACTCLASS

Service ObjectA

EagerSpawn

ServiceManager

ThreadSpawn

LazySpawn

(2) Standard Subclassesof Service_Object

ProcessSpawn

ServiceObject

ClientListeneropen()listenerreactor

SERVICE-SPECIFIC

ServiceObject

A

suspend()resume()

EventHandler

handle_input()handle_output()handle_exception()handle_signal()handle_timeout ()handle_close()get_fd()A

SharedObject

init()fini ()info()

A

LinkSpawn

Figure 4: The Server Daemon Class Components and their Relationships

abstract base class. This base class supplies an event dis-patching interface that consists of virtual member functionsfor (1) synchronous input, output, and exception eventsand (2) timer-based events. In the SVC-CON framework,application-specific subclasses indirectly inherit and refinethis functionality through the Service Object derivedclass. This derivation process results in composite ob-jects that are subsequently registered with an instance ofthe Reactor [5]. The Reactor then extracts the under-lying I/O descriptor from the Event Handler portion ofa composite object and passes it along with other descrip-tors to select or poll I/O demultiplexing system calls.When events associated with a registered object occur atrun-time, the Reactor automatically dispatches the appro-priate member function(s) of the object, which then performapplication-specific services.� The Service Object Abstract Derived Class: TheService Object class exports an abstract interface con-sisting of three pure virtual functions [16] that impose a“contract” between the general-purpose foundation classesprovided by the SVC-CON and application-specific servicesutilizing these classes. The use of pure virtual functionsensures that an application service supplies the SVC-CONframework with the appropriate information necessary tolink, initialize, identify, and unlink a service at run-time.

During development, application-specific subclasses mustimplement the init function to perform initialization oper-ations when an instance of a composite Service Objectfirst comes into existance. Likewise, during service initial-ization, init serves as the “entry-point” to an applicationservice, (i.e., it is passed a pair of “argc/argv”-style pa-rameters that are similar to those passed to the main functionof a stand-alone executable program). The fini member

function is called automatically to perform any necessary ter-mination operations when a Service Object is unlinkedand removed from a daemon at run-time. The infomemberfunction returns a humanly-readable string that documentsthe functionality and addressing information of a service.� Application-Specific Concrete Derived Subclasses:The Service Object and Event Handler are both“abstract” classes since they contain pure virtual functions.Therefore, developers must derive concrete subclasses (suchas theSignal Router subclass described in Section 5) thatdefine the functions inherited from the abstract base classesand implement the application-specific service functionality.Application-specific classes are also responsible for supply-ing the necessary “encode-state” and “decode-state” conver-sion functions necessary to enable service migration [17].

4.2 The Service Repository Class

The SVC-CON framework supports the configuration ofboth single-service and multi-service network daemons.To simplify administration, it is often necessary to in-dividually and/or collectively control and coordinate theService Objects that comprise a daemon’s services.The Service Repository is an object manager thatcoordinates local and remote queries and updates involv-ing the services offered by a SVC-CON-based application.A search structure within the object manager binds ser-vice names (represented as ASCII strings) with instancesof composite Service Objects (represented as C++ ob-ject code). A service name uniquely identifies an instanceof a Service Object stored in the repository. As shownin Figure 4 (2), each entry in the Service Repository

8

Symbol Description

dynamic Dynamically link and enable a servicestatic Enable a statically linked serviceremove Completely remove a servicesuspend Suspend service without removing itresume Resume a previously suspended servicestream Configure a Stream into a daemon

Table 1: Service Config Directives

contains a pointer to the Service Object portion of anapplication-specific C++ derived class.

Figure 4 (2) also depicts the member functions that load,enable, disable, reenable, or remove Service Objectsfrom a daemon statically and/or dynamically. For dynami-cally linked Service Objects, the repository also storesa handle to the underlying shared object. This handle isused to unlink and unload a Service Object from arunning daemon when its services are no longer required.In addition, an iterator class is provided to visit everyService Object in the repository without compromis-ing data encapsulation. For example, a complete listing ofall currently enabled daemon services may be obtained bycalling the info virtual function on each enabled entry inthe Service Repository. This iterator feature is usedby the standard Service Directory service describedin Section 4.3.2 below.

4.3 The Service Config Class

As illustrated in Figure 4 (3), the Service Config classis the central abstraction in the SVC-CON framework. Thisclass integrates the other foundation services (such as theService Repository and the Reactor) to facilitatethe static and/or dynamic configuration of concurrent, multi-service network daemons. The following subsections out-line the configuration and run-time activities performed byService Config class functions.

4.3.1 Server Daemon Configuration Activities

This subsection briefly describes the standard daemon con-figuration process supported by the SVC-CON framework.Alternative mechanisms for statically or dynamically insert-ing and/or removing services from a daemon are also exam-ined. In addition, the steps used to implement the variousmechanisms are also outlined.� The svc.conf File: The svc.conf file is the heart of theSVC-CON configuration and reconfiguration process. Eachinstance of the Service Config class may be associatedwith a distinct svc.conf configuration file that charac-terizes essential attributes of the services offered by a dae-mon. This file simplifies both service administration anddaemon development. Service administration is simplifiedby consolidating service installation parameters into a sin-gle location. Likewise, daemon development is simplified

by decoupling the configuration and reconfiguration mecha-nisms provided by the framework from the policies specifiedin the svc.conf file. The svc.conf file is consultedwhen a new instance of a daemon is first started. This file isalso when a running daemon receives either a pre-designatedexternal signal or IPC request from a remote managementfacility.

Figure 5 uses extended-Backus/Naur Format (EBNF) todescribe the primary syntactical elements of service configentries used in a svc.conf file. Each line in the file beginswith a service config directive that indicates the configurationactivity to perform (Table 1 summarizes the valid serviceconfig directives). For example, the dynamic directive isfollowed by a service identifier:

dynamic /svcs/Logger.so:_alloc() Logger -p 7001

/svcs/Logger.so: alloc() is a service identifier thatindicates the pathname of a shared object file to dynamicallylink (/svcs/logger), as well as the name of the associ-ated Service Object (or in this case, a function calledalloc that dynamically allocates a Service Object).

The remaining contents on the line (Logger -p 7001)represent a service-specific set of configuration parame-ters. These parameters are passed to the init functionof the service as argv-style command-line arguments. Theargv[0] argument (Logger) specifies the service namethat will identify the corresponding Service Objectwithin the Service Repository.

Figure 6 illustrates a complete svc.conf file used toconfigure EOS project services (described further in Sec-tion 5). This figure also indicates how services may be selec-tively configured either statically (e.g., Svc Directory,MML Svc, and GICI Svc) or dynamically (e.g., PBX Svc,XAD Svc, and Client Muxer) in the same daemon, de-pending on the format of the configuration file.� Static Configuration: In a statically configured daemon,all Service Objects are completely specified at daemoninstallation-time. This limits a daemon to a specific, non-reconfigurable set of services, which may be necessary forsecure daemons that contain only “trusted” services. Imple-menting a daemon composed solely of statically configuredservices requires developers to derive a subclass from theService Config base class. This subclass then becomesresponsible for pre-initializing the Service Repositoryto contain only trusted services. The derived class may

9

<service-config-entry> ::= <service-config-directive>[ <service-identifier> ]SERVICE_NAME[ <optional-parameters> ]

<service-config-directive> ::= DYNAMIC | STATIC | REMOVE | DISABLE | ENABLE<service-identifier> ::= SHARED_OBJECT ’:’ [ <service_initializer> ]<service_initializer> ::= OBJECT_NAME | FUNCTION_NAME ’(’ ’)’

Figure 5: EBNF Format for a Service Config Entry

SvcManager

ServiceRepository

Reactor

ServiceConfig

ClientLogger

DeviceAdapter

ClientRouter

EventAnalyzer

CCMApp

svc.confstatic Svc_Manager "-p 911"dynamic Client_Logger Service_Object * /svcs/Cli_Logger.so : alloc() "-p 2112"stream CCM_App dynamic STREAM * /svc/CCM_App.so : alloc(){ dynamic Device_Adapter Module * /svcs/DA.so : alloc() "-p 2001" dynamic Event_Analyzer Module * /svcs/EA.so : alloc() dynamic Client_Router Module * /svcs/CR.so : alloc() "-p 2010"}

Figure 6: Object Components in the Server Daemon Framework

also redefine one or more of the virtual functions inher-ited from the base class so that only the pre-initializedService Repository is searched to locate a service(the default behavior is to search the symbol table of thedynamically linked shared object to locate the appropriateService Object). These modifications ensure that anydynamic service configuration directives in the svc.conffile will be properly ignored. As a further precaution to pre-vent the use of non-trustedservices, derived classes should beconfigured to use onlyService Objects that are fully re-solved at static link-time (i.e., no implicit dynamically linkedservices should be allowed). Clearly, static configurationtrades off flexibility for increased security.�Dynamic Configuration: A dynamically configured dae-mon permits the insertion, modification, or removal ofService Objects during the initial daemon invocation

sequence. This behavior is specified by placing the dynamicservice configuration directive before the service identifier inthe svc.conf file. Dynamic configuration requires the un-derlying operating system to support explicit dynamic linking(SVR4 and OSF/1 UNIX and Windows NT all support thisfeature). In general, dynamic linking simplifies the config-uration of network daemons by avoiding the modification,recompilation, relinking, or restarting of running daemoncode. Moreover, if every daemon service is dynamicallyconfigured, the svc.conf file contains all the informationnecessary to populate the Service Repository. Thismakes it possible to extend a daemon’s services “in the field”without requiring an administrator to have access to the orig-inal source code.

Dynamic configuration also helps reduce overall end-system memory utilization by creating instantiations ofService Object derived classes as dynamically linked

10

shared objects. These Service Objects will not beloaded into a daemon unless the svc.conf file indicatesthey are actually required. Naturally, developers must care-fully consider the subtle trade-offs between flexibility andtime/space efficiency when choosing between dynamic andstatic linking ([6] enumerates many of the trade-offs).�Dynamic Reconfiguration: Dynamic reconfiguration al-lows the modification of services offered by a network dae-mon without actually terminating an executing instance ofthe daemon [18]. Reconfiguration may be triggered byexternal events that are generated both locally and/or re-motely. For example, when an executing SVC-CON receivesa pre-designated signal (e.g., SIGHUP) that was generatedon the local host machine, the configuration steps are per-formed again for any services added to or removed from thesvc.conf file. Likewise, the Service Directory ser-vice described below in Section 4.3.2 may also be used toinitiate reconfigurationacross a network via a remote daemonservice management facility.

The development and administrative steps used to add aservice to aSVC-CON are straight-forward. First, a developerwrites a new service that inherits from the interface offeredby the Service Object/Event Handler class hierar-chy. In general, services may be arbitrarily complex, thoughmany standard network services (such as ftp and telnet)do not require the retention of persistent state informationbe-tween consecutive service invocations (these “stateless” ser-vices are often simpler to configure and reconfigure reliably).Next, an object of the derived class is instantiated, linked intothe daemon, and inserted into the Service Repository(this sequence of steps may be performed by the SVC-CONeither statically at compile-time or dynamically at run-time).The svc.conf file is then updated manually or via an ad-ministrative tool to contain an additional entry that identifiesthe location of the new service and specifies its command-lineconfiguration parameters, which indicate the arguments topass the init function of the specified Service Objectand whether to use static or dynamic linking. At this point,the developer either starts, restarts, or sends a pre-designatedsignal to a SVC-CON to initiate configuration or reconfigu-ration.

The configuration steps performed internally by a net-work daemon are initiated when the application calls theopen function of the SVC-CON class. This function parsescommand-line arguments to enable daemon options, opensa channel to the distributed logging service, invokes thedaemonization code, dynamically creates an instance of theReactor, and calls the process directives functionto process the daemon’s configuration file.

The process directives function processes thesvc.conf file line-by-line. It first converts each lineinto an argv-style vector of arguments. Then it carriesout the specified service configuration directive. For exam-ple, if the dynamic directive appears, the load servicefunction is called to (1) dynamically link the appropri-ate Service Object into the address space of the dae-

mon and (2) insert the address of the object into theService Repository. Likewise, if the remove direc-tive is specified, the unload service function is calledto gracefully close down and delete the service from theService Repository. If the service was dynamicallylinked, the shared object file is unloaded from the executabledaemon.

The enable service function is invoked if the con-figuration directive is static or enable. This functionqueries the Service Repository to determine the ap-propriate instance of the statically or dynamically configuredService Object that is currently bound to the associ-ated service name. After the instance is located, its initfunction is called and the remaining argv arguments arepassed as a parameter. If init returns the REGISTER SVCvalue, the Event Handler portion of the newly initializedService Object is registered with the Reactor auto-matically.

If the disable directive appears at the beginning of a line,the disable service function is invoked. This func-tion temporarily restricts access to the named service withoutactually unlinking and fully removing it from the daemon.Temporarily disabling services is useful during maintenanceperiods when certain services may be inaccessible, but theirexisting non-persistent state informationmust be retained un-til the service is reactived. A subsequence reconfigurationmay be performed to re-enable the service without perform-ing the entire sequence of initialization steps again.

4.3.2 Server Daemon Run-Time Activities

When configuration activities are complete, an applicationcalls theService Config’srun event loop function.This function enters an endless loop that continuously callsthe Reactor’s handle events service dispatch func-tion, which blocks awaiting the occurrence of events suchas I/O from clients or timer expiration. As these eventsoccur, the Reactor automatically dispatches previously-registered application-specific handler(s) to perform the des-ignated services.

Run-time activities may be influenced by a set ofService Object subclasses (illustrated in Figure 7) thatperform the following standard daemon foundation services:� Eager and Lazy Process and Thread Generation: Twostandard subclasses of Service Object implement the“eager” and “lazy” process and thread generation techniquesdiscussed in Section 3.2.3 above. The Eager Gen sub-class pre-spawns one or more processes or threads to form apool that minimizes service startup overhead when requestsarrive. The Lazy Gen subclass, on the other hand, onlyspawns a new process if an executing request does not finishwithin a certain time interval. Application services that usethese techniques may inherit from either the Eager Gen orLazy Gen subclasses.� Lightweight Dynamic Service Spawning: Two sub-classes of Service Object implement service spawning

11

Service ObjectA

Link

Spawn

Eager Gen

Extern

Spawn

Service

Directory

Thread

Spawn

Lazy Gen

Figure 7: Standard Service Object Subclasses

techniques that are typically “lighter-weight” than the processinvocation method used by inetd and listen. For exam-ple, rather than use fork and exec to create new processesthat perform service requests externally, the Link Spawnsubclass dynamically links and executes a new service in-ternally. Moreover, services derived from Link Spawn areloaded and unloaded on demand. This contrasts with thedefault dynamic configuration behavior obtained by speci-fying the dynamic service config directive, which pre-loadsservices during daemon initialization. The Link Spawnsubclass is implemented by (1) dynamically linking an ob-ject file, (2) obtaining the entry-point of the appropriateService Object in this file, and (3) invoking the ser-vice to perform the client request. Upon completion, theservice installed by Link Spawn is automatically removedby closing down the Service Object and unlinking theobject file from the daemon’s address space.3

TheThread Spawn subclass provides another techniquefor handling service requests internally. It creates a separatethread on-demand and each thread carries out the serviceto completion. However, unlike the Eager Gen subclass,these threads are not pre-spawned and cached. The use ofthreads is typically less time consuming than using forkand exec [20]. On the other hand, the fork/exec ap-proach may be preferable in situations where the owner ofthe child process must differ from the parent for securityreasons, which is typically the case with remote login andfile access services. Moreover, spawning separate threadsmay be less robust than spawning separate processes sinceall threads share resources in a process and global data struc-tures may be corrupted if errors occur. In general, developersmust consider their application requirements carefully whenselecting an appropriate service execution agent.� Service Directory: The Service Directory sub-class provides local and/or remote clients with access todaemon administration commands that report and manage

3This technique was inspired by the command-line interpreter mecha-nisms used to invoke programs in Multics [19].

the services currently offered by a network daemon. Thesecommands “externalize” certain internal service attributesin an active network daemon. During daemon config-uration, a Service Directory object may be regis-tered at a well-known communication port accessible byclients using the following entry in the svc.conf file (theService Directory service is statically linked into theSVC-CON framework):

static Service_Directory -d -p 9000

When clients request a summary of a daemon’s active ser-vices, theService Repository iterator is automaticallyinvoked by the Service Directory. This iterator trans-fers a complete listing of the developer-supplied informationfor each enabled service back to the client. This listing indi-cates both the address format and the transport protocol to useto contact a given service, and provides a brief explanationof each service. The Service Directory may also beused to trigger reconfiguration requests from remote sites.� Internet Superserver Emulation: The external servicedispatching semantics of inetd are provided via a subclassof Service Object called Extern Spawn. This classspawns processes on-demand to handle client requests asexternal services. By default, Extern Spawn utilizes thestandard inetd.conf file and serves as a replacement forinetd.

5 Using the Server Daemon for EOSApplications

This section describes how the SVC-CON frameworkforms the basis for implementing the primary services thatcomprise the Ericsson EOS application family. The boxes en-closing certain collections of services in Figure 8 indicate thedefault binding of services to processes (the thread bindingsare described further below). The SVC-CON framework’sconfiguration techniques, tools, and resources simplify thetask of modifying these default bindings in response to per-formance enhancements and additional application require-ments. The following paragraphs describe the EOS servicesand indicate the communication protocol, service, and con-currency dimensions associated with each service:� GICI Manager Services: The GICI (General Informa-tion Computer Interface) Manager provides services that ex-change low-level, real-time status information with a PBX.The GICI protocol operates over an RS-232 serial link, ex-changing signals (represented as short sequences of ASCIIcharacters) between an external computer and the Informa-tion Computer Unit (ICU) port on the PBX. The GICI Man-ager provides services that transmit signals to the PBX uponrequest of a client and asynchronously receive signals gener-ated by the PBX. To increase throughout and reduce latency,this service is implemented internally via a single separatethread within the Directory Management application process.

12

DIRECTORY

MANAGEMENT

SERVICESCLIENT

NETWORK

CALL CENTER

MANAGEMENT

SERVICES

EXTENSION

MANAGEMENT

SERVICES

DATABASEPBXS

SERVER

CLIENTCLIENT

: DeviceAdapter

MODULE

OBJECT

DAEMON

PROCESS

: EventAnalyzer

: MulticastRouter

: Reactor

Figure 8: Services Offered by EOS Applications� MML Manager Services: The MML (Man-MachineLanguage) Manager provides services that perform low-level, static configuration operations on the PBX. The MMLprotocol involves the synchronous, request-response trans-mission of an MML command from an external computer tothe I/O Processor Unit (IPU) of a PBX via an RS-232 seriallink. An MML command is a string of ASCII characters con-taining a command identification code and associated param-eters. The response from the PBX is returned to the externalcomputer via the same RS-232 link. The MML Manager isimplemented in the Extension Management application as aninternal service via a separate thread that serializes multipleclients accessing a PBX.� Signal Router Services: The Signal Router services pro-vide capabilities for demultiplexing GICI signals passed fromthe GICI Manager monitoring a PBX to the proper client(s)that have registered to receive the generated signals. Thisservice is implemented internally via a single separate threadwithin the Call Center Management application (the threaduses a multicast protocol [21] to forward signals to interestedclients).� PBX Manager Services: The PBX Manager providesservices for high-level PBX management operations such ascall profiling, diversion management, and message manage-ment. This service is implemented internally within the Di-rectory Management application and is controlled by a ClientMuxer.� Client Muxer: A Client Muxer enables one or more ser-vices to communicate concurrently with multiple clients viaconnection-oriented or request-response protocols (such asTCP or RPC, respectively). A separate thread is maintainedfor each client connection. Depending on configuration pa-rameters, threads may be allocated from pool spawned byEager Gen or on-demand via Thread Spawn.

�Extension Administration (XAD) Services: The Exten-sion Administration services provide high-level PBX opera-tions such as adding, deleting, and modifying extensions. Inaddition, services are provided to download PBX extensionconfiguration information, which is mirrored in a database onthe server to improve response time and off-load redundantprocessing from the PBX. This service is implemented as aninternal service that interacts with clients via a Client Muxercommunicating over a connection-oriented protocol.� Batch Manager Services: The Batch Manager providesscheduling services for queueing and executing extension ad-ministration requests at a pre-determined time. Services areprovided to insert new batch requests, delete batch requests(that have not yet been executed), or query the completionstatus of batch requests that have been executed. This serviceis implemented as an external service running in a separateprocess invoked periodically via a service dispatcher drivenby an external system clock (such as the UNIX cron facil-ity).

The layering of the services in Figure 8 illustrates the usesrelations between the various services in each application.4

In addition to reusing the foundation classes provided by theSVC-CON the EOS applications also reuse several of theservices described above. For example, the GICI Managerservice is shared by the Call Center Management and Direc-tory Management applications. Likewise, the Client Muxerservice is reused by the Directory Management and ExtensionManagement applications. In general, services may be im-plemented as shared objects to reduce primary and secondary

4Currently, the layered application services interoperate via ad hoc com-munication techniques (such as message queues,shared memory,and param-eter passing). Future versions of the SVC-CONwill incorporate a user-levelcommunication framework known as uStreams [22] to handle hierarchically-organized services [23] more elegantly and efficiently (e.g., by reducingcontext switching and data copying overhead [24]).

13

storage consumption.Note that the SVC-CON framework tries to make as few

assumptions as possible regarding the structure of the client(and even the server). Basically, the primary contributionof the SVC-CON is to provide a set of object-oriented inter-faces and standard mechanisms for automatically configuringa set of (practically arbitrary) services into a server applica-tion (actually, the same approach could also be used for theclient, though that is somewhat less common). The term“practically arbitrary” indicates that the current version as-sumes services will be communicating via an I/O descriptorthat is capable of being select’d or poll’d. Therefore,it is feasible to integrate the svc functionality “underneath”an RPC communication model, though it might require somequasi-portable assumptions to extract the underlying descrip-tor from a given RPC toolkit.

We are currently evaluating the performance of the config-uration depicted in Figure 8 to determine whether to incor-porate other SVC-CON features such as Link Spawn andLazy Gen. We are also investigating service reconfigura-tion policies to formulate guidelines that ensure the dynamicmodification of a daemon does not corrupt or seriously dis-rupt existing services. A more ambitious extension involvesusing the SVC-CON mechanisms to experiment with servicemigration policies that relocate certain services dynamicallyto reduce overall system workload.

6 Concluding Remarks

The SVC-CON is an integration framework that supportsstatic and dynamic configuration of internal and external net-work services the execute within one or more OS processesand threads. The long-termgoals of this project are (1) to pro-duce an extensible environment that coordinates reusable ab-stractions and components to support families of distributedapplications and (2) to devise techniques and tools for de-veloping distributed systems that are efficient, cost-effective,modular, scalable, extensible, and easily configured and in-stalled. To help achieve these goals, the general principlesunderlying the SVC-CON framework involve (1) separatingpolicies from mechanisms via object-oriented class abstrac-tions, inheritance, dynamic binding, and parameterized typesin order to enhance the reuse of common network daemoncomponents, (2) decoupling the binding of OS processesand threads from the application services to improve flex-ibility and performance, and (3) utilizing dynamic linkingand threads to improve extensibility and permit fine-grainedtime/space tradeoffs.

The existing prototype implementation described in thispaper fulfills many of the project’s goals. We are currentlyusing the SVC-CON framework to configure, install, and ad-minister a suite of concurrent network services for the Erics-son EOS client/server PBX management applications. Thusfar, the primary benefits of the framework center around en-abling developers to (1) enhance network daemon function-ality and reliability and (2) fine-tune performance without

extensive redevelopment and reinstallation effort. For exam-ple, debugging a faulty service typically involves reinstallinga functionally equivalent service containing additional instru-mentation that helps isolate the source of erroneous behavior.The utility of certain features remain to be seen. For exam-ple, the Link Spawn service may be less applicable fornetwork servers running on multi-threaded platforms, com-pared with the Thread Spawn service. In addition, we areexperimenting with certain reconfiguration and service mi-gration mechanisms offered by the SVC-CON to determinecircumstances where they may be applied reliably. We arealso developing a suite of tools that reduce the effort requiredto administer daemon configuration files (which are currentlymanaged manually).

An implementation of a public domain subset of theSVC-CON framework described in this article is avail-able via anonymous ftp from ics.uci.edu in thegnu/C++ wrappers.tar.Z file. This file also con-tains the source code, documentation, and examples for theIPC SAP and Reactor utilities described in [3, 4, 5].

References[1] Ericsson Business Communications, Tyreso, Sweden, MD110

Operations and Maintenance, 1992.

[2] D. C. Schmidt, D. F. Box, and T. Suda, “ADAPTIVE: A Dy-namically Assembled Protocol Transformation, Integration,and eValuation Environment,” Journalof Concurrency: Prac-tice and Experience, vol. 5, pp. 269–286, June 1993.

[3] D. C. Schmidt, “IPC SAP: An Object-Oriented Interface toInterprocess Communication Services,” C++ Report, vol. 4,November/December 1992.

[4] D. C. Schmidt, “The Reactor: An Object-Oriented Interfacefor Event-Driven UNIX I/O Multiplexing (Part 1 of 2),” C++Report, vol. 5, February 1993.

[5] D. C. Schmidt, “The Object-Oriented Design and Implemen-tation of the Reactor: A C++ Wrapper for UNIX I/O Multi-plexing (Part 2 of 2),” C++ Report, vol. 5, September 1993.

[6] R. Gingell, M. Lee, X. Dang, and M. Weeks, “Shared Librariesin SunOS,” in Proceedingsof the Summer 1987 USENIX Tech-nical Conference, (Phoenix, Arizona), 1987.

[7] H. Custer, Inside Windows NT. Redmond, Washington: Mi-crosoft Press, 1993.

[8] S. Rago, UNIX System V Network Programming. Reading,MA: Addison-Wesley, 1993.

[9] S. J. Leffler, M. McKusick, M. Karels, and J. Quarterman, TheDesign and Implementation of the 4.3BSD UNIX OperatingSystem. Addison-Wesley, 1989.

[10] W. R. Stevens, UNIX Network Programming. EnglewoodCliffs, NJ: Prentice Hall, 1990.

[11] D. C. Schmidt, “Object-Oriented Techniques for DevelopingExtensible Network Servers,” in Proceedings of the SecondC++ World Conference, (Dallas, Texas), SIGS, Oct. 1993.

[12] D. C. Schmidt, B. Stiller, T. Suda, A. Tantawy, and M. Zit-terbart, “LanguageSupport for Flexible, Application-TailoredProtocol Configuration,” in Proceedings of the 18th Confer-ence on Local Computer Networks, (Minneapolis, Minnesota),pp. 369–378, Sept. 1993.

[13] D. E. Comer and D. L. Stevens, Internetworking with TCP/IPVol III: Client – Server Programming and Applications. En-glewood Cliffs, NJ: Prentice Hall, 1992.

14

[14] W. W. Ho and R. Olsson, “An Approach to Genuine Dy-namic Linking,” Software: Practice and Experience, vol. 21,pp. 375–390, Apr. 1991.

[15] G. Booch, Object Oriented Analysis and Design with Ap-plications (2nd Edition). Redwood City, California: Ben-jamin/Cummings, 1993.

[16] Bjarne Stroustrup and Margret Ellis, The Annotated C++ Ref-erence Manual. Addison-Wesley, 1990.

[17] M. Herlihy and B. H. Liskov, “A Value Transmission Methodfor Abstract Data Types,” ACM Transactionson ProgrammingLanguages and Systems, vol. 4, pp. 527–551, October 1982.

[18] C. R. Hofmeister and J. M. Purtilo, “Dynamic Reconfigurationof Distributed Programs,” in Proceedings of the 11th Interna-tional Conference on Distributed Computing Systems, IEEE,1991.

[19] E. Organick, The Multics System – An Examination of ItsStructure. M.I.T. Press, 1972.

[20] J. Eykholt, S. Kleiman, S. Barton, R. Faulkner, A. Shivalin-giah, M. Smith, D. Stein, J. Voll, M. Weeks, and D. Williams,“Beyond Multiprocessing... Multithreading the SunOS Ker-nel,” in Proceedingsof the Summer USENIX Conference, (SanAntonio, Texas), June 1992.

[21] S. E. Deering and D. R. Cheriton, “Multicast routing in data-gram internetworks and extended LANs,” ACM Transactionson Computer Systems, vol. 8, no. 2, pp. 85–110, May 1990.

[22] D. Ritchie, “A Stream Input–Output System,” AT&T Bell LabsTechnical Journal, vol. 63, pp. 311–324, Oct. 1984.

[23] D. Batory and S. W. O’Malley, “The Design and Implementa-tion of Hierarchical Software Systems Using Reusable Com-ponents,” ACM Transactions on Software Engineering andMethodology, vol. 1, Oct. 1992.

[24] N. C. Hutchinson and L. L. Peterson, “The x-kernel: An Ar-chitecture for Implementing Network Protocols,” IEEE Trans-actions on Software Engineering, vol. 17, pp. 64–76, January1991.

15