RealTime Event Services

1
Real-Time Event Services

• Guoliang Xing
• Huang-Ming Huang

2
Outline

• RT Publisher/Subscriber Model
• TAO RT Event Channel
• Conclusion Comparision

3
RT Publisher/Subscriber Model

• Publish/Subscribe semantic
• Decouple publisher/subscriber
• Distribution tag (DT)
• Logical handle abstraction
• Publishers synchronously publish messages on DT
• Subscribers synchronously receive messages on DT
• Lightweight implementation
• Real-time support
• Allow real-time schedulability analysis

4
Programming Interfaces

• Create_Distribution_Tag(tag_id_t tag, domain_t
  domain)
• Destroy_Distribution_Tag( tag_id_t tag )
• Get_Send_Access( tag_id_t tag )
• Release_Send_Access( tag_id_t tag )
• Subscribe( tag_id_t tag )
• Unsubscribe( tag_id_t tag )
• Send_Message( tag_id_t tag, void msg, int msglen
  )
• Receive_Message( tag_id_t tag, void msg, int
  msglen, timeval_t tout, in_addr_t from_addr
  NULL )
• sender_list_t Get_Senders_On_Distribution_Tag(
  tag_id_t tag )
• receiver_list_t Get_Receivers_On_Distribution_Tag(
  tag_id_t tag )

5
Example
6
Architecture

• Post Service Analogy
• Node Sender/Receiver
• IPC Daemon Local post office
• IPC Client Mailbox
• Tag Table Address directory

7
Design -- The IPC Daemon

• Local Manager
• Receives requests for tag creation/deletion and
  publication/subscription rights
• Conveys the requests to local/remote Update
  Manager
• Low priority
• Update Manager
• Updates the local tag table
• Higher priority
• Delivery Manager
• Deliver single copy of messages to all local
  clients
• Highest Priority

8
Design IPC Client Interfaces

• Local Request Service
• Interface between clients and local Request
  Manager
• Delivery Service
• Deliver messages in the context of publisher

9
Examples

• Tag creation/deletion
• Client sends request to Local Manager and blocks
• Local Manager sends an update status to Update
  Managers of remote IPC daemons
• Local Manager sends response back to client
• Publish message
• Client thread sends the message to remote
  delivery managers
• Receive message
• Client thread blocks to receive msg from Delivery
  Manager

10
Real-time Issues

• Priority Inversions due to
• Atomic nature of local tag table accesses
• Asynchronous tag status update
• Scheduling
• Static priority preemptive scheduling
• Application programmer responsible for
  schedulability analysis

11
PerformanceBase Line
12
Performance
13
Performance Contd.
14
Critiques

• No QoS support for messages
• Publisher push/Subscriber pull
• Synchronous send/receive
• Extensive copying across layers
• Non-configurable architecture
• Central channel for publisher/subscribers etc.
• Motivating more powerful model ? TAO RT Event
  Service

15
TAO Real-Time Event Channel

• Features
• Architecture
• Federated EC
• EC Dispatcher Mechanism
• EC Performance Tests
• Conclusion

16
Motivation

• Event channel used in signaling/control path
• To trigger method execution
• To notify data is ready
• Challenges
• End-to-end timeliness

17
Standard Event Channel Model
18
TAO RTEC

• Extensions
• Real-time Event Dispatching and Scheduling
• Centralized Event Filtering and Correlation
• Periodic Processing
• Limitation
• Only Push Model
• Deterministic event delivery
• Bounded Latency
• Minimized Blocking
• Limit bandwidth

19
Prioritizing event consumer dispatches

• The standard OMG event channel dispatches events
  to consumer at the same priority
• All consumers are considered to be of equal
  importance.
• No support for real-time dispatching
• FIFO event dispatching.
• TAO RTEC
• Dispatches events based on user-supplied QoS
• Dispatches events to consumer based on
  information received from the scheduler.

20
Event Filtering and Correlation

• OMG ES is limited to a single any parameter.
• TAO RTEC
• Uses a structure to represent events
• Contains header and data section
• Header source ID, type, creation time, send
  time, recv time.
• Allows multiple events to be passed
• Allows consumers to specify their event filter
  via the ConsumerQos structure.
• Correlation support delays individual
  transmission of events until all of the events in
  an event set are received by EC.

21
Periodic Events

• Implemented as a filter
• Events are received at the end of successive
  timeout periods
• The event type corresponds to the type of timeout
  event requested.
• Two types are supported
• Interval timeout
• Deadline timeout

22
Event Channel Architecture
ConsumerAdmin_ptr admin ec-gtfor_consumer() Proxy
PushConsumer_ptr proxy admin-gtobtain_proxy_push
_supplier() proxy-gtconnect_push_consumer() pro
xy-gtdisconnect()
SupplierAdmin_ptr admin ec-gtfor_suppliers() Prox
yPushConsumer_ptr proxy admin-gtobtain_proxy_
push_consumer() proxy-gtconnect_push_supplier()
proxy-gtpush(data)
23
Federating Event Channels

• Motivation
• How federation work
• Different federation types

24
Using a Single Event Channel

• Advantages
• All consumers Suppliers connect to a single EC
• Simplifies the setup and Initialization
• Disadvantages
• Most events requires two trips across the network
• Excessive amount of network traffic
• EC becomes performance bottleneck

S1
C2
S2
C1
EC
S3
C3
25
Using Multiple Event Channels

• Advantages
• Most events are reduced to one network hop
• Increased throughput or load balancing
• Disadvantages
• Each consumer/supplier may have to connect to
  more than one EC.
• Application decides which event channel to
  publish events
• Large amounts of network traffic when there are
  multiple, distributed consumers for particular
  events.

C2
S1
S2
EC2
C1
EC1
EC3
S3
C3
26
CORBA-based Federated Event Channels
C2

• Advantages
• Consumers and suppliers deal with single EC
• Events kept local when consumer and supplier are
  on the same host
• Disadvantage
• Does not scale well for large numbers of ECs
• Subscription changes in large federations can be
  quite expensive
• Events required on all nodes are transmitted
  repeatedly across network.

S1
GW
C1
EC
S2
EC
GW
GW
GW
GW
GW
EC
S3
C3
27
UDP-Based Federation

• Advantages
• Consumer and supplier only deal with single EC
• Events kept local when supplier and consumer are
  on the same host
• Scales better than CORBA-based federation
• Disadvantages
• Events required on all nodes are transmitted
  repeatedly across network
• UDP are unreliable, events may be lost.

S1
sender
sender
S2
sender
sender
EC
EC
C2
receiver
receiver
C1
receiver
sender
sender
S3
C3
EC
28
Multicast based Federation

• Advantages
• Consumer and suppliers deal with single EC
• Events kept local when Suppliers and Consumers
  are on same host
• Events requires on all nodes transmitted only
  once on the network
• Disadvantages
• Multicast is unreliable
• Difficulty in across subnet.

S1
S2
sender
sender
EC
EC
C2
receiver
receiver
C1
Multicast port
receiver
sender
S3
C3
EC
29
Dispatcher Strategies
30
CPU Utilization for different dispatching
Strategies
Total CPU Utilization
100
90
80
70
60
Multithread
RTU
50
Single Thread
EFD
40
10
20
30
40
50
60
70
80
90
100
CPU Utilization for Highest rate tasks
31
Latency Measurement
32
Conclusion

• Requires large amount of memory, especially in
  the federation models.
• No structured events support
• No subscription notification
• Suppliers only push events when consumers are
  available.
• Allow consumer to subscribe to new event types
  when available.
• Fault Tolerance Support

33
RT Publisher/Subscriber vs. TAO RTEC
34

• Questions?