Remote Procedure Calls (RPC)“Implementing RPC”MotivationHow RPC Works (Diagram)BindingPowerPoint PresentationNotes on BindingPacket-Level TransportSimple CaseSimple Case DiagramSimple Case (cont.)Complicated CallSlide 13Exception HandlingProcessesOther OptimizationEnvironmentPerformance ChartPerformance ExplanationsPerformance cont.Slide 21RPCRuntime Recap“Performance of Firefly RPC”RPC Implementation on FireflyFirefly SystemStandard MeasurementsLatency and ThroughputSlide 28Marshaling TimeAnalysis of PerformanceTransporterReducing LatencySlide 33Slide 34Understanding PerformanceSlide 36Latency of RPC OverheadsLatency for Null and MaxImprovementsImprovements (cont.)Slide 41Effect of Processors TableEffect of ProcessorsEffect of Processors (cont.)Comparisons TableComparisonsRemote Procedure Calls (RPC)Presenter: Benyah ShaparenkoCS 614, 2/24/2004“Implementing RPC”Andrew Birrell and Bruce NelsonTheory of RPC was thought outImplementation details were sketchyGoal: Show that RPC can make distributed computation easy, efficient, powerful, and secureMotivationProcedure calls are well-understoodWhy not use procedural calls to model distributed behavior?Basic GoalsSimple semantics: easy to understandEfficiency: procedures relatively efficientGenerality: procedures well knownHow RPC Works (Diagram)BindingNaming + LocationNaming: what machine to bind to?Location: where is the machine?Uses a Grapevine databaseExporter: makes interface availableGives a dispatcher methodInterface info maintained in RPCRuntimeNotes on BindingExporting machine is statelessBindings broken if server crashesCan call only procedures server exportsBinding typesDecision about instance made dynamicallySpecify type, but dynamically pick instanceSpecify type and instance at compile timePacket-Level TransportSpecifically designed protocol for RPCMinimize latency, state informationBehaviorIf call returns, procedure executed exactly onceIf call doesn’t return, executed at most onceSimple CaseArguments/results fit in a single packetMachine transmits till packet receivedI.e. until either Ack, or a response packetCall identifier (machine identifier, pid)Caller knows response for current callCallee can eliminate duplicatesCallee’s state: table for last call ID rec’dSimple Case DiagramSimple Case (cont.)Idle connections have no state infoNo pinging to maintain connectionsNo explicit connection terminationCaller machine must have unique call identifier even if restartedConversation identifier: distinguishes incarnations of calling machineComplicated CallCaller sends probes until gets responseCallee must respond to probeAlternative: generate Ack automaticallyNot good because of extra overheadWith multiple packets, send packets one after another (using seq. no.) only last one requests Ack messageException HandlingSignals: the exceptionsImitates local procedure exceptionsCallee machine can only use exceptions supported in exported interface“Call Failed” exception: communication failure or difficultyProcessesProcess creation is expensiveSo, idle processes just wait for requestsPackets have source/destination pid’sSource is caller’s pidDestination is callee’s pid, but if busy or no longer in system, can be given to another process in callee’s systemOther OptimizationRPC communication in RPCRuntime bypasses software layersJustified since authors consider RPC to be the dominant communication protocolSecurityGrapevine is used for authenticationEnvironmentCedar programming environmentDoradosCall/return < 10 microseconds24-bit virtual address space (16-bit words)80 MB diskNo assembly language3 Mb/sec Ethernet (some 10 Mb/sec)Performance ChartPerformance ExplanationsElapsed times accurate to within 10% and averaged over 12000 callsFor small packets, RPC overhead dominatesFor large packets, data transmission times dominateThe time not from the local call is due to the RPC overheadPerformance cont.Handles simple calls that are frequent really wellWith more complicated calls, the performance doesn’t scale so wellRPC more expensive for sending large amounts of data than other procedures since RPC sends more packetsPerformance cont.Able to achieve transfer rate equal to a byte stream implementation if various parallel processes are interleavedExporting/Importing costs unmeasuredRPCRuntime RecapGoal: implement RPC efficientlyHope is to make possible applications that couldn’t previously make use of distributed computingIn general, strong performance numbers“Performance of Firefly RPC”Michael Schroeder and Michael BurrowsRPC gained relatively wide acceptanceSee just how well RPC performsAnalyze where latency creeps into RPCNote: Firefly designed by Andrew BirrellRPC Implementation on FireflyRPC is primary communication paradigm in FireflyUsed for inter-machine communicationAlso used for communication within a machine (not optimized… come to the next class to see how to do this)Stubs automatically generatedUses Modula2+ codeFirefly System5 MicroVAX II CPUs (1 MIPS each)16 MB shared memory, coherent cacheOne processor attached to Qbus10 Mb/s EthernetNub: system kernelStandard MeasurementsNull procedureNo arguments and no resultsMeasures base latency of RPC mechanismMaxResult, MaxArg proceduresMeasures throughput when sending the maximum size allowable in a packet (1514 bytes)Latency and ThroughputLatency and ThroughputThe base latency of RPC is 2.66 ms7 threads can do 741 calls/secLatency for Max is 6.35 ms4 threads can achieve 4.65 Mb/secData transfer rate in application since data transfers use RPCMarshaling TimeAs expected, scales linearly with size and number of arguments/resultsExcept when library code is called…0100200300400500600700NI L 1 128MarshalingTimeAnalysis of PerformanceSteps in fast path (95% of RPCs)Caller: obtains buffer, marshals arguments, transmits packet and waits (Transporter)Server: unmarshals arguments, calls server procedure, marshals results, sends resultsClient: Unmarshals results, free packetTransporterFill in RPC header in call packetSender fills in other headersSend packet on Ethernet (queue it, read it from memory, send it from CPU