1 / 45

Remote Procedure Calls (RPC)

Remote Procedure Calls (RPC). - Swati Agarwal. RPC – an overview. Request / reply mechanism Procedure call – disjoint address space. client. server. request. computation. reply. Why RPC?. Function Oriented Protocols Telnet, FTP

missy
Download Presentation

Remote Procedure Calls (RPC)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Remote Procedure Calls (RPC) - Swati Agarwal

  2. RPC – an overview • Request / reply mechanism • Procedure call – disjoint address space client server request computation reply

  3. Why RPC? • Function Oriented Protocols • Telnet, FTP • cannot perform “execute function Y with arguments X1, X2 on machine Z” • Construct desired program interface • Build run time environment – format outgoing commands, interface with the IPC facility, parse incoming response

  4. Why RPC ? (cont.) • Why not give transparency to programmers? • Make programmers life easy !! • Distributed applications can be made easier • Solution – Formalize a separate protocol • Idea proposed by J. E. White in 1976

  5. Implementing Remote Procedure Calls- Andrew Birrell, B. J. Nelson • Design issues reflected + how these can be addressed • Goals • Show that RPC can make distributed computation easy • Efficient RPC communication • Provide secure communication with RPC

  6. Issues faced by designers • Binding • Communication protocol • Dealing with failures – network / server crash • Addressable arguments • Integration with existing systems • Data Integrity and security

  7. How it works?

  8. Issue : Binding • Naming - How to specify what to bind to? • Location - How to find the callee’s address, how to specify to the callee the procedure to be invoked? • Possible solutions : - Specify network addresses in applications - Some form of broadcast protocol - Some naming system

  9. Issue : Binding - Solution • Grapevine • Distributed and reliable database • For naming people, machines and services • Used for naming services exported by the server • Solves Naming problem • Primarily used for delivery of messages (mails) • Locating callee similar to locating mailboxes • Addresses Location problem • For authentication

  10. Binding cont..

  11. Binding cont.. • Exporting machine - stateless • Importing – no effect • Bindings broken if exporter crashes • Grapevine allows several binding choices : • Specify network address as instance • Can specify both type and instance of interface • Only type of interface can be specified – most flexible

  12. Issue : Packet-level Transport Protocol • Design specialized protocol? • Minimize latency • Maintaining state information (for connection based) unacceptable – will grow with clients • Required semantics • Exactly once – if call returns • Else report exception

  13. Simple Calls • Arguments / Results fit in one packet

  14. Simple Calls (cont..) • Client retransmits until ack received • Result acts as an ack (Same for the callee, next call packet is a sufficient ack) • Callee maintains table for last call ID • Duplicate call packets can be discarded • This shared state acts as connection – no special connection establishment required • Call ID to be unique – even if caller restarts • Conversation identifier – distinguish m/c incarnations

  15. Advantages.. • No special connection establishment • In Idle state • Callee : only call id table stored • Caller : single counter sufficient (for sequence num) • No concern for state of connection – ping packets not required • No explicit connection termination

  16. Complicated Calls • Caller retransmits until acknowledged • For complicated calls – packet modified for explicit acks • Caller sends probes until gets response • Callee must respond • Type of failure can be judged (communication / server crash) – exception accordingly reported

  17. Complicated Calls (cont.)

  18. Exception Handling • Emulate local procedure exceptions – caller notified • Callee can transmit an exception instead of result packet • Exception packet handled as new call packet, but no new call invoked instead raises exception to appropriate process • Call failed - may be raised by RPCRuntime • Differs from local calls

  19. Processes - optimizations • Process creation and swap expensive • Idle server processes – also handle incoming packets • Packets have source / destination pids • Subsequent call packets can use these • Packets can be dispatched to waiting processes directly from interrupt handler

  20. Other optimization – • Bypass software layers of normal protocol hierarchy for RPC packets • RPC intended to become the dominant communication protocol • Security • Encryption – based security for calls possible • Grapevine can be used as an authentication server

  21. Performance • Measurements made for remote calls between Dorados computers connected by Ethernet (3 Mbps)

  22. Performance Summary • Mainly RPC overhead – not due to local call • For small packets, RPC overhead dominates • For large packets, transmission time dominates • Protocols other than RPC have advantage • High data rate achieved by interleaving parallel remote calls from multiple processes • Exporting / Importing cost unmeasured

  23. Summary • RPC package fully implemented and in use • Package convenient to use • Should encourage development of new distributed applications formerly considered infeasible

  24. Performance of Firefly RPC - M. Schroeder , M. Burrows) • RPC already gained wide acceptance • Goals : • Measure performance of RPC (intermachine) • Analyze implementation and account for latency • Estimate how fast it could be

  25. RPC in Firefly • RPC – primary communication paradigm • Used for all communication with another address space irrespective of same / different machines • Uses stub procedures • Automatically generated from Modula2+ interface definition

  26. Measurements • Null Procedure • No arguments and no results • Measures base latency of RPC mechanism • MaxResult Procedure • Measures server-to-caller throughput by sending maximum packet size allowed • MaxArg Procedure • Same as MaxResult : measures throughput in opposite direction

  27. Latency and Throughput

  28. Latency and Throughput • The base latency of RPC is 2.66 ms • 7 threads can do ~740 calls/sec • Latency for MaxResult is 6.35 ms • 4 threads can achieve 4.65 Mb/sec • Data transfer rate in application since data transfers use RPC

  29. Marshalling Time • Most arguments and results copied directly • Few complex types call library marshalling procedures • Scale linearly with number of arguments and size of arguments / result – for simple arguments

  30. Marshalling Time - Much slower when library marshalling procedures called

  31. Analysis of performance • Steps in fast path (95 % of RPCs) • Caller: obtains buffer (Starter), marshals arguments, transmits packet and waits (Transporter) • Server: unmarshals arguments, calls server procedure, marshals results, sends results • Caller: Unmarshals results, free packet (Ender)

  32. Transporter • Fill RPC header in call packet • Call Sender - fills in other headers • Send packet on Ethernet (queue it, notify Ethernet controller) • Register outstanding call in RPC call table, wait for result packet (not part of RPC fast path) • Packet-arrival interrupt on server • Wake server thread - Receiver • Return result (send+receive)

  33. Reducing Latency • Usage of direct assignments rather than calling library procedures for marshalling • Starter, Transporter and Ender through procedure variables not through table lookup • Interrupt routine wakes up correct thread • OS doesn’t demultiplex incoming packet • For Null(), going through OS takes 4.5 ms

  34. Reducing Latency • Packet buffer management scheme • Server stub can retain call packet for result • Waiting thread contain packet buffer – this packet can be used for retransmission • Packet buffers reside in memory shared by everyone • Security can be an issue • RPC call table also shared

  35. Improvements • Write fast path code in assembly not in Modula2+ • Speeded up by a factor of 3 • Application behavior unchanged

  36. Proposed Improvements • Different Network Controller • Save 11 % on Null() and 28 % on MaxResult • Faster Network – 100 Mbps Ethernet • Null – 4 %, MaxResult – 18% • Faster CPUs • Null – 52 %, MaxResult – 36 % • Omit UDP checksums • Ethernet controller occasionally makes errors • Redesign RPC Protocol

  37. Improvements • Omit layering on IP and UDP • Busy Wait – caller and server threads • Time for wakeup can be saved • Recode RPC run-time routines

  38. Effects of processors

  39. Effect of processors • Problem: 20ms latency for uniprocessor • Uniprocessor has to wait for dropped packet to be resent • Solution: take 100 microsecond penalty on multiprocessor for reasonable uniprocessor performance

  40. Effect of processors • Sharp increase in uniprocessor latency • Firefly RPC implementation of fast path is only for a multiprocessor

  41. Comparison Table

  42. Summary • Concentrates upon the performance of RPC • Understand where time is spent • Resulting performance is good, but not demonstrably better than others • Faster implementations exist but on different processors • Performance would be worse on multi-user computer – packet buffers cannot be shared

More Related