5.2. Characteristics of Space-based Communication

So far, we have seen a couple examples of fairly standard message passing between two processes. These space-based “message passing” examples behave like conventional message passing: one process sends out a message, and another process receives it. But if we scratch the surface a bit, we'll see that the space-based examples illustrate the loosely coupled style of communication we mentioned earlier.

We will fully explore the loosely coupled style of communication shortly—it will be helpful as we begin to explore more sophisticated communication patterns. Let's first take a look at the alternative: tightly coupled communication.

5.2.1. Tightly Coupled Communication

Conventional message passing—supplied by most low-level communication packages—forces senders and receivers to “rendezvous” in order to exchange a message. A rendezvous requires that the sender and receiver

• Know each other's identity (say, a process identifier)

• Know each other's precise location (say, a machine's network address)

• Exist at the same time

We can call these three properties the who, where, and when of communication. With conventional message passing, all three must be specified explicitly in order for a message to be delivered. This requirement tightly couples components (senders and receivers) in a distributed application: in order for a sender and receiver to communicate successfully, they must know each other's identity and location, and must both be running at the same time. If a participant is late, or is unsure of the other's identity, or ends up at the wrong location, then the message exchange will fail to occur. This tight coupling of components leads to inflexible applications that are particularly difficult to build and debug, and more fragile than necessary.

5.2.2. Loosely Coupled Communication

With tightly coupled systems, the communication questions of “who?”, “where?” and “when?” must be answered with “that process,” “that machine,” “right now.” Space-based communication dramatically eases this requirement and allows the question to be answered with “anyone,” “anywhere,” at “anytime.” Let's look at what each of these answers means:

Anyone: Senders and receivers don't need to know each other's identities, but can instead communicate anonymously. In our space-based messaging examples, processes that pick up messages don't know who sent them. We can go even one step further and omit the receiver field from our Message entry, meaning that a sender doesn't direct messages to anyone in particular. Since neither party knows or cares who the other is, this would be truly “anonymous” communication.

Anonymous communication is powerful: it allows you to send a message to “anyone” that knows what to do with the message. You don't care exactly who gets it, but you assume that some process that knows how to handle the message will eventually pick it up. Conversely, the process that picks up your message doesn't necessarily care who sent it. Think of a space where you submit requests for computation, say a calculation of your income tax. You drop a “help wanted” request into the space. Eventually, an available worker process with the right know-how picks up the request, performs the calculation, and posts the result to the space. At some point, you'll retrieve the result. You care only that your job gets done, and you don't need to direct your task to a specific receiver. Workers just pick up work from the space, not from any particular sender.

Anywhere: Senders and receivers can be located anywhere, as long as they have access to an agreed-upon space for exchanging messages. The sender doesn't need to know the receiver's location—it just drops an entry into the space. Conversely, the receiver picks up the message from the space using associative lookup, and has no need to know where the sender is. Even if the sender and receiver roam from machine to machine, the communication code used by your space-based programs doesn't need to change.

Anytime: With space-based communication, senders and receivers are able to communicate even if they don't exist at the same time, because message entries persist in the space. Persistence enables us to build flexible, “time-uncoupled” communication patterns. Suppose the sender exists before the receiver and leaves a message in the space; when the receiver comes along, it can pick up the message without waiting. Even if you start the receiver long after the sender has terminated, the persistent nature of the space ensures that the message is still there, ready to be removed. On the other hand, if the receiver exists before the sender and the receiver tries to perform a take, for example, it will have to wait until the sender shows up to drop the message into the space. Even if you start the sender long after the receiver, the receiver is ready and waiting to pick up the message once it arrives.

Of course, not every communication in a space-based program is specified as anyone/anywhere/anytime. You might send a message that is meant for “this receiver” /anywhere/anytime, or “any receiver that knows how to compute pi”/anywhere/ “by next Tuesday,” and so on.

5.2.3. Benefits of Loose Coupling

By being able to break the tight coupling inherent in other communication approaches, we can build systems that are more flexible, adaptable, and reliable. Throughout the examples in this chapter, you'll see the benefits of loosely coupled communication. Take PingPong, for instance. Because the PingPong players don't need to know each other's location to communicate, they can exist anywhere, and can even migrate from machine to machine, without changing how they communicate. Because communication is time-uncoupled, the players can continue to play the game whether they're both active at the same time, or taking occasional breaks to do other things.

Besides enabling flexible communication, loose coupling facilitates the composition of large applications by letting programmers easily add components without redesigning the entire application. If we want multiple Ping and Pong players on each side, for instance, we simply start up more Ping and Pong applications, in equal numbers (if the numbers of players are uneven, some will end up waiting forever for balls that will never come). Each ball will still be bounced back by just one player on a side at a given time, and the code for the players can remain unchanged.

Loose coupling also promotes the reuse of software components. Even if a player is removed from the game through partial failure (a player's machine crashes or is “cut off” by a network failure), we can plug in a replacement player that follows the same protocol with the space, and the system continues merrily on its way. Thanks to loosely coupled communication, it doesn't matter who the stand-in is, where it lives, or when it was plugged in—as long as it adheres to the protocol.