summaryrefslogtreecommitdiff
path: root/apps/Gateway/README
diff options
context:
space:
mode:
Diffstat (limited to 'apps/Gateway/README')
-rw-r--r--apps/Gateway/README80
1 files changed, 0 insertions, 80 deletions
diff --git a/apps/Gateway/README b/apps/Gateway/README
deleted file mode 100644
index 7a198d9d07b..00000000000
--- a/apps/Gateway/README
+++ /dev/null
@@ -1,80 +0,0 @@
-OVERVIEW
-
-This directory contains source code for a prototype application-level
-gateway implemented with ACE. This prototype was developed in my
-cs422 grad OS class at Washington University.
-
-DIRECTORY STRUCTURE
-
-There are 2 directories:
-
-Gateway
-
- -- The application Gateway, which must be started *after* all
- the Peers described below). This process reads the
- cc_config and rt_config files. The cc_config file tells
- the Gateway what connections to establish with which hosts
- on which ports, etc. The rt_config file tells the Gateway
- how to route data coming from "sources" to the appropriate
- "destinations."
-
-Peer
-
- -- The test driver programs that must be started *before* the
- Gateway. To do anything interesting you'll need at
- least two Peers: one for supplying events and one for consuming
- them. In the configuration files, these two types of Peers
- are designated as follows:
-
- (1) Input Peers (designated by an "I" in the Gateway's
- cc_config configuration file). These Peers are "sources"
- of messages to the Gateway.
-
- (2) Output Peers (designated by an "O" in the Gateway's
- cc_config file). These Peers are "destinations" of
- messages routed by the Gateway (routing is based on
- the settings in the rt_config configuration file).
-
-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 rt_config and cc_config files as discussed above.
-
-3. Start up the Peers (peerd). You can start up as many as you
- like, as per the cc_config file, but you'll need at least
- two (one for supplying input and one for consuming output). 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 connections from the Gateway.
-
-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. 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
- messages from Input Peers by typing commands in the Peer window.
- This input will be sent to the Gateway, which will forward
- the message to all Output Peers that have "subscribed" to receive
- these messages.
-
- 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
- and the process will shut down gracefully.
-
-Please let me know if there are any questions.
-
- Doug
-
-schmidt@cs.wustl.edu