diff options
Diffstat (limited to 'apps/Gateway/README')
| -rw-r--r-- | apps/Gateway/README | 67 |
1 files changed, 39 insertions, 28 deletions
diff --git a/apps/Gateway/README b/apps/Gateway/README index ffd7e52bdf4..ce0c97856be 100644 --- a/apps/Gateway/README +++ b/apps/Gateway/README @@ -1,9 +1,10 @@ OVERVIEW -This directory contains source code for a prototype application-level -gateway implemented with ACE. This prototype was developed in my -cs422 OS class at Washington University. It illustrates the use of -Event Channels to forward events from Suppliers to Consumers in a +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 @@ -17,33 +18,33 @@ There are 2 directories: Gateway - -- The application Gateway, which must be started *after* all - the Peers described below). This process reads the - connection_config and consumer_config files: + -- 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 connection_config file is used to establish the "physical - configuration." It tells the Gateway what connections - to establish with particular hosts using particular - ports. + 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 "sources" to the appropriate - "destinations." + data coming from Suppliers to the appropriate + Consumers. Peer - -- The test driver programs that must be started *before* the - Gateway. 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: + -- 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 - connection_config configuration file). These Peers are + proxy_config configuration file). These Peers are "suppliers" of events to the Gateway. 2. Consumer Peers (designated by an 'C' in the Gateway's - connection_config file). These Peers are "consumers" of + 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). @@ -54,18 +55,27 @@ 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 connection_config files as discussed - above to indicate the desired physical and logical mappings. +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 connection_config file, but you'll need at least - two (one to supply and one to consume). I typically start up each + 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 - should print out some diagnostic info and then block awaiting + will print out some diagnostic info and then block awaiting connections from the Gateway. 4. Start up the Gateway (gatewayd). This will print out a bunch of - events as it reads the config files and connects to all the Peers. + 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 @@ -82,8 +92,9 @@ To run the tests do the following: 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 and the process - will shut down gracefully. +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. |