Main Page Namespace List Class Hierarchy Alphabetical List Compound List File List Namespace Members Compound Members File Members Related Pages

# RtecEventComm::EventHeader Struct Reference

Define the structure of an event header. More...

`import "RtecEventComm.idl";`

List of all members.

## Public Attributes
EventType | type
| The event type. More...
EventSourceID | source
| Some way to identify the supplier. More...
long | ttl
| The "Time To Live" counter. More...
Time | creation_time
| Applications can use this field to time-stamp the event at the source. More...
Benchmarking timestamps
The following timestamps are used to benchmark the Event Channel, they should not be used by the application and may be removed without notice.
Time | ec_recv_time
Time | ec_send_time

## Detailed Description

Define the structure of an event header.

The event header is the portion of the event examined by the event service for filtering purposes.

Events can be filtered based on their type and SourceID, though the latest is a misnomer, over time it has evolved into a 'source class' or 'event domain' field, i.e. multiple sources can have the same 'ID' and the same source can generate events with different IDs.

## Member Data Documentation

Time RtecEventComm::EventHeader::creation_time

| Applications can use this field to time-stamp the event at the source. Todo: Because the filtering language uses EventHeaders as filtering expressions (yeah, it sucks) we also use this field to pass timeout values into the EC filter.

Time RtecEventComm::EventHeader::ec_recv_time

Time RtecEventComm::EventHeader::ec_send_time

EventSourceID RtecEventComm::EventHeader::source

| Some way to identify the supplier.

long RtecEventComm::EventHeader::ttl

| The "Time To Live" counter. Each time an EC process the event it decreases the TTL field, when it gets to zero the message is no longer forwarded.

EventType RtecEventComm::EventHeader::type

| The event type. Notice that the 'type' of the event may or may not be related to the data type in its contents. I.e. it is perfectly possible to send the same payload with different values in this field. In other words, this is just a filterable value, and it is up to the application to define (or not) its relation to the contents of the event.

The documentation for this struct was generated from the following file:

- RtecEventComm.idl