Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
CS 704DAdvanced Operating System(RPC)<br />Debasis Das<br />
Remote ProcedureCalls(RPC)<br />2<br />
Remote Procedure Calls<br /><ul><li>A special case for building distributed applications
RPC became popular IPC mechanisms for distributed applications
Simple call syntax
Familiar semantics, similar to local procedure calls
Well defined interface, compile time type checking, auto interface generation
Ease of use, clean & Simple
Generality & efficiency
Same IPC mechanism can be used for procedure on different machines as well as on the same machine</li></ul>11/21/2009<br /...
The RPC Model<br /><ul><li>Based on procedure call model
Make a procedure call, place parameters in a known location
Transfer control to the procedure
Procedure executes with copies of the parameters/arguments
Control is returned to calling procedure with result, if any</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasi...
RPC Model(Graphically)<br />Caller<br />Client Process<br />Request message & parameters<br />Send reply with result, if a...
RPC Characteristics<br /><ul><li>Server process is normally dormant. Works when called
If concurrency required, calling processes can leave messages asynchronously, server process keeps serving requests
Server process can have threads. Starts a thread on request, server is free to field further calls if they come along</li>...
Transparency of RPC<br /><ul><li>For a programmer it should be transparent whether he is calling a local or a remote proce...
Syntactic transparency
Semantic transparency
Syntactic transparency is easy to achieve but not semantic transparency</li></ul>11/21/2009<br />IT703D: Distributed Compu...
Semantic Transparency<br /><ul><li>Nearly impossible to achieve, because
No shared memory: passing addresses as arguments is meaningless, call by reference pointers are useless, structures refere...
More vulnerable to failures: two different processes, two different machines, intervening network. Processor and communica...
RPCs can take much more time(x100 to x1000) due to communication congestions. Long delays need to be handled.</li></ul>11/...
Implementing RPC Mechanism<br />Server<br />Client<br />Return<br />Call<br />Call<br />Return<br />Execute<br />Stubs<br ...
Stubs<br /><ul><li>Client stub
On call request, packs specs of remote procedure and arguments
Asks RPC Runtime to transmit the message to the server
Server stub
After receipt, the RPC Runtime passes the message to it. It then unpacks the message and makes a usual call to the procedure.
On receipt of result, packs the result and asks the runtime to send it back to the client.</li></ul>11/21/2009<br />IT703D...
Stub & Transparency<br /><ul><li>Except for the stubs everything operates the same transparent way for local or remote pro...
No need to dabble in send & receive primitives</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />11<...
Stub Generation<br /><ul><li>Manually
Write code to implement translation functions provided by the RPC implementer
Automatically
By using IDL. Procedures supported by the interface, types of arguments and results
IDL compiler will ensure compilation, type checking etc.
Optimizes data to be sent over the network. Interface definition usually will have information as to which arguments are i...
Automatic Stub Generation, IDL etc.<br /><ul><li>Interface export: server that implements the procedures that can be used ...
Interface import: calls procedures from the interface
Define an interface using the IDL, write client program that imports the interface and server program that exports the int...
IDL compilers generate client stub procedure, server stub procedure, header files. Compile & link the stubs.
Interface code thus generated could be combined with client/server procedures done in different languages</li></ul>11/21/2...
RPC Messages<br /><ul><li>Call messages
Sent by client to server with request to execute a remote procedure
Reply messages
Sent by server to the requesting client to indicate completion of a request and related results if generated
The messages follow RPC protocols and has nothing to do with network transport protocol</li></ul>11/21/2009<br />IT703D: D...
RPC Call Message<br /><ul><li>Basic fields of the message
Id information for the remote procedure to be executed
Required arguments to execute the procedure
Additional fields
Message id field, essentially a sequence number
Message type field identifying if a call/reply message
Client id field, identifying the requesting client and for authentication</li></ul>11/21/2009<br />IT703D: Distributed Com...
RPC Call Message Structure<br />Remote Procedure id<br />Client<br />id<br />Message<br />id<br />Message<br />type<br />P...
RPC Reply Message<br /><ul><li>Call message not understood, call rejected
Client id not authorized, failure message
Procedure id not available on server, failure message
Parameters not successfully decoded, failure message
Exception(e.g. divide by zero) happens, failure message
Procedure executes successfully, return result(s)</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
RPC Reply Message Structure<br />Message<br />id<br />Message<br />type<br />Reply<br />Status<br />success<br />Result(s)...
Marshaling Arguments & Results<br /><ul><li>Data structures to be converted into stream form and results decoded back
This is the marshalling process and involves
Take the arguments/result
Encoding of data on sender’s machine
Decoding of message data on receiver’s machine
Representation method(tagged or untagged) should be known, type safety can be ensured
Must reflect structure of all types; primitive types, structured types and user defined types</li></ul>11/21/2009<br />IT7...
Marshalling Procedure Types<br />Provided as part of the RPC support. Procedures for scalar types and compound ones built ...
Server Management<br /><ul><li>Server Implementation
Upcoming SlideShare
Loading in …5
×

Cs 704 d rpc

1,307 views

Published on

Remote procedure calls, issues, implementation

Cs 704 d rpc

  1. 1. CS 704DAdvanced Operating System(RPC)<br />Debasis Das<br />
  2. 2. Remote ProcedureCalls(RPC)<br />2<br />
  3. 3. Remote Procedure Calls<br /><ul><li>A special case for building distributed applications
  4. 4. RPC became popular IPC mechanisms for distributed applications
  5. 5. Simple call syntax
  6. 6. Familiar semantics, similar to local procedure calls
  7. 7. Well defined interface, compile time type checking, auto interface generation
  8. 8. Ease of use, clean & Simple
  9. 9. Generality & efficiency
  10. 10. Same IPC mechanism can be used for procedure on different machines as well as on the same machine</li></ul>11/21/2009<br />IT703D: Dirstibuted Computing Debasis Das<br />3<br />
  11. 11. The RPC Model<br /><ul><li>Based on procedure call model
  12. 12. Make a procedure call, place parameters in a known location
  13. 13. Transfer control to the procedure
  14. 14. Procedure executes with copies of the parameters/arguments
  15. 15. Control is returned to calling procedure with result, if any</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />4<br />
  16. 16. RPC Model(Graphically)<br />Caller<br />Client Process<br />Request message & parameters<br />Send reply with result, if any<br />Server Process<br />11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />5<br />
  17. 17. RPC Characteristics<br /><ul><li>Server process is normally dormant. Works when called
  18. 18. If concurrency required, calling processes can leave messages asynchronously, server process keeps serving requests
  19. 19. Server process can have threads. Starts a thread on request, server is free to field further calls if they come along</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />6<br />
  20. 20. Transparency of RPC<br /><ul><li>For a programmer it should be transparent whether he is calling a local or a remote procedure. Requires
  21. 21. Syntactic transparency
  22. 22. Semantic transparency
  23. 23. Syntactic transparency is easy to achieve but not semantic transparency</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />7<br />
  24. 24. Semantic Transparency<br /><ul><li>Nearly impossible to achieve, because
  25. 25. No shared memory: passing addresses as arguments is meaningless, call by reference pointers are useless, structures referenced by pointers are difficult.
  26. 26. More vulnerable to failures: two different processes, two different machines, intervening network. Processor and communication failures need to be taken care of.
  27. 27. RPCs can take much more time(x100 to x1000) due to communication congestions. Long delays need to be handled.</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />8<br />
  28. 28. Implementing RPC Mechanism<br />Server<br />Client<br />Return<br />Call<br />Call<br />Return<br />Execute<br />Stubs<br />Unpack<br />Pack<br />Pack<br />Unpack<br />RPC Runtimes<br />Receive<br />Send<br />Receive<br />Send<br />Wait<br />11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />9<br />
  29. 29. Stubs<br /><ul><li>Client stub
  30. 30. On call request, packs specs of remote procedure and arguments
  31. 31. Asks RPC Runtime to transmit the message to the server
  32. 32. Server stub
  33. 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. 34. On receipt of result, packs the result and asks the runtime to send it back to the client.</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />10<br />
  35. 35. Stub & Transparency<br /><ul><li>Except for the stubs everything operates the same transparent way for local or remote procedure call.
  36. 36. No need to dabble in send & receive primitives</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />11<br />
  37. 37. Stub Generation<br /><ul><li>Manually
  38. 38. Write code to implement translation functions provided by the RPC implementer
  39. 39. Automatically
  40. 40. By using IDL. Procedures supported by the interface, types of arguments and results
  41. 41. IDL compiler will ensure compilation, type checking etc.
  42. 42. Optimizes data to be sent over the network. Interface definition usually will have information as to which arguments are input/output/both.</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  43. 43. Automatic Stub Generation, IDL etc.<br /><ul><li>Interface export: server that implements the procedures that can be used by others
  44. 44. Interface import: calls procedures from the interface
  45. 45. Define an interface using the IDL, write client program that imports the interface and server program that exports the interface
  46. 46. IDL compilers generate client stub procedure, server stub procedure, header files. Compile & link the stubs.
  47. 47. Interface code thus generated could be combined with client/server procedures done in different languages</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  48. 48. RPC Messages<br /><ul><li>Call messages
  49. 49. Sent by client to server with request to execute a remote procedure
  50. 50. Reply messages
  51. 51. Sent by server to the requesting client to indicate completion of a request and related results if generated
  52. 52. The messages follow RPC protocols and has nothing to do with network transport protocol</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  53. 53. RPC Call Message<br /><ul><li>Basic fields of the message
  54. 54. Id information for the remote procedure to be executed
  55. 55. Required arguments to execute the procedure
  56. 56. Additional fields
  57. 57. Message id field, essentially a sequence number
  58. 58. Message type field identifying if a call/reply message
  59. 59. Client id field, identifying the requesting client and for authentication</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  60. 60. RPC Call Message Structure<br />Remote Procedure id<br />Client<br />id<br />Message<br />id<br />Message<br />type<br />Program<br />number<br />Version<br />number<br />Procedure<br />number<br />Arguments<br />11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />16<br />
  61. 61. RPC Reply Message<br /><ul><li>Call message not understood, call rejected
  62. 62. Client id not authorized, failure message
  63. 63. Procedure id not available on server, failure message
  64. 64. Parameters not successfully decoded, failure message
  65. 65. Exception(e.g. divide by zero) happens, failure message
  66. 66. Procedure executes successfully, return result(s)</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  67. 67. RPC Reply Message Structure<br />Message<br />id<br />Message<br />type<br />Reply<br />Status<br />success<br />Result(s)<br />Message<br />id<br />Message<br />type<br />Reply<br />Status<br />failure<br />Failure<br />reason<br />11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />18<br />
  68. 68. Marshaling Arguments & Results<br /><ul><li>Data structures to be converted into stream form and results decoded back
  69. 69. This is the marshalling process and involves
  70. 70. Take the arguments/result
  71. 71. Encoding of data on sender’s machine
  72. 72. Decoding of message data on receiver’s machine
  73. 73. Representation method(tagged or untagged) should be known, type safety can be ensured
  74. 74. Must reflect structure of all types; primitive types, structured types and user defined types</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />19<br />
  75. 75. Marshalling Procedure Types<br />Provided as part of the RPC support. Procedures for scalar types and compound ones built from Scalar types are included<br />Defined by users of RPC systems. Includes marshalling procedures for user defined data types<br />11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  76. 76. Server Management<br /><ul><li>Server Implementation
  77. 77. Stateful servers
  78. 78. Stateless servers
  79. 79. Why stateless servers
  80. 80. Server creation semantics
  81. 81. Instance-per-call servers
  82. 82. Instance-per-session servers
  83. 83. Persistent servers</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  84. 84. Stateful Servers<br /><ul><li>When the server maintains state information from a previous call to the server by the specific client
  85. 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. 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.</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  87. 87. Stateless Servers<br /><ul><li>When the server does not maintain any state information
  88. 88. It is the responsibility of the server to ensure the operations are carried out correctly
  89. 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. 90. Read(filename, position, bytes, buffer) or Write(filename, position, bytes, buffer)</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  91. 91. Why Stateless Servers?<br /><ul><li>Stateful servers allow easier programming and typically they are more efficient, so why bother with a stateless server?
  92. 92. Stateless servers protect against failures
  93. 93. Server crashes, state information is lost
  94. 94. Client may be unaware of crash & restart creating inconsistent results.
  95. 95. Client crashes and restarts, server has useless state information that cannot be easily rolled back</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  96. 96. Server Creation Semantics<br /><ul><li>Servers are independent processes compared to client servers
  97. 97. Independent lifetimes
  98. 98. Independent locations
  99. 99. Independent address spaces
  100. 100. Servers may be created prior to the client processes or on demand</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  101. 101. Instance-per-call Servers<br /><ul><li>Server is created by RPC runtime when a call for it arrives
  102. 102. Deleted when the call has been serviced
  103. 103. Not a very common method because
  104. 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.</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  105. 105. Instance-per-session Servers<br /><ul><li>Server managers for each type of service
  106. 106. Server managers are registered with a binding agent
  107. 107. When a client needs a service, contacts binding agent
  108. 108. Binding agent sends address of server manager
  109. 109. Client sends request to server manager, who spawns a server and sends its address
  110. 110. Client interacts with server until it no longer requires the server
  111. 111. Server manager destroys the server</li></ul>What should be type of server; stateful or stateless?<br />11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  112. 112. Persistent Servers<br /><ul><li>Indefinite lifetime
  113. 113. Shared by more than one client
  114. 114. Created and installed prior to clients
  115. 115. Servers register with binding agent
  116. 116. Client request binding agent for a server
  117. 117. Binding agent selects one randomly or as per some policy
  118. 118. Client requests are interleaved and several sets of state are maintained
  119. 119. Multiple servers improves load sharing/failure tolerance</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  120. 120. Parameter Passing Semantics<br /><ul><li>Call by value
  121. 121. Send value of arguments along with invocation message
  122. 122. Can be complicated and wasteful for complex data structures
  123. 123. Call by reference
  124. 124. Does not make sense in separate address spaces
  125. 125. Systems with shared distributed memory would be ok
  126. 126. Call by object reference
  127. 127. Call by move
  128. 128. Call by visit</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  129. 129. Call Semantics<br /><ul><li>Why are they needed?
  130. 130. Call message can get lost
  131. 131. Reply message can get lost
  132. 132. Caller node can crash and get restarted
  133. 133. Callee node can crash and get restarted
  134. 134. The issue is to use call semantics that can protect against this
  135. 135. Application procedure is obviously not the place to handle these issues
  136. 136. Best place would be the RPC runtime system</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  137. 137. Call Semantics<br /><ul><li>Possibly or May-be call semantics
  138. 138. Last one call semantics
  139. 139. Last-of many call semantics
  140. 140. At-least-once call semantics
  141. 141. Exactly-once call semantics</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  142. 142. Possibly or May be<br /><ul><li>Call and then wait for a time-out then continue
  143. 143. Call ack. or results are not guaranteed
  144. 144. Weakest semantic, may be ok for situations where no response is really required.
  145. 145. May be within a LAN which has high probability of transmission success</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  146. 146. Last One<br /><ul><li>Call, wait for time-out, resend if result not received
  147. 147. Repeat until one call succeeds
  148. 148. This can work well only when only two nodes on which the processes work are involved.
  149. 149. Nested calls to different nodes will create problems
  150. 150. Orphan processes create problems
  151. 151. Let the orphans complete or exterminate them</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  152. 152. Last of Many<br /><ul><li>Similar to Last One semantics
  153. 153. Ignore orphans
  154. 154. Attach call ids to calls, response returns the same id
  155. 155. Calls repeated has new id
  156. 156. Ignore response if it does not match the latest call id</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  157. 157. At least Once<br /><ul><li>Guarantees the call is executed at least once but does not specify which results are returned
  158. 158. Implemented by the time-out based method
  159. 159. Takes the result of the first response without bothering if the result is from an orphan</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  160. 160. Exactly Once<br /><ul><li>With the earlier weak semantics server may get executed more than once
  161. 161. Programmers will have to ensure indempotency by creating appropriate interfaces
  162. 162. Whereas if the callee executes exactly once, indempotency can be guaranteed
  163. 163. Implementation uses timeouts, re-transmissions, call id, same id for repeats and reply cache for callee</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  164. 164. Communication Protocols for RPCs<br /><ul><li>Request protocol
  165. 165. Request/Reply protocol
  166. 166. Request/reply/Acknowledge-Reply protocol</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  167. 167. Request Protocol( R Protocol)<br /><ul><li>Caller process send a message and continues
  168. 168. Callee process does not send any reply
  169. 169. Also called an asynchronous protocol
  170. 170. Improves client and server performance
  171. 171. Example, remote X-window system</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  172. 172. R Protocol with Unreliable Delivery<br /><ul><li>Asynchronous protocol with unreliable delivery would mean loss of request
  173. 173. RPC runtime does not take responsibility of retransmission
  174. 174. Some applications may still manage with this simple protocol and unreliable delivery
  175. 175. Time update for example
  176. 176. Receivers may request specific update after fixed period if connection lost for a long time</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  177. 177. Request/Reply Protocol(RR Protocol)<br /><ul><li>Can be used for simple RPCs
  178. 178. A simple protocol is one I which the request, arguments, results can all fit into a single packet
  179. 179. Duration of call and interval between calls are small, smaller than transmission time of the packet
  180. 180. Implicit acknowledgements used
  181. 181. A reply is considered as an ack. To the earlier request
  182. 182. A request is considered as ack. For earlier reply
  183. 183. Timeout & retires used for failure handling</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  184. 184. RR with Retransmission Implications<br /><ul><li>With duplicate requests hanging around it is like at least once semantics on client side (duplicate requests are not filtered out)
  185. 185. Exactly once semantics on server possible with reply cache</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  186. 186. Request/Reply/Acknowledge-Reply Protocol(RRA Protocol)<br /><ul><li>RR protocol, exactly once semantics requires storage of a lot of information in the server cache
  187. 187. Request, reply followed by a reply ack. Completes the cycle
  188. 188. The reply ack. Itself may get lost
  189. 189. Use sequence numbers, the ack. carries the sequence number original request, as does the reply message</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  190. 190. Complicated RPCs<br /><ul><li>RPCs involving long-duration calls or large gaps between calls
  191. 191. RPCs involving arguments and/or results that cannot be fitted into one datagram</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  192. 192. Long Duration/Large Gap Calls<br /><ul><li>Periodic probing of the server by the client
  193. 193. Request message to server, periodic probes with the same request number, server generates ack.
  194. 194. If original request was not received, server says so and client is intimated of failure
  195. 195. Periodic generation of acknowledgments by server
  196. 196. Server generates ack. Prior to timeout. So the client knows the server is working on request.
  197. 197. If ack. or reply not received within timeout, failure of node or comm. is assumed and user informed.</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  198. 198. Too Large Arguments/Results<br /><ul><li>Example file read /write
  199. 199. Use multiple physical RPC for each logical RPC. Each physical RPC handles data for one datagram
  200. 200. Inefficient due to fixed overheads with each physical RPC
  201. 201. Use multi datagram messages, handle missing or out of sequence datagrams as discussed in IPC </li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  202. 202. Client server Binding<br /><ul><li>Client must know address of server before a remote call can be made
  203. 203. The process of associating a client & a server is binding
  204. 204. Server “exports” services it is willing to undertake
  205. 205. Client imports these services via RPC runtime</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  206. 206. Binding Issues<br /><ul><li>How does a client specify the server to which it needs to be bound?
  207. 207. How does the binding process locate the required server?
  208. 208. When is it proper to bind a client to a server?
  209. 209. Can the client change the binding during execution?
  210. 210. Can a client get bound to multiple server with similar service?</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  211. 211. Server Naming<br /><ul><li>Interface name: type, instance
  212. 212. Type includes a version number
  213. 213. When client is not bothered, it does not specify an instance
  214. 214. User decides semantics of interfaces, RPC package has no contribution
  215. 215. Example, file_server is a type, which may be provided by many instances</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  216. 216. Server Locating<br /><ul><li>When needed a serve has to be located first
  217. 217. Broadcasting
  218. 218. Client node broadcasts request to all
  219. 219. First response received from a server is given the client process
  220. 220. Binding Agent
  221. 221. Maintains a mapping table of interface name and location information
  222. 222. Servers register themselves, may deregister also
  223. 223. Identification information and a handle
  224. 224. Binding agent check periodically and deregister non responding servers</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  225. 225. Primitives used: register, deregister and lookup<br />Server registers<br />Client request for server<br />Server information<br />Client calls the server<br />Binding Agent<br />2<br />1<br />3<br />Server<br />Process<br />Client<br />Process<br />4<br />11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />Binding Process<br />
  226. 226. Binding Time<br /><ul><li>Binding at compile time
  227. 227. Server address is compiled into code at compile time
  228. 228. Inflexible
  229. 229. Binding at link time
  230. 230. Server registers with binding agent
  231. 231. Client requests import of service, binding agent return handle
  232. 232. Handle retained by client for subsequent calls
  233. 233. Binding at call time
  234. 234. By indirect call</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  235. 235. Binding<br />Agent<br />Client passes server interface name<br />name & arguments<br />2. Agent does RPC call to server<br />3.Server returns result<br />4. Agent returns result & handle<br />5.Client makes subsequent calls directly<br />1<br />3<br />2<br />4<br />Server<br />Process<br />Client<br />Process<br />5<br />11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />Call Time Binding(Indirect call)<br />
  236. 236. Changing Bindings<br /><ul><li>A client or a server may want to change binding
  237. 237. Client may want to change binding to another server if the earlier call failed
  238. 238. Server may want to change binding if it has to change to another node or upgrade to another version
  239. 239. When a server wants to change binding, the current state data may have to be transferred to the alternate server</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  240. 240. Multiple Simultaneous Binding<br /><ul><li>Useful in situations where multiple servers must act on a request
  241. 241. For example update of multiple copies of a file at different nodes
  242. 242. It is advantageous then to bind the client to multiple servers
  243. 243. Bind the client to all the servers that has copies of the file at different nodes</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  244. 244. Exception Handling<br /><ul><li>In case of errors they need to be reported to a client
  245. 245. Define exception conditions and raise exceptions
  246. 246. Can be handled by programming languages that have exception handling constructs
  247. 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)</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  248. 248. Security<br /><ul><li>Security may be needed
  249. 249. Considerations are
  250. 250. Is authentication of server required by the client?
  251. 251. Is authentication of server required when result is returned?
  252. 252. Is it ok if results and arguments of RPC are required or they could be shared by other users? (Other than caller & callee)</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  253. 253. Special RPCs<br /><ul><li>Callback RPC
  254. 254. Interactive programs may need several client actions before completing the original call
  255. 255. Broadcast RPC
  256. 256. Client request broadcast on network, several server may respond to the request
  257. 257. Batch Mode RPC
  258. 258. Send a batch of RPC calls. High call rate(50-100 remote calls per second) applications can use this</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  259. 259. To make Call back work<br /><ul><li>For call back facility to work
  260. 260. Provide server with client’s handle
  261. 261. Making client process wait for callback RPC
  262. 262. Handling callback deadlock</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  263. 263. Provide Server with Client’s Handle<br /><ul><li>Client process uses a transient program number for the callback service and exports service by registering with the binding agent
  264. 264. Program number sent to server as part of RPC request
  265. 265. Server then can initiate a RPC to client
  266. 266. A handle also may be sent so that further calls can be made directly</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  267. 267. Making Client Process wait for Callback RPC<br /><ul><li>Client has to wait for callbacks specifically so that callbacks are not treated as a reply of an earlier call
  268. 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 received</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  269. 269. Waiting for reply<br />From P2<br />Process P1<br />Process P2<br />Process P3<br />Waiting for <br />Reply from P3<br />Waiting for reply<br />From P1<br />11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />Handling Callback Deadlocks<br />
  270. 270. Broadcast RPC<br /><ul><li>1.Use a broadcast primitive to indicate it is a broadcast call to binding agent
  271. 271. Agent sends it to servers registered for that service
  272. 272. The broadcast call will find only the ones registered with the binding agent
  273. 273. 2. Get a binding for broadcast port
  274. 274. Broadcast a RPC
  275. 275. o/one or m out of n may be adopted
  276. 276. Servers with successful results respond, ones with error may remain silent</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  277. 277. Batch Mode RPC<br /><ul><li>Send a batch of requests in one RPC call
  278. 278. Reduces overheads in sending individual calls
  279. 279. Clients with high call rates can use it, needs reliable transport
  280. 280. Entire queue requests are sent to server when
  281. 281. A predetermined interval elapses
  282. 282. Predetermined requests have been queued
  283. 283. Amount of batched data exceeds buffer size
  284. 284. A call is made which needs a reply, one must be able to distinguish between the batch calls and non-queueing RPC request</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  285. 285. RPCs in Heterogeneous Environment<br /><ul><li>Data representation
  286. 286. Participation machines may have different data representation
  287. 287. Transport protocol
  288. 288. RPC mechanism should be transparent of network protocol
  289. 289. Control protocol
  290. 290. Should be transparent of network control protocols
  291. 291. Delay the decision. Binding agent sends the necessary data conversion and protocol routines to the client stub at binding time</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  292. 292. Lightweight RPCs<br /><ul><li>Were developed for micro kernel OS architectures
  293. 293. Needs communications of two types
  294. 294. Cross domain
  295. 295. Cross machine
  296. 296. LPRC is about cross domain communication, techniques used
  297. 297. Simple control transfer
  298. 298. Simple data transfer
  299. 299. Simple stubs
  300. 300. Design for concurrency</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  301. 301. Simple Control Transfer<br /><ul><li>Special threads scheduling: hands off scheduling
  302. 302. When calling, client supplies an argument stack and the thread
  303. 303. Trap to kernel
  304. 304. Kernel validates caller, creates call linkage
  305. 305. Server starts executing the thread
  306. 306. When complete send the results and control back</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  307. 307. Simple Data Transfer<br /><ul><li>Use a shared argument stack
  308. 308. One copy: copy from client stack to the shared argument stack
  309. 309. In contrast regular RPC has to do 4 copies
  310. 310. Client stack to RPC message buffer
  311. 311. Message in client domain to kernel domain
  312. 312. Kernel domain to server domain
  313. 313. Server domain buffer to server stack</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  314. 314. Simple Stubs<br /><ul><li>End to end, as per programming languages & architecture
  315. 315. Stub to stub implemented by the stubs themselves
  316. 316. Domain to domain implemented by the kernel</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  317. 317. Design for Concurrency<br /><ul><li>When a node has multiple processors
  318. 318. Shared data structures minimized to reduce lock contention on domain transfer path
  319. 319. Reduce context switching latency by caching domains on idle processors
  320. 320. LRPC increases throughput by a factor of three!</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  321. 321. Optimizations for Performance<br /><ul><li>Concurrent access to multiple servers
  322. 322. Serving multiple requests simultaneously
  323. 323. Reducing per-call workload of servers
  324. 324. Reply caching of indempotent remote procedures
  325. 325. Proper selection of time out values
  326. 326. Proper design of RPC protocol specification</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  327. 327. Concurrent access to multiple servers<br /><ul><li>Use of threads, each thread can call a separate server
  328. 328. Addressing in the underlying protocol needs to be rich enough to provide correct routing of results
  329. 329. Early reply method
  330. 330. Split call, client sends parameters, server sends a tag
  331. 331. Client call again with tag when convenient to get result
  332. 332. Problem is server will have hold on to the result until required
  333. 333. Call buffering (via a call buffer server)
  334. 334. Sends call with parameters to call buffer server
  335. 335. Gets the result when it is ready
  336. 336. A variation of that method
  337. 337. Use a variable promise(can be blocked or ready) operation ready and claim on that</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  338. 338. Serving multiple requests Simultaneously<br /><ul><li>Common types of delay
  339. 339. Server may have to wait for a shared resource
  340. 340. Server calls a remote process that takes time or involves transmission delays
  341. 341. While waiting, server should be able to service other calls
  342. 342. Implement threads</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  343. 343. Reducing per call Workload of Servers<br /><ul><li>Server performance gets affected when there are too many calls and/or too much to be done per call
  344. 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 anyway</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  345. 345. Reply caching of indempotent Remote Procedures<br /><ul><li>As requests build up at a server, some calls will fail, prompting the client to send retransmissions making the problem worse.
  346. 346. A cache helps</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  347. 347. Proper Selection of Timeout Values<br /><ul><li>Too small, too many retransmissions
  348. 348. Too large, reduction in throughput
  349. 349. Using retransmission time back off method is one solution</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />
  350. 350. Proper Design of RPC Design Specifications<br /><ul><li>Minimize data to be sent
  351. 351. Reduces encoding/decoding time
  352. 352. Reduces transfer time
  353. 353. One could use an existing general purpose protocol; in fact many RPC systems use TCP/IP and UDP/IP
  354. 354. General purpose protocols may be wasteful
  355. 355. For example RPC does not need the checksum field. It has to filled and takes computation time</li></ul>11/21/2009<br />IT703D: Distributed Computing Debasis Das<br />

×