summaryrefslogtreecommitdiff
path: root/netsvcs/ACE-netsvcs.html
diff options
context:
space:
mode:
Diffstat (limited to 'netsvcs/ACE-netsvcs.html')
-rw-r--r--netsvcs/ACE-netsvcs.html898
1 files changed, 0 insertions, 898 deletions
diff --git a/netsvcs/ACE-netsvcs.html b/netsvcs/ACE-netsvcs.html
deleted file mode 100644
index b3854dc0811..00000000000
--- a/netsvcs/ACE-netsvcs.html
+++ /dev/null
@@ -1,898 +0,0 @@
-<HTML>
-
-<HEAD>
-<TITLE>Overview of the ACE Network Services</TITLE>
-
-<BODY text = "#000000"
-link="#000fff"
-vlink="#ff0f0f"
-bgcolor="#ffffff">
-
-<HR>
-<H3>Overview of the ACE Network Services</H3>
-
-ACE provides a <A
-HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/netsvcs/">
-standard library</A> of network services:<P>
-
-<TABLE>
-<TD>
-<UL>
-<LI><A HREF="#name-overview">Naming Service</A>
-<LI><A HREF="#time-overview">Time Service</A>
-<LI><A HREF="#token-overview">Token Service</A>
-</UL>
-</TD>
-
-<TD>
-<UL>
-<LI><A HREF="#server-logging-overview">Server Logging Service</A>
-<LI><A HREF="#client-logging-overview">Client Logging Service</A>
-<LI><A HREF="#logging-strategy-overview">Logging Strategy Service</A>
-</UL>
-</TD>
-</TABLE>
-
-These services play two roles in ACE:<P>
-
-<UL>
-<LI> They provide reusable components for common distributed system
- tasks such as logging, naming, locking, and time synchronization.<P>
-<LI> They illustrate how to utilize ACE features such as the <A
- HREF="ACE-papers.html#ipc">IPC wrappers</A>, <A HREF="ACE-papers.html#reactor">Reactor</A>,
- <A HREF="ACE-papers.html#config">Service Configurator</A>, <A
- HREF="ACE-papers.html#initialize">Service Initialization</A>, and <A HREF="ACE-papers.html#concurrency">Concurrency</A> components. <P>
-</UL>
-
-The heart of the ACE network services is the <A
-HREF="http://www.cs.wustl.edu/~schmidt/ACE-papers.html#config">Service
-Configurator</A>, which is an object-oriented framework that automates
-the configuration and reconfiguration of multi-service daemons. All
-the ACE network services are configured using the Service
-Configurator. Please refer to the <A
-HREF="http://www.cs.wustl.edu/~schmidt/ACE-INSTALL.html">online
-documentation</a> for more information on installing and testing the
-ACE network services.<P>
-
-<P><HR>
-<A NAME="name-overview">
-<H3> Overview of Naming Service</H3>
-
-A Naming Service associates names with values in a distributed
-system. Clients can query these values using these names as keys. Such
-a name-to-value association is called a <I> Name Binding </I>. Name
-bindings are defined relative to a <I> Naming Context </I>. A naming
-context is a collection that contains a set of name bindings in which
-each name is unique. Different names can be bound to the same value in
-the same or different naming contexts at the same time. There are
-three types of naming contexts: <P>
-
-<OL>
-<LI> Process Local Naming Context: Name bindings are accessible from
-processes with the same name running on the same host. <P>
-<LI> Node Local Naming Context: Name bindings are accessible from all
-processes running on the same host. <P>
-<LI> Network Local Naming Context: Name bindings are accessible from
-all processes running on any machine within a (sub)network. <P>
-</OL>
-
-<P>
-To bind a name is to create a name binding in a given context.
-Querying a value using a name determines the value associated with the
-name in a given context. Note that a name is always bound relative to
-a context. Thus, there are no absolute names. <P>
-
-The following are the key classes in the ACE Naming Service: <P>
-
-<UL>
-<LI> <B><TT> Class Naming_Context </TT></B> <P>
-
-This is the main class ``entry point'' into the Naming Service. It is
-used both by client processes and by server process. It manages access
-to the appropriate Name/Binding database (that is the file where
-Name/Bindings are stored) and it also manages the communication
-between a client process and the server (by using class Name_Proxy,
-which is a private member of Naming_Context). If a client process
-runs on the same host as the server no IPC is necessary because the
-Naming_Context uses shared memory. <P>
-
-<LI> <B><TT> Class Name_Acceptor </TT></B> <P>
-
-The Name_Acceptor allocates in its handle_input() routine a new
-instance of class Name_Handler on the heap, and accepts connections
-into this Name_Handler. <P>
-
-<LI> <B><TT> Class Name_Handler </TT></B> <P>
-
-The class Name_Handler represents the server side of communication
-between client and server. It interprets incoming requests to the
-Net_Local namespace and delegates the requests to its own
-Naming_Context (which is the Net_Local namespace on the current
-host). For communication it uses the helper classes Name_Request and
-Name_Reply.<P>
-
-<LI> <B> Dependencies </B> <P>
-
-The ACE Naming Service uses ACE_WString String classes since it must
-handle wide character strings in order to support
-internationalization. <P>
-</UL>
-
-The following describes how to configure the Name_Server server and
-client test applications. <P>
-
-<UL>
-<LI> <B> Startup configuration </B> <P>
-Configuring a Name_Server server or client requires specifying all or
-some of the following parameters. These parameters can be passed in to
-main through command line as follows:<P>
-
-<TABLE cellpadding = 10 cellspacing = 0 border = 5>
-<TD VALIGN = TOP ALIGN = LEFT>
-<B> Option </B>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-<B> Description </B>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-<B> Default value </B>
-</TD>
-<TR>
-<TD VALIGN = TOP ALIGN = LEFT>
--c &ltnaming context&gt <BR>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-Naming Context to use. Can be either "PROC_LOCAL" or "NODE_LOCAL" or
-"NET_LOCAL" <BR>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-PROC_LOCAL
-</TD>
-<TR>
-<TD VALIGN = TOP ALIGN = LEFT>
--h &lthostname&gt
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-Specify the server hostname (needed by Name Server clients for
-PROC_LOCAL naming context)
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-ACE_DEFAULT_SERVER_HOST
-</TD>
-<TR>
-<TD VALIGN = TOP ALIGN = LEFT>
--p &ltnameserver port&gt <BR>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-Port number where the server process expects requests <BR>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-ACE_DEFAULT_SERVER_PORT
-</TD>
-<TR>
-<TD VALIGN = TOP ALIGN = LEFT>
--l &ltnamespace dir&gt <BR>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-Directory that holds the NameBinding databases <BR>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-ACE_DEFAULT_NAMESPACE_DIR
-</TD>
-<TR>
-<TD VALIGN = TOP ALIGN = LEFT>
--P &ltprocess name&gt <BR>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-Name of the client process
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-argv[0]
-</TD>
-<TR>
-<TD VALIGN = TOP ALIGN = LEFT>
--s &ltdatabase name&gt <BR>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-Name of the database. NameBindings for the appropriate naming context
-are stored in file &ltnamespace_dir&gt/&ltdatabase name&gt.
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-<I> null </I>
-</TD>
-<TR>
-<TD VALIGN = TOP ALIGN = LEFT>
--d &ltdebug&gt
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-Turn debugging on/off
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-0 (off)
-</TD>
-<TR>
-<TD VALIGN = TOP ALIGN = LEFT>
--T &lttrace&gt
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-Turn tracing on/off
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-0 (off)
-</TD>
-<TR>
-<TD VALIGN = TOP ALIGN = LEFT>
--v &ltverbose&gt
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-Turn verbose on/off
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-0 (off)
-</TD>
-
-</TABLE>
-<P>
-
-<LI><B>Examples</B><P>
-<OL>
-<LI> Here is what a config file would look like for starting up a
-server at port 20222 using NET_LOCAL naming context with database
-called MYDATABSE located in directory /tmp:
-
-<PRE> <CODE>
-dynamic Naming_Service Service_Object *
- ../lib/netsvcs:_make_ACE_Name_Acceptor()
- "-p 20222 -c NET_LOCAL -l /tmp -s MYDATABASE"
-</PRE> </CODE>
-
-<LI> Here is what a config file would look like for starting up a
-client that connects to a Name Server running on host
-tango.cs.wustl.edu at port 20222:
-
-<PRE> <CODE>
-dynamic Naming_Service_Client Service_Object *
- ../lib/netsvcs:_make_Client_Test()
- "-h tango.cs.wustl.edu -p 20222"
-</PRE> </CODE>
-</OL>
-
-Note:<P>
-<UL>
-<LI> These files would vary if the services are run on NT. For
-example, instead of using *.so, we would have to use *.dll.<P>
-<LI> Values for parameters can also be passed in using environment
-variables. For example, instead of specifying absolute hostname or
-port numbers in the config file, we can use $HOST and $PORT,
-respectively, in the file (assuming that these environment variables
-have been set). <P>
-<LI> If the environment variable LD_LIBRARY_PATH (in the case of UNIX)
-or PATH (in the case of Win32) contains the path to the shared object
-files or dll, then the config file can be further simplified. Instead
-of specifying an absolute path to the shared object or dll, only the
-name of the shared object or dll would suffice. That is, the Service
-Configurator makes use of LD_LIBRARY_PATH (on UNIX) or PATH (on Win32)
-to look for the shared object files or dlls.
-</UL>
-
-</UL>
-
-<P><HR><P>
-<A NAME="time-overview">
-<H3> Overview of Time Service</H3>
-
-Time Service provides accurate, fault-tolerant clock synchronization
-for computers collaborating in local area networks and wide area
-networks. Synchronized time services are important in distributed
-systems that require multiple hosts to maintain accurate global
-time. The architecture of the distributed time service contains the
-following Time Server, Clerk, and Client components: <P>
-
-<UL>
-<LI> <I> Time Server </I> answers queries about the time made by
-Clerks. <P>
-
-<LI> <I> Clerk </I> queries one or more Time Servers to determine
-the correct time, calculates the approximate correct time using one of
-several distributed time algorithms and updates its own local system
-time. <P>
-
-<LI> <I> Client </I> uses the global time information maintained by
-a Clerk to provide consistency with the notion of time used by clients
-on other hosts. <P>
-</UL>
-<P>
-The following are the key classes in the ACE Time Service: <P>
-
-<UL>
-<LI> <B><TT> Class TS_Server_Handler </TT></B> <P>
-
-TS_Server_Handler represents the server side of communication between
-clerk and server. It interprets incoming requests for time updates,
-gets the system time, creates a reply in response to the request and
-then sends the reply to the clerk from which it received the request.
-For communication it uses the helper class Time_Request.<P>
-
-<LI> <B><TT> Class TS_Server_Acceptor </TT></B> <P>
-
-TS_Server_Acceptor allocates in its handle_input routine a new instance
-of class TS_Server_Handler on the heap, and accepts connections into this
-TS_Server_Handler.<P>
-
-<LI> <B><TT> Class TS_Clerk_Handler </TT></B> <P>
-
-TS_Clerk_Handler represents the clerk side of communication between
-clerk and server. It generates requests for time updates every timeout
-period and then sends these requests to all the servers it is
-connected to asynchronously. It receives the replies to these requests
-from the servers through its handle_input method and then adjusts the
-time using the roundtrip estimate. It caches this time, which is
-subsequently retrieved by TS_Clerk_Processor.<P>
-
-<LI> <B><TT> Class TS_Clerk_Processor </TT></B> <P>
-
-TS_Clerk_Processor creates a new instance of TS_Clerk_Handler for
-every server connection it needs to create. It periodically calls
-send_request() of every TS_Clerk_Handler to send a request for time
-update to all the servers. In the process, it retrieves the latest
-time cached by each TS_Clerk_Handler and then uses it to compute its
-notion of the local system time.<P>
-
-<LI> <B> Algorithms </B> <P>
-
-Currently, updating the system time involves taking the average of all
-the times received from the servers.<P>
-</UL>
-
-The following is a description of how to configure the Time Server
-clerk and server services: <P>
-
-<UL>
-
-<LI> <B> Startup configuration </B> <P>
-
-Configuring a server requires specifying the port number of the
-server. This can be specified as a command line argument as follows: <P>
-
- -p &ltport number&gt
-
-<P>
-A clerk communicates with one or more server processes. To communicate
-with the server process, a client needs to know the INET_Addr, where
-the server offers its service. The configuration parameters namely the
-server port and server host are passed as command line arguments when
-starting up the clerk service as follows: <P>
-
- -h &ltserver host1&gt:&ltserver port1&gt -h &ltserver host2&gt:&ltserver port2&gt ...
-<P>
-Note that multiple servers can be specified in this manner for the
-clerk to connect to when it starts up. The server name and the port
-number need to be concatenated and separated by a ":". In addition,
-the timeout value can also be specified as a command line argument as
-follows:
-<P>
-
- -t timeout
-
-<P>
-The timeout value specifies the time interval at which the clerk
-should query the servers for time updates.
-<P>
-By default a Clerk does a non-blocking connect to a server. This can
-be overridden and a Clerk can be made to do a blocking connect by
-using the -b flag.
-<P>
-
-<LI> <B>Examples</B> <P>
-<OL>
-<LI> Here is what a config file would look like for starting up a
-server at port 20202:
-
-<PRE> <CODE>
-dynamic Time_Service Service_Object *
- ../lib/netsvcs:_make_ACE_TS_Server_Acceptor()
- "-p 20202"
-</PRE> </CODE>
-
-<LI> Here is what a config file would look like for starting up a
-clerk that needs to connect to two servers, one at tango and one at
-lambada:
-
-<PRE> <CODE>
-dynamic Time_Server_test Service_Object *
- ../lib/netsvcs:_make_ACE_TS_Clerk_Connector ()
- "-h tango:20202 -h lambada:20202 -t 4"
-</PRE> </CODE>
-</OL>
-
-Note:<P>
-<UL>
-<LI> These files would vary if the services are run on NT. For
-example, instead of using *.so, we would have to use *.dll.<P>
-<LI> Values for parameters can also be passed in using environment
-variables. For example, instead of specifying absolute hostname or
-port numbers in the config file, we can use $HOST and $PORT,
-respectively, in the file (assuming that these environment variables
-have been set). <P>
-<LI> If the environment variable LD_LIBRARY_PATH (in the case of UNIX)
-or PATH (in the case of Win32) contains the path to the shared object
-files or dll, then the config file can be further simplified. Instead
-of specifying an absolute path to the shared object or dll, only the
-name of the shared object or dll would suffice. That is, the Service
-Configurator makes use of LD_LIBRARY_PATH (on UNIX) or PATH (on Win32)
-to look for the shared object files or dlls.
-</UL>
-<P>
-
-</UL>
-
-<P><HR><P>
-<H3><A NAME="token-overview">Token Service</A></H3>
-
-The ACE Token Service provides local and remove mutexes and
-readers/writer locks. For information regarding the deadlock
-detection algorithm, check out ACE_Token_Manager.h. For information
-about an implementation of the Composite Pattern for Tokens, check out
-Token_Collection.h. The classes which implement the local and remote
-synchronization primitives are listed below:<P>
-
-<UL>
- <LI> <B><TT>ACE_Local_Mutex</TT></B><P>
-
- This class is a more general-purpose synchronization mechanism
- than SunOS 5.x mutexes. For example, it implements "recursive
- mutex" semantics, where a thread that owns the token can
- reacquire it without deadlocking. In addition, threads that
- are blocked awaiting the token are serviced in strict FIFO
- order as other threads release the token (SunOS 5.x mutexes
- don't strictly enforce an acquisition order). Lastly,
- ACE_Local_Mutex performs deadlock detection on acquire
- calls.<p>
-
- <LI> <B><TT>ACE_Remote_Mutex</TT></B><P>
-
- This is the remote equivalent to ACE_Local_Mutex. The
- Remote_Mutex class offers methods for acquiring, renewing, and
- releasing a distributed synchronization mutex. Similar to
- ACE_Local_Mutex, ACE_Remote_Token_Proxy offers recursive
- acquisition, FIFO waiter ordering, and deadlock detection. It
- depends on the Token Server for its distributed synchronization
- semantics.<p>
-
- <LI> <B><TT>ACE_Local_RLock</TT></B><P>
-
- This class implements the reader interface to canonical
- readers/writer locks. Multiple readers can hold the lock
- simultaneously when no writers have the lock. Alternatively,
- when a writer holds the lock, no other participants (readers or
- writers) may hold the lock. This class is a more
- general-purpose synchronization mechanism than SunOS 5.x
- RLocks. For example, it implements "recursive RLock"
- semantics, where a thread that owns the token can reacquire it
- without deadlocking. In addition, threads that are blocked
- awaiting the token are serviced in strict FIFO order as other
- threads release the token (SunOS 5.x RLockes don't strictly
- enforce an acquisition order).<P>
-
- <LI> <B><TT>ACE_Local_WLock</TT></B><P>
-
- This class implements the writer interface to canonical
- readers/writer locks. Multiple readers can hold the lock
- simultaneously when no writers have the lock. Alternatively,
- when a writer holds the lock, no other participants (readers or
- writers) may hold the lock. This class is a more
- general-purpose synchronization mechanism than SunOS 5.x WLock.
- For example, it implements "recursive WLock" semantics, where a
- thread that owns the token can reacquire it without
- deadlocking. In addition, threads that are blocked awaiting
- the token are serviced in strict FIFO order as other threads
- release the token (SunOS 5.x WLocks don't strictly enforce an
- acquisition order).<P>
-
- <LI> <B><TT>ACE_Remote_RLock</TT></B><P>
-
- This is the remote equivalent to ACE_Local_RLock. Multiple
- readers can hold the lock simultaneously when no writers have
- the lock. Alternatively, when a writer holds the lock, no
- other participants (readers or writers) may hold the lock.
- ACE_Remote_RLock depends on the ACE Token Server for its
- distributed synchronization semantics.<P>
-
- <LI> <B><TT>ACE_Remote_RLock</TT></B><P>
-
- This is the remote equivalent to ACE_Local_WLock.<P>
-</UL>
-
-The Token Server provides distributed mutex and readers/writer lock
-semantics to the ACE Token library. ACE_Remote_Mutex,
-ACE_Remote_RLock, and ACE_Remote_WLock, are proxies to the Token
-Server. The following are the key classes in the ACE Token
-Server:<P>
-
-<UL>
- <LI> <B><TT>class Token_Acceptor</TT></B><P>
-
- The Token_Acceptor is a Token_Handler factory. It accepts
- connections and passes the service responsibilities off to a
- new Token_Handler.<p>
-
- <LI> <B><TT>class Token_Handler</TT></B><P>
-
- This class is the main class ``entry point'' of the ACE Token service. It
- receives token operation requests from remote clients and turns
- them into calls on local tokens (acquire, release, renew, and
- remove). In OMG CORBA terminology, it is an ``Object Adapter.'' It also
- schedules and handles timeouts that are used to support "timed
- waits." Clients used timed waits to bound the amount of time
- they block trying to get a token.<P>
-</UL>
-
-The following describes how to configure the Token Server:<P>
-<UL>
- <LI> <b>Startup configuration</B><P>
-
- The only parameter that the Token Server takes is a listen port
- number. You can specify a port number by passing a "-p
- <port_number>" to the application. This can be done via the
- svc.conf file.<P>
-
- <LI> <B>Examples </B><P>
-
- Here is an example NT svc.conf entry that dynamically loads the
- Token Server specifying port number to listen on for client
- connections:<P>
-
- <code><pre>
- dynamic Token_Service Service_Object *
- ../lib/netsvcs:_make_ACE_Token_Acceptor()
- "-p 10202"
- </code></pre>
- <P>
-
- Here is an example UNIX svc.conf entry that dynamically loads the
- Token Server specifying port number to listen on for client
- connections. Notice that only the name of the library file
- changed:<P>
-
- <code><pre>
- dynamic Token_Service Service_Object *
- ../lib/netsvcs:_make_ACE_Token_Acceptor()
- "-p 10202"
- </code></pre>
-</UL>
-Note:<P>
-<UL>
-<LI> These files would vary if the services are run on NT. For
-example, instead of using *.so, we would have to use *.dll.<P>
-<LI> Values for parameters can also be passed in using environment
-variables. For example, instead of specifying absolute hostname or
-port numbers in the config file, we can use $HOST and $PORT,
-respectively, in the file (assuming that these environment variables
-have been set). <P>
-<LI> If the environment variable LD_LIBRARY_PATH (in the case of UNIX)
-or PATH (in the case of Win32) contains the path to the shared object
-files or dll, then the config file can be further simplified. Instead
-of specifying an absolute path to the shared object or dll, only the
-name of the shared object or dll would suffice. That is, the Service
-Configurator makes use of LD_LIBRARY_PATH (on UNIX) or PATH (on Win32)
-to look for the shared object files or dlls.
-</UL>
-
-
-<P><HR><P>
-<A NAME="server-logging-overview">
-<H3>Overview of Server Logging Service</H3>
-
-The Server Logging Service provides a concurrent, multi-service daemon
-that processes logging records received from one or more client hosts
-simultaneously. The object-oriented design of the Server Logging
-Service is decomposed into several modular components that perform
-well-defined tasks. <P>
-
-The following are the key classes in the Server Logging Service: <P>
-<UL>
-<LI> <B> <TT> Server_Logging_Handler </TT> </B> <P>
-The Server_Logging_Handler class is a parameterized type that is
-responsible for processing logging records sent to the Server from
-participating client hosts. When logging records arrive from the
-client host associated with a particular Logging Handler object, the
-handle_input() method of the Server_Logging_Handler class is called
-which in turn formats and displays the records on one or more output
-devices (such as the printer, persistent storage, and/or console
-devices. <P>
-
-<LI> <B> <TT> Server_Logging_Acceptor </TT> </B> <P>
-The class Server_Logging_Acceptor allocates in its handle_input()
-routine a new instance of class Server_Logging_Handler on the heap,
-and accepts connections into this Server_Logging_Handler. <P>
-</UL>
-
-The following describes how to configure the Logging Server:<P>
-<UL>
- <LI> <b>Startup configuration</B><P>
-
- The only parameter that the Logging Server takes is a listen
- port number. You can specify a port number by passing a "-p
- <port_number>" to the application. This can be done via the
- svc.conf file.<P>
-
- <LI> <B>Examples </B><P>
-
- Here is an example NT svc.conf entry that dynamically loads the
- Logging Server specifying port number to listen on for client
- connections:<P>
-
- <PRE> <CODE>
- dynamic Server_Logging_Service Service_Object *
- ../lib/netsvcs:_make_ACE_Server_Logging_Acceptor()
- "-p 10202"
- </PRE></CODE>
- <P>
-
- Here is an example UNIX svc.conf entry that dynamically loads the
- Logging Server specifying port number to listen on for client
- connections. Notice that only the name of the library file
- changed:<P>
-
- <PRE> <CODE>
- dynamic Server_Logging_Service Service_Object *
- ../lib/netsvcs:_make_ACE_Server_Logging_Acceptor()
- "-p 10202"
- </PRE></CODE>
-</UL>
-Note:<P>
-<UL>
-<LI> These files would vary if the services are run on NT. For
-example, instead of using *.so, we would have to use *.dll.<P>
-<LI> Values for parameters can also be passed in using environment
-variables. For example, instead of specifying absolute hostname or
-port numbers in the config file, we can use $HOST and $PORT,
-respectively, in the file (assuming that these environment variables
-have been set). <P>
-<LI> If the environment variable LD_LIBRARY_PATH (in the case of UNIX)
-or PATH (in the case of Win32) contains the path to the shared object
-files or dll, then the config file can be further simplified. Instead
-of specifying an absolute path to the shared object or dll, only the
-name of the shared object or dll would suffice. That is, the Service
-Configurator makes use of LD_LIBRARY_PATH (on UNIX) or PATH (on Win32)
-to look for the shared object files or dlls.
-</UL>
-
-<P><HR><P>
-<A NAME="client-logging-overview">
-<H3>Overview of Client Logging Service</H3>
-
-The Client Logging Service multiplexes messages recevied from
-different applications to the Server Logging Daemon running on a
-designated host in a network/internetwork.
-
-
-The following are the key classes in the Client Logging Service: <P>
-<UL>
-<LI> <B> <TT> Client_Logging_Handler </TT> </B> <P>
-The Client_Logging_Handler class is a parameterized type that is
-responsible for setting up a named pipe and using it to communicate
-with different user processes on the same host. Once logging records
-arrive from these processes, the handler reads these records in
-priority order, performs network-byte order conversions on
-multiple-header fields, and then transmits these records to the Server
-Logging daemon across the network. <P>
-
-<LI> <B> <TT> Client_Logging_Connector </TT> </B> <P>
-The class Client_Logging_Connector connects to the Server Logging
-daemon and then in its handle_input() routine it allocates a new
-instance of the Client_Logging_Handler on the heap. <P>
-</UL>
-
-The following describes how to configure the Logging Client:<P>
-<UL>
- <LI> <b>Startup configuration</B><P>
-
-Configuring a Logging Client requires specifying all or some of the
-following parameters. These parameters can be passed in to main
-through command line as follows:<P>
-
-<TABLE cellpadding = 10 cellspacing = 0 border = 5>
-<TD VALIGN = TOP ALIGN = LEFT>
-<B> Option </B>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-<B> Description </B>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-<B> Default value </B>
-</TD>
-<TR>
-<TD VALIGN = TOP ALIGN = LEFT>
--h &hostname&gt <BR>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-Hostname of the Server Logging Daemon <BR>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-ACE_DEFAULT_SERVER_HOST
-</TD>
-<TR>
-<TD VALIGN = TOP ALIGN = LEFT>
--p &ltport number&gt
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-Port number of the Server Logging Daemon <BR>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-ACE_DEFAULT_LOGGING_SERVER_PORT
-</TD>
-<TR>
-<TD VALIGN = TOP ALIGN = LEFT>
--p &ltrendezvous key&gt
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-Rendezvous key used to create named pipe
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
-ACE_DEFAULT_RENDEZVOUS
-</TD>
-</TABLE>
-<P>
-
- <LI> <B>Examples </B><P>
-
- Here is an example NT svc.conf entry that dynamically loads the
- Logging Client specifying host name and port number of the
- Logging Server: <P>
-
- <PRE> <CODE>
- dynamic Client_Logging_Service Service_Object *
- ../lib/netsvcs:_make_ACE_Client_Logging_Connector()
- "-h tango.cs.wustl.edu -p 10202"
- </PRE></CODE>
- <P>
-
- Here is an example UNIX svc.conf entry that dynamically loads the
- Logging Client specifying host name and port number of the
- Logging Server. Notice that only the name of the library file
- changed:<P>
-
- <PRE> <CODE>
- dynamic Client_Logging_Service Service_Object *
- ../lib/netsvcs:_make_ACE_Client_Logging_Connector()
- "-h tango.cs.wustl.edu -p 10202"
- </PRE></CODE>
-</UL>
-Note:<P>
-<UL>
-<LI> These files would vary if the services are run on NT. For
-example, instead of using *.so, we would have to use *.dll.<P>
-<LI> Values for parameters can also be passed in using environment
-variables. For example, instead of specifying absolute hostname or
-port numbers in the config file, we can use $HOST and $PORT,
-respectively, in the file (assuming that these environment variables
-have been set). <P>
-<LI> If the environment variable LD_LIBRARY_PATH (in the case of UNIX)
-or PATH (in the case of Win32) contains the path to the shared object
-files or dll, then the config file can be further simplified. Instead
-of specifying an absolute path to the shared object or dll, only the
-name of the shared object or dll would suffice. That is, the Service
-Configurator makes use of LD_LIBRARY_PATH (on UNIX) or PATH (on Win32)
-to look for the shared object files or dlls.
-</UL>
-
-<P><HR><P>
-<A NAME="logging-strategy-overview">
-<H3> Overview of Logging Strategy Service</H3>
-
-The Logging Strategy Service can be used to control the output of all the
-network services. It can be invoked with certain flags that determine
-where the output of all the services should go. The Logging Strategy
-Service sets the flags in ACE_Log_Msg, which controls all the streams
-through macros such as ACE_DEBUG, ACE_ERROR, and ACE_ERROR_RETURN. If
-default behavior is required, the Logging Strategy Service need not be
-invoked or it can be invoked with no parameters. <P>
-
-The following describes how to configure the Logging Strategy
-Service:<p>
-
-<UL>
-<LI> <b>Startup configuration</B><P>
-
-Here are the command line arguments that can be given to the Logging
-Strategy Service: <P>
-
- -f &ltflag1&gt|&ltflag2&gt|&ltflag3&gt (etc...) <P>
-
- where a flag can be any of the following: <P>
-
-<TABLE cellpadding = 10 cellspacing = 0 border = 5>
-<TD VALIGN = TOP ALIGN = LEFT>
- <B> Flags </B>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
- <B> Description </B>
-</TD>
-<TR>
-<TD VALIGN = TOP ALIGN = LEFT>
- STDERR <BR>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
- Write messages to stderr. <BR>
-</TD>
-<TR>
-<TD VALIGN = TOP ALIGN = LEFT>
- LOGGER <BR>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
- Write messages to the local client logger deamon. <BR>
-</TD>
-<TR>
-<TD VALIGN = TOP ALIGN = LEFT>
- OSTREAM <BR>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
- Write messages to the ostream that gets created by specifying a
- filename (see below) <BR>
-</TD>
-<TR>
-<TD VALIGN = TOP ALIGN = LEFT>
- VERBOSE <BR>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
- Display messages in a verbose manner <BR>
-</TD>
-<TR>
-<TD VALIGN = TOP ALIGN = LEFT>
- SILENT <BR>
-</TD>
-<TD VALIGN = TOP ALIGN = LEFT>
- Do not print messages at all <BR>
-</TD>
-
-</TABLE>
-<P>
-
-Note: If more than one flag is specified, the flags need to be 'OR'ed
-as above syntax shows. Make sure there is no space in between the flag
-and '|'. <P>
-
- -s filename
- <P>
-
-If the OSTREAM flag is set, this can be used to specify the filename
-where the output should be directed. Note that if the OSTREAM flag is
-set and no filename is specified, ACE_DEFAULT_LOGFILE will be used to
-write the output to. <P>
-
-<LI> <B> Examples: </B> <P>
-<OL>
-<LI> To direct output only to STDERR, specify command line arguments as: <P>
- "-f STDERR"
-<P>
-
-<LI> To direct output to both STDERR and a file called "mylog", specify
-command line arguments as: <P>
- "-f STDERR|OSTREAM -s mylog"
-</OL>
-Note:<P>
-<UL>
-<LI> These files would vary if the services are run on NT. For
-example, instead of using *.so, we would have to use *.dll.<P>
-<LI> Values for parameters can also be passed in using environment
-variables. For example, instead of specifying absolute hostname or
-port numbers in the config file, we can use $HOST and $PORT,
-respectively, in the file (assuming that these environment variables
-have been set). <P>
-<LI> If the environment variable LD_LIBRARY_PATH (in the case of UNIX)
-or PATH (in the case of Win32) contains the path to the shared object
-files or dll, then the config file can be further simplified. Instead
-of specifying an absolute path to the shared object or dll, only the
-name of the shared object or dll would suffice. That is, the Service
-Configurator makes use of LD_LIBRARY_PATH (on UNIX) or PATH (on Win32)
-to look for the shared object files or dlls.
-</UL>
-</UL>
-
-<P><HR><P>
-Back to the <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">
-ACE</A> home page.
-<!--#include virtual="/~schmidt/cgi-sig.html" -->
-</BODY>
-</HTML>