Remote Procedure CallOutlineIntroductionSlide 4Slide 5The RPC modelRPC MechanismsSlide 8Slide 9Slide 10BenefitsCharacteristicsDesign issuesParameter passingRepresenting dataSlide 16BindingFailuresDelivery guaranteesCall SemanticsSlide 21Slide 22Slide 23More issuesProgramming with RPCSlide 26Slide 27Case Studies: SUN RPCReferencesThank you!1Remote Procedure CallCISC 879 – Spring 03Tam Vu ([email protected])March 06, 032OutlineIntroductionRPC mechanismsDesign issuesProgramming with RPCCase study: SUN RPC3IntroductionProblem with socketsSocket interface is straightforwardConnectRead/writeDisconnectForces read/write mechanismNot how we generally programWe usually use procedure callsTo make distributed computing look more like centralized:I/O is not the way to go4Introduction1984: Birrell & NelsonMechanisms to call procedures on other machinesProcesses on machine A can call procedures on machine BA is suspendedExecution continues on BWhen B returns, control passed back to AGoal: it appears to the programmer that a normal call is taking place5IntroductionRemote Procedure Call (RPC) is a high-level model for client-sever communication.RPC enables clients to communicate with servers by calling procedures in a similar way to the conventional use of procedure calls in high-level languages.Examples: File service, Authentication service.6The RPC modelBlocking stateclientserverrequestreplyExecuting stateCalls procedure and wait for replyReceives request and starts process executionSends reply and wait for next executionResumes execution7RPC MechanismsThe client transfer call request (the procedure name) and the arguments to the server via client stub functionstub function marshals arguments and places them into a message together with the remote procedure identifier.Sends message to server and waits for call return8RPC MechanismsServer receives the call request and passes to an appropriate server stub function.server stub function unmarshals the arguments, call the corresponding (local) service procedure.On return, the server stub marshals the output arguments into a call return message and sends back to the client.9RPC MechanismsClient stub receives call reply, unmarshals value, returns to client code10RPC Mechanismsclient stubfunc.CommunicationmoduleLocal returnLocal callClient computerServer computerserver stubfunc.client service procedureReceivereplySendrequestUnmarshalresultsMarshalargumentsReceiverequestSendreplySelect procedureUnmarshalargumentsMarshalresultsExecute procedure11BenefitsFamiliar procedure call interfaceWriting applications is simplifiedRPC hides all networks codesProgrammers don’t have to worry about details (sockets, port numbers, byte ordering)RPC: presentation layer in OSI model12CharacteristicsThe called procedure is in another process which may reside in another machine.The processes do not share address space.Passing of parameters by reference and passing pointer values make no sense.The called remote procedure executes within the environment of the server process. The called procedure does not have access to the calling procedure's environment.13Design issues14Parameter passingBy values easy, just copy data to network message.By referencemakes no sense without shared memoryTrickCopy items referenced to message bufferShip them overUnmarshal data at serverPass local pointer to server stub functionSend new value back15Representing dataNo such things as incompatibility on local systemsRemote machine may have:Different byte orderingDifferent sizes of integers and other typesDifferent floating point representationsDifferent character setsNeed standard encoding to enable communication between heterogeneous systems16Representing dataImplicit typingOnly values are transmitted, not data type or parameter informationE.g., Sun XDR (eXternal Data Representation)Explicit typingTypes are transmitted with valuesE.g., ISO ANS.1, XML17BindingHow to locate host and server process?Solution 1: use a central DBServer sends message to central DB indicating the services it can offerClients contact this authority whenever they need to locate a serviceSolution 2:Client needs to know server nameServer maintains a DB of available services18FailuresLocal procedure calls do not failIf they core dump, the entire process diesRPC is more vulnerable to failure:Server could generate errorsProblems in networkServer crashClient crash while server is still running code for itTransparency breaks hereApplications should be prepared to deal with RPC failure19Delivery guaranteesRetry request message: Client retransmits the request message until either a reply or the server is assumed to have failed.Duplicate filtering : server filters out duplicate message.Retransmission of replies: Server keeps a history of reply messages to enable lost replies retransmitted without re-executing the server operations.20Call SemanticsSemantic of local procedure calls: exactly-onceExactly-once maybe difficult to achieve with RPCAt-least-onceThe client assumes that the RP is executed at least once (on return from the RP).Can be implemented by retransmission of the request message on time-out. Acceptable only if the server’s operations are idempotent. That is f(x) = f(f(x)).21Call SemanticsAt-most-onceWhen a RPC returns, the remote procedure (RP) is assume to have been called exactly once or not at all.Implemented by the server's filtering of duplicate requests and caching of replies.22Call SemanticsAt-most-onceThis ensure the RP is called exactly once if the server does not crash during execution of the RP. When the server crashes during the RP's execution, the partial execution may lead to erroneous results. In this case, we want the effect that the RP has not been executed at all.23Call Semantics24More issuesPerformanceremote procedure call and return time can be significantly slower than that for local procedure call (1 - 3 orders of magnitude).SecurityMessages visible over the networkAuthenticate clientAuthenticate server25Programming with RPCMost languages (C, C++, Java,…) have no concept of remote procedure callsLanguage compilers will not generate client and server