### TAO's Real-time Event Service

Point of contact: Johnny Willemsen

#### Last Updated: $Date$

Documentation for the command line and service configurator options used to configure the real-time event service is available here.

### New on this release

- The consumer/supplier control can be controlled better, interval and timeout can be configured.

- At the moment a consumer is connected it can be controlled when the connection from the EC to the consumer is created, this can be directly at the first connect or with the first push.

- The IIOP Gateway has been expanded with several options to control its behaviour.

- The implementation of the multicast gateway has been improved.

### Known issues:

The new EC does not use the scheduling service

  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

  To achieve this goals the EC will able to run without any scheduling service or only consulting the schedule, but not updating the dependencies.

  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.

Further details:

  Many lower level issues and tasks can be found in the DOC Center Bugzilla webpage .

### Examples

For general documentation on the Event Service please read The Design and Performance of a Real-time CORBA Event Service.

The simplest test for the Event Channel is `Event_Latency`, below are the basic instructions to run it:

1. Compile everything under `$TAO_ROOT/orbsvcs`, this needs, obviously, `$TAO_ROOT/tao` and the IDL compiler in `$TAO_ROOT/TAO_IDL`.

Run the naming service, the scheduling service, the event service and the test in `$TAO_ROOT/TAO/orbsvcs/tests/Event_Latency`. As in:

`$ cd $TAO_ROOT/orbsvcs`

`$ cd Naming_Service ; ./tao_cosnaming &`

`$ cd Event_Service ; ./tao_rtevent &`

`$ cd tests/Event_Latency ; ./Event_Latency -m 20 -j &`

You may want to run each program in a separate window. Try using a fixed port number for the `Naming Service` so you can use the `NameService` environment variable.

The script `start_services` in `$TAO_ROOT/orbsvcs/tests` can help with this.

2. 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.

Another example is `EC_Multiple`, numerous examples on how to run this test can be found in the scripts located in `$TAO_ROOT/orbsvcs/tests/EC_Multiple`.

### Features in previous releases

- The copy-on-write semantics has been supported for a while now.

- The event service library has been divided in several smaller libraries, so applications only link the required components. The base code for the Event Service is located in the `TAO_RTEvent` library. `TAO_RTOLDEvent` contains the old implementation for the real-time Event Service, in addition to this the `TAO_RTSchedEvent` contains the components that will support scheduling in the new Event Service. This means that applications using only the `TAO_RTEvent` library do not need to link the scheduling service.

- More details can be found on the `README` file in the `$TAO_ROOT/orbsvcs/orbsvcs/Event` directory.

- Add strategies to remove unresponsive or dead consumers and/or suppliers

- Lots of bug fixes since the last time this releases notes where updated.

- In this release the EC supports atomic updates of subscriptions and publications. In previous versions events could be lost during an update of the subscription list.

- The internal data structures in the event channel have been strategized, for example, it is possible to use RB-trees instead of ordered lists. The benefits are small at this stage.

- New implementation of the serialization protocols. The new version is based on "internal iterators" (aka Worker). This implementation can support copy-on-read (already implemented) and copy-on-write (in progress).

- The new EC allows the suppliers and consumers to update their publications and subscriptions, they can simply call the corresponding `connect` operation. The default EC configuration disallows this, but it is very easy to change it.

- The new EC uses an abstract factory to build its strategies, this factory can be dynamically loaded using the service configurator.

- The new EC can use trivial filters for both consumers and suppliers, resulting in optimal performance for broadcasters.

- Most of the locks on the new EC are strategized.

- The duration of all locks in the EC can be bounded, resulting in very predictable behavior.

- Added fragmentation and reassembly support for the multicast gateways

- 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.

  The subscriptions and publications on a particular EC can be remotely observed by instances of the `RtecChannelAdmin::Observer` class. Once more using CORBA for this interface cost us little or nothing because it is usually used by objects collocated with the EC.

  `TAO_EC_UDP_Receiver` is a helper class that receives events from multicast groups and dispatches them as a supplier to some event channel. This class has to join the right multicast groups, using the `Observer` described above and the `RtecUDPAdmin` to map the subscriptions into multicast groups it can do this dynamically, as consumers join or leave its Event Channel.

  When sending Events through multicast all the `TAO_EC_UDP_Sender` objects can shared the same socket.

- Added a prototype Consumer and Supplier that can send events though multicast groups (or regular UDP sockets).

  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.

  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.

  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.

  Locally the proxy connects as a supplier, publishing all the events it has register for.

  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.

  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.

  We use the COS Time Service types (not the services) to specify time for the Event Service and Scheduling Service.

- The `Gateway` to connect two event channels was moved from a test to the library. The corresponding test (`EC_Multiple`) has been expanded and improved.

- The user can register a set of `EC_Gateways` with the `EventChannel` implementation, the event channel will automatically update the subscription list as consumers subscribe to the EC.

- The code for consumer and supplier disconnection was improved and seems to work without problems now

- The `Event_Service` program creates a collocated `Scheduling Service` this works around a problem in the ORB when running on multiprocessor.

- Startup and shutdown were revised, the event channel shutdown cleanly now.

- Added yet another example (`$TAO_ROOT/orbsvcs/tests/EC_Throughput`), 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 marshaling or late dermarhaling of the event payload. Future versions of the test will help measuring the EC throughput, hence the name.