Distributed Systems

CH – 02
Distributed Objects and File System

Baikuntha Acharya (baikunth2a@gmail.com)

Lecturer, Sagarmatha Engineering College, Sanepa, Lalitpur

© Baikuntha Acharya (baikunth2a@gmail.com)

 Distributed Objects

✓ A distributed application can be viewed as a collection of objects

(user interfaces, databases, application modules, customers).
• Objects have its own attributes and methods which define its behavior.

• Like a regular object but it can be accessed from anywhere on the network
remotely. (E.g.: Client and Server Objects)

✓ Distributed objects might be used :

• to share information across applications or
users and invoking methods.

• to synchronize activity across several

machines.

• For the location transparency, remote

objects appear the same as local objects.

• Communication: remote method invocation

(RMI), generally by message-passing.
2
© Baikuntha Acharya (baikunth2a@gmail.com)
 Distributed Objects (Cont..)

✓ Local Objects vs. Distributed Objects

• Reference: Remote references to distributed objects are more complex than
simple pointers to memory addresses.

• Request Latency: A distributed object request is orders of magnitude slower

than local method invocation.

• Object Activation: Distributed objects may not always be available to serve an

object request at any point in time.

• Parallelism: Distributed objects may be executed in parallel.

• Failure: Distributed objects have far more points of failure than typical local
objects.

• Security: Distribution makes them vulnerable to attack.

3
© Baikuntha Acharya (baikunth2a@gmail.com)
 Communication in Distributed Objects
✓ Communication channel is realized by using two generated objects:
• Stubs or proxy – client side object that acts as gateway for all outgoing requests.
• can be written up manually or generated

• wraps client object functionality and adds network logic for reliable communication

• translating calls from the caller object

• marshalling of the parameters

• informing the skeleton that the call should be invoked

• passing arguments to the skeleton over the network

• unmarshalling of the response from the skeleton

• informing the caller that the call is complete

• Skeletons – server side object that acts as a getaway for incoming client requests.
• can be written up manually or generated

• wraps server object functionality and exposes it to the clients and adds network logic

• translating incoming data from the stub

• unmarshalling of the arguments from received data

4
© Baikuntha Acharya (baikunth2a@gmail.com)
 Communication in Distributed Objects
• Skeletons (Cont..)
• passing arguments to server objects

• marshalling of the returned values from server objects

• passing values back to the client stub over the network

✓ General Communication Steps

• caller calls a local procedure implemented by the stub

• stub marshalls call type and the input arguments into a request message

• client stub sends the message over the network to the server and blocks the
current execution thread

• server skeleton receives the request message from the network

• skeleton unpacks call type from the request message and looks up the procedure
on the called object

• skeleton unmarshalls procedure arguments

• skeleton executes the procedure on the called object

5
© Baikuntha Acharya (baikunth2a@gmail.com)
 Communication in Distributed Objects
✓ General Communication Steps (Cont..)
• called object performs a computation and returns the result

• skeleton packs the output arguments into a response message

• skeleton sends the message over the network back to the client

• client stub receives the response message from the network

• stub unpacks output arguments from the message

• stub passes output arguments to the caller, releases execution thread and caller
then continues in execution

✓ Advantage of Stub-Skeleton Implementation:

• neither the caller nor the called object has to implement network related logic.

6
© Baikuntha Acharya (baikunth2a@gmail.com)
 Basic RPC Operation
✓ Remote Procedure Call (RPC) is an inter-process communication technique
which is used for client-server applications.
• executes a subroutine in different address space without specifically coding the details for
the remote interaction.

7
© Baikuntha Acharya (baikunth2a@gmail.com)
 Basic RPC Operation (Cont..)
✓ Typical RPC Example

8
© Baikuntha Acharya (baikunth2a@gmail.com)
 RPC Operation (Cont..)
Characteristics & Features of RPC

✓ Essential characteristics of RPC:

• Called procedure is in another process, which is likely to reside in another machine.

• The processes do not share address space.

• Parameters are passed only by values.

• RPC executes within the environment of the server process.

• It doesn't offer access to the calling procedure's environment.

✓ Features of RPC
• Simple call syntax

• Offers known semantics

• Provide a well-defined interface

• It can communicate between processes on the same or different machines

9
© Baikuntha Acharya (baikunth2a@gmail.com)
 RPC Operation (Cont..)
Advantages/Disadvantages of RPC

✓ Advantages:
• Uses the conventional use of procedure calls in high-level languages.

• RPC supports process and thread-oriented models.

• RPC makes the internal message passing mechanism hidden from the user.

• The effort needs to re-write and re-develop the code is minimum.

• provides abstraction.

• allows the usage of the applications in a distributed environment

✓ Disadvantages:
• Supports pass by value only (not pass by reference)

• RPC (and return) time (i.e., overheads) can be significantly lower than that for a local procedure.

• highly vulnerable to failure.

• Standardization issue (due to variation in implementation)

• Not offers any flexibility in RPC for hardware architecture as It is mostly interaction-based.

10
© Baikuntha Acharya (baikunth2a@gmail.com)
 RPC Operation (Cont..)
Call Semantics in RPC Communication

✓ The normal functioning of an RPC may get disrupted due to:

• Call message is lost or response message is lost

• The callee node crashes and is restarted

• The caller node crashes and is restarted.

✓ Call semantics determines how often the remote procedure may

be executed under fault conditions.

✓ May-Be Call Semantics

• weakest semantics - a timeout mechanism for preventing waiting indefinitely.

• caller waits until a pre-determined timeout period and then continues to execute

• this semantics does not guarantee the receipt of call message nor the execution.

• applicable where the response message is less important

11
© Baikuntha Acharya (baikunth2a@gmail.com)
 RPC Operation (Cont..)
Call Semantics in RPC (Cont..)

✓ Last-Once Call Semantics

• retransmits the call message based on timeouts until receiving a response.

• call is keep repeating until result of procedure execution is received by the caller.

• results of the last executed call are used by the caller (last-once semantics)

• easy to implement for two nodes but tricky for nested RPCs and cases by orphan
calls.

12
© Baikuntha Acharya (baikunth2a@gmail.com)
 References

13
© Baikuntha Acharya (baikunth2a@gmail.com)