summaryrefslogtreecommitdiff
path: root/apps/Gateway/README
blob: ce0c97856bed620a89adaf64df3548562f5f234f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
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).

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.

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