Upgrade to Pro — share decks privately, control downloads, hide ads and more …

A Brief History of Distributed Programming: RPC

A Brief History of Distributed Programming: RPC

Given at CodeMesh 2016

Caitie McCaffrey

November 03, 2016
Tweet

More Decks by Caitie McCaffrey

Other Decks in Technology

Transcript

  1. A Brief History of Distributed
    Programming: RPC
    Code Mesh London 2016

    View full-size slide

  2. Christopher Meiklejohn
    Université catholique de Louvain
    @cmeik
    christophermeiklejohn.com

    View full-size slide

  3. Caitie McCaffrey
    Distributed Systems Engineer
    @caitie
    caitiem.com

    View full-size slide

  4. Computation can advance without waiting
    for all other computations to complete
    Computation is accomplished via the communication
    and coordination of networked computers
    Concurrent Programming
    Distributed Programming

    View full-size slide

  5. “An asynchronous event driven
    JavaScript runtime”
    Single Threaded
    Event Loop
    Callbacks

    View full-size slide

  6. Golang
    Go Routines Channels

    View full-size slide

  7. How do you communicate
    with code running on other
    machines?

    View full-size slide

  8. How do you communicate
    with code running on other
    machines?
    We’ve left that as an
    exercise for the reader…

    View full-size slide

  9. Erlang
    Actor Model
    for Concurrency
    Transparent
    Distribution
    Added Later
    &

    View full-size slide

  10. Cloud Haskell
    Haskell Implementations of Distributed
    Erlang semantics
    Extension of a Concurrent Language for
    Distribution

    View full-size slide

  11. RPC: Remote Procedure Call
    make remote calls just as simple a local calls

    View full-size slide

  12. 1974 1975 1976
    Present
    Future
    RFC 674 RFC 684 RFC 707
    1988
    A Critique of the
    Remote
    Procedure Call
    1989
    RFC 1094
    NFS
    1991
    CORBA
    1994
    A Note on
    Distributed
    Computing
    Overview
    1984
    Implementing
    Remote
    Procedure Calls

    View full-size slide

  13. Procedure Call
    Paradigm (PCP) is an
    attempt at defining a
    mechanism for
    resources sharing
    across all 70 nodes
    on the Internet.
    RFC 674
    1974

    View full-size slide

  14. RFC 684 Criticisms
    Local Calls & Remote Calls have different
    Cost Profiles
    Asynchronous Message Passing is a better
    model because it makes the passing of
    messages explicit
    Remote Calls can be delayed or never return
    1975

    View full-size slide

  15. RFC 707, 1976
    RFC 707
    1976
    A High-Level Framework for
    Network-Based Resource Sharing
    Generalization to functions
    Generalize TELNET and FTP’s call-
    and-response model to functions from
    an application-specific grammar. One
    port for all protocols
    Control Flow Critique
    RPC only allows for sequential
    composition

    View full-size slide

  16. 1984 Implementing Remote Procedure Calls
    First Commercial Grade RPC

    View full-size slide

  17. “We propose the
    following test for a
    general-purpose
    RPC system"
    1988

    View full-size slide

  18. “Imagine that two programmers
    are working on a project.
    Programmer 1 is writing the
    main program. Programmer 2 is
    writing a collection of
    procedures to be called by the
    main program”
    A Critique of the Remote Procedure Call Paradigm

    View full-size slide

  19. “At the very last minute, after
    all the code has been
    thoroughly tested, debugged,
    and documented and both
    programmers have quit their
    jobs and left the country …”
    A Critique of the Remote Procedure Call Paradigm

    View full-size slide

  20. “…the project management is
    forced by unexpected,
    external circumstances to run
    the program on a distributed
    system.”
    A Critique of the Remote Procedure Call Paradigm

    View full-size slide

  21. “…the project management is
    forced by unexpected,
    external circumstances to run
    the program on a distributed
    system.”
    A Critique of the Remote Procedure Call Paradigm

    View full-size slide

  22. “It is our contention that a
    large number of thing may
    now go wrong due to the fact
    that RPC tries to make remote
    procedure calls look exactly
    like local ones, but is unable
    to do it perfectly”
    A Critique of the Remote Procedure Call Paradigm

    View full-size slide

  23. “There is, in fact, no protocol that
    guarantees that both sides
    definitely and unambiguously
    know that the RPC is over in the
    face of a lossy network.”
    A Critique of the Remote Procedure Call Paradigm

    View full-size slide

  24. RFC 1094
    First major distributed
    filesystem that gained
    popularity and adhered
    to the existing UNIX
    filesystem API
    Network File System
    1989

    View full-size slide

  25. Network File System
    Soft Mounting
    Hard Mounting
    Introduced new error codes for distributed failures that
    existing UNIX applications could not handle
    Operations would block until they could be
    completed successfully

    View full-size slide

  26. CORBA
    Common Object Request Broker Architecture
    1991
    Supported Cross-Language, Cross Address Space
    Interoperability for Object-Oriented Programming
    Interface Definition Language (IDL) : used to generate stubs for
    remote objects & mappings between different primitive types
    “It’s Just a Mapping Problem” Remote to local exception
    mapping, remote to local method invocation.

    View full-size slide

  27. “It is the thesis of this note
    that this unified view of
    objects is mistaken”
    1994

    View full-size slide

  28. A Note on Distributed Computing
    Performance analysis is non-trivial and one design is not
    always going to be the right design.
    How do we deal with the problems of pointers and references?
    Once moved they are no longer valid unless we use distributed
    shared memory.
    Failures are detectable in the local environment and result in a
    “return of control”. In distributed computing this isn’t true.
    Latency
    Memory Access
    Partial Failure

    View full-size slide

  29. Two Paths Forward
    Treat all
    objects as
    local
    Treat all
    objects as
    remote
    Or
    A Note on Distributed Computing

    View full-size slide

  30. “This approach would also defeat the overall purpose of unifying
    the object models. The real reason for attempting such a unification
    is to make distributed computing more like local computing and
    thus make distributed computing easier. This second approach to
    unifying the models makes local computing as complex as
    distributed computing.”
    Treat all objects as remote
    A Note on Distributed Computing

    View full-size slide

  31. Microservices

    View full-size slide

  32. Microservices

    View full-size slide

  33. Microservices
    The Re-emergence of RPC Frameworks

    View full-size slide

  34. Finagle
    IDL: Thrift
    RPC System for the JVM
    Based on Futures
    Request/Response

    View full-size slide

  35. gRPC IDL: Protobufs
    Multi-Language RPC
    framework
    Supports Bi Directional
    Streaming
    (C/C++, C#, Node.js, PHP,
    Ruby, Python, Go, Java)

    View full-size slide

  36. Don’t Provide a Unified Model
    Modern RPC Frameworks

    View full-size slide

  37. –A Note on Distributed Computing
    “The hard problems in distributed
    computing are not the problems of
    getting things on and off the wire.”
    Kendall et al., “A Note On Distributed Computing”, 1994

    View full-size slide

  38. The point of RPC was to make remote
    calls just as simple as local calls.

    View full-size slide

  39. The point of RPC was to make remote
    calls just as simple as local calls.
    If we treat everything as remote, have we simplified
    distributed computation at all?

    View full-size slide

  40. The point of RPC was to make remote
    calls just as simple as local calls.
    If we treat everything as remote, have we simplified
    distributed computation at all?
    If we can't treat all calls as local, is the *procedure
    call* the right abstraction for distributed
    computation?

    View full-size slide

  41. Future
    Spores: A Type-Based Foundation for
    Closures in the Age of Concurrency and
    Distribution
    Lasp: Distributed Deterministic Data Flow
    Programming for Erlang
    Consistency Analysis in Bloom: a CALM
    and Collected Approach

    View full-size slide

  42. Spores
    Serializable closures with capture controlled by
    the type system (Scala)
    Dual to Actor Systems (like Erlang). Actors
    exchange data with async messaging, spores are
    stateless processes that pass functions around with
    asynchronous messages
    Spores are small units of possibly mobile
    functional behavior

    View full-size slide

  43. Thanks
    @Caitie @Cmeik
    https://github.com/CaitieM20/Talks/tree/
    master/DistributedProgrammingRPC
    Resources

    View full-size slide