diff options
Diffstat (limited to 'examples/ASX/Event_Server/README')
| -rw-r--r-- | examples/ASX/Event_Server/README | 79 |
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). - |