armada middleware and communication services
Download
Skip this Video
Download Presentation
ARMADA Middleware and Communication Services

Loading in 2 Seconds...

play fullscreen
1 / 37

ARMADA Middleware and Communication Services - PowerPoint PPT Presentation


  • 287 Views
  • Uploaded 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.

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

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
Agenda
  • Introduction
  • RTCAST Group Comm. Service
  • Real-Time Channel Architecture
  • Platforms
  • RTPB Replication Service
  • Evaluation Tools
target applications
Target Applications
  • Embedded fault-tolerant applications
  • Industrial and manufacturing systems
  • Distributed multimedia
  • Air traffic control
key challenges
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
ARMADA Architecture

Applications

Evaluation

Tools

Middleware

Services

API

Real-Time

Channels

Microkernel

rtcast
RTCAST
  • Multicast comm. and group management in timely fashion, with faults
group communication
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
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
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
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
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
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
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
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
Token Rotation Period
  • Ptoken – Token rotation time
  • Ti – maximum token hold time at any processor
  • n – number of processes
  • dmax – comm. delay
admission control
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
Admission Control – Contd.
  • Real-time message: Maximum transmission time Ci, period Pi, deadline di
  • Sufficient Schedulability Condition:
slide22

Agenda

  • Introduction
  • RTCAST Group Comm. Service
  • Real-Time Comm. Architecture
  • Platforms
  • RTPB Replication Service
  • Evaluation Tools
  • Conclusion
rt comm architecture contd
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
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
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

Agenda

  • Introduction
  • RTCAST Group Comm. Service
  • Real-Time Comm. Architecture
  • Platforms
  • RTPB Replication Service
  • Evaluation Tools
  • Conclusion
platforms
Platforms
  • Microkernel
  • x-kernel: Co-located server
  • UDP/IP
rtpb architecture
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
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
Conclusions
  • Middleware Services for fault-tolerant group communication
  • Real-time communication services
  • validation tools
ad