Distributed Objects and File System
Introduction to Distributed Object
- Distributed objects are the objects with respect to object oriented programming paradigm, that are distributed across different address spaces, which may be on multiple computers within a network or on multiple processes running on a same computer.
- The distributed objects are capable to work together by sharing data and invoking methods.
- It provides location transparency. It means that the remote objects and local objects appear similar within a process or a computer.
- Distributed objects generally communicate with Remote Method Invocation (RMI).
- RMI has message passing mechanism in which one object sends message to another object in a remote machine or process to carry out some task and the results are sent back to the calling object.
Distributed Objects Communication
Remote Method Invocation (RMI)
- RMI is the means by which objects in different processes can communicate with one another.
- It allows object in one process to invoke or call the methods of an object in another process.
- Each process consists of a set of objects. These objects may receive local invocation or remote invocation or both.
- The method invocation between the objects in different processes within a computer or different computer is known as remote method invocation.
- The method invocation between the objects in same process is known as local method invocation.
- The objects which can receive remote invocations are called remote objects
- All the objects can receive local invocation from another object within a same process if and only if the invoking object have a reference to the invoked object.
- In the figure, object C can invoke object E locally because C has reference to E.
- The object from other process can invoke a remote object if and only if that object has access to remote object references of the remote object. In the figure, object A can invoke object B remotely; so A must have access to remote object references of B.
- Remote interfaces are the interface contained by a remote object that specifies which of the methods of remote object can be invoked remotely by object from another process.
- An action is initiated by a method invocation which may result in further invocations on methods in other objects and the objects in this chain may be in different processes. In the figure, object A can get remote object reference of F through object B.
- If garbage collection is supported, RMI allow distributed garbage collection by cooperation of local garbage collector and an added module, based on reference counting.
- RMI should be able to raise exceptions if the remote invocation between distributed objects fails.
- The request-reply message structure consists of messageType(int 0:request 1:reply), requestId(int), objectReference(RemoteObjectRef), methodId(int/Method) and arguments(array of bytes).
RMI Design Issues
RMI Invocation Semantics:
- RMI invocation works with request-reply protocol which can be implemented as retry request message(retransmit request until reply is received or server is assumed to fail), duplicate filtering(filter out duplicate requests at the server while retransmitting) and retransmission of results(keep a history of result messages to enable lost results to be retransmitted).
- In local method invocation, the semantics are exactly once (every method is executed exactly once).
RMI invocation semantics can be produced by the choice of above implementation of request-reply protocol.
- In maybe invocation semantics, the remote method may be executed once or not at all. It occurs if no fault tolerance options are adopted. It causes omission failure(message is lost) and crash failure(server fails).
- In at-least-once invocation semantics, the invoker gets result if method was executed at least once and if method was not executed, exception is received by the invoker. It may suffer from crash failure and arbitrary failure(multiple method execution causing wrong value to be returned).
- In at-most-once invocation semantics, the invoker receives result if method was executed exactly once otherwise receives an exception.
RMI Transparency
- It involves hiding of marshalling, message passing as well as the task of locating and contacting a remote object so as to make both local and remote invocations look similar.
Remote Procedure Call
- RPC is a remote communication medium in which a client program calls a procedure in another program running in a server process.
- The role of server and client is designated based on the work which is temporarily assigned. It means the server may also be clients of other servers creating a chains of RPC.
- A server process consists of a service interface which defines the procedures available for remote calling.
- RPC do not consists of object references.
- RPC also lacks the ability to create new instances of objects.
- It is implemented with maybe, at-least-once and at-most-once invocation semantics.
- It works under request-reply protocol omitting the object reference from request messages.
Working of RPC
1. Client procedure calls client stub in normal way.
2. Client stub builds message, call local OS.
3. Client's OS sends message to remote OS.
4. Remote OS gives message to server stub.
5. Server stub unpacks parameters, call server.
6. Server does work, returns result to the stub.
7. Server stub packs it in message, call local OS.
8. Server's OS sends message to client's OS.
9. Client's OS gives message to client stub.
10. Stub unpacks result, returns to client.
Case Study : Sun RPC
- SUN RPC was designed for client-server communication in the Sun Network File System.
- It can be used over either UDP or TCP. Over UDP, the length of request and reply messages is restricted in length(theoretically 64 kilobytes).
- It uses at-least-once invocation semantics.
- It provides an interface language called XDR and an interface compiler rpcgen used with C language.
Interface Definition Language
- The Sun RPC provides interface language called XDR that is used to define a service interface by specifying a set of procedure definitions and supporting type definitions.
- It supplies a program number and version number rather than interface name. The program number is unique for every program and version number changes if procedure changes. The program number and version number are passed in request message to ensure both client and server are using the same version.
- A procedure definition consists of a procedure signature and a procedure number. The procedure number is passed in request message to identify which procedure is being called.
- Only a single input parameter is allowed. Structure should be implemented if multiple input parameters are required.
- The output parameters of a procedure are returned via a single result.
- The procedure signature contains result type, procedure name and input parameter type.
- The program number is 9999 and the version is 2.
- READ procedure has number 2 while WRITE has number 1.
- The rpcgen is used to generate client stub procedure; server main procedure, dispatcher and server stub procedure; XDR marshalling and unmarshalling procedures from an interface definition.
Binding
- Binding defines the way of binding server and client together during a remote procedure call.
- It runs a local binding service called port mapper at a known port of a computer.
- Each instance of a port mapper records the program number, version number and port number in use by each service.
- When a server starts, it registers program no, version no and port no with the local port mapper.
- When a client starts, it finds server’s port by making remote request to port mapper at server’s host specifying program and version numbers.
Authentication
- The messages in Sun RPC provide additional field to pass authentication information between client and server during critical operations like accessing the network file system.
- The supported authentication protocols are none, UNIX style, shared key and Kerberos style.
- RPC header consists of a field which indicates the authentication style used.
Introduction to DFS
- File system is necessary for organization, storage, retrieval, naming, sharing and protection of files.
- Files contain data and attributes.
- Distributed file system is a model of file system that is distributed across multiple machines.
- DFS provides services to the clients of distributed system.
Requirements of DFS
1. The design of DFS must support transparency of access, location, migration , performance, etc.
2. Concurrent file updates should be controlled.
3. It should support file replication to enhance scalability and fault tolerance.
4. The service interfaces should be defined such that they can be implemented in heterogeneous systems.
5. The service should continue to operate even in case of client or server failures.
6. It should maintain consistent states for files.
7. It should provide access control mechanisms to provide security.
Importance of DFS
1. It supports sharing of information in the form of files throughout the Intranet.
2. It enables programs to store and access remote files exactly as they do on local ones.
File Service Architecture
- Distributed file system consists of three components:
a) Flat file service
b) Directory service
c) Client module
Flat file service
- It is a component responsible for implementing operations on the file contents.
- During requests for file service operations, Unique File Identifier (UFID) is used to indicate the files.
- The various flat file service operations are: Read, write, create, delete, getAttributes and setAttributes.
Directory Service
- It is a component that provides mapping between text names for files and their UFID.
- The various directory service operations are: lookup, addName, unName and getNames.
Client Module
- It is a component running in client computer, integrating the file service and directory service operations under a single API.
- With the use of cache, client module helps to achieve high performance.
SUN Network File System
- SUN NFS is a first successful network file system developed by SUN microsystems that focuses on transparancy.
Properties
1. It is both an implementation and a specification of how to access remote files.
2. It focuses on sharing a file system in a transparent way.
3. It uses client server model. A node can act both as client and server.
4. It uses mount to make server file system visible from a client.
5. It is stateless (all client requests must be self contained).
6. It is machine and operating system independent.
Architecture
1. Protocol:
- It uses SUN RPC mechanism and SUN external data representation (XDR) standard.
- The protocol is stateless. It enhances crash recovery.
- Each procedure call must contain all the information necessary to complete the call.
2. Server Side:
- It provides file handle consisting of:
a) Filesystem id (identify disk partition)
b) I-node number (identify file)
c) Generation number
- File system id is stored in super block.
- Generation number is stored in I-node.
3. Client Side:
- It provides transparent interface to NFS.
- Mapping between remote file name and remote file address is done at server boot time through remote mount.
Operations
1. Search for file within directory
2. Read a set of directory entries
3. Manipulate links and directories
4. Read/write file attributes
5. Read/write file data
Name Services
- Names are used to refer various resources.
- Resources are accessed using identifier or references.
- A name is a value that can be resolved to an identifier or an address.
- Names are used because they are human readable.
- Name services are those services that are used to resolve resource names.
- Name service returns the information about the resource when the name of a resource is given.
- Name service is responsible to store a collection of one or more naming contexts.
DNS
-DNS is the Internet naming scheme that allows resources to be accessed by using alphanumeric names.
- A valid DNS names allows; A to Z, a to z, 0 to 9 and Hyphen (-).
- The DNS is a distributed hierarchical database as shown below :
-A ‘.’ is used as a separator.
Working Mechanism:
1. Issue a DNS query to ask for IP address of www.egnitenotes.com
2. Issue a query to root name server.
3. Returns the IP address of TLD.
4. Issue a query and sent to TLD servers.
5. Reply with ns1.egnitenotes.com and IP address.
6. Issue another query and sent to ns1.egnitenotes.com
7. Reply IP address of www.egnitenotes.com
8. Return IP address of www.egnitenotes.com to client.
9. Request for web content to IP address of www.egnitenotes.com
Terminology
- A query is a request for name resolution which is directed to a DNS server.
- A recursive query is sent to DNS server and requires a complete answer.
- A iterative query is directed to DNS server which may be answered with a referral to another DNS server.
- Root hints contain IP address for DNS root servers.
Resource Records
1. A- record = Address
2. CNAME = Alias
3. NS = Authoritative name server
4. MX = Mail exchange
5. PTR = Domain Name Pointer
by Sural Awal
Ⓒ Copyright ESign Technology 2019. A Product of ESign Technology. All Rights Reserved.