Distributed System Models is as follows:

1. Architectural Models
2. Interaction Models
3. Fault Models

1. Architectural Models

Architectural model describes responsibilities distributed between system components and how are these components placed.

a)Client-server model

☞ The system is structured as a set of processes, called servers, that offer services to the users, called clients.

• The client-server model is usually based on a simple request/reply protocol, implemented with send/receive primitives or using remote procedure calls (RPC) or remote method invocation (RMI):
• The client sends a request (invocation) message to the server asking for some service;
• The server does the work and returns a result (e.g. the data requested) or an error code if the work could not be performed.

A server can itself request services from other servers; thus, in this new relation, the server itself acts like a client.

b)Peer-to-peer

☞ All processes (objects) play similar role.

• Processes (objects) interact without particular distinction between clients and servers.
• The pattern of communication depends on the particular application.
• A large number of data objects are shared; any individual computer holds only a small part of the application database.
• Processing and communication loads for access to objects are distributed across many computers and access links.
• This is the most general and flexible model.

• Peer-to-Peer tries to solve some of the above
• It distributes shared resources widely -> share computing and communication loads.

☞ Problems with peer-to-peer:

• High complexity due to
  • Cleverly place individual objects
  • retrieve the objects
  • maintain potentially large number of replicas.

2.Interaction Model

Interaction model are for handling time i. e. for process execution, message delivery, clock drifts etc.

• Synchronous distributed systems

Main features:

• Lower and upper bounds on execution time of processes can be set.
• Transmitted messages are received within a known bounded time.
• Drift rates between local clocks have a known bound.

Important consequences:

1. In a synchronous distributed system there is a notion of global physical time (with a known relative precision depending on the drift rate).

2. Only synchronous distributed systems have a predictable behavior in terms of timing. Only such systems can be used for hard real-time applications.

3. In a synchronous distributed system it is possible and safe to use timeouts in order to detect failures of a process or communication link.

☞ It is difficult and costly to implement synchronous distributed systems.

• Asynchronous distributed systems

☞ Many distributed systems (including those on the Internet) are asynchronous. - No bound on process execution time (nothing can be assumed about speed, load, and reliability of computers). - No bound on message transmission delays (nothing can be assumed about speed, load, and reliability of interconnections) - No bounds on drift rates between local clocks.

Important consequences:

1. In an asynchronous distributed system there is no global physical time. Reasoning can be only in terms of logical time (see lecture on time and state).
2. Asynchronous distributed systems are unpredictable in terms of timing.
3. No timeouts can be used.

☞ Asynchronous systems are widely and successfully used in practice.

In practice timeouts are used with asynchronous systems for failure detection.

However, additional measures have to be applied in order to avoid duplicated messages, duplicated execution of operations, etc.

3. Fault Models

☞ Failures can occur both in processes and communication channels. The reason can be both software and hardware faults.

☞ Fault models are needed in order to build systems with predictable behavior in case of faults (systems which are fault tolerant).

☞ such a system will function according to the predictions, only as long as the real faults behave as defined by the “fault model”.