diff options
Diffstat (limited to 'TAO/docs/releasenotes/ec.html')
| -rw-r--r-- | TAO/docs/releasenotes/ec.html | 214 |
1 files changed, 0 insertions, 214 deletions
diff --git a/TAO/docs/releasenotes/ec.html b/TAO/docs/releasenotes/ec.html deleted file mode 100644 index 89c4fb506e8..00000000000 --- a/TAO/docs/releasenotes/ec.html +++ /dev/null @@ -1,214 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<HTML> -<HEAD> - <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> - <META NAME="GENERATOR" CONTENT="Mozilla/4.06 [en] (X11; I; SunOS 5.5.1 sun4u) [Netscape]"> - <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>Added fragmentation and reassembly support for the multicast - gateways</P> - </LI> -</UL> - -<H3> -Known issues:</H3> - -<DL> -<DT> -<I>The schedule cannot be downloaded</I></DT> - -<DD> -The Scheduling Service seems to compute proper schedules, but it is not -possible to download them, apparently there is a marshalling problem for -sequences of complex structures.</DD> - -<P>Due to this problem we have been unable to test the run-time scheduler -and performance it is impossible to complete performance measurements and -optimizations: the (global) scheduling service latency and overhead is -at least as large as the EC itself. -<P><B>Note:</B> This does not seem to be the case anymore, but the comment -will remain here until I can confirm that the problem dissapeared. -<DT> - -<P><I>Run-time scheduler requires re-link</I></DT> - -<DD> -During a normal execution of the system there is no need to use the a global -Real-time Scheduling Service, a faster, collocated implementation for the -service is available. Obviously the scheduling information is precomputed -in some config run.</DD> - -<P>Unfortunately the current scheme requires a relink of all the involved -applications against the generated tables for the run-time scheduling service. -<P>We should be able to download the schedule to the interested parties, -without need for a separate link phase. This will simplify and speed up -the developing cycle, but requires a (small and fixed) amount of dynamic -memory allocation. It could be interesting to "save" the schedule computation -in some persistent form, so startup cost are lower too. -<P>The current design contemplates a config run were a global consumer -accumulates the QoS requirements of all the objects, next an external utility -is used to force a computation and save of the schedule. In future executions -the global scheduler pre-loads this schedule and the clients simply download -the precomputed schedule, and all scheduling queries are to a local scheduling -service, without any further contact to the global instance. -<DT> -<P><I>Users have no control over service collocations</I></DT> - -<P>The user should have complete control of services collocation, using -ACE Service Configurator; currently the services must be explicitly instantiated -by the user. -<DT> - -<DT> -<P><I>Further details:</I></DT> - -<P>Many lower level issues and tasks can be found in the <A HREF="TODO.html">TODO -list</A>. - -</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>; remember -to give a different port to each one, using the <TT>-ORBport</TT> option. -As in: -<P><TT>$ cd $TAO_ROOT/orbsvcs</TT> -<P><TT>$ cd Naming_Service ; ./Naming_Service -ORBport 10000 &</TT> -<P><TT>$ cd Event_Service ; ./Event_Service -ORBport 0 &</TT> -<P><TT>$ cd tests/Event_Latency ; ./Event_Latency -ORBport 0 -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>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> |