blob: 892fe43ba6de35ea86ff396cb8489f4cd7246fff (
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
|
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. You can get a paper
that explains the patterns used in this implementation at URL
http://www.cs.wustl.edu/~schmidt/TAPOS-95.ps.gz
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
|
