CS514: Intermediate Course in Operating SystemsRemote Procedure CallA brief history of RPCMore historyThe basic RPC protocolSlide 6Slide 7Slide 8Slide 9Compilation stageBinding stageData in messagesRequest marshallingCosts in basic protocol?Schroeder and BurroughsTypical optimizations?Fancy argument passingOvercoming lost packetsSlide 19Slide 20Slide 21Costs in fault-tolerant version?Big packetsRPC “semantics”Implementing at most/least onceRPC versus local procedure callRPC costs in case of local destination processRPC exampleRPC in normal caseSlide 30Slide 31Important optimizations: LRPCLRPCSlide 34LRPC performance impactFbufsSlide 37Slide 38Slide 39Slide 40Slide 41Active messagesPerformance impact?U/NetU/Net conceptsU/Net implementationU-Net ArchitectureU-Net protection guaranteesU-Net reliability guaranteesMinimum U/Net costs?Protocols over U/NetVIA and Winsock DirectBroad comments on RPCContents of an RPC environmentExamples of RPC environmentsClosely Related TopicMultithreading debateSingle threading: drawbacksMultithreadingMultithreaded RPCNegatives to multithreadingThreads: can spawn too manySlide 63Slide 64Upcall modelUpcalls combined with threadsRecent RPC historyReadings for next lectureCS514: Intermediate Course in Operating SystemsProfessor Ken BirmanBen Atkin: TALecture 3: August 31Remote Procedure Call•Basic concepts•Implementation issues, usual optimizations•Where are the costs?•Firefly RPC, Lightweight RPC, Winsock Direct and VIA•Reliability and consistency•Multithreading debateA brief history of RPC•Introduced by Birrell and Nelson in 1985•Idea: mask distributed computing system using a “transparent” abstraction–Looks like normal procedure call–Hides all aspects of distributed interaction–Supports an easy programming model•Today, RPC is the core of many distributed systemsMore history•Early focus was on RPC “environments”•Culminated in DCE (Distributed Computing Environment), standardizes many aspects of RPC•Then emphasis shifted to performance, many systems improved by a factor of 10 to 20•Today, RPC often used from object-oriented systems employing CORBA or COM standards. Reliability issues are more evident than in the past.The basic RPC protocolclient server“binds” to serverregisters with name serviceThe basic RPC protocolclient server“binds” to serverprepares, sends requestregisters with name service receives requestThe basic RPC protocolclient server“binds” to serverprepares, sends requestregisters with name service receives requestinvokes handlerThe basic RPC protocolclient server“binds” to serverprepares, sends requestregisters with name service receives requestinvokes handlersends replyThe basic RPC protocolclient server“binds” to serverprepares, sends requestunpacks replyregisters with name service receives requestinvokes handlersends replyCompilation stage•Server defines and “exports” a header file giving interfaces it supports and arguments expected. Uses “interface definition language” (IDL)•Client includes this information•Client invokes server procedures through “stubs”–provides interface identical to the server version–responsible for building the messages and interpreting the reply messages–passes arguments by value, never by reference–may limit total size of arguments, in bytesBinding stage•Occurs when client and server program first start execution•Server registers its network address with name directory, perhaps with other information•Client scans directory to find appropriate server•Depending on how RPC protocol is implemented, may make a “connection” to the server, but this is not mandatoryData in messages•We say that data is “marshalled” into a message and “demarshalled” from it•Representation needs to deal with byte ordering issues (big-endian versus little endian), strings (some CPUs require padding), alignment, etc•Goal is to be as fast as possible on the most common architectures, yet must also be very generalRequest marshalling•Client builds a message containing arguments, indicates what procedure to invoke•Do to need for generality, data representation a potentially costly issue!•Performs a send I/O operation to send the message•Performs a receive I/O operation to accept the reply•Unpacks the reply from the reply message•Returns result to the client programCosts in basic protocol?•Allocation and marshalling data into message (can reduce costs if you are certain client, server have identical data representations)•Two system calls, one to send, one to receive, hence context switching•Much copying all through the O/S: application to UDP, UDP to IP, IP to ethernet interface, and back up to applicationSchroeder and Burroughs•Studied RPC performance in O/S kernel•Suggested a series of major optimizations•Resulted in performance improvments of about 10-fold for Xerox firefly workstation (from 10ms to below 1ms)Typical optimizations?•Compile the stub “inline” to put arguments directly into message•Two versions of stub; if (at bind time) sender and dest. found to have same data representations, use host-specific rep.•Use a special “send, then receive” system call (requires O/S extension)•Optimize the O/S kernel path itself to eliminate copying – treat RPC as the most important task the kernel will doFancy argument passing•RPC is transparent for simple calls with a small amount of data passed–“Transparent” in the sense that the interface to the procedure is unchanged–But exceptions thrown will include new exceptions associated with network•What about complex structures, pointers, big arrays? These will be very costly, and perhaps impractical to pass as arguments•Most implementations limit size, types of RPC arguments. Very general systems less limited but much more costly.Overcoming lost packetsclient serversends requestOvercoming lost packetsclient serversends requestretransmitack for requestduplicate request: ignoredTimeout!Overcoming lost packetsclient serversends requestretransmitack for requestreplyTimeout!Overcoming lost packetsclient serversends requestretransmitack for requestreplyack for replyTimeout!Costs in fault-tolerant version?•Acks are expensive. Try and avoid them, e.g. if the reply will be sent quickly supress the initial ack•Retransmission is costly. Try and tune the delay to be “optimal”•For big messages, send packets in bursts and ack a
View Full Document
Unlocking...