Docsity
Docsity
Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity

Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips
Guidelines and tips
Sell on Docsity
Sell on Docsity
Docsity AI
Docsity AI
Log inSign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents
download point icon20 Points

For each uploaded document

Answer questions
download point icon5 Points

For each given answer (max 1 per day)

All the ways to get free points
Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

Remote Procedure Call in Distributed systems 3, Lecture notes of Distributed Programming and Computing

Alexandria UniversityDistributed Programming and Computing

Remote Procedure Call (RPC) is a mechanism that allows distributed applications to communicate with each other across a network, as if they were running on the same machine. It is a fundamental building block of modern distributed systems, allowing programs to transparently invoke functions or methods on a remote machine, without the need for the caller to have any knowledge of the underlying network protocols or details.

Typology: Lecture notes

2022/2023

Uploaded on 04/13/2023

abdel-halim-mansour
abdel-halim-mansour 🇪🇬

3 documents

1 / 4

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Remote Procedure Call
Design issues for RPC
RPC call semantics
We covered request-reply protocols and demonstrated how
doOperation may be implemented in several ways to offer various
delivery guarantees. The principal options are:
• Retry request message: determines whether to send the request
message again until the server responds or until the server is
considered to have failed.
• Duplicate filtering: controls the usage of retransmissions and if
duplicate requests should be blocked at the server.
• Retransmission of results: Controls whether to preserve a history
of result messages to allow for the retransmission of lost results
without having to restart server operations.
Combinations of these options result in a wide range of potential
meanings for the invoker's perception of the dependability of distant
invocations. Image 5.9 Image 5.9 semantics of calls Measures to
tolerate faults semantics of calls Request message retransmission
redundant filtering Re-run the operation or send the response again
Not at all appropriate Not relevant Maybe Yes No repeat the process
pf3
pf4

Partial preview of the text

Download Remote Procedure Call in Distributed systems 3 and more Lecture notes Distributed Programming and Computing in PDF only on Docsity!

Remote Procedure Call

Design issues for RPC

RPC call semantics We covered request-reply protocols and demonstrated how doOperation may be implemented in several ways to offer various delivery guarantees. The principal options are:

  • Retry request message: determines whether to send the request message again until the server responds or until the server is considered to have failed.
  • Duplicate filtering: controls the usage of retransmissions and if duplicate requests should be blocked at the server.
  • Retransmission of results: Controls whether to preserve a history of result messages to allow for the retransmission of lost results without having to restart server operations. Combinations of these options result in a wide range of potential meanings for the invoker's perception of the dependability of distant invocations. Image 5.9 Image 5.9 semantics of calls Measures to tolerate faults semantics of calls Request message retransmission redundant filtering Re-run the operation or send the response again Not at all appropriate Not relevant Maybe Yes No repeat the process

Once at least Yes Yes Response sent again At-most-once displays the relevant options along with names for the resulting semantics. Keep in mind that the semantics for local procedure calls are precisely once, which means that each procedure is run exactly once (except in the case of process failure). The following definitions outline the options for RPC invocation semantics. Maybe semantics: The remote procedure call may be executed once or not at all when maybe semantics are used. Maybe semantics develops in the absence of fault-tolerance controls and is susceptible to the following failure types:

  • failures due to omissions if the request or result message is misplaced;
  • Crash errors that occur when the server hosting the remote operation malfunctions

done once; if it were repeated, the sum would keep increasing! At-least-once call semantics could be acceptable if server activities can be planned so that every procedure in their service interfaces is an idempotent operation. At-most-once semantics: With at-most-once semantics, the caller will either know that the method was performed precisely once upon receiving a result, or upon receiving an exception notifying it that no result was obtained, in which case the procedure will have either been executed once or not at all. All of the fault-tolerance techniques shown in Figure 5.9 can be used to obtain at-most-once semantics. The use of retries, like in the prior instance, hides any request or result message omission failures. This collection of fault tolerance controls makes sure that a process is never run more than once for each RPC, preventing arbitrary failures. At least-once call semantics are offered by Sun RPC.