summaryrefslogtreecommitdiff
path: root/examples/ASX/Event_Server/README
diff options
context:
space:
mode:
Diffstat (limited to 'examples/ASX/Event_Server/README')
-rw-r--r--examples/ASX/Event_Server/README79
1 files changed, 0 insertions, 79 deletions
diff --git a/examples/ASX/Event_Server/README b/examples/ASX/Event_Server/README
deleted file mode 100644
index 262b7ee9633..00000000000
--- a/examples/ASX/Event_Server/README
+++ /dev/null
@@ -1,79 +0,0 @@
-This subdirectory illustrates a number of the ACE ASX framework
-features using an ACE_Stream application called the Event Server. For
-more information on the design and use of the ACE ASX framework please
-see http://www.cs.wustl.edu/~schmidt/C++-USENIX-94.ps.gz and
-http://www.cs.wustl.edu/~schmidt/ACE-concurrency.ps.gz. For more
-information on the Event Server, please see
-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.
-
-2. The ./Event_Server/Transceiver/transceiver application plays
- the role of either a Consumer or a Supplier (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:
-
- # Consumer
- % transceiver -p 10002 -h hostname -C
-
- or
-
- # Supplier
- % transceiver -p 10003 -h hostname -S
-
- 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 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). However, 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 application.
-
-What makes this example particularly interesting is that once you've
-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 to the other components.
-
-There are a bunch of features that aren't implemented in this
-prototype that you'd probably want to do for a "real" application.
-Some of the more interesting things to add would be:
-
-0. Complete "full-duplex" support, i.e., Peers could play the
- role of Suppliers and Consumers simultaneously.
-
-1. Support for "commands", which would change the behavior
- of the Event_Server based on messages it got from Suppliers
- (or Consumers).
-
-3. Support for "pull" operations, as well as "push" operations.
- This would basically involve adding a "MIB Module" to get/set
- the "values" associated with "names" passed in by Peers. This
- could probably replace the Event_Analysis Module.
-
-4. Filtering and correlation (this should probably be done
- via a separate Module that handles filtering and correlation).
-
-5. More flexible concurrency model(s), e.g., "Active Object per-Consumer".
- This would enable the Event Server process to handle flow control
- more gracefully than it does not (it currently "hangs," which isn't
- desirable).
-