diff options
Diffstat (limited to 'examples/Service_Configurator/IPC-tests/README')
| -rw-r--r-- | examples/Service_Configurator/IPC-tests/README | 112 |
1 files changed, 0 insertions, 112 deletions
diff --git a/examples/Service_Configurator/IPC-tests/README b/examples/Service_Configurator/IPC-tests/README deleted file mode 100644 index cb242ef616d..00000000000 --- a/examples/Service_Configurator/IPC-tests/README +++ /dev/null @@ -1,112 +0,0 @@ -This file describes how to invoke the Reactor client/server tests in -the $WRAPPER_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 -$WRAPPER_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. |