Distributed Objects:

The term distributed objects usually refers to software modules that are
designed to work together,
but reside either in multiple computers connected via a network or in
different processes inside the same computer.
One object sends a message to another object in a remote machine or process
to perform some task.
The results are sent back to the calling object.

Replicated objects are groups of software components (replicas) that

run a distributed
multi-party protocol to achieve a high degree of consistency between their
internal states,
and that respond to requests in a coordinated manner.

Live distributed objects (or simply live objects)[1] generalize the

replicated object concept to groups of replicas that
might internally use any distributed protocol,
perhaps resulting in only a weak consistency between their local states.

Distributed object communication

Distributed object communication realizes communication between distributed
objects
in the distributed computing environment.

The main role is to interconnect objects residing in non-local memory space

and
allowing them to perform remote calls and exchange data.

The widely used approach on how to implement the communication channel is

realized by using stubs and skeletons.
They are generated objects whose structure and behavior depends on chosen
communication protocol,
but in general provide additional functionality
that ensures reliable communication over the network.
When a caller wants to perform remote call on the called object,

it delegates requests to its stub which initiates communication with the

remote skeleton.

Consequently,the stub passes caller arguments over the network to the server
skeleton.

The skeleton then passes received data to the called object,

waits for a response and returns back the result to the client stub.

Note, there is no direct communication between the caller and the called
object.

In more details, the communication consists of several steps:

1. caller calls a local procedure implemented by the stub

2. stub marshalls call type and input arguments into a request message

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

4. server skeleton receives the request message from the network

5. skeleton unpacks call type from the request message and looks up the
procedure on the called object
 6. skeleton unmarshalls procedure arguments

7. skeleton executes the procedure on the called object

8. called object performs a computation and returns the result

9. skeleton packs the output arguments into a response message

10. skeleton sends the message over the network back to the client

11. client stub receives the response message from the network

12. stub unpacks output arguments from the message

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

The advantage of this architecture is that neither the caller nor

the called object has to implement network related logic.

This functionality, that ensures reliable communication channel over the

network,

has been moved to the stub and the skeleton layer

RPC
In computer science, a remote procedure call (RPC) is an inter-process
communication that allows

a computer program to cause a subroutine or procedure to execute in another

address space (commonly on another computer on a shared network) without

the programmer explicitly coding the details for this remote interaction.

That is, the programmer writes essentially the same code whether

the subroutine is local to the executing program, or remote.

When the software in question uses object-oriented principles,

RPC is called remote invocation or remote method invocation.

Sequence of events during a RPC

1. The client calls the Client stub. The call is a local procedure call,
with parameters pushed on to the stack in the normal way.

2. The client stub packs the parameters into a message and makes a system
call to send the message. Packing the parameters is called marshalling.

3. The kernel sends the message from the client machine to the server
machine.

4. The kernel passes the incoming packets to the server stub.

5. Finally, the server stub calls the server procedure. The reply traces
the same in other direction

Distributed file system

a distributed file system or network file system is any file system that
allows access

to files from multiple hosts sharing via a computer network.

This makes it possible for multiple users on multiple machines to share files
and storage resources.

Network File System (protocol)

Network File System (NFS) is a network file system protocol originally developed by
Sun Microsystems in 1984,

allowing a user on a client computer to access files over a network in a manner

similar to how local storage

is accessed. NFS, like many other protocols, builds on the Open Network Computing
Remote Procedure Call (ONC RPC) system.

The Network File System is an open standard defined in RFCs,

allowing anyone to implement the protocol.

Original NFS version

The implementation details are defined in RFC 1094. Sun used version 1 only for in-
house experimental purposes.

When the development team added substantial changes to NFS version 1

and released it outside of Sun, they decided to release the new version as v2,

so that version interoperation and RPC version fallback could be tested.

NFSv2

Version 2 of the protocol (defined in RFC 1094, March 1989) originally operated
entirely over UDP.

Its designers meant to keep the protocol stateless, with locking (for example)
implemented outside of the core protocol. People involved in the creation of NFS
version 2 include Rusty Sandberg, Bob Lyon, Bill Joy, and Steve Kleiman.

NFSv2 only allowed the first 2 GB of a file to be read.

NFSv3

Version 3 (RFC 1813, June 1995) added:

* support for 64-bit file sizes and offsets, to handle files larger than 2
gigabytes (GB);

* support for asynchronous writes on the server, to improve write performance;

* additional file attributes in many replies, to avoid the need to re-fetch them;

* a READDIRPLUS operation, to get file handles and attributes along with file
names when scanning a directory;

* assorted other improvements.

At the time of introduction of Version 3, vendor support for TCP as a transport-layer

protocol began increasing.

While several vendors had already added support for NFS Version 2 with TCP as a
transport,
Sun Microsystems added support for TCP as a transport for NFS at the same time it
added support for Version 3.

Using TCP as a transport made using NFS over a WAN more feasible.

Platforms

NFS is often used with Unix operating systems such as Solaris, AIX,
HP-UX,

FreeBSD and Unix-like operating systems (such as Linux).

It is also available to operating systems such as the classic Mac OS,

OpenVMS, Microsoft Windows,

Novell NetWare, and IBM AS/400.

Alternative remote file access protocols include the Server Message

Block (SMB, also known as CIFS).

Andrew File System

The Andrew File System (AFS) is a distributed networked file system which
uses a set of trusted servers to present a homogeneous,

location-transparent file name space to all the client workstations.

It was developed by Carnegie Mellon University as part of the Andrew Project.

It is named after Andrew Carnegie and Andrew Mellon.

Features
AFS[1] has several benefits over traditional networked file systems,
particularly in the areas of security and scalability

Each client caches files on the local filesystem for increased speed on
subsequent requests for the same file.

This also allows limited filesystem access in the event of a server crash or
a network outage.

Read and write operations on an open file are directed only to the locally
cached copy. When a modified file is closed,

the changed portions are copied back to the file server.

Cache consistency is maintained by a mechanism called callback. When a file

is cached, the server makes a note of this and promises to inform the client
if the file is updated by someone else.

A significant feature of AFS is the volume, a tree of files, sub-directories

and AFS mountpoints

(links to other AFS volumes). Volumes are created by administrators and

linked at a specific

named path in an AFS cell. Once created, users of the filesystem may create
directories and files as usual without concern for the physical location of
the volume. A volume may have a quota assigned to it in order to limit the
amount of space consumed. As needed, AFS administrators can move that volume
to another server and disk location without the need to notify users;

indeed the operation can occur while files in that volume are being used.

The file name space on an Andrew workstation is partitioned into a shared and
local name space. The shared name space (usually mounted as /afs on the Unix
filesystem) is identical on all workstations. The local name space is unique
to each workstation. It only contains temporary files needed for workstation
initialization and symbolic links to files in the shared name space.
Available permissions

The following Access Control List permissions can be granted:

Lookup (l)

allows a user to list the contents of the AFS directory, examine the ACL
associated with the directory and access subdirectories.

Insert (i)

allows a user to add new files or subdirectories to the directory.

Delete (d)

allows a user to remove files and subdirectories from the directory.

Administer (a)

allows a user to change the ACL for the directory. Users always have this
right on their home directory, even if they accidentally remove themselves
from the ACL.

Permissions that affect files and subdirectories include:

Read (r)

allows a user to look at the contents of files in a directory and list

files in subdirectories. Files that are to be granted read access to any
user, including the owner, need to have the standard UNIX "owner read"
permission set.

Write (w)

allows a user to modify files in a directory. Files that are to be

granted write access to any user, including the owner, need to have the
standard UNIX "owner write" permission set.

Lock (k)

allows the processor to run programs that need to "flock" files in the
directory.