Overview of Naming Service

1. Process Local Naming Context: Name bindings are accessible from processes with the same name running on the same host.

2. Node Local Naming Context: Name bindings are accessible from all processes running on the same host.

3. Network Local Naming Context: Name bindings are accessible from all processes running on any machine within a (sub)network.

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.

The following are the key classes in the ACE Naming Service:

• Class Naming_Context

  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.

• Class Name_Acceptor

  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.

• Class Name_Handler

  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.

• Dependencies

  The ACE Naming Service uses ACE_WString String classes since it must handle wide character strings in order to support internationalization.

• Startup configuration

  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:

  Option	Description	Default value
  -c <naming context>	Naming Context to use. Can be either "PROC_LOCAL" or "NODE_LOCAL" or "NET_LOCAL"	PROC_LOCAL
  -h <hostname>	Specify the server hostname (needed by Name Server clients for PROC_LOCAL naming context)	ACE_DEFAULT_SERVER_HOST
  -p <nameserver port>	Port number where the server process expects requests	ACE_DEFAULT_SERVER_PORT
  -l <namespace dir>	Directory that holds the NameBinding databases	ACE_DEFAULT_NAMESPACE_DIR
  -P <process name>	Name of the client process	argv[0]
  -s <database name>	Name of the database. NameBindings for the appropriate naming context are stored in file <namespace_dir>/<database name>.	null
  -d <debug>	Turn debugging on/off	0 (off)
  -T <trace>	Turn tracing on/off	0 (off)
  -v <verbose>	Turn verbose on/off	0 (off)

• Examples
  1. 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:

      
     dynamic Naming_Service Service_Object *
       ../lib/netsvcs:_make_ACE_Name_Acceptor()
       "-p 20222 -c NET_LOCAL -l /tmp -s MYDATABASE"
     

  2. 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:

      
     dynamic Naming_Service_Client Service_Object *
       ../lib/netsvcs:_make_Client_Test()
       "-h tango.cs.wustl.edu -p 20222"
     

  Note:
  • 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).

  • 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 a 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.

• Time Server answers queries about the time made by Clerks.

• Clerk 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.

• Client uses the global time information maintained by a Clerk to provide consistency with the notion of time used by clients on other hosts.

The following are the key classes in the ACE Time Service:

• Class TS_Server_Handler

  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.

• Class TS_Server_Acceptor

  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.

• Class TS_Clerk_Handler

  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.

• Class TS_Clerk_Processor

  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.

• Algorithms

  Currently, updating the system time involves taking the average of all the times received from the servers.

• Startup configuration

  Configuring a server requires specifying the port number of the server. This can be specified as a command line argument as follows:

  -p <port number>

  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:

  -h <server host1>:<server port1> -h <server host2>:<server port2> ...

  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:

  -t timeout

  The timeout value specifies the time interval at which the clerk should query the servers for time updates.

  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.

• Examples
  1. Here is what a config file would look like for starting up a server at port 20202:

      
     dynamic Time_Service Service_Object *
       ../lib/netsvcs:_make_ACE_TS_Server_Acceptor()
       "-p 20202"
     

  2. 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:

      
     dynamic Time_Server_test Service_Object *
       ../lib/netsvcs:_make_ACE_TS_Clerk_Connector ()
       "-h tango:20202 -h lambada:20202 -t 4"
     

  Note:
  • These files would vary if the services are run on NT. For example, instead of using *.so, we would have to use *.dll.

  • 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).

  • 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 a 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.

The following are the key classes in the Server Logging Service:

• Server_Logging_Handler

  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.

• Server_Logging_Acceptor

  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.

• Startup configuration

  The only parameter that the Logging Server takes is a listen port number. You can specify a port number by passing a "-p " to the application. This can be done via the svc.conf file.

• Examples

  Here is an example svc.conf entry that dynamically loads the Logging Server specifying port number to listen on for client connections:

   
        dynamic Server_Logging_Service Service_Object *
          ../lib/netsvcs:_make_ACE_Server_Logging_Acceptor()
          "-p 10202"
        

• These files would vary if the services are run on NT. For example, instead of using *.so, we would have to use *.dll.

• 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).

• 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 a 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.

• Client_Logging_Handler

  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.

• Client_Logging_Connector

  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.

• Startup configuration

  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:

  Option	Description	Default value
  -h <hostname>	Hostname of the Server Logging Daemon	ACE_DEFAULT_SERVER_HOST
  -p <port number>	Port number of the Server Logging Daemon	ACE_DEFAULT_LOGGING_SERVER_PORT
  -p <rendezvous key>	Rendezvous key used to create named pipe	ACE_DEFAULT_RENDEZVOUS

• Examples

  Here is an example svc.conf entry that dynamically loads the Logging Client specifying host name and port number of the Logging Server:

   
        dynamic Client_Logging_Service Service_Object *
          ../lib/netsvcs:_make_ACE_Client_Logging_Connector()
          "-h tango.cs.wustl.edu -p 10202"
        

• These files would vary if the services are run on NT. For example, instead of using *.so, we would have to use *.dll.

• 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).

• 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 a 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.

The following describes how to configure the Logging Strategy Service:

• Startup configuration

  Here are the command line arguments that can be given to the Logging Strategy Service:

  -f <flag1>|<flag2>|<flag3> (etc...)

  where a flag can be any of the following:

  Flags	Description
  STDERR	Write messages to stderr.
  LOGGER	Write messages to the local client logger deamon.
  OSTREAM	Write messages to the ostream that gets created by specifying a filename (see below)
  VERBOSE	Display messages in a verbose manner
  SILENT	Do not print messages at all

  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 '|'.

  -s filename

  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.

• Examples:

  Here is an example svc.conf entry that dynamically loads the Logging Strategy Service specifying that the output be sent to STDERR:

   
        dynamic Logging_Strategy_Service Service_Object *
          ../lib/netsvcs:_make_ACE_Logging_Strategy()
          "-f STDERR"
        

  1. To direct output only to STDERR, specify command line arguments as:

     "-f STDERR"

  2. To direct output to both STDERR and a file called "mylog", specify command line arguments as:

     "-f STDERR|OSTREAM -s mylog"

  Note:
  • These files would vary if the services are run on NT. For example, instead of using *.so, we would have to use *.dll.

  • 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).

  • 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 a 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.