Distributed Systems Research

7/29/2019 Distributed Systems Research

1/6

Distributed systems (computers)

A distributed system consists of a collection of autonomous computers linked by a

computer network and equipped with distributed system software. This softwareenables computers to coordinate their activities and to share the resources of the

system hardware, software, and data. Users of a distributed system should perceivea single, integrated computing facility even though it may be implemented by

many computers in different locations. This is in contrast to a network, where the

user is aware that there are several machines whose locations, storage replications,load balancing, and functionality are not transparent. Benefits of distributed

systems include bridging geographic distances, improving performance andavailability, maintaining autonomy, reducing cost, and allowing for interaction.

The object-oriented model for a distributed system is based on the model supported

by object-oriented programming languages. Distributed object systems generallyprovide remote method invocation (RMI) in an object-oriented programming

language together with operating systems support for object sharing andpersistence. Remote procedure calls, which are used in client-server

communication, are replaced by remote method invocation in distributed objectsystems.

The state of an object consists of the values of its instance variables. In the object-

oriented paradigm, the state of a program is partitioned into separate parts, each of

which is associated with an object. Since object-based programs are logically

partitioned, the physical distribution of objects into different processes orcomputers in a distributed system is a natural extension. The Object Management

Group's Common Object Request Broker (CORBA) is a widely used standard fordistributed object systems. Other object management systems include the Open

Software Foundation's Distributed Computing Environment (DCE) and Microsoft'sDistributed Common Object Manager (DCOM).

CORBA specifies a system that provides interoperability among objects in a

heterogeneous, distributed environment in a way that is transparent to theprogrammer. Its design is based on the Object Management Group's object model.

This model defines common object semantics for specifying the externally visiblecharacteristics of objects in a standard and implementation-independent way. In

this model, clients request services from objects (which will also be called servers)through a well-defined interface. This interface is specified in Object Management

Group Interface Definition Language (IDL). The request is an event, and it carries


2/6

information including an operation, the object reference of the service provider,

and actual parameters (if any). The object reference is a name that defines anobject reliably.

The central component of CORBA is the object request broker (ORB). It

encompasses the entire communication infrastructure necessary to identify andlocate objects, handle connection management, and deliver data. In general, the

object request broker is not required to be a single component; it is simply defined

by its interfaces. The core is the most crucial part of the object request broker; it isresponsible for communication of requests.

The basic functionality provided by the object request broker consists of passingthe requests from clients to the object implementations on which they are invoked.

In order to make a request, the client can communicate with the ORB core through

the Interface Definition Language stub or through the dynamic invocation interface(DII). The stub represents the mapping between the language of implementation of

the client and the ORB core. Thus the client can be written in any language as longas the implementation of the object request broker supports this mapping. The

ORB core then transfers the request to the object implementation which receivesthe request as an up-call through either an Interface Definition Language (IDL)

skeleton (which represents the object interface at the server side and works withthe client stub) or a dynamic skeleton (a skeleton with multiple interfaces).

Many different ORB products are currently available; this diversity is very

wholesome since it allows the vendors to gear their products toward the specificneeds of their operational environment. It also creates the need for different object

request brokers to interoperate. Furthermore, there are distributed and client-serversystems that are not CORBA-compliant, and there is a growing need to provide

interoperability between those systems and CORBA. In order to answer theseneeds, the Object Management Group has formulated the ORB interoperabilityarchitecture.

The interoperability approaches can be divided into mediated and immediate

bridging. With mediated bridging, interacting elements of one domain aretransformed at the boundary of each domain between the internal form specific to

this domain and some other form mutually agreed on by the domains. This

common form could be either standard (specified by the Object Management

Group, for example, Internet Inter-ORB Protocol or IIOP), or a private agreementbetween the two parties. With immediate bridging, elements of interaction aretransformed directly between the internal form of one domain and the other. The


3/6


4/6

2. Client stub builds message, calls local OS3. Client's OS sends message to remote OS4. Remote OS gives message to server stub5. Server stub unpacks parameters, calls server6. Server does work, returns result to the stub7. Server stub packs it in message, calls local OS8. Server's OS sends message to client's OS9. Client's OS gives message to client stub10.Stub unpacks result, returns to client

Five different classes of failures in RPC systems:

Client Cannot Locate the ServerServer might be down or New server with old client


5/6

return -1 for error is not good enough because the return value might be-1 (e.g.adding 7 to -8)

raise an exception (so write your own SIGNOSERVER)

Lost Request Messageseasiest to deal with, just have the kernel start a timer when sending the request,and resend it if time-out.

Lost Reply Messagesuse timeragain, but this time you cannot tell whether the reply is lost or the serveris just slow

idempotent transactions

reading the first 1024 byte of a file is idempotent;

transferring 1 million $ from a bank account is non-idempotent

solution 1: construct all requests in an idempotent way

solution 2: have the clients kernels assigned each request a seq. number

Server Crashes

- In the 2nd case, the system has to report failure back to the client- In the 3rd case, it can just retransmit the request- at least-once semantics- at most-once semantics- exactly once semantics

Client Crashes- unwanted computation is called orphan- solution 1: extermination --keeping log for every request


6/6

- Solution 2: reincarnation --divide time into sequentially numbered epochs.Client broadcasts a message to all machines declaring a new epoch. Allremote computations are killed.

- solution 3: gentle reincarnation --same as 2, but remote computations arekilled only if they cannot find their owner

- Solution 4: expiration --each RPC is given a standard time T to do a job, if itcannot finish within T, it have to ask the for another quantum. After theclient crash, it waits for T unit of time to make sure that all orphans are

gone, then it reboots.

Distributed Systems Research

Documents

Transcript of Distributed Systems Research