diff options
Diffstat (limited to 'examples/ASX/Event_Server/README')
| -rw-r--r-- | examples/ASX/Event_Server/README | 53 |
1 files changed, 31 insertions, 22 deletions
diff --git a/examples/ASX/Event_Server/README b/examples/ASX/Event_Server/README index 8e1342fd7bc..f54d724e1fe 100644 --- a/examples/ASX/Event_Server/README +++ b/examples/ASX/Event_Server/README @@ -7,38 +7,47 @@ http://www.cs.wustl.edu/~schmidt/DSEJ-94.ps.gz The Event Server example works as follows: 1. When the ./Event_Server/event_server executable is run it - creates two SOCK_Acceptors, which listen for and accept - incoming connections from Consumers and Suppliers. + creates two SOCK_Acceptors, which listen for and accept incoming + connections from Consumers and Suppliers. 2. The ./Event_Server/Transceiver/transceiver application plays - the role of Consumer and Supplier. It can be started multiple - times. Each call should be either: + the role of either a Consumer or a Supplier (but with the current + implementation it can only play one role at a time). The + transceiver process can be started multiple times. Each call + should be either: - % transceiver -p XYZ -h hostname + # Consumer + % transceiver -p 10002 -h hostname -C or - % transceiver -p ABC -h hostname + # Supplier + % transceiver -p 10003 -h hostname -S - where XYZ and ABC are the Consumer listening port and the Supplier - listening port, respectively, on the event server and "hostname" is - the name of the machine the event_server is running. I typically - run the Consumer(s) and Supplier(s) in different windows. + where 10002 and 10003 are the default Consumer listening port and + the Supplier listening port, respectively, on the event server, + "hostname" is the name of the machine the event_server is running, + and -C and -S indicate that the transceiver plays the role of a + Consumer or Supplier, respectively. I typically run the + Consumer(s) and Supplier(s) in different windows to make it easier + to understand the output. -3. Once the Consumer(s) and Supplier(s) are connected, you can type - data from any Supplier window. This data will be routed - through the Modules/Tasks in an event_server's Stream and - be forwarded to the Consumer(s). Note that you can also - send messages from the Consumer(s) to Supplier(s), but the - Event Server will warn you about this since it's not really - kosher... +3. Once the Consumer(s) and Supplier(s) are connected, you can + type data from any Supplier window. This data will be routed + through the Modules/Tasks in the event_server's Stream and be + forwarded to the Consumer(s). + + Since the transceivers are full-duplex you can also send messages + from the Consumer(s) to Supplier(s), but the Event Server will warn + you about this since it's not really kosher to have Consumers + sending to Suppliers ;-) 4. When you want to shut down the tranceivers or event server - just type ^C (which generates a SIGINT) or type any input - in the window running the Event Server. + just type ^C (which generates a SIGINT) or type any input in the + window running the Event Server. What makes this example particularly interesting is that once you've -got the hang of this basic architecture, you can "push" new filtering -Modules onto the event_server Stream and modify the application's -behavior transparently. +got the hang of the ASX Streams architecture, you can "push" new +filtering Modules onto the event_server Stream and modify the +application's behavior transparently. |