diff options
| author | levine <levine@ae88bc3d-4319-0410-8dbf-d08b4c9d3795> | 1996-10-21 21:41:34 +0000 |
|---|---|---|
| committer | levine <levine@ae88bc3d-4319-0410-8dbf-d08b4c9d3795> | 1996-10-21 21:41:34 +0000 |
| commit | a5fdebc5f6375078ec1763850a4ca23ec7fe6458 (patch) | |
| tree | bcf0a25c3d45a209a6e3ac37b233a4812f29c732 /netsvcs/ACE-netsvcs.html | |
| download | ATCD-a5fdebc5f6375078ec1763850a4ca23ec7fe6458.tar.gz | |
Initial revision
Diffstat (limited to 'netsvcs/ACE-netsvcs.html')
| -rw-r--r-- | netsvcs/ACE-netsvcs.html | 895 |
1 files changed, 895 insertions, 0 deletions
diff --git a/netsvcs/ACE-netsvcs.html b/netsvcs/ACE-netsvcs.html new file mode 100644 index 00000000000..1fef080dc3e --- /dev/null +++ b/netsvcs/ACE-netsvcs.html @@ -0,0 +1,895 @@ +<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 <A HREF="#service-overviews">network +services</A>:<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#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="NETSVC-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 <naming context> <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 <hostname> +</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 <nameserver port> <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 <namespace dir> <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 <process name> <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 <database name> <BR> +</TD> +<TD VALIGN = TOP ALIGN = LEFT> +Name of the database. NameBindings for the appropriate naming context +are stored in file <namespace_dir>/<database name>. +</TD> +<TD VALIGN = TOP ALIGN = LEFT> +<I> null </I> +</TD> +<TR> +<TD VALIGN = TOP ALIGN = LEFT> +-d <debug> +</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 <trace> +</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 <verbose> +</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/libnetsvcs.so:_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/libnetsvcs.so:_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 <port number> + +<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 <server host1>:<server port1> -h <server host2>:<server port2> ... +<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/libnetsvcs.so:_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/libnetsvcs.so:_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 * + ../../ace/libnet_svcs.dll:_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 * + ../../ace/netsvcs.so:_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 * + ../../ace/libnet_svcs.dll:_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 * + ../../ace/netsvcs.so:_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> <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 <port number> +</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 <rendezvous key> +</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 * + ../../ace/libnet_svcs.dll:_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 * + ../../ace/netsvcs.so:_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 <flag1>|<flag2>|<flag3> (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. |