diff options
Diffstat (limited to 'TAO/docs/releasenotes/ec.html')
| -rw-r--r-- | TAO/docs/releasenotes/ec.html | 215 |
1 files changed, 0 insertions, 215 deletions
diff --git a/TAO/docs/releasenotes/ec.html b/TAO/docs/releasenotes/ec.html deleted file mode 100644 index 00a0b54f316..00000000000 --- a/TAO/docs/releasenotes/ec.html +++ /dev/null @@ -1,215 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<HTML> -<HEAD> - <TITLE>Event Service Status</TITLE> - <!-- $Id$ --> -</HEAD> -<BODY TEXT="#000000" BGCOLOR="#FFFFFF"> - -<H3>TAO's Real-time Event Service</H3> - Point of contact: <A HREF="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</A> - <H4>Last Updated: $Date$</H4> - -<H3>New on this release</H3> - - <UL> - <LI><P>It has been available for several releases now, but not - well documented. A complete re-implementation of the EC is - available, this implementation provides: - </P> - </LI> - <LI><P>The new EC allows the suppliers and consumers to update - their publications and subscriptions, they can simply call - the corresponding <CODE>connect</CODE> operation. - The default EC configuration disallows this, but it is very - easy to change it. - </P> - </LI> - <LI><P>The new EC uses an asbtract factory to build its - strategies, this factory can be dynamically loaded using the - service configurator. - </P> - </LI> - <LI><P>The new EC can use trivial filters for both consumers and - suppliers, resulting in optimal performance for broadcasters. - </P> - </LI> - <LI><P>Most of the locks on the new EC are strategized. - </P> - </LI> - <LI><P>The duration of all locks in the EC can be bounded, - resulting in very predictable behavior. - </P> - </LI> - <LI><P>More details can be found on the <CODE>README</CODE> file - in the <CODE>$TAO_ROOT/orbsvcs/orbsvcs/Event</CODE> - directory. - </P> - </LI> - </UL> - -<H3>Known issues:</H3> - - <DL> - <DT><I>The new EC does not use the scheduling service</I> - </DT> - <DD> - <P>The new implementation has been designed to simplify its use - in applications that do not require an scheduling service and - to minimize the code footprint when the scheduling service is - only required for dispatching - </P> - <P>To achieve this goals the EC will able to run without any - scheduling service or only consulting the schedule, but not - updating the dependencies. - </P> - <P>Using strategies and factories we will be able to - configure the EC to update the schedule only in the - configurations that required. - Unfortunately this features have not been implemented yet. - </P> - </DD> - - <DT><I>Further details:</I></DT> - - <DD><P>Many lower level issues and tasks can be found in the - <A HREF="TODO.html">TODO list</A>. - </P> - </DD> - </DL> - -<H3>Examples</H3> - - -For general documentation on the Event Service please read <A HREF="http://www.cs.wustl.edu/~schmidt/oopsla.ps.gz">The -Design and Performance of a Real-time CORBA Event Service</A>. -<P>The simplest test for the Event Channel is <TT>Event_Latency</TT>, below -are the basic instructions to run it: -<OL> -<LI> -Compile everything under <TT>$TAO_ROOT/orbsvcs</TT>, this needs, obviously, -<TT>$TAO_ROOT/tao</TT> -and the IDL compiler in <TT>$TAO_ROOT/TAO_IDL</TT>.</LI> - -<P>Run the naming service, the scheduling service, the event service and -the test in <TT>$TAO_ROOT/TAO/orbsvcs/tests/Event_Latency</TT>. -As in: -<P><TT>$ cd $TAO_ROOT/orbsvcs</TT> -<P><TT>$ cd Naming_Service ; ./Naming_Service &</TT> -<P><TT>$ cd Event_Service ; ./Event_Service &</TT> -<P><TT>$ cd tests/Event_Latency ; ./Event_Latency -m 20 -j &</TT> -<P>You may want to run each program in a separate window. Try using a fixed -port number for the <TT>Naming Service</TT> so you can use the <TT>NameService</TT> -environment variable. -<P>The script <TT>start_services</TT> in <TT>$TAO_ROOT/orbsvcs/tests</TT> -can help with this. -<LI> -If you want real-time behavior on Solaris you may need to run these programs -as root; on the other hand, this particular example really has no priority -inversion, since only one thread runs at a time.</LI> -</OL> -Another example is <TT>EC_Multiple</TT>, numerous examples on how to run -this test can be found in the scripts located in <TT>$TAO_ROOT/orbsvcs/tests/EC_Multiple</TT>. - -<H3> -Features in previous releases</H3> - -<UL> - - <LI><P>Added fragmentation and reassembly support for the multicast - gateways</P> - </LI> - -<LI><P>Continued work on the multicast support for the EC, we added a new -server that maps the event types (and supplier ids) into the right mcast -group. Usually this server is collocated with the helper classes that send -the events through multicast, so using a CORBA interface for this mapping -is not expensive, further it adds the flexibility of using a global service -with complete knowledge of the traffic in the system, that could try to -optimize multicast group usage. -<P>The subscriptions and publications on a particular EC can be remotely -observed by instances of the <TT>RtecChannelAdmin::Observer</TT> class. -Once more using CORBA for this interface cost us little or nothing because -it is usually used by objects collocated with the EC. -<P><TT>TAO_EC_UDP_Receiver</TT> is a helper class that receives events -from multicast groups and dispatches them as a supplier to some event channel. -This class has to <B>join</B> the right multicast groups, using the <TT>Observer</TT> -described above and the <TT>RtecUDPAdmin</TT> to map the subscriptions -into multicast groups it can do this dynamically, as consumers join or -leave its Event Channel. -<P>When sending Events through multicast all the <TT>TAO_EC_UDP_Sender</TT> -objects can shared the same socket. -</P> -</LI> - -<LI><P>Added a prototype Consumer and Supplier that can send events though -multicast groups (or regular UDP sockets). -<P>The Event Channel can be configured using a Factory that constructs -the right modules (like changing the dispatching module), in the current -release only the default Factory is implemented. -<P>When several suppliers are consumers are distributed over the network -it could be nice to exploit locality and have a separate Event Channel -on each process (or host). Only when an event is required by some remote -consumer we need to send it through the network. -<P>The basic architecture to achieve this seems very simple, each Event -Channel has a proxy that connects to the EC peers, providing a "merge" -of its (local) consumer subscriptions as its own subscription list. -<P>Locally the proxy connects as a supplier, publishing all the events -it has register for. -<P>To avoid event looping the events carry a time-to-live field that is -decremented each time the event goes through a proxy, when the TTL gets -to zero the event is not propagated by the proxy. -<P>In the current release an experimental implementation is provided, it -basically hardcodes all the subscriptions and publications, we are researching -on how to automatically build the publication list. -<P>We use the COS Time Service types (not the services) to specify time -for the Event Service and Scheduling Service. -</P> -</LI> - -<LI> -<P>The <TT>Gateway</TT> to connect two event channels was moved from a test -to the library. The corresponding test (<TT>EC_Multiple</TT>) has been -expanded and improved. -</P> -</LI> - -<LI> -<P>The user can register a set of <TT>EC_Gateways</TT> with the <TT>EventChannel</TT> -implementation, the event channel will automatically update the subscription -list as consumers subscribe to the EC. -</P> -</LI> - -<LI> -<P>The code for consumer and supplier disconnection was improved and seems -to work without problems now -</P> -</LI> - -<LI> -<P>The <TT>Event_Service</TT> program creates a collocated <TT>Scheduling -Service</TT> this works around a problem in the ORB when running on -multiprocessor. -</P> -</LI> - -<LI> -<P>Startup and shutdown were revised, the event channel shutdown -cleanly now. -</P> -</LI> - -<LI> -<P>Added yet another example -(<TT>$TAO_ROOT/orbsvcs/tests/EC_Throughput</TT>), -this one ilustrate how to use the TAO extensions to create octet sequences -based on CDR streams, without incurring in extra copies. This is useful -to implement custom marshalling or late dermashalling of the event payload. -Future versions of the test will help measuring the EC throughput, hence -the name.</P> -</LI> -</UL> - -</BODY> -</HTML> |