Send/Receive/Reply Messaging


In this scheme we usually refer to processes as being either "senders" or "receivers". This loosely parallels the "clients" and "servers" in the more popular computing circles.

In a typical application, as part of the initialization sequence, both the sender and receiver processes register a name with a "central name storage entity". The name is used as a more convenient method of referring to the other entity.

The sender then typically "locates" the name of it's intended receiver and is given a "port" number to that receiver process. When it comes time for the sender to exchange a message with the receiver it does a BLOCKING SEND to the receiver "port". The sender simply waits until the receiver replies to its message. This represents a portion of the built in synchronization that occurs by default with this messaging scheme.

Once the receiver completes its initialization it typically drops into an endless loop where at the top it RECEIVE BLOCKS on a message. When the receiver gets notification that a message has arrived it unblocks, reads the message, processes it and then replies to the sender process. At this point the receiver typically returns to the top of its loop to block again and wait for the next message. This represents the other half of the built in synchronization.

When the sender gets the reply it UNBLOCKS and processes the reply information and continues on its execution path.

While the example above represents one of the simplest of applications, out of these very simple building blocks some very complex distributed application constructs can be created.

An example would be an inverse of the above example where the BLOCKING SEND is used to drive a sender loop. This scheme is sometimes referred to as "reply blocking".

Occasionally, it is desirable to simply "trigger" the receiver to do an action. The proxy message is simply a message ID and has no other content. Furthermore the proxy is not replied to and hence the sender does not block.

What all this buys you in software design is the ability to decompose a software problem into fully encapsulated processes. Each of these processes can be readily unit tested in isolation from the rest of the system. Because the messaging is all synchronous the final application will behave in a very deterministic manner. This type of software design lends itself well to distributed systems and to fault tolerant systems. For a given level of complexity this type of design is often far easier (and hence cheaper) to debug ,enhance and maintain.

back to SIMPL main page


This project is being coordinated by FC software Inc.