ACE/examples/ASX/Event_Server/README

   1
   2
   3 This subdirectory illustrates a number of the ACE ASX framework
   4 features using an ACE_Stream application called the Event Server.  For
   5 more information on the design and use of the ACE ASX framework please
   6 see http://www.dre.vanderbilt.edu/~schmidt/PDF/C++-USENIX-94.pdf and
   7 http://www.dre.vanderbilt.edu/~schmidt/PDF/ACE-concurrency.pdf.  For more
   8 information on the Event Server, please see
   9
  10 http://www.dre.vanderbilt.edu/~schmidt/PDF/DSEJ-94.pdf
  11
  12 The Event Server example works as follows:
  13
  14 1. When the ./Event_Server/event_server executable is run it
  15    creates two SOCK_Acceptors, which listen for and accept incoming
  16    connections from Consumers and Suppliers.
  17
  18 2. The ./Event_Server/Transceiver/transceiver application plays
  19    the role of either a Consumer or a Supplier (with the current
  20    implementation it can only play one role at a time).  The
  21    transceiver process can be started multiple times.  Each call
  22    should be either:
  23
  24    # Consumer
  25    % transceiver -p 10002 -h hostname -C
  26
  27    or
  28
  29    # Supplier
  30    % transceiver -p 10003 -h hostname -S
  31
  32    where 10002 and 10003 are the default Consumer listening port and
  33    the Supplier listening port, respectively, on the event server,
  34    "hostname" is the name of the machine the event_server is running,
  35    and -C and -S indicate that the transceiver plays the role of a
  36    Consumer or Supplier, respectively.  I typically run the
  37    Consumer(s) and Supplier(s) in different windows to make it easier
  38    to understand the output.
  39
  40 3. Once the Consumer(s) and Supplier(s) are connected, you can
  41    type data from any Supplier window.  This data will be routed
  42    through the Modules/Tasks in the event_server's Stream and be
  43    forwarded to the Consumer(s).
  44
  45    Since the transceivers are full-duplex you can also send messages
  46    from the Consumer(s) to Supplier(s).  However, the Event Server will
  47    warn you about this since it's not really kosher to have Consumers
  48    sending to Suppliers...
  49
  50 4. When you want to shut down the tranceivers or event server
  51    just type ^C (which generates a SIGINT) or type any input in the
  52    window running the Event Server application.
  53
  54 What makes this example particularly interesting is that once you've
  55 got the hang of the ASX Streams architecture, you can "push" new
  56 filtering Modules onto the event_server Stream and modify the
  57 application's behavior transparently to the other components.
  58
  59 There are a bunch of features that aren't implemented in this
  60 prototype that you'd probably want to do for a "real" application.
  61 Some of the more interesting things to add would be:
  62
  63 0. Complete "full-duplex" support, i.e., Peers could play the
  64    role of Suppliers and Consumers simultaneously.
  65
  66 1. Support for "commands", which would change the behavior
  67    of the Event_Server based on messages it got from Suppliers
  68    (or Consumers).
  69
  70 3. Support for "pull" operations, as well as "push" operations.
  71    This would basically involve adding a "MIB Module" to get/set
  72    the "values" associated with "names" passed in by Peers.  This
  73    could probably replace the Event_Analysis Module.
  74
  75 4. Filtering and correlation (this should probably be done
  76    via a separate Module that handles filtering and correlation).
  77
  78 5. More flexible concurrency model(s), e.g., "Active Object per-Consumer".
  79    This would enable the Event Server process to handle flow control
  80    more gracefully than it does not (it currently "hangs," which isn't
  81    desirable).
  82