Message Passing

Overview

Message passing refers to a means of communication between

When messages are passed between two different processes we speak of inter-process communication, or IPC.

Message passing can be used as a more process-oriented approach to synchronization than the "data-oriented" approaches used in providing mutual exclusion for shared resources.

The two main dimensions

Simple Message Passing

One process/thread is the sender and another is the receiver

Symmetric Naming

Process P
Sender
Process Q
Receiver
    .
    .
    send(Q, message);
    .
    .
    .
    .
    receive(P, &message);
    .
    .

Asymmetric Naming

Process P
Sender
Process Q
Receiver
    .
    .
    send(Q, message);
    .
    .
    .
    .
    receive(&message);
    .
    .

Here the receiver will accept a message from any sender. The sender can pass its own id inside the message if it wants.

Synchronous Communication

P and Q have to wait for each other (one blocks until the other is ready).

Asynchronous Communication

Underlying system buffers the messages so P and Q don't have to wait for each other. This is less efficient due to the overhead of managing the buffer.

Client-Server Communication

A system in which the receiver (server) does care about the sender and is normally responsible for sending a reply message.

Knowledge of the sender can be implemented by

Client-Server communication is basically synchronous, using the rendezvous as a primitive for building up more sophisticated communication mechanisms, including asynchronous ones.

Rendezvous

The client blocks while the server computes and sends back the reply.

waiting.png

If the computation may take a long time, and the client has useful work to do, the rendezvous action should be kept short and some other way can be found to get the result back to the client.

Note that because the client blocks while the response is sent back, we say message exchange is atomic.

Callback

The client calls the server with the input data and its id and doesn't block. Sometime later, the server will call the client and pass the result.

callback.png

Receipt

The client calls the server, passing in the input data and receiving (immediately) a receipt from the server; later, the client contacts the server again, using the receipt to get the result. (Supposedly, dry cleaners and photo developers work this way.)

receipt.png

Mailbox

The client gives the server the address of the mailbox where it wants the result to go; the client retrieves the result later.

mailbox1.png

A mailbox can also be used to send the input data to the server:

mailbox2.png

Relay

A relay implements a fully asynchronous, no-wait send, and is used only when no reply is necessary. The relay blocks "on behalf of" the client.

relay.png

Buffer

This one is classic.

buffer.png

Channels

Instead of considering the identities of the processes as central, some systems view the communication channel as the named entity through which information is passed.

One example is the occam language. In this language, channels must be laid out at compile time, making client-server programming (in which a server can serve multiple clients) difficult.

Unix Pipes

A pipe is similar to a mailbox, but

Pipes are inherited by forked processes. Be careful when communicating with children; you might read your own message.

Also note that Windows has named pipes too. And furthermore, some programming languages have pipes in their APIs.

Unix Messages

System V Unix introduced arbitrary typed messages and the following system calls:

msgget
creates or establishes a connection to a message channel; returns a channel descriptor.
msgsnd
sends message through a channel (one of the arguments is a descriptor returned by msgget).
msgrcv
receives message (using a descriptor returned from a previous call to msgget).

Sockets

Sockets are much more widely used than System V messages. (At least I think they are.) We'll cover them later since they are so important.

Things to Note

On Communication

On Naming

On Perl

Perl's got quite a lot of functions (and packages) in the whole message passing area. See perlipc.