1 / 16

RPC Design Issues

RPC Design Issues. Presented By Gayathri Vijay S-8,CSE. Design Issues:. Classes of RPC System Interface definition language Exception Handling Delivery guarantees Transparency. Classes of RPC System.

robertodavis
Download Presentation

RPC Design Issues

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. RPC Design Issues Presented By Gayathri Vijay S-8,CSE

  2. Design Issues: • Classes of RPC System • Interface definition language • Exception Handling • Delivery guarantees • Transparency

  3. Classes of RPC System RPC system fall into two classes.In the first class RPC mechanism is integrated with particular programming language.In the second class,a special purpose interface definition language is used for describing clients and servers.

  4. Interface Definition Language RPC Interface Definition specifies characteristics of procedures provided by a server that are visible to its clients.Characteristics include name of the procedure & its parameters

  5. Each parameter should be defined as Input,output or as both.Interface contain list of procedure signatures(names together with input or output argument)

  6. Exception Handling RPC may fail because -RPC may not be able to contact server. -Server has failed or is too busy to reply.

  7. Exception handling mechanism has two parts:- -Raising Exception -Handling Procedures

  8. Delivery guarantees DoOperation can be implemented in different ways to provide delivery guarantees: -Retry request message -Duplicate filtering -Retransmission of replies

  9. Combination of these leads to semantics:- -Maybe call semantics -At-least-once call semantics -At most-once call semantics

  10. May be call semantics: No fault tolerance measures.3 cases are: -Reply message has not received after the time-out -Request message lost -Reply message lost

  11. At-least-once call semantics The caller is either given a reply or is informed that server is presumed to have failed.So request message is retransmitted,server may receive & execute it more than once.When RPC is completed,client will not know how many times it has been called.

  12. At-most-once call semantics Some operations can have wrong effect if they are performed more than once.For them RPCs should be designed to execute their operations exactly once.For the case of Cedar if the server does not crash and the client receives the result of a call,

  13. then the procedure has been executed exactly once.Else an exception is reported and the procedure will have been called either once or not at all.This is at-most one call semantics.

  14. Transparency In RPC, although request messages are retransmitted after a timeout,this is transparent to the caller & the duration of remote call is unlimited(server is still running)In the transparent case, the client calls remote procedure in normal way for language in use.

  15. In the non transparent case, the client uses a special notation for calling remote procedure.The advantage of this is the notation may provide the ability to express requirements for distributed programming.

  16. THANK YOU...

More Related