1 / 21

Reliable High-Performance Communication Systems: A Modular Approach

This paper explores the design and implementation of reliable, high-performance communication systems using modular software components. It discusses the benefits of component-based design, such as ease of customization and extensibility, alongside challenges including configuration complexity and performance limitations. Key techniques for optimizing efficiency in communication protocols are highlighted, including garbage collection avoidance and header compression. The paper emphasizes the importance of formal methods in ensuring correctness and robustness, and provides insights into practical applications and design lessons learned from implementations.

adanna
Download Presentation

Reliable High-Performance Communication Systems: A Modular Approach

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. Building reliable, high-performance communication systems from components Xiaoming Liu, Christoph Kreitz, Robbert van Renesse, Jason Hickey, Mark Hayden, Ken Birman, Bob Constable (shepherd: Peter Lee) Cornell, Caltech, Compaq (CMU, Cedilla)

  2. Why software components? • Ease design and development • Tuning to environment • Customization to user app • Extensibility • Verification and robustness

  3. Why not? • Configuration is hard • Performance is bad • Abstraction barriers • Poor locality • Redundant code • Not reliable • Not faster

  4. Group Communication Network

  5. History Ensemble Horus Isis V • Layers • Protocols • Multicast • ML • Formal methods • Membership • CATOCS

  6. Specification logical predicates code of a layer Properties (English) Concrete (ML) Implementation

  7. Specification Abstract Spec (I/O Automata) proof refinement Properties (English) Concrete (ML) Implementation

  8. Abstract IOA specificationof totally ordered multicast S: array[integer] ofmessage next: integer deliv: array[process] ofinteger action Multicast(m) { S[next++] := m; } action Deliver(p, m) precond: deliv[p] < next && m == S[deliv[p]] { deliv[p]++; } global state

  9. abstract FIFO network spec Layer correctness Hickey, Lynch, Van Renesse, TACAS’99 Token layer on each CPU abstract Total Order network spec network + layer == network++

  10. Stack correctness Seqno layer For example: Token Seqno unreliable Token layer FIFO total

  11. Efficiency? • Ensemble stacks have many layers, improving clarity, but inefficient. • 5 optimization techniques: • Avoiding (in-line) garbage collection • Avoiding marshaling • Delaying non-critical message processing • Identifying common paths • Header compression

  12. A protocol layer is a function! old state new state layer input event output events

  13. (off-line) partial evaluation original code NuPrl layer Specialized code Common Case Predicate Hacker + Formal person

  14. Two-phase optimization Off-line On-line Programmer Formal User bypass function code CCP TT TT

  15. Header compaction T_Data T_Data seqno Hash seqno T_Last • Less space • Faster processing

  16. Architecture (deliver only) Application generated bypass original stack CCP (e.g., hdr.seq = win.lo) ? (marshaling, device independence) Transport driver Network

  17. Architecture Application CCP ? generated bypass original stack ? (marshaling, device independence) Transport driver Network

  18. Performance • Three different versions: • Original (ORIG) • Hand-optimized (HAND) • Machine-optimized (MACH) • 300 MHz UltraSparc/Solaris 2.6 • OCaml 2.0 native code compiler

  19. Code latency (sec) (See paper for CPU cycles and TLB misses)

  20. Lessons learned • Design with formalization in mind • Use small, but not too small components • Use a language with formal semantics • Use IOA as a specification language • Use formal tool with in-house expertise

  21. Final remarks • See CD or Web for code samples, links to all code, as well as how to reproduce our results • Still working on a machine-generated proof of correctness

More Related