1 / 37

ARMADA Middleware and Communication Services

ARMADA Middleware and Communication Services. T. ABDELZAHER, M. BJORKLUND, S. DAWSON, W.-C. FENG, F. JAHANIAN, S. JOHNSON, P. MARRON, A. MEHRA, T. MITTON, A. SHAIKH, K. SHIN, Z. WANG, H. ZOU Real-Time Computing Laboratory University of Michigan Presented by Guoliang Xing. Agenda.

inara
Download Presentation

ARMADA Middleware and Communication Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ARMADA Middleware and Communication Services T. ABDELZAHER, M. BJORKLUND, S. DAWSON, W.-C. FENG, F. JAHANIAN, S. JOHNSON, P. MARRON, A. MEHRA, T. MITTON, A. SHAIKH, K. SHIN, Z. WANG, H. ZOU Real-Time Computing Laboratory University of Michigan Presented by Guoliang Xing

  2. Agenda • Introduction • RTCAST Group Comm. Service • Real-Time Channel Architecture • Platforms • RTPB Replication Service • Evaluation Tools

  3. Target Applications • Embedded fault-tolerant applications • Industrial and manufacturing systems • Distributed multimedia • Air traffic control

  4. Key Challenges • Timely delivery of services with end-to-end real-time constraints • Dependabilityof services in the presence of h/s failures • Scalability of computation and communication resources • Exploitation of open systems and emerging standards in operating systems and communication services

  5. ARMADA Architecture Applications Evaluation Tools Middleware Services API Real-Time Channels Microkernel

  6. RTCAST • Multicast comm. and group management in timely fashion, with faults

  7. Group Communication • Reliable message delivery • Agreement on group membership • Failure detection and handling • Consistency • Atomicity: either everybody gets the message or nobody gets it • Global order

  8. Real-time Group Comm. • Late message means failure • Atomic, ordered message delivery in timely fashion • Immediate message delivery without compromising the above

  9. Achieve reliability, atomicity, RT • Reliability: each member either receives a multicast message m or crashes before receiving m • Atomicity: correct members receive all message and in the same order • Time-bounded multicast: each member either receives each multicast m in total order within T time units or crashes during T before receiving m

  10. RTCAST - Architecture Real-time Process Groups API Admission Control and Schedulability Analysis Group Membership Service Timed Atomic Multicast Clock Synchronization Virtual Network Interface Unicast Datagram Communication

  11. System Model • Assumptions: • each processor has its own unique identifier • a path exists between any two processors • communication delay is bounded (in the absence of failures) • synchronized clocks • Failures • processors may suffer performance or crash failures • messages may suffer performance or omission failures

  12. Agreement on membership • All members have the same membership view at group initialization time • For each membership update U which changes membership view from V to V’, U is delivered atomically (in order) to all members in V U V’ within T time units

  13. Steady-state operation

  14. Steady-state operation • Token Ring: ensure order • A processor sends messages only after holds token • Upon receiving the token • sends multicast messages within maximum token hold time • sends a heartbeat which is a token to successor • Upon receiving a multicast message • deliver to application in sequence • if message omission detected, crash

  15. Steady-state operation– contd.

  16. Handle faults

  17. Membership Changes • Processor crashes • Each processor checks the heartbeats from members when its turn comes • Send membership update multicast • Joins • Sends a join request to some processor which multicasts membership change message • Joining processor checks the consistence of membership views sent in ACKs

  18. Token Rotation Period • Ptoken – Token rotation time • Ti – maximum token hold time at any processor • n – number of processes • dmax – comm. delay

  19. Admission Control • Goal: Only admit affordable messages • Assumptions: • Each sender can transmit messages for up to Tj units of time within P • Time elapsed between the send and delivery is bounded by Δ

  20. Admission Control – Contd. • Real-time message: Maximum transmission time Ci, period Pi, deadline di • Sufficient Schedulability Condition:

  21. Implementation

  22. Agenda • Introduction • RTCAST Group Comm. Service • Real-Time Comm. Architecture • Platforms • RTPB Replication Service • Evaluation Tools • Conclusion

  23. RT Channel Architecture

  24. RT Comm. Architecture – Contd. • Real-time channel: unicast virtual connection between two hosts with bounded end-to-end delay guarantee • RTC API: • Clip: endpoint with QoS parameters • RTCOP: Signaling and resource reservation • QoS model & Admission control:

  25. RTC API

  26. RTCOP-Contd. • Real-Time Connection Ordination Protocol: Distributed end-to-end signaling • Request and reply handler: manage signaling state and interface to admission control • Comm. module: reliably forward signaling message • Signaling connection is non-real-time but reliable

  27. RTCOP

  28. Resource scheduling

  29. Resource scheduling- Contd. • QoS-sensitive CPU scheduling: • Each message must be sent within deadline • Comm. Handler scheduled with EDF policy • Resource reservation: • Associate each Comm. Handler with budget • Policing: • Link bandwidth allocation: • Dynamic priority based link scheduler

  30. Resource Scheduling – contd.

  31. Traffic isolation in RTC

  32. Agenda • Introduction • RTCAST Group Comm. Service • Real-Time Comm. Architecture • Platforms • RTPB Replication Service • Evaluation Tools • Conclusion

  33. Platforms • Microkernel • x-kernel: Co-located server • UDP/IP

  34. RTPB Architecture • Many RT applications can tolerate minor inconsistencies in replicated state • Backup maintains a less current copy of primary • Distance between the primary and backup data is bounded within a time window

  35. Evaluation Tools - ORCHESTRA • A distributed protocol is viewed as an abstraction layer through which participants communicate by exchanging messages • A probe/fault injection (PFI) layer is inserted between any two consecutive layers in a protocol stack. • PFI layer can delay, drop, reorder, duplicate, modify, introducing spontaneous messages

  36. Conclusions • Middleware Services for fault-tolerant group communication • Real-time communication services • validation tools

  37. Questions?

More Related