diff options
Diffstat (limited to 'TAO/docs/releasenotes/ec.html')
| -rw-r--r-- | TAO/docs/releasenotes/ec.html | 234 |
1 files changed, 0 insertions, 234 deletions
diff --git a/TAO/docs/releasenotes/ec.html b/TAO/docs/releasenotes/ec.html deleted file mode 100644 index 6f84f2ec177..00000000000 --- a/TAO/docs/releasenotes/ec.html +++ /dev/null @@ -1,234 +0,0 @@ -<!-- $Id$ --> - -<HTML> - <HEAD> - <TITLE>Event Service Status</TITLE> - </HEAD> - -<BODY TEXT="#000000" BGCOLOR="#FFFFFF"> - <BODY> - <H3>Event Service Status</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> - Added a prototype Consumer and Supplier that can send events - though multicast groups (or regular UDP sockets). - </LI> - <LI> - 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. - </LI> - </UL> - - <H3>Known issues:</H3> - <DL> - <DT><EM>The schedule cannot be downloaded</EM></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. - - <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> - </DD> - - <DT><EM>Run-time scheduler requires re-link</EM></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. - - <P>Unfortunately the current scheme requires a relink of all the - involved applications against the generated tables for the - run-time scheduling service.</P> - - <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> - - <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.</P> - </DD> - - <DT><EM>Users have no control over service - collocations</EM></DT> - <DD> - The user should have complete control of services collocation, - using ACE Service Configurator; - currently the services must be explicitly instantiated by the - user. - </DD> - - </DL> - - <H3>Examples</H3> - - <P>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 - <CODE>Event_Latency</CODE>, - below are the basic instructions to run it:</P> - - <OL> - <LI> Compile everything under <CODE>$TAO_ROOT/orbsvcs</CODE>, this - needs, obviously, <CODE>$TAO_ROOT/tao</CODE> and - the IDL compiler in <CODE>$TAO_ROOT/TAO_IDL</CODE>.</LI> - - <LI><P>Run the naming service, the scheduling service, the event service - and the test in - <CODE>$TAO_ROOT/TAO/orbsvcs/tests/Event_Latency</CODE>; - remember to give a different port to each one, - using the <CODE>-ORBport</CODE> option. As in:</P> - - <CODE> - <P> - $ cd $TAO_ROOT/orbsvcs - </P> - <P> -$ cd Naming_Service ; ./Naming_Service -ORBport 10000 & - </P> - <P> -$ cd Event_Service ; ./Event_Service -ORBport 0 & - </P> - <P> -$ cd tests/Event_Latency ; ./Event_Latency -ORBport 0 -m 20 -j & - </P> - </CODE> - - <P> - You may want to run each program in a separate window. - Try using a fixed port number for the <CODE>Naming - Service</CODE> so you can use the <CODE>NameService</CODE> - environment variable. - </P> - - <P> - The script <CODE>start_services</CODE> - in <CODE>$TAO_ROOT/orbsvcs/tests</CODE> can help with - this. - </P> - - </LI> - - <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> - - <P>Another example is <CODE>EC_Multiple</CODE>, - numerous examples on how to run this test can be found in the - scripts located in - <CODE>$TAO_ROOT/orbsvcs/tests/EC_Multiple</CODE>.</P> - - <H3>Features in previous releases</H3> - - <UL> - <LI> - <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> - - <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> - - <P> - Locally the proxy connects as a supplier, - publishing all the events it has register for. </P> - - <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> - - <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> - </LI> - - <LI> <P> - We use the COS Time Service types (not the services) to - specify time for the Event Service and Scheduling Service.</P> - </LI> - - <LI>The <CODE>Gateway</CODE> to connect two event channels was - moved from a test to the library. - The corresponding test (<CODE>EC_Multiple</CODE>) has been - expanded and improved.</LI> - - <LI> - The user can register a set of <CODE>EC_Gateways</CODE> with - the <CODE>EventChannel</CODE> implementation, the event - channel will automatically update the subscription list as - consumers subscribe to the EC. - </LI> - <LI> - The code for consumer and supplier disconnection was - improved and seems to work without problems now - </LI> - <LI> - The <CODE>Event_Service</CODE> program creates a collocated - <CODE>Scheduling Service</CODE> this works around a problem - in the ORB when running on multiprocessor. - </LI> - <LI> - Startup and shutdown were revised, the event channel - shutdown cleanly now. - </LI> - <LI> - Added yet another example - (<CODE>$TAO_ROOT/orbsvcs/tests/EC_Throughput</CODE>), 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. - </LI> - </UL> - - </BODY> -</HTML> |