TAO/docs/releasenotes/ec.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
   2 <HTML>
   3 <HEAD>
   4    <TITLE>Event Service Status</TITLE>
   5     <!--  -->
   6 </HEAD>
   7 <BODY TEXT="#000000" BGCOLOR="#FFFFFF">
   8
   9 <H3>TAO's Real-time Event Service</H3>
  10     Point of contact: <A HREF="mailto:jwillemsen@remedy.nl">Johnny Willemsen</A>
  11
  12     Documentation for the command line and service configurator
  13     options used to configure the real-time event service is available <A
  14     HREF="../ec_options.html">here</A>.
  15
  16
  17 <H3>New on this release</H3>
  18
  19     <UL>
  20       <LI><P>The consumer/supplier control can be controlled better, interval
  21         and timeout can be configured.
  22   </P>
  23       </LI>
  24       <LI><P>At the moment a consumer is connected it can be controlled when the
  25         connection from the EC to the consumer is created, this can be directly
  26         at the first connect or with the first push.
  27   </P>
  28       </LI>
  29       <LI><P>The IIOP Gateway has been expanded with several options to control
  30         its behaviour.
  31   </P>
  32       </LI>
  33       <LI><P>The implementation of the multicast gateway has been improved.
  34   </P>
  35       </LI>
  36     </UL>
  37
  38 <H3>Known issues:</H3>
  39
  40     <DL>
  41       <DT><I>The new EC does not use the scheduling service</I>
  42       </DT>
  43       <DD>
  44   <P>The new implementation has been designed to simplify its use
  45     in applications that do not require an scheduling service and
  46     to minimize the code footprint when the scheduling service is
  47     only required for dispatching
  48   </P>
  49   <P>To achieve this goals the EC will able to run without any
  50     scheduling service or only consulting the schedule, but not
  51     updating the dependencies.
  52   </P>
  53   <P>Using strategies and factories we will be able to
  54     configure the EC to update the schedule only in the
  55     configurations that required.
  56     Unfortunately this features have not been implemented yet.
  57   </P>
  58       </DD>
  59
  60       <DT><I>Further details:</I></DT>
  61
  62       <DD><P>Many lower level issues and tasks can be found in the
  63     <A HREF="http://bugzilla.dre.vanderbilt.edu/index.cgi">
  64       DOC Center Bugzilla webpage
  65     </A>.
  66   </P>
  67       </DD>
  68     </DL>
  69
  70 <H3>Examples</H3>
  71
  72
  73 For general documentation on the Event Service please read <A HREF="http://www.cs.wustl.edu/~schmidt/oopsla.ps.gz">The
  74 Design and Performance of a Real-time CORBA Event Service</A>.
  75 <P>The simplest test for the Event Channel is <TT>Event_Latency</TT>, below
  76 are the basic instructions to run it:
  77 <OL>
  78 <LI>
  79 Compile everything under <TT>$TAO_ROOT/orbsvcs</TT>, this needs, obviously,
  80 <TT>$TAO_ROOT/tao</TT>
  81 and the IDL compiler in <TT>$TAO_ROOT/TAO_IDL</TT>.</LI>
  82
  83 <P>Run the naming service, the scheduling service, the event service and
  84 the test in <TT>$TAO_ROOT/TAO/orbsvcs/tests/Event_Latency</TT>.
  85 As in:
  86 <P><TT>$ cd $TAO_ROOT/orbsvcs</TT>
  87 <P><TT>$ cd Naming_Service ; ./tao_cosnaming &amp;</TT>
  88 <P><TT>$ cd Event_Service ; ./tao_rtevent &amp;</TT>
  89 <P><TT>$ cd tests/Event_Latency ; ./Event_Latency -m 20 -j &amp;</TT>
  90 <P>You may want to run each program in a separate window. Try using a fixed
  91 port number for the <TT>Naming Service</TT> so you can use the <TT>NameService</TT>
  92 environment variable.
  93 <P>The script <TT>start_services</TT> in <TT>$TAO_ROOT/orbsvcs/tests</TT>
  94 can help with this.
  95 </OL>
  96 Another example is <TT>EC_Multiple</TT>, numerous examples on how to run
  97 this test can be found in the scripts located in <TT>$TAO_ROOT/orbsvcs/tests/EC_Multiple</TT>.
  98
  99 <H3>
 100 Features in previous releases</H3>
 101
 102     <UL>
 103       <LI><P>The copy-on-write semantics has been supported for a
 104     while now.
 105   </P>
 106       </LI>
 107       <LI><P>The event service library has been divided in several
 108     smaller libraries, so applications only link the required
 109     components.
 110     The base code for the Event Service is located in the
 111     <CODE>TAO_RTEvent</CODE> library.
 112     <CODE>TAO_RTOLDEvent</CODE> contains the old implementation
 113     for the real-time Event Service,
 114     in addition to this the <CODE>TAO_RTSchedEvent</CODE>
 115     contains the components that will support scheduling in the
 116     new Event Service.
 117     This means that applications using only the
 118     <CODE>TAO_RTEvent</CODE> library do not need to link the
 119     scheduling service.
 120   </P>
 121       </LI>
 122       <LI><P>More details can be found on the <CODE>README</CODE> file
 123     in the <CODE>$TAO_ROOT/orbsvcs/orbsvcs/Event</CODE>
 124     directory.
 125   </P>
 126       </LI>
 127       <LI><P>Add strategies to remove unresponsive or dead consumers
 128     and/or suppliers
 129   </P>
 130       </LI>
 131       <LI><P>Lots of bug fixes since the last time this releases notes
 132     where updated.
 133   </P>
 134       </LI>
 135       <LI><P>In this release the EC supports atomic updates of
 136     subscriptions and publications.  In previous versions events
 137     could be lost during an update of the subscription list.
 138   </P>
 139       </LI>
 140       <LI><P>The internal data structures in the event channel have
 141     been strategized, for example, it is possible to use
 142     RB-trees instead of ordered lists.  The benefits are small
 143     at this stage.
 144   </P>
 145       </LI>
 146       <LI><P>New implementation of the serialization protocols. The
 147     new version is based on "internal iterators" (aka Worker).
 148     This implementation can support copy-on-read (already
 149     implemented) and copy-on-write (in progress).
 150   </P>
 151       </LI>
 152       <LI><P>The new EC allows the suppliers and consumers to update
 153     their publications and subscriptions, they can simply call
 154     the corresponding <CODE>connect</CODE> operation.
 155     The default EC configuration disallows this, but it is very
 156     easy to change it.
 157   </P>
 158       </LI>
 159       <LI><P>The new EC uses an abstract factory to build its
 160     strategies, this factory can be dynamically loaded using the
 161     service configurator.
 162   </P>
 163       </LI>
 164       <LI><P>The new EC can use trivial filters for both consumers and
 165     suppliers, resulting in optimal performance for broadcasters.
 166   </P>
 167       </LI>
 168       <LI><P>Most of the locks on the new EC are strategized.
 169   </P>
 170       </LI>
 171       <LI><P>The duration of all locks in the EC can be bounded,
 172     resulting in very predictable behavior.
 173   </P>
 174       </LI>
 175
 176   <LI><P>Added fragmentation and reassembly support for the multicast
 177     gateways</P>
 178   </LI>
 179
 180 <LI><P>Continued work on the multicast support for the EC, we added a new
 181 server that maps the event types (and supplier ids) into the right mcast
 182 group. Usually this server is collocated with the helper classes that send
 183 the events through multicast, so using a CORBA interface for this mapping
 184 is not expensive, further it adds the flexibility of using a global service
 185 with complete knowledge of the traffic in the system, that could try to
 186 optimize multicast group usage.
 187 <P>The subscriptions and publications on a particular EC can be remotely
 188 observed by instances of the <TT>RtecChannelAdmin::Observer</TT> class.
 189 Once more using CORBA for this interface cost us little or nothing because
 190 it is usually used by objects collocated with the EC.
 191 <P><TT>TAO_EC_UDP_Receiver</TT> is a helper class that receives events
 192 from multicast groups and dispatches them as a supplier to some event channel.
 193 This class has to <B>join</B> the right multicast groups, using the <TT>Observer</TT>
 194 described above and the <TT>RtecUDPAdmin</TT> to map the subscriptions
 195 into multicast groups it can do this dynamically, as consumers join or
 196 leave its Event Channel.
 197 <P>When sending Events through multicast all the <TT>TAO_EC_UDP_Sender</TT>
 198 objects can shared the same socket.
 199 </P>
 200 </LI>
 201
 202 <LI><P>Added a prototype Consumer and Supplier that can send events though
 203 multicast groups (or regular UDP sockets).
 204 <P>The Event Channel can be configured using a Factory that constructs
 205 the right modules (like changing the dispatching module), in the current
 206 release only the default Factory is implemented.
 207 <P>When several suppliers are consumers are distributed over the network
 208 it could be nice to exploit locality and have a separate Event Channel
 209 on each process (or host). Only when an event is required by some remote
 210 consumer we need to send it through the network.
 211 <P>The basic architecture to achieve this seems very simple, each Event
 212 Channel has a proxy that connects to the EC peers, providing a "merge"
 213 of its (local) consumer subscriptions as its own subscription list.
 214 <P>Locally the proxy connects as a supplier, publishing all the events
 215 it has register for.
 216 <P>To avoid event looping the events carry a time-to-live field that is
 217 decremented each time the event goes through a proxy, when the TTL gets
 218 to zero the event is not propagated by the proxy.
 219 <P>In the current release an experimental implementation is provided, it
 220 basically hardcodes all the subscriptions and publications, we are researching
 221 on how to automatically build the publication list.
 222 <P>We use the COS Time Service types (not the services) to specify time
 223 for the Event Service and Scheduling Service.
 224 </P>
 225 </LI>
 226
 227 <LI>
 228 <P>The <TT>Gateway</TT> to connect two event channels was moved from a test
 229 to the library. The corresponding test (<TT>EC_Multiple</TT>) has been
 230 expanded and improved.
 231 </P>
 232 </LI>
 233
 234 <LI>
 235 <P>The user can register a set of <TT>EC_Gateways</TT> with the <TT>EventChannel</TT>
 236 implementation, the event channel will automatically update the subscription
 237 list as consumers subscribe to the EC.
 238 </P>
 239 </LI>
 240
 241 <LI>
 242 <P>The code for consumer and supplier disconnection was improved and seems
 243 to work without problems now
 244 </P>
 245 </LI>
 246
 247 <LI>
 248 <P>The <TT>Event_Service</TT> program creates a collocated <TT>Scheduling
 249 Service</TT> this works around a problem in the ORB when running on
 250 multiprocessor.
 251 </P>
 252 </LI>
 253
 254 <LI>
 255 <P>Startup and shutdown were revised, the event channel shutdown
 256 cleanly now.
 257 </P>
 258 </LI>
 259
 260 <LI>
 261 <P>Added yet another example
 262 (<TT>$TAO_ROOT/orbsvcs/tests/EC_Throughput</TT>),
 263 this one ilustrate how to use the TAO extensions to create octet sequences
 264 based on CDR streams, without incurring in extra copies. This is useful
 265 to implement custom marshaling or late dermarhaling of the event payload.
 266 Future versions of the test will help measuring the EC throughput, hence
 267 the name.</P>
 268 </LI>
 269 </UL>
 270
 271 </BODY>
 272 </HTML>