diff options
Diffstat (limited to 'apps/Gateway/README')
| -rw-r--r-- | apps/Gateway/README | 126 |
1 files changed, 0 insertions, 126 deletions
diff --git a/apps/Gateway/README b/apps/Gateway/README deleted file mode 100644 index 7c087e2d25c..00000000000 --- a/apps/Gateway/README +++ /dev/null @@ -1,126 +0,0 @@ -OVERVIEW - -This directory contains source code for an application-level -Communication Gateway implemented with ACE. This prototype was -developed in my cs422 OS class at Washington University in 1994. The -Gateway has recently been updated to illustrate the use of ACE Event -Channels, which forward events from Suppliers to Consumers in a -distributed system. - -You can get a paper that explains the patterns used in this -implementation at the following WWW URL: - -http://www.cs.wustl.edu/~schmidt/TAPOS-95.ps.gz - -DIRECTORY STRUCTURE - -There are 2 directories: - -Gateway - - -- The application Gateway, which generally should be started - after all the Peers described below. This process reads the - proxy_config and consumer_config files: - - 1. The proxy_config file is used to establish the "physical - configuration" of the Consumer and Supplier proxies. It - tells the Gateway what connections to establish with - particular hosts using particular ports. - - 2. The consumer_config file is used to establish the "logical - configuration." It tells the Gateway how to forward - data coming from Suppliers to the appropriate - Consumers. -Peer - - -- The test driver programs, which generally should be started - before the Gateway process. To do anything interesting you'll - need at least two Peers: one to supply events and one to consume - events. In the configuration files, these two types of Peers - are designated as follows: - - 1. Supplier Peers (designated by an 'S' in the Gateway's - proxy_config configuration file). These Peers are - "suppliers" of events to the Gateway. - - 2. Consumer Peers (designated by an 'C' in the Gateway's - proxy_config file). These Peers are "consumers" of - events forwarded by the Gateway (forwarding is based on - the settings in the consumer_config configuration file). - - Note that in the current implementation, the same Peer - process (peerd) cannot serve as both a Consumer and - Supplier of Events. Naturally, multiple peerd processes - can work together to play these different roles. - -RUNNING THE TESTS - -To run the tests do the following: - -1. Compile everything (i.e., first compile the ACE libraries, then - compile the the Gateway directories). - -2. Edit the consumer_config and proxy_config files as discussed - above to indicate the desired physical and logical mappings - for Consumers and Suppliers. - -3. Start up the Peers (peerd). You can start up as many as you - like, as per the proxy_config file, but you'll need at least - two (i.e., one Supplier and Consumer). I typically start up each - Peer in a different window on a different machine. The Peers - will print out some diagnostic info and then block awaiting - connections from the Gateway. - - If you want to set the port numbers of the Peers from - the command-line do the following: - - a. Change the svc.conf file in the ./Peer/ directory to - another name (e.g., foo.conf). This will keep the - program from starting up with the svc.conf file - (which dynamically links in the Peers). - - b. Then run the peers in different windows as - - # Window 1 - % peerd -p 10003 - - # Window 2 - % peerd -p 10004 - - etc. - -4. Start up the Gateway (gatewayd). This will print out a bunch of - messages as it reads the config files and connects to all the Peers. - By default, the Gateway is purely reactive, i.e., it handles - Consumers and Suppliers in the same thread of control. However, - if you give the '-t OUTPUT_MT' option the Gateway will handle all - Consumers in separate threads. If you give the '-t INPUT_MT' option - the Gateway will handle all Suppliers in separate threads. If you - give the '-t INPUT_MT|OUTPUT_MT' option both Consumers and Suppliers - will be handled in the separate threads. - - Assuming everything works, then all the Peers will be connected. - If some of the Peers aren't set up correctly then the Gateway will - use an exponential backoff algorithm to attempt to reestablish - those connections. - -5. Once the Gateway has connected with all the Peers you can send - events from Supplier Peers by typing commands in the Peer window. - This Supplier will be sent to the Gateway, which will forward the - event to all Consumer Peers that have "subscribed" to receive these - events. - - Note that if you type ^C in a Peer window the Peer will shutdown - its handlers and exit. The Gateway will detect this and will start - trying to reestablish the connection using the same exponential - backoff algorithm it used for the initial connection establishment. - -7. When you want to terminate a Gateway, just type ^C or type any - characters in the ./gatewayd window and the process will shut down - gracefully. - -Please let me know if there are any questions. - - Doug - - schmidt@cs.wustl.edu |