1 / 10

Replicated State Machines

Replicated State Machines. ITV Model-based Analysis and Design of Embedded Software Techniques and methods for Critical Software Anders P. Ravn Aalborg University September 2011. A simple State machine. Object-oriented. Message-oriented. process SM{ (m,args)= getMessage();

lulu
Download Presentation

Replicated State Machines

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. Replicated State Machines ITV Model-based Analysis and Design of Embedded Software Techniques and methods for Critical Software Anders P. Ravn Aalborg University September 2011

  2. A simple State machine Object-oriented Message-oriented process SM{ (m,args)= getMessage(); switch m { case m_1: ... sendMessage(OB,m,arg) ... ... } class SM { void method m_1(par_1) { ... OB.m(arg); ... } ... } Note: Asynchronous communication, cf. Module 1

  3. Constraints • Asynchronous message passing (unbounded buffering). Thus it must be proved no buffer-overflow for an implementation. • No timing (delays, timeouts) in state machines. State machines are scheduled as a set of periodic or sporadic processes

  4. Fault Tolerance • Byzantine failures: SMs may fail in any way. Requires 2t+1 replicas to tolerate t failures. • Fail-stop failures: Failing processors stop and the stop state is detectable. Only t+1 replicas needed.

  5. Agreement and Order • Every request message is received by every non-faulty processor. This requires reliable message passing – a fault in a particular link translates to a byzantine failure for the receiving state machine • Requests are processed in order. Requests sent from same destination cannot overtake each other. Cf. TCP and UDP in Internet

  6. Agreement IC1: Select a non-faulty transmitter IC2: Ensure that the value sent by the transmitter is recieved by all other non-faulty processors The difficult part is implementing a move of the transmitter, cf. Token rings. Alternative. Broadcasts

  7. Watch-dogs for Fail-stop Logical clock stability test

  8. Dynamic Configurations C – clients S – state machines O – output devices This state machine could be the watch dog.

  9. Integration after repair • Resynchronization with getting a check-pointed state from a replica. • Alignment with received messages.

  10. Perspective • A general paradigm suitable for highly critical distributed processing. • Fail-stop may be feasible for medium level criticality. • Both may become cost-efficient in a multi-core setting. Requires highly dependable hardware and kernel support.

More Related