Armada middleware and communication services
Download
1 / 37

ARMADA Middleware and Communication Services - PowerPoint PPT Presentation


  • 287 Views
  • Updated On :

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.

Related searches for ARMADA Middleware and Communication Services

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'ARMADA Middleware and Communication Services' - Olivia


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Armada middleware and communication services l.jpg

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 l.jpg
Agenda

  • Introduction

  • RTCAST Group Comm. Service

  • Real-Time Channel Architecture

  • Platforms

  • RTPB Replication Service

  • Evaluation Tools


Target applications l.jpg
Target Applications

  • Embedded fault-tolerant applications

  • Industrial and manufacturing systems

  • Distributed multimedia

  • Air traffic control


Key challenges l.jpg
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


Armada architecture l.jpg
ARMADA Architecture

Applications

Evaluation

Tools

Middleware

Services

API

Real-Time

Channels

Microkernel


Rtcast l.jpg
RTCAST

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


Group communication l.jpg
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


Real time group comm l.jpg
Real-time Group Comm.

  • Late message means failure

  • Atomic, ordered message delivery in timely fashion

  • Immediate message delivery without compromising the above


Achieve reliability atomicity rt l.jpg
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


Rtcast architecture l.jpg
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


System model l.jpg
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


Agreement on membership l.jpg
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



Steady state operation14 l.jpg
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




Membership changes l.jpg
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


Token rotation period l.jpg
Token Rotation Period

  • Ptoken – Token rotation time

  • Ti – maximum token hold time at any processor

  • n – number of processes

  • dmax – comm. delay


Admission control l.jpg
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 Δ


Admission control contd l.jpg
Admission Control – Contd.

  • Real-time message: Maximum transmission time Ci, period Pi, deadline di

  • Sufficient Schedulability Condition:



Slide22 l.jpg

Agenda

  • Introduction

  • RTCAST Group Comm. Service

  • Real-Time Comm. Architecture

  • Platforms

  • RTPB Replication Service

  • Evaluation Tools

  • Conclusion



Rt comm architecture contd l.jpg
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:



Rtcop contd l.jpg
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




Resource scheduling contd l.jpg
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




Slide32 l.jpg

Agenda

  • Introduction

  • RTCAST Group Comm. Service

  • Real-Time Comm. Architecture

  • Platforms

  • RTPB Replication Service

  • Evaluation Tools

  • Conclusion


Platforms l.jpg
Platforms

  • Microkernel

  • x-kernel: Co-located server

  • UDP/IP


Rtpb architecture l.jpg
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


Evaluation tools orchestra l.jpg
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


Conclusions l.jpg
Conclusions

  • Middleware Services for fault-tolerant group communication

  • Real-time communication services

  • validation tools