0% found this document useful (0 votes)
78 views13 pages

Procedures and Remote Procedures: Procedure Call

Remote procedure calls (RPCs) allow procedures to be executed remotely in a similar way to local procedure calls. With RPCs, tasks can interact with both local and remote procedures seamlessly. However, with remote procedures, parameters cannot be passed by stack as with local procedures, and the calling process does not block waiting for a return following the call.

Uploaded by

rhushein
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
78 views13 pages

Procedures and Remote Procedures: Procedure Call

Remote procedure calls (RPCs) allow procedures to be executed remotely in a similar way to local procedure calls. With RPCs, tasks can interact with both local and remote procedures seamlessly. However, with remote procedures, parameters cannot be passed by stack as with local procedures, and the calling process does not block waiting for a return following the call.

Uploaded by

rhushein
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 13

Procedures and Remote Procedures

A procedure call is executed on the main processor by writing the name


of the procedure followed by the associated parameters enclosed in
parentheses.

Procedure resides in a remote address space, we would still like to be


able to use similar semantics. Such an invocation is known as a RPC.

One may also see the terminology remote procedure invocation (RPI)
used.

Remote procedure calls are similar to, yet different from, the familiar
local procedure calls. Support for the remote call generally includes an
interface language processor, a binding service, and a communication
driver.
Calling a Remote Procedure – RPC Semantics
The RPC paradigm combines the familiar (local) procedure call model
with the client-server model.

The goal of the RPC model is to have tasks interact with local and
remote procedures seamlessly.

local procedure , parameters and any return value are usually passed
into and returned from that procedure via a stack.

Following the call, the calling procedure then blocks waiting for the
return.

Such an approach is not possible with a remote procedure.


Remote procedure
Single-message transport is supported by two operations, send and
receive.

To communicate, one process sends a message (a sequence of data


items) to a destination.

The destination process receives the message. Earlier, communication


between the sending and receiving processes was identified as
synchronous or asynchronous with respect to a common clock.

A synchronous exchange is accomplished by requiring that when a send


is issued, the client process blocks and waits until the corresponding
receive is issued before sending out the next request. Similarly, the
receiving process will block and await an incoming message. Such an
exchange is called Idle RQ or Stop-and-Wait
Asynchronous, rather than blocking following a send, the client process
is allowed to proceed as soon as the outgoing message is copied into a
local buffer.
If the client does not block, the client and the server are working in
parallel.

The client can send consecutive messages without waiting for a reply.

Similarly, the server may queue up several reply messages while working
on the next call.
RPC Interface Definition

Input only – such parameters are only permitted to pass information


into a remote procedure.

Output only – parameters of this type can only send information from
the server to the client. The same parameter cannot be used to send
information back to the server.

Input and Output – such a parameter can be used to send information


to a server and then used by the server to return information to the
client.
REMOTE DEVICE MODEL
Asynchronous Information Exchange
Because there is no inherent clock associated with an asynchronous
exchange, coordination and synchronization are accomplished using a
protocol that permits (re)synchronization of the data to the receiving
system’s internal clock.

Both the protocols and the amount of data exchanged can vary
tremendously.
Resynchronization
Synchronous Information Exchange
The asynchronous transmission schemes have several drawbacks,
including the extra overhead of control bits and the bit clock
synchronization scheme, which becomes less reliable at higher data
rates.

 Encode the clock in the data.

 Re-derive the clock from the data.


BIPOLAR ENCODING

You might also like