NETWORKS AND DISTRIBUTED SYSTEMS

Networks and Distributed Systems

Networks and Distributed Systems

Introduction

In distributed systems, processes communicate by passing messages. The inter-process communication is necessary for distribution of computational load and sharing of resources. At each process, the received messages are initially stored in volatile storage, and are processed later. When a process fails, it looses contents of the volatile store, thereby losing the received messages. These are called lost messages. It also looses the effect of processing the messages, and the knowledge of messages sent to other processes. To avoid inconsistencies within the system, a non-failed process needs to resend the messages lost by a failed process(Özalp Babaoglu 1993 pp.67-72). Also, it must discard messages it has received from the failed process, because the sender has lost knowledge of such messages. These messages are termed as orphan messages, and the receiving process is called an orphan process. The recovery mechanisms aim at discarding orphan messages. The process of restoration of state of a process to an earlier state, is termed as process rollback. Thus, the effect of a failure is not limited to the failed process alone due to message dependencies. 

Message Passing

Message passing systems have been called "shared nothing" systems because the message passing abstraction hides underlying state changes that may be used in the implementation of sending messages(Andrew Nelson 1984 p.39-59 ).

Message passing model based programming languages typically define messaging as the (usually asynchronous) sending (usually by copy) of a data item to a communication endpoint (Actor, process, thread, socket, etc.). Such messaging is used in Web Services by SOAP. This concept is the higher-level version of a datagram except that messages can be larger than a packet and can optionally be made reliable, durable, secure, and/or transacted(Birrell et al 1994 pp.34-49).

Messages are also commonly used in the same sense as a means of interprocess communication; the other common technique being streams or pipes, in which data are sent as a sequence of elementary data items instead (the higher-level version of a virtual circuit). In some very well defined and controlled application environments, a message protocol may not need message identifiers at all. The interactions between agents may be so strictly defined that there's no need to specify the type of message being sent because the receiver is already expecting it. Suppose, for example, that we have two chess-playing agents talking to each other. Assuming that they both always make valid moves and that they both continue to play until checkmate results, the only kind of message they need to exchange is one that contains the next move that they want to make, with an optional argument that indicates if the move results in a "check" or a "checkmate." In this case, there's no need for message identifiers--the messages can just contain the chess players' moves.

Utilization of Message Passing

In a sense, every network standard and protocol discussed so far can be boiled down to some form of message passing. HTTP, SSL, even low-level network protocols like TCP/IP are protocols built around some form of message passing. When we speak of message passing in this chapter, however, we are talking about message ...