summaryrefslogtreecommitdiff
path: root/apps/Gateway/README
diff options
context:
space:
mode:
Diffstat (limited to 'apps/Gateway/README')
-rw-r--r--apps/Gateway/README140
1 files changed, 0 insertions, 140 deletions
diff --git a/apps/Gateway/README b/apps/Gateway/README
deleted file mode 100644
index 2fe4e79c372..00000000000
--- a/apps/Gateway/README
+++ /dev/null
@@ -1,140 +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 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:
-
-1. Gateway
-
- This directory contains the source code for the
- application-level Gateway process, gatewayd. The gatewayd
- routes event messages between Peers. By default, the gatewayd
- plays the Connector role and initializes itself by reading the
- connection_config and consumer_config files:
-
- 1. The connection_config file establishes the "physical
- configuration" of the Consumer and Supplier proxies. This
- file tells the Gateway what connections to establish with
- particular hosts using particular ports.
-
- 2. The consumer_config file establishes the "logical
- configuration." This file tells the Gateway how to forward
- data coming from Suppliers to the appropriate Consumers.
-
- The application Gateway generally should be started after all
- the Peers described below, though the process should work
- correctly even if it starts first.
-
-2. Peer
-
- This directory contains the source code for the Peer process,
- peerd. There are typically many Peers, which act as suppliers
- and consumers of event messages that are routed through the
- gatewayd.
-
- 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
- "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
- events forwarded by the Gateway. Forwarding is based on
- the settings in the consumer_config configuration file.
-
-----------------------------------------
-
-HOW TO RUN THE TESTS
-
-To run the tests do the following:
-
-1. Compile everything (i.e., first compile the ACE libraries, then
- compile the Gateway and Peer directories).
-
-2. Edit the consumer_config and connection_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
- (i.e., one Supplier and Consumer). I typically start up each Peer
- in a different window on a different machine, but you can run them
- on the same machine as long as you pick different port numbers.
- 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 and uses the -a option to
- set the port).
-
- b. Then run the peers in different windows as
-
- # Window 1 (Supplier)
- % peerd -a S:10011
-
- # Window 2 (Consumer)
- % peerd -a C:10012
-
- etc. Naturally, you can also edit the svc.conf file, but that
- may be more of a pain if you've got a network filesystem and
- all your hosts share the same svc.conf file.
-
-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, or if they aren't
- started first, 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 problems, questions, or
-suggestions for improvement.
-
- Doug
-
- schmidt@cs.wustl.edu