REMOTE PROCEDURE CALLS Steve Vinoski Basho Technologies, Cambridge, - - PowerPoint PPT Presentation

MYTHBUSTING

REMOTE PROCEDURE CALLS

Steve Vinoski

Basho Technologies, Cambridge, MA USA @stevevinoski, vinoski@ieee.org, http://steve.vinoski.net/

Monday, October 1, 12

Remote Procedure Call

Monday, October 1, 12

Remote Procedure Call

Monday, October 1, 12

Remote Procedure Call

"Remote procedure call (RPC) is an Inter-process communication technology that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction."

Monday, October 1, 12

Remote Procedure Call

"Remote procedure call (RPC) is an Inter-process communication technology that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction." "That is, the programmer would write essentially the same code whether the subroutine is local to the executing program, or remote." —Wikipedia

Monday, October 1, 12

RPC History: The 1970s

Monday, October 1, 12

Early Networked Systems

ARPANET started in 1969 Early host-to-host protocols focused on human-to-computer communications Email: 1971 FTP and interoperable Telnet: 1973 There was interest in app-to-app protocols

Monday, October 1, 12

RFC 707: the Beginnings of RPC

In late 1975, James E. White wrote RFC 707, "A High-Level Framework for Network-Based Resource Sharing" Culmination of several earlier RFCs (such as 674) and other related work Tried to address concerns of application-to- application protocols

Monday, October 1, 12

“Because the network access discipline imposed by each resource is a human-engineered command language, rather than a machine-

• riented communication protocol, it is virtually

impossible for one resource to programatically draw upon the services of others.” —RFC 707

Monday, October 1, 12

Distributed Systems Difficulties

Monday, October 1, 12

Also concerned with whether average developers could even write networked applications:

Distributed Systems Difficulties

Monday, October 1, 12

Also concerned with whether average developers could even write networked applications: "Because the system provides only the IPC facility as a foundation, the applications programmer is deterred from using remote resources by the amount of specialized knowledge and software that must first be acquired." —RFC 707

Distributed Systems Difficulties

Monday, October 1, 12

Procedure Call Model

Monday, October 1, 12

Procedure Call Model

Monday, October 1, 12

Procedure Call Model

developers were already familiar with calling libraries

• f procedures

Monday, October 1, 12

Procedure Call Model

developers were already familiar with calling libraries

• f procedures

"Ideally, the goal...is to make remote resources as easy to use as local ones. Since local resources usually take the form of resident and/or library subroutines, the possibility of modeling remote commands as ‘procedures’ immediately suggests itself." —RFC 707

Monday, October 1, 12

Procedure Call Model

Monday, October 1, 12

Procedure Call Model

the Procedure Call Model would make calls to networked applications look just like normal procedure calls

Monday, October 1, 12

Procedure Call Model

the Procedure Call Model would make calls to networked applications look just like normal procedure calls "The procedure call model would elevate the task

• f creating applications protocols to that of

defining procedures and their calling sequences." —RFC 707

Monday, October 1, 12

"The Model is further confirmed by the similarity that exists between local procedures and the remote commands to which the Protocol provides

• access. Both carry out arbitrarily complex,

named operations on behalf of the requesting program (the caller); are governed by arguments supplied by the caller; and return to it results that reflect the outcome of the

• peration. The procedure call model thus

acknowledges that, in a network environment, programs must sometimes call subroutines in machines other than their own."

Monday, October 1, 12

"This integration of local and network programming environments can even be carried as far as modifying compilers to provide minor variants of their normal procedure-calling constructs for addressing remote procedures..."

Monday, October 1, 12

RFC 707 Caveats

Monday, October 1, 12

RFC 707 Caveats

Monday, October 1, 12

RFC 707 Caveats

"Although in many ways it accurately portrays the class of network interactions with which this paper deals, the Model...may in other respects tend to mislead the applications programmer."

Monday, October 1, 12

RFC 707 Caveats

"Although in many ways it accurately portrays the class of network interactions with which this paper deals, the Model...may in other respects tend to mislead the applications programmer." "Local procedure calls are cheap; remote procedure calls are not."

Monday, October 1, 12

RFC 707 Caveats

Monday, October 1, 12

RFC 707 Caveats

"Conventional programs usually have a single locus of control; distributed programs need not."

Monday, October 1, 12

RFC 707 Caveats

"Conventional programs usually have a single locus of control; distributed programs need not." "...the applications programmer must recognize that by no means all useful forms of network communication are effectively modeled as procedure calls."

Monday, October 1, 12

RFC 684

Monday, October 1, 12

RFC 684

"A Commentary on Procedure Calling as a Network Protocol" by Rick Schantz, April 1975 Expressed concerns with the Procedure Call Protocol (from RFC 674) and related efforts that later led to RFC 707 Contains a wealth of distributed systems wisdom

Monday, October 1, 12

"While the procedure call may be an appropriate basis for certain applications, we believe that it can neither directly nor accurately model the interactions and control structures that occur in many distributed multi-computer systems." —RFC 684

Monday, October 1, 12

"Since procedure calling is more suitable as an intra-process notion, it seems to be a better idea to take the interprocess communication framework and extend it to have a uniform interpretation locally and remotely, rather than to extend the procedure calling model." —RFC 684

Monday, October 1, 12

"It is also our contention that a model which relies

• n procedure calling for its basis does not take into

account the special nature of the network environment, and that such an environment can be more suitably handled in a message passing model." —RFC 684

Monday, October 1, 12

"An IPC model, by emphasizing the connections between disjoint processes, seems to reinforce the idea that distributed computing is accomplished by joining separate entities, and that defensive programming and error handling techniques are appropriate." —RFC 684

Monday, October 1, 12

"In the PCP model, it may become awkward or resource consuming for a service program to do such things as queue operations for execution at a later time (persistence) or at a more opportune time (priority servicing mechanism)." —RFC 684

Monday, October 1, 12

"Our conclusion is that procedure calling is not the appropriate basis for distributed multi-computer systems because it can neither directly nor accurately model the network environment." —RFC 684

Monday, October 1, 12

RPC History: The 1980s

Monday, October 1, 12

Research to Practice

Monday, October 1, 12

Research to Practice

Monday, October 1, 12

Research to Practice

Computing platforms: mainframe to mini to workstation to PC

Monday, October 1, 12

Research to Practice

Computing platforms: mainframe to mini to workstation to PC Methodologies: structured programming to OOP

Monday, October 1, 12

Research to Practice

Computing platforms: mainframe to mini to workstation to PC Methodologies: structured programming to OOP Languages: Lisp, Pascal, C, Smalltalk, C++, Eiffel, Ada, Objective-C, Perl, Erlang, etc.

Monday, October 1, 12

Research to Practice

Computing platforms: mainframe to mini to workstation to PC Methodologies: structured programming to OOP Languages: Lisp, Pascal, C, Smalltalk, C++, Eiffel, Ada, Objective-C, Perl, Erlang, etc. Distributed Systems: OS, languages, frameworks, applications

Monday, October 1, 12

Distributed Systems

Monday, October 1, 12

Distributed Systems

BSD socket API

Monday, October 1, 12

Distributed Systems

BSD socket API Argus, a language/system for reliable distributed apps

Monday, October 1, 12

Distributed Systems

BSD socket API Argus, a language/system for reliable distributed apps Xerox Cedar: the seminal Birrell/Nelson paper "Implementing Remote Procedure Calls"

Monday, October 1, 12

Distributed Systems

BSD socket API Argus, a language/system for reliable distributed apps Xerox Cedar: the seminal Birrell/Nelson paper "Implementing Remote Procedure Calls" Eden, an OO distributed OS based on RPC

Monday, October 1, 12

Distributed Systems

Monday, October 1, 12

Distributed Systems

Emerald, a distributed object language providing

• bject mobility and local/remote transparency

Monday, October 1, 12

Distributed Systems

Emerald, a distributed object language providing

• bject mobility and local/remote transparency

ANSAware, a full-feature RPC-based system for portable distributed apps

Monday, October 1, 12

RPC Everywhere

Monday, October 1, 12

RPC Everywhere

Monday, October 1, 12

RPC Everywhere

Distributed systems research focus: full-stack systems

Monday, October 1, 12

RPC Everywhere

Distributed systems research focus: full-stack systems OS, language, compiler, distribution mechanisms

Monday, October 1, 12

RPC Everywhere

Distributed systems research focus: full-stack systems OS, language, compiler, distribution mechanisms Most used RPC as a key abstraction

Monday, October 1, 12

Focus on Uniformity

Monday, October 1, 12

Focus on Uniformity

Local/remote transparency, location transparency

Monday, October 1, 12

Focus on Uniformity

Local/remote transparency, location transparency Single type system across the distributed system

Monday, October 1, 12

Focus on Uniformity

Local/remote transparency, location transparency Single type system across the distributed system Types checked at compile-time

Monday, October 1, 12

Protocols

Research systems papers rarely discussed network protocols Closed, proprietary, specialized per system Protocol was just part of "RPC black box"

Monday, October 1, 12

Industrial Distributed Systems

Monday, October 1, 12

Industrial Distributed Systems

Vendors supplied full stacks: hardware, software, network Limited network interoperability between stacks Homogeneous systems

Monday, October 1, 12

Research Into Practice

Monday, October 1, 12

Research Into Practice

Vendors needed to adopt distributed systems research

Monday, October 1, 12

Research Into Practice

Vendors needed to adopt distributed systems research But didn't want to adopt full research stacks

Monday, October 1, 12

Research Into Practice

Vendors needed to adopt distributed systems research But didn't want to adopt full research stacks Porting was difficult

Monday, October 1, 12

Research Into Practice

Vendors needed to adopt distributed systems research But didn't want to adopt full research stacks Porting was difficult Everything had to be compiled to get reasonable performance

Monday, October 1, 12

Research Into Practice

Vendors needed to adopt distributed systems research But didn't want to adopt full research stacks Porting was difficult Everything had to be compiled to get reasonable performance Little interest in interpreters and virtual machines

Monday, October 1, 12

Standards

Rapid hardware advances produced a need for software portability and interoperability Users began to have heterogeneous networks, so they wanted portable OS interfaces standard/portable programming languages standard networks and protocols

Monday, October 1, 12

Languages

Researchers had their own distributed languages Industry wanted standard languages

Monday, October 1, 12

Research Into Practice

Vendors adopted research ideas But kept their own stacks and used standard languages

Monday, October 1, 12

Industrial RPC Systems

Apollo's Network Computing System (NCS), an RPC system with an IDL Sun's Open Network Computing (ONC) RPC DEC, IBM, HP also had RPC-based projects

Monday, October 1, 12

Internet Influence

ARPANET converted to TCP/IP in 1983 Internet services such as email and file transfer continued to improve and gain popularity through the 1980s Industry started adopting TCP/IP in the latter half

• f the 80s

Monday, October 1, 12

RPC History: The 1990s

Monday, October 1, 12

Distributed Objects

Monday, October 1, 12

Distributed Objects

Distributed systems were popping up everywhere OOP was viewed as the way to develop software Vendors all had their own distributed objects projects

Monday, October 1, 12

CORBA

Industry standard comprising contributions from a variety of vendors Based squarely on 1980s research, focused on distributed objects languages (first C, then C++, others later) local/remote transparency

Monday, October 1, 12

Published in 1999

Still earns royalties! :)

Monday, October 1, 12

CORBA

Industry standard comprising contributions from a variety of vendors Based squarely on 1980s research, focused on distributed objects languages (first C, then C++, others later) local/remote transparency

Monday, October 1, 12

A Note on Distributed Computing

Monday, October 1, 12

A Note on Distributed Computing

Monday, October 1, 12

A Note on Distributed Computing

Important 1994 paper by Jim Waldo, Ann Wollrath, Geoff Wyant, Sam Kendall

Monday, October 1, 12

A Note on Distributed Computing

Important 1994 paper by Jim Waldo, Ann Wollrath, Geoff Wyant, Sam Kendall Explained (again) why distributed objects and local objects were different

Monday, October 1, 12

A Note on Distributed Computing

Important 1994 paper by Jim Waldo, Ann Wollrath, Geoff Wyant, Sam Kendall Explained (again) why distributed objects and local objects were different latency

Monday, October 1, 12

A Note on Distributed Computing

Important 1994 paper by Jim Waldo, Ann Wollrath, Geoff Wyant, Sam Kendall Explained (again) why distributed objects and local objects were different latency access models

Monday, October 1, 12

A Note on Distributed Computing

Important 1994 paper by Jim Waldo, Ann Wollrath, Geoff Wyant, Sam Kendall Explained (again) why distributed objects and local objects were different latency access models partial failure

Monday, October 1, 12

A Note on Distributed Computing

Important 1994 paper by Jim Waldo, Ann Wollrath, Geoff Wyant, Sam Kendall Explained (again) why distributed objects and local objects were different latency access models partial failure concurrency

Monday, October 1, 12

"Communications protocol development has tended to follow two paths. One path has emphasized integration with the current language model. The other path has emphasized solving the problems inherent in distributed

• computing. Both are necessary, and successful

advances in distributed computing synthesize elements from both camps." —A Note on Distributed Computing

Monday, October 1, 12

Fallacies of Distributed Computing

The network is reliable Latency is zero Bandwidth is infinite The network is secure Topology doesn't change There is one administrator Transport cost is zero The network is homogeneous

FROM HTTP://EN.WIKIPEDIA.ORG/WIKI/FALLACIES_OF_DISTRIBUTED_COMPUTING Monday, October 1, 12

Distributed Java

Monday, October 1, 12

Distributed Java

Various Java distributed computing projects, too many to cover here But large parts of Java adopted CORBA Later, CORBA adopted ill-conceived "Objects By Value" and "Reverse Java-IDL Mapping" specs to allow Java objects to be passed over the wire

Monday, October 1, 12

The Rise of the Web

Monday, October 1, 12

The Rise of the Web

CORBA and Java focused on the enterprise and later, SOAP Meanwhile, the Web was taking over the world

Monday, October 1, 12

Distributed Objects!

Monday, October 1, 12

Distributed Objects!

The Web is arguably distributed objects too, but:

Monday, October 1, 12

Distributed Objects!

The Web is arguably distributed objects too, but: fixed set of methods

Monday, October 1, 12

Distributed Objects!

The Web is arguably distributed objects too, but: fixed set of methods hypermedia coupling

Monday, October 1, 12

Distributed Objects!

The Web is arguably distributed objects too, but: fixed set of methods hypermedia coupling language independent

Monday, October 1, 12

Distributed Objects!

The Web is arguably distributed objects too, but: fixed set of methods hypermedia coupling language independent designed specifically for large-scale networks

Monday, October 1, 12

RPC History: New Millennium

Monday, October 1, 12

Web Services

Monday, October 1, 12

Web Services

Early 2000: W3C works on Web Services standards based on SOAP and WSDL

Monday, October 1, 12

Web Services

Early 2000: W3C works on Web Services standards based on SOAP and WSDL An attempt to apply the enterprise view of distributed systems to the Web

Monday, October 1, 12

Web Services

Early 2000: W3C works on Web Services standards based on SOAP and WSDL An attempt to apply the enterprise view of distributed systems to the Web "CORBA with angle brackets"

Monday, October 1, 12

Web Services

Thankfully, not used on the web But still used in the enterprise even today, due to simple Java code generation tools write a Java object push a button in the IDE get WSDL and a Web Service, yay! there's that language focus again...

Monday, October 1, 12

REST

Monday, October 1, 12

REST

REpresentational State Transfer (REST) coined in Roy Fielding's doctoral thesis, published in 2000

Monday, October 1, 12

REST

REpresentational State Transfer (REST) coined in Roy Fielding's doctoral thesis, published in 2000 Provides significant analysis of tradeoffs made to deal with network issues and scale

Monday, October 1, 12

REST

REpresentational State Transfer (REST) coined in Roy Fielding's doctoral thesis, published in 2000 Provides significant analysis of tradeoffs made to deal with network issues and scale Try to find any RPC system that provides similar analysis—you won't, due to language focus

Monday, October 1, 12

RPC Today

Monday, October 1, 12

RPC Today

Monday, October 1, 12

RPC Today

Do we still use RPC in 2012?

Monday, October 1, 12

RPC Today

Do we still use RPC in 2012? Yes, definitely

Monday, October 1, 12

RPC Today

Do we still use RPC in 2012? Yes, definitely Are we smarter about it?

Monday, October 1, 12

RPC Today

Do we still use RPC in 2012? Yes, definitely Are we smarter about it? Somewhat

Monday, October 1, 12

Improved Awareness

Differences between local and remote Netsplits and partial failure Problems with blocking calls Support for multiple communication patterns Coupling problems Programming language renaissance Better understanding of scaling issues

Monday, October 1, 12

Local vs. Remote

Huge differences in latency and failure modes You can't hide these differences Distributed systems offer redundancy and resiliency; embrace them and take advantage!

Monday, October 1, 12

Blocking Calls

Monday, October 1, 12

Blocking Calls

A true RPC is blocking: first call, then wait for return (and BTW "Async RPC" is an oxymoron)

Monday, October 1, 12

Blocking Calls

A true RPC is blocking: first call, then wait for return (and BTW "Async RPC" is an oxymoron) Better to just send a message, rendezvous later if needed

Monday, October 1, 12

Blocking Calls

A true RPC is blocking: first call, then wait for return (and BTW "Async RPC" is an oxymoron) Better to just send a message, rendezvous later if needed Consider how each message fits into the overall flow of work

Monday, October 1, 12

Blocking Calls

A true RPC is blocking: first call, then wait for return (and BTW "Async RPC" is an oxymoron) Better to just send a message, rendezvous later if needed Consider how each message fits into the overall flow of work know what to do if a message gets lost or delayed

Monday, October 1, 12

Communication Patterns

Monday, October 1, 12

Communication Patterns

True RPC is point-to-point request-reply

Monday, October 1, 12

Communication Patterns

True RPC is point-to-point request-reply Ignores multicast, broadcast, fire-and-forget, pub- sub, delayed execution, message priorities

Monday, October 1, 12

Communication Patterns

True RPC is point-to-point request-reply Ignores multicast, broadcast, fire-and-forget, pub- sub, delayed execution, message priorities These are hard to model in typical programming language semantics

Monday, October 1, 12

Communication Patterns

True RPC is point-to-point request-reply Ignores multicast, broadcast, fire-and-forget, pub- sub, delayed execution, message priorities These are hard to model in typical programming language semantics Embrace the protocols, don't hide them

Monday, October 1, 12

Coupling Problems

Monday, October 1, 12

Coupling Problems

RPC imposes app-specific methods and data types contrast with REST's app-independent verbs, independent reusable content types, content negotiation

Monday, October 1, 12

Coupling Problems

RPC imposes app-specific methods and data types contrast with REST's app-independent verbs, independent reusable content types, content negotiation RPC imposes implied workflow and hides state transitions

Monday, October 1, 12

Coupling Problems

RPC imposes app-specific methods and data types contrast with REST's app-independent verbs, independent reusable content types, content negotiation RPC imposes implied workflow and hides state transitions RPC imposes fixed transfer syntax

Monday, October 1, 12

Coupling Problems

RPC imposes app-specific methods and data types contrast with REST's app-independent verbs, independent reusable content types, content negotiation RPC imposes implied workflow and hides state transitions RPC imposes fixed transfer syntax RPC imposes heavy infrastructure on both ends

Monday, October 1, 12

Language Renaissance

Around 2000 nobody seemed to be working on new programming languages, but that's changed Significant interest in functional programming New languages on the JVM JavaScript everywhere

Monday, October 1, 12

My Favorite: Erlang

Monday, October 1, 12

My Favorite: Erlang

Erlang is the best example I know addressing the two paths raised in "A Note on Distributed Computing" language model problems inherent in distributed computing

Monday, October 1, 12

My Favorite: Erlang

Erlang is the best example I know addressing the two paths raised in "A Note on Distributed Computing" language model problems inherent in distributed computing Sadly, many ignore it because it's not on the JVM (but see Erjang) they don't like its Prolog-based syntax umm, have you seen JavaScript, Java, C++ syntax? WTF!

Monday, October 1, 12

Scaling Systems

Developers have a better grasp on scaling today Thanks to the Web and R&D to address large- scale systems

Monday, October 1, 12

Scaling Systems

Shared-nothing architectures CAP Theorem Staged Event-Driven Architectures (SEDA) Amazon Dynamo Google's architectures Mechanical Sympathy Operating system improvements in networking and measurement tools

Monday, October 1, 12

Scaling Systems

Caching and intermediaries are critical for large- scale systems Ever try to cache RPC? Doable, but only if you consider it up front No language constructs help Intermediation can be difficult due to RPC type systems

Monday, October 1, 12

Summary

RPC is a convenient but flawed accident of history Should have paid better attention to RFC 684! Fortunately, the scale of the Web has forced us down much better paths

Monday, October 1, 12

Friends don't let friends commit RPC

Monday, October 1, 12

Steve Vinoski

Basho Technologies, Cambridge, MA USA @stevevinoski, vinoski@ieee.org, http://steve.vinoski.net/

Monday, October 1, 12