Chapter 2   Communication

Rules for communication:

Using the OSI model plus these protocols:

Middleware:  Webservices + SOAP(protocol for using XML to package messages, supported by most languages) + HTTP/SMTP/TCP/UDP

Models of communication (message passing communication):

bulletRPC(remote procedure call) Should look as much as possible like a local one.  Used in strict client/server patterns. Synchron and asynchronous.  A client program calls a procedure running in another program running in a server process.  Servers may be clients of others servers.  The server process has a service interface for what procedures that are available for calling remotely. THE MESSAGE PASSING MESSAGES ARE NOT VISIBLE TO THE PROGRAMMER.
bulletRMI (remote method invocation)  improvements of RPC with distributed objects (separation between interface and object/method, local invocation between remote objects).
bulletMOM (message oriented middleware, used where RPC and RMI can not be used like integration of many databases) Like e-amail messages where messages are queued.


Remote invocation:  A complete interaction between a client anda server.  From the point when the client sends its requestto when it receives the server`s response.

Stub:  Piece of code that transforms requests coming in over the network, into local procedure calls (stredfortreder program).

Migration:  Used when  code is not in use

Relocation:  Used when code is in use (strongest).


RPC steps: 

  1. client procedure calls the CLIENT stub (normal way..)

  2. client stub builds a message and calls the local OS

  3. The client`s OS sends the message to the remote OS.

  4. The remote OS gives the message to the SERVER stub.

  5. The server stub unpacks the parameters and calls the server.

  6. The server does the work and returns the result to the stub.

  7. The server stub packs it in a message and calls its local OS

  8. The server`s OS sends the message to the client`s OS

  9. The client`s OS gives the message to the CLIENT stub.

  10. The stub unpacks the result and returns IT to the client.

Shared memory communication uses Monitor for locking when coordinating between the threads.  MULTICOMPUTERS SEE CHAPTER 1.

Continuous and discrete data (multimedia distributed systems):

bullettime is important for contiuous data
bulletHigh QoS (flow specification, token bucket algorithm,
bulletStream synchonization

From Wikipedia:

Concurrent interaction and communication

In some concurrent computing systems communication between the concurrent components is hidden from the programmer (e.g., by using futures), while in others it must be handled explicitly. Explicit communication can be divided into two classes:

Shared memory communication

Concurrent components communicate by altering the contents of shared memory locations (exemplified by Java and C#). This style of concurrent programming usually requires the application of some form of locking (e.g., mutexes, semaphores, or monitors) to coordinate between threads.


Message passing communication

Concurrent components communicate by exchanging messages (exemplified by Erlang and occam). The exchange of messages may be carried out asynchronously (sometimes referred to as "send and pray", although it is standard practice to resend messages that are not acknowledged as received), or may use a rendezvous style in which the sender blocks until the message is received. Message-passing concurrency tends to be far easier to reason about than shared-memory concurrency, and is typically considered a more robust form of concurrent programming. A wide variety of mathematical theories for understanding and analyzing message-passing systems are available, including the Actor model, and various process calculi.


Proxy:  Provide a surrogate or placeholder for another object to control access to it.


Persistent communication:  message is stored by the communication system as long as it takes to deliver it to the receiver.  Message is never lost.

Transient communication:  message is tored by the communication system only as long as both sender and receiver are executing.  Message may be discarded.