This file describes how to invoke the Reactor client/server tests in
the $ACE_ROOT/tests/Reactor/{client,server} directories.

These tests exercise all of the IPC_SAP communication mechanisms, the
Reactor event demultiplexor, and the Service Configurator dynamic
service configuration framework.  To gain a deeper understanding of
what is going on, you should read the IPC_SAP.ps, reactor-[1-3].ps,
and service_configurator.ps papers available for anonymous ftp from
ics.uci.edu in the ftp/gnu/C++_wrappers_doc.tar.Za[a-c] files.

The key to running the Reactor client/server tests is to understand
the purpose of the svc.conf file located in the
$ACE_ROOT/tests/Reactor/server directory.  This file contains a
list of services that may be dynamically configured into a the address
space of a network daemon process.  If you look at the example
svc.conf file included in the Reactor tests you'll see that most of
the entries are commented out (the comment symbol is the '#', which is
an "ignore until end-of-line comment" with the same semantics as the
UNIX C and Bourne shells).  Before reading any further, take a look at
this svc.conf file with your favorite editor or file browser.

There are several types of entries in this file.  The two most
important are the lines beginning with the keywords "static" and
"dynamic".  For example, the first non-commented line says:

static ACE_Service_Manager "-d -p 3911"

When this line is parsed at startup time by the Service Configurator
object in the ./server_test executable, it causes the pre-configured
Svc_Manager object to be initialized with an "argv" argument of "-d -p
3911."  This results in TCP port 3911 being created to listen
connection requests from clients.  To see how this works do the
following:

1. Comment out all the other lines except 

static Svc_Manager "-d -p 3911"

   in the svc.conf file

2. Start up the ./server_test executable in one window, as follows:

	% ./server_test -d

3. Make another window on the *same* host and cd to the ../client
   directory 

4. Run the ./remote_service_directory_test program as follows:

	% ./remote_service_directory_test -p 3911 -h localhost

If everything has been compiled and initialized correctly, you should
get the following message:

	Svc_Manager 3911/tcp # lists all services in the daemon

This message is telling you that the Svc_Manager is currently the only
service that is active within the ./server_test program.  To configure
and activate another service dynamically, perform the following steps:

1. *Without* shutting down the ./server_test program, edit the svc.conf
   file.  Comment out the Svc_Manager line by adding a '#' at the front, i.e.:

# static Svc_Manager "-d -p 3911"

   and then uncomment the second line:

dynamic Remote_Brdcast Service_Object * .obj/Handle_Broadcast.so:remote_broadcast "-p 10001"

2. Send the SIGHUP signal to the process running the ./server_test program
   (use "ps -gux" on SunOS 4.x or "ps -elf" on SunOS 5.x to find the
   correct process id).  This will cause the ./server_test program to
   reconfigure itself based on the new contents of the svc.conf file.
   After reconfiguration, you'll now have a second active service in
   the address space of the ./server_test daemon.  To see this, rerun
   the remote_service_directory_test command, e.g.:

	% ./remote_service_directory_test -p 3911 -h localhost

   You should now see the following output:
   
	Svc_Manager 3911/tcp # lists all services in the daemon
	Remote_Brdcast 10001/udp # tests broadcasting
   
   which indicates that the remote broadcast service is now active.

3. To test the remote broadcast service, run the following program
   in the ../client directory:

	% ./broadcast_client_test -p 10001

   This should cause the window running the ./server_test to 
   display the following output:

	received broadcast datagram from host spare.ics.uci.edu
	----------------------------------------
	testing socket broadcast service
	----------------------------------------

If you want to run other tests, using other configurations, simply
uncomment the appropriate lines in the svc.conf file and experiment
with the corresponding test drivers in the ../client directory.  All
the source code is available so once you get the hang of what is
happening, you might want to take a look at how it is all implemented.
I think you'll be surprised at how much of the ACE framework code is
reused for each different service.  Moreover, writing a new service is
often simply a matter of copying an existing file and filling in the
behavior of some of the methods (e.g., the handle_input() method and
the init() method).

The service_configurator.ps paper and the ACE.ps paper describe the
details of the Service Configurator framework.