Architectural Model and Fundamental Model of Distributed System

Architectural Models of Distributed System:
How responsibilities distributed between system components and how are these components placed?
Basically, in two parts: -
1.     Peer-to-peer
2.     Client-server model
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 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 as a client.

 Peer-to-Peer Model:
All processes play a similar role.
• Processes 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




Fundamental Models of Distributed System:
Understanding the characteristics that impact distributed system performance and operation.
Interaction:
Fundamentally, distributed systems are comprised of entities that communicate and coordinate by passing messages.
Generally, it is sufficient to know the order in which events occur. A logical clock is a counter that allows a system to keep track of when events occur in relation to other events.

Failure

It is important to understand the kinds of failures that may occur in a system.
  • Fail stop: A process halts and remains halted. Other processes can detect that the process has failed.
  • Crash: A process halts and remains halted. Other processes may not be able to detect this state.
  • Omission: A message inserted in an outgoing message buffer never arrives at the other end's incoming message buffer.
  • Send-omission: A process completes a send, but the message is not put in its outgoing message buffer.
  • Receive-omission: A message is put in a process's incoming message buffer, but that process does not receive it.
  • Timing failure: Clock drift exceeds allowable bounds.

Security

There are several potential threats a system designer need be aware of:
  • Threats to processes - An attacker may send a request or response using a false identity (spoofing).
  • Threats to communication channels - An attacker may eavesdrop (listen to messages) or inject new messages into a communication channel. An attacker can also save messages and replay them later.
  • Denial of service - An attacker may overload a server by making excessive requests.
Cryptography and authentication are often used to provide security. Communication entities can use a shared secret (key) to ensure that they are communicating with one another and to encrypt their messages so that they cannot be read by attackers.




Comments