Cs 704 d rpc
Download as PPTX, PDF2 likes794 views
RPC allows for remote procedure calls to be made across distributed systems in a similar way to local procedure calls. RPC uses stubs to pack and unpack arguments and results so that the calls appear transparent whether local or remote. RPC messages contain information about the procedure, arguments, and client for execution on the server and returning results. Marshalling converts data to a stream for transmission and decoding on the receiving end. Servers can be stateful, maintaining information across calls, or stateless, requiring all needed information be passed each time.
Cs 704 d rpc
- 1. CS 704DAdvanced Operating System(RPC)Debasis Das
- 3. Remote Procedure CallsA special case for building distributed applications
- 4. RPC became popular IPC mechanisms for distributed applications
- 6. Familiar semantics, similar to local procedure calls\
- 7. Well defined interface, compile time type checking, auto interface generation
- 8. Ease of use, clean & Simple
- 10. Same IPC mechanism can be used for procedure on different machines as well as on the same machine11/21/2009IT703D: Dirstibuted Computing Debasis Das3
- 11. The RPC ModelBased on procedure call model
- 12. Make a procedure call, place parameters in a known location
- 13. Transfer control to the procedure
- 14. Procedure executes with copies of the parameters/arguments
- 15. Control is returned to calling procedure with result, if any11/21/2009IT703D: Distributed Computing Debasis Das4
- 16. RPC Model(Graphically)CallerClient ProcessRequest message & parametersSend reply with result, if anyServer Process11/21/2009IT703D: Distributed Computing Debasis Das5
- 17. RPC CharacteristicsServer process is normally dormant. Works when called
- 18. If concurrency required, calling processes can leave messages asynchronously, server process keeps serving requests
- 19. Server process can have threads. Starts a thread on request, server is free to field further calls if they come along11/21/2009IT703D: Distributed Computing Debasis Das6
- 20. Transparency of RPCFor a programmer it should be transparent whether he is calling a local or a remote procedure. Requires
- 23. Syntactic transparency is easy to achieve but not semantic transparency11/21/2009IT703D: Distributed Computing Debasis Das7
- 24. Semantic TransparencyNearly impossible to achieve, because
- 25. No shared memory: passing addresses as arguments is meaningless, call by reference pointers are useless, structures referenced by pointers are difficult.
- 26. More vulnerable to failures: two different processes, two different machines, intervening network. Processor and communication failures need to be taken care of.
- 27. RPCs can take much more time(x100 to x1000) due to communication congestions. Long delays need to be handled.11/21/2009IT703D: Distributed Computing Debasis Das8
- 28. Implementing RPC MechanismServerClientReturnCallCallReturnExecuteStubsUnpackPackPackUnpackRPC RuntimesReceiveSendReceiveSendWait11/21/2009IT703D: Distributed Computing Debasis Das9
- 29. StubsClient stub
- 30. On call request, packs specs of remote procedure and arguments
- 31. Asks RPC Runtime to transmit the message to the server
- 32. Server stub
- 33. After receipt, the RPC Runtime passes the message to it. It then unpacks the message and makes a usual call to the procedure.
- 34. On receipt of result, packs the result and asks the runtime to send it back to the client.11/21/2009IT703D: Distributed Computing Debasis Das10
- 35. Stub & TransparencyExcept for the stubs everything operates the same transparent way for local or remote procedure call.
- 36. No need to dabble in send & receive primitives11/21/2009IT703D: Distributed Computing Debasis Das11
- 38. Write code to implement translation functions provided by the RPC implementer
- 39. Automatically
- 40. By using IDL. Procedures supported by the interface, types of arguments and results
- 41. IDL compiler will ensure compilation, type checking etc.
- 42. Optimizes data to be sent over the network. Interface definition usually will have information as to which arguments are input/output/both.11/21/2009IT703D: Distributed Computing Debasis Das
- 43. Automatic Stub Generation, IDL etc.Interface export: server that implements the procedures that can be used by others
- 44. Interface import: calls procedures from the interface
- 45. Define an interface using the IDL, write client program that imports the interface and server program that exports the interface
- 46. IDL compilers generate client stub procedure, server stub procedure, header files. Compile & link the stubs.
- 47. Interface code thus generated could be combined with client/server procedures done in different languages11/21/2009IT703D: Distributed Computing Debasis Das
- 49. Sent by client to server with request to execute a remote procedure
- 50. Reply messages
- 51. Sent by server to the requesting client to indicate completion of a request and related results if generated
- 52. The messages follow RPC protocols and has nothing to do with network transport protocol11/21/2009IT703D: Distributed Computing Debasis Das
- 53. RPC Call MessageBasic fields of the message
- 54. Id information for the remote procedure to be executed
- 55. Required arguments to execute the procedure
- 57. Message id field, essentially a sequence number
- 58. Message type field identifying if a call/reply message
- 59. Client id field, identifying the requesting client and for authentication11/21/2009IT703D: Distributed Computing Debasis Das
- 60. RPC Call Message StructureRemote Procedure idClientidMessageidMessagetypeProgramnumberVersionnumberProcedurenumberArguments11/21/2009IT703D: Distributed Computing Debasis Das16
- 61. RPC Reply MessageCall message not understood, call rejected
- 62. Client id not authorized, failure message
- 63. Procedure id not available on server, failure message
- 64. Parameters not successfully decoded, failure message
- 65. Exception(e.g. divide by zero) happens, failure message
- 66. Procedure executes successfully, return result(s)11/21/2009IT703D: Distributed Computing Debasis Das
- 67. RPC Reply Message StructureMessageidMessagetypeReplyStatussuccessResult(s)MessageidMessagetypeReplyStatusfailureFailurereason11/21/2009IT703D: Distributed Computing Debasis Das18
- 68. Marshaling Arguments & ResultsData structures to be converted into stream form and results decoded back
- 69. This is the marshalling process and involves
- 71. Encoding of data on sender’s machine
- 72. Decoding of message data on receiver’s machine
- 73. Representation method(tagged or untagged) should be known, type safety can be ensured
- 74. Must reflect structure of all types; primitive types, structured types and user defined types11/21/2009IT703D: Distributed Computing Debasis Das19
- 75. Marshalling Procedure TypesProvided as part of the RPC support. Procedures for scalar types and compound ones built from Scalar types are includedDefined by users of RPC systems. Includes marshalling procedures for user defined data types11/21/2009IT703D: Distributed Computing Debasis Das
- 77. Stateful servers
- 83. Persistent servers11/21/2009IT703D: Distributed Computing Debasis Das
- 84. Stateful ServersWhen the server maintains state information from a previous call to the server by the specific client
- 85. For example a Stateful file server will remember that a particular client opened a file(given file id) previously and will let consecutive reads /writes and other operations on that file to be done properly
- 86. Two consecutive reads such as Read(fid,100,buf) will read two consecutive 100 bytes of data from the open file, opened in an earlier procedure call.11/21/2009IT703D: Distributed Computing Debasis Das
- 87. Stateless ServersWhen the server does not maintain any state information
- 88. It is the responsibility of the server to ensure the operations are carried out correctly
- 89. For a similar example; you may have to open the file, seek to the correct location and then read to have a Read correctly.
- 90. Read(filename, position, bytes, buffer) or Write(filename, position, bytes, buffer)11/21/2009IT703D: Distributed Computing Debasis Das
- 91. Why Stateless Servers?Stateful servers allow easier programming and typically they are more efficient, so why bother with a stateless server?
- 92. Stateless servers protect against failures
- 93. Server crashes, state information is lost
- 94. Client may be unaware of crash & restart creating inconsistent results.
- 95. Client crashes and restarts, server has useless state information that cannot be easily rolled back11/21/2009IT703D: Distributed Computing Debasis Das
- 96. Server Creation SemanticsServers are independent processes compared to client servers
- 100. Servers may be created prior to the client processes or on demand11/21/2009IT703D: Distributed Computing Debasis Das
- 101. Instance-per-call ServersServer is created by RPC runtime when a call for it arrives
- 102. Deleted when the call has been serviced
- 103. Not a very common method because
- 104. Will have to be a stateless server and state information to be maintained by the client process or the OS. OS involvement is expensive.11/21/2009IT703D: Distributed Computing Debasis Das
- 105. Instance-per-session ServersServer managers for each type of service
- 106. Server managers are registered with a binding agent
- 107. When a client needs a service, contacts binding agent
- 108. Binding agent sends address of server manager
- 109. Client sends request to server manager, who spawns a server and sends its address
- 110. Client interacts with server until it no longer requires the server
- 111. Server manager destroys the serverWhat should be type of server; stateful or stateless?11/21/2009IT703D: Distributed Computing Debasis Das
- 113. Shared by more than one client
- 114. Created and installed prior to clients
- 115. Servers register with binding agent
- 116. Client request binding agent for a server
- 117. Binding agent selects one randomly or as per some policy
- 118. Client requests are interleaved and several sets of state are maintained
- 119. Multiple servers improves load sharing/failure tolerance11/21/2009IT703D: Distributed Computing Debasis Das
- 120. Parameter Passing SemanticsCall by value
- 121. Send value of arguments along with invocation message
- 122. Can be complicated and wasteful for complex data structures
- 123. Call by reference
- 124. Does not make sense in separate address spaces
- 125. Systems with shared distributed memory would be ok
- 126. Call by object reference
- 127. Call by move
- 128. Call by visit11/21/2009IT703D: Distributed Computing Debasis Das
- 129. Call SemanticsWhy are they needed?
- 130. Call message can get lost
- 131. Reply message can get lost
- 132. Caller node can crash and get restarted
- 133. Callee node can crash and get restarted
- 134. The issue is to use call semantics that can protect against this
- 135. Application procedure is obviously not the place to handle these issues
- 136. Best place would be the RPC runtime system11/21/2009IT703D: Distributed Computing Debasis Das
- 137. Call SemanticsPossibly or May-be call semantics
- 138. Last one call semantics
- 139. Last-of many call semantics
- 141. Exactly-once call semantics11/21/2009IT703D: Distributed Computing Debasis Das
- 142. Possibly or May beCall and then wait for a time-out then continue
- 143. Call ack. or results are not guaranteed
- 144. Weakest semantic, may be ok for situations where no response is really required.
- 145. May be within a LAN which has high probability of transmission success11/21/2009IT703D: Distributed Computing Debasis Das
- 146. Last OneCall, wait for time-out, resend if result not received
- 147. Repeat until one call succeeds
- 148. This can work well only when only two nodes on which the processes work are involved.
- 149. Nested calls to different nodes will create problems
- 150. Orphan processes create problems
- 151. Let the orphans complete or exterminate them11/21/2009IT703D: Distributed Computing Debasis Das
- 152. Last of ManySimilar to Last One semantics
- 153. Ignore orphans
- 154. Attach call ids to calls, response returns the same id
- 155. Calls repeated has new id
- 156. Ignore response if it does not match the latest call id11/21/2009IT703D: Distributed Computing Debasis Das
- 157. At least OnceGuarantees the call is executed at least once but does not specify which results are returned
- 158. Implemented by the time-out based method
- 159. Takes the result of the first response without bothering if the result is from an orphan11/21/2009IT703D: Distributed Computing Debasis Das
- 160. Exactly OnceWith the earlier weak semantics server may get executed more than once
- 161. Programmers will have to ensure indempotency by creating appropriate interfaces
- 162. Whereas if the callee executes exactly once, indempotency can be guaranteed
- 163. Implementation uses timeouts, re-transmissions, call id, same id for repeats and reply cache for callee11/21/2009IT703D: Distributed Computing Debasis Das
- 164. Communication Protocols for RPCsRequest protocol
- 166. Request/reply/Acknowledge-Reply protocol11/21/2009IT703D: Distributed Computing Debasis Das
- 167. Request Protocol( R Protocol)Caller process send a message and continues
- 168. Callee process does not send any reply
- 169. Also called an asynchronous protocol
- 170. Improves client and server performance
- 171. Example, remote X-window system11/21/2009IT703D: Distributed Computing Debasis Das
- 172. R Protocol with Unreliable DeliveryAsynchronous protocol with unreliable delivery would mean loss of request
- 173. RPC runtime does not take responsibility of retransmission
- 174. Some applications may still manage with this simple protocol and unreliable delivery
- 175. Time update for example
- 176. Receivers may request specific update after fixed period if connection lost for a long time11/21/2009IT703D: Distributed Computing Debasis Das
- 177. Request/Reply Protocol(RR Protocol)Can be used for simple RPCs
- 178. A simple protocol is one I which the request, arguments, results can all fit into a single packet
- 179. Duration of call and interval between calls are small, smaller than transmission time of the packet
- 181. A reply is considered as an ack. To the earlier request
- 182. A request is considered as ack. For earlier reply
- 183. Timeout & retires used for failure handling11/21/2009IT703D: Distributed Computing Debasis Das
- 184. RR with Retransmission ImplicationsWith duplicate requests hanging around it is like at least once semantics on client side (duplicate requests are not filtered out)
- 185. Exactly once semantics on server possible with reply cache11/21/2009IT703D: Distributed Computing Debasis Das
- 186. Request/Reply/Acknowledge-Reply Protocol(RRA Protocol)RR protocol, exactly once semantics requires storage of a lot of information in the server cache
- 187. Request, reply followed by a reply ack. Completes the cycle
- 188. The reply ack. Itself may get lost
- 189. Use sequence numbers, the ack. carries the sequence number original request, as does the reply message11/21/2009IT703D: Distributed Computing Debasis Das
- 190. Complicated RPCsRPCs involving long-duration calls or large gaps between calls
- 191. RPCs involving arguments and/or results that cannot be fitted into one datagram11/21/2009IT703D: Distributed Computing Debasis Das
- 192. Long Duration/Large Gap CallsPeriodic probing of the server by the client
- 193. Request message to server, periodic probes with the same request number, server generates ack.
- 194. If original request was not received, server says so and client is intimated of failure
- 195. Periodic generation of acknowledgments by server
- 196. Server generates ack. Prior to timeout. So the client knows the server is working on request.
- 197. If ack. or reply not received within timeout, failure of node or comm. is assumed and user informed.11/21/2009IT703D: Distributed Computing Debasis Das
- 198. Too Large Arguments/ResultsExample file read /write
- 199. Use multiple physical RPC for each logical RPC. Each physical RPC handles data for one datagram
- 200. Inefficient due to fixed overheads with each physical RPC
- 201. Use multi datagram messages, handle missing or out of sequence datagrams as discussed in IPC 11/21/2009IT703D: Distributed Computing Debasis Das
- 202. Client server BindingClient must know address of server before a remote call can be made
- 203. The process of associating a client & a server is binding
- 204. Server “exports” services it is willing to undertake
- 205. Client imports these services via RPC runtime11/21/2009IT703D: Distributed Computing Debasis Das
- 206. Binding IssuesHow does a client specify the server to which it needs to be bound?
- 207. How does the binding process locate the required server?
- 208. When is it proper to bind a client to a server?
- 209. Can the client change the binding during execution?
- 210. Can a client get bound to multiple server with similar service?11/21/2009IT703D: Distributed Computing Debasis Das
- 211. Server NamingInterface name: type, instance
- 212. Type includes a version number
- 213. When client is not bothered, it does not specify an instance
- 214. User decides semantics of interfaces, RPC package has no contribution
- 215. Example, file_server is a type, which may be provided by many instances11/21/2009IT703D: Distributed Computing Debasis Das
- 216. Server LocatingWhen needed a serve has to be located first
- 217. Broadcasting
- 218. Client node broadcasts request to all
- 219. First response received from a server is given the client process
- 220. Binding Agent
- 221. Maintains a mapping table of interface name and location information
- 222. Servers register themselves, may deregister also
- 223. Identification information and a handle
- 224. Binding agent check periodically and deregister non responding servers11/21/2009IT703D: Distributed Computing Debasis Das
- 225. Primitives used: register, deregister and lookupServer registersClient request for serverServer informationClient calls the serverBinding Agent213ServerProcessClientProcess411/21/2009IT703D: Distributed Computing Debasis DasBinding Process
- 226. Binding TimeBinding at compile time
- 227. Server address is compiled into code at compile time
- 228. Inflexible
- 229. Binding at link time
- 230. Server registers with binding agent
- 231. Client requests import of service, binding agent return handle
- 232. Handle retained by client for subsequent calls
- 233. Binding at call time
- 234. By indirect call11/21/2009IT703D: Distributed Computing Debasis Das
- 235. BindingAgentClient passes server interface namename & arguments2. Agent does RPC call to server3.Server returns result4. Agent returns result & handle5.Client makes subsequent calls directly1324ServerProcessClientProcess511/21/2009IT703D: Distributed Computing Debasis DasCall Time Binding(Indirect call)
- 236. Changing BindingsA client or a server may want to change binding
- 237. Client may want to change binding to another server if the earlier call failed
- 238. Server may want to change binding if it has to change to another node or upgrade to another version
- 239. When a server wants to change binding, the current state data may have to be transferred to the alternate server11/21/2009IT703D: Distributed Computing Debasis Das
- 240. Multiple Simultaneous BindingUseful in situations where multiple servers must act on a request
- 241. For example update of multiple copies of a file at different nodes
- 242. It is advantageous then to bind the client to multiple servers
- 243. Bind the client to all the servers that has copies of the file at different nodes11/21/2009IT703D: Distributed Computing Debasis Das
- 244. Exception HandlingIn case of errors they need to be reported to a client
- 245. Define exception conditions and raise exceptions
- 246. Can be handled by programming languages that have exception handling constructs
- 247. Alternatively(like in Unix) return a value -1 to indicate error and a global variable errno that contains a number indicating error type( a legitimate result could be -1)11/21/2009IT703D: Distributed Computing Debasis Das
- 248. SecuritySecurity may be needed
- 249. Considerations are
- 250. Is authentication of server required by the client?
- 251. Is authentication of server required when result is returned?
- 252. Is it ok if results and arguments of RPC are required or they could be shared by other users? (Other than caller & callee)11/21/2009IT703D: Distributed Computing Debasis Das
- 254. Interactive programs may need several client actions before completing the original call
- 255. Broadcast RPC
- 256. Client request broadcast on network, several server may respond to the request
- 257. Batch Mode RPC
- 258. Send a batch of RPC calls. High call rate(50-100 remote calls per second) applications can use this11/21/2009IT703D: Distributed Computing Debasis Das
- 259. To make Call back workFor call back facility to work
- 260. Provide server with client’s handle
- 261. Making client process wait for callback RPC
- 262. Handling callback deadlock11/21/2009IT703D: Distributed Computing Debasis Das
- 263. Provide Server with Client’s HandleClient process uses a transient program number for the callback service and exports service by registering with the binding agent
- 264. Program number sent to server as part of RPC request
- 265. Server then can initiate a RPC to client
- 266. A handle also may be sent so that further calls can be made directly11/21/2009IT703D: Distributed Computing Debasis Das
- 267. Making Client Process wait for Callback RPCClient has to wait for callbacks specifically so that callbacks are not treated as a reply of an earlier call
- 268. To do that the client usually calls a svc-routine. The svc-routine waits for a callback and intimates client when a callback is received11/21/2009IT703D: Distributed Computing Debasis Das
- 269. Waiting for replyFrom P2Process P1Process P2Process P3Waiting for Reply from P3Waiting for replyFrom P111/21/2009IT703D: Distributed Computing Debasis DasHandling Callback Deadlocks
- 270. Broadcast RPC1.Use a broadcast primitive to indicate it is a broadcast call to binding agent
- 271. Agent sends it to servers registered for that service
- 272. The broadcast call will find only the ones registered with the binding agent
- 273. 2. Get a binding for broadcast port
- 274. Broadcast a RPC
- 275. o/one or m out of n may be adopted
- 276. Servers with successful results respond, ones with error may remain silent11/21/2009IT703D: Distributed Computing Debasis Das
- 277. Batch Mode RPCSend a batch of requests in one RPC call
- 278. Reduces overheads in sending individual calls
- 279. Clients with high call rates can use it, needs reliable transport
- 280. Entire queue requests are sent to server when
- 281. A predetermined interval elapses
- 282. Predetermined requests have been queued
- 283. Amount of batched data exceeds buffer size
- 284. A call is made which needs a reply, one must be able to distinguish between the batch calls and non-queueing RPC request11/21/2009IT703D: Distributed Computing Debasis Das
- 285. RPCs in Heterogeneous EnvironmentData representation
- 286. Participation machines may have different data representation
- 287. Transport protocol
- 288. RPC mechanism should be transparent of network protocol
- 289. Control protocol
- 290. Should be transparent of network control protocols
- 291. Delay the decision. Binding agent sends the necessary data conversion and protocol routines to the client stub at binding time11/21/2009IT703D: Distributed Computing Debasis Das
- 292. Lightweight RPCsWere developed for micro kernel OS architectures
- 293. Needs communications of two types
- 294. Cross domain
- 295. Cross machine
- 296. LPRC is about cross domain communication, techniques used
- 298. Simple data transfer
- 299. Simple stubs
- 300. Design for concurrency11/21/2009IT703D: Distributed Computing Debasis Das
- 301. Simple Control TransferSpecial threads scheduling: hands off scheduling
- 302. When calling, client supplies an argument stack and the thread
- 303. Trap to kernel
- 304. Kernel validates caller, creates call linkage
- 305. Server starts executing the thread
- 306. When complete send the results and control back11/21/2009IT703D: Distributed Computing Debasis Das
- 307. Simple Data TransferUse a shared argument stack
- 308. One copy: copy from client stack to the shared argument stack
- 309. In contrast regular RPC has to do 4 copies
- 310. Client stack to RPC message buffer
- 311. Message in client domain to kernel domain
- 312. Kernel domain to server domain
- 313. Server domain buffer to server stack11/21/2009IT703D: Distributed Computing Debasis Das
- 314. Simple StubsEnd to end, as per programming languages & architecture
- 315. Stub to stub implemented by the stubs themselves
- 316. Domain to domain implemented by the kernel11/21/2009IT703D: Distributed Computing Debasis Das
- 317. Design for ConcurrencyWhen a node has multiple processors
- 318. Shared data structures minimized to reduce lock contention on domain transfer path
- 319. Reduce context switching latency by caching domains on idle processors
- 320. LRPC increases throughput by a factor of three!11/21/2009IT703D: Distributed Computing Debasis Das
- 321. Optimizations for PerformanceConcurrent access to multiple servers
- 322. Serving multiple requests simultaneously
- 323. Reducing per-call workload of servers
- 324. Reply caching of indempotent remote procedures
- 325. Proper selection of time out values
- 326. Proper design of RPC protocol specification11/21/2009IT703D: Distributed Computing Debasis Das
- 327. Concurrent access to multiple serversUse of threads, each thread can call a separate server
- 328. Addressing in the underlying protocol needs to be rich enough to provide correct routing of results
- 329. Early reply method
- 330. Split call, client sends parameters, server sends a tag
- 331. Client call again with tag when convenient to get result
- 332. Problem is server will have hold on to the result until required
- 333. Call buffering (via a call buffer server)
- 334. Sends call with parameters to call buffer server
- 335. Gets the result when it is ready
- 336. A variation of that method
- 337. Use a variable promise(can be blocked or ready) operation ready and claim on that11/21/2009IT703D: Distributed Computing Debasis Das
- 338. Serving multiple requests SimultaneouslyCommon types of delay
- 339. Server may have to wait for a shared resource
- 340. Server calls a remote process that takes time or involves transmission delays
- 341. While waiting, server should be able to service other calls
- 342. Implement threads11/21/2009IT703D: Distributed Computing Debasis Das
- 343. Reducing per call Workload of ServersServer performance gets affected when there are too many calls and/or too much to be done per call
- 344. One way to reduce the load is to use stateless servers. Clients can keep track of the state. It is responsible for the processing anyway11/21/2009IT703D: Distributed Computing Debasis Das
- 345. Reply caching of indempotent Remote ProceduresAs requests build up at a server, some calls will fail, prompting the client to send retransmissions making the problem worse.
- 346. A cache helps11/21/2009IT703D: Distributed Computing Debasis Das
- 347. Proper Selection of Timeout ValuesToo small, too many retransmissions
- 348. Too large, reduction in throughput
- 349. Using retransmission time back off method is one solution11/21/2009IT703D: Distributed Computing Debasis Das
- 350. Proper Design of RPC Design SpecificationsMinimize data to be sent
- 353. One could use an existing general purpose protocol; in fact many RPC systems use TCP/IP and UDP/IP
- 354. General purpose protocols may be wasteful
- 355. For example RPC does not need the checksum field. It has to filled and takes computation time11/21/2009IT703D: Distributed Computing Debasis Das