Basic FM concepts

Message streams

The FM interface uses message streams for sending and receiving messages. This means that messages can be sent and received piecewise rather than as single, atomic units. Every message in FM is sent as an individual message stream. Hence, unlike TCP byte streams, FM message streams honor message boundaries. In effect, FM retains a traditional messaging model, but adds the flexibility to treat data within a message as a stream of bytes.

Message streams can improve communication performance in two important ways:

1. Latency is reduced by eliminating excess data copying. That is, message streams obviate the need to marshall messages into contiguous buffers before transmission and unmarshall them upon reception. This is especially useful for constructing higher-level messaging layers that attach/remove headers to/from user-supplied messages. In addition, message streams are useful as a generalized gather/scatter mechanism that can send noncontiguous data structures, such as trees and linked lists.
2. Throughput is increased by enabling the receiver to begin processing a message even before the sender has finished sending it. That is, sending and receiving can be heavily pipelined.

Handlers

Unlike many messaging layers, FM saves the programmer from the burden of having to match every send operation with a precisely-matching receive operation. Instead, messages are extracted from the network and automatically processed by a sender-specified handler function. A handler's primary responsibility is to consume or copy the data in the message passed to it before returning. As soon as the handler returns, FM reclaims the resources used by its message stream.

Dynamic process model

In most messaging layers designed for parallel computers, all processes in a program are assumed to begin simultaneously. That is, as soon as a program begins, it knows how many processes it contains and is able to send messages from any process to any other process. The problem with this approach is its static nature; once a program begins execution, processes may neither join nor leave. The dominant alternative, most known for its use in socket interfaces, is to eschew the notion of a parallel "program" and allow arbitrary connections among processes. While this enables client-server-style communication, it also implies that processes cannot trust each other a priori and must explicitly authenticate each connection (or each packet in a connectionless protocol).

FM 2.1's dynamic process model bridges these two views of a computation in a consistent manner. It allows communication only between processes with the same program key. Thus, a parallel program can use a secret program key to block out communication from processes that are not part of that program. And the server in a client-server program can use a publicly-advertised program key to enable the clients to find it.

The GRM assigns each process within a program a logical node number (or rank), which is used to uniquely identify a process within a program. Logical node numbers are assigned sequentially, starting from 0.

Network virtualization

Unlike previous versions of FM, FM 2.1 virtualizes each machine's network interface into a number of "logical" network interfaces called contexts. Hence, instead of being limited to one FM process per machine, users can have multiple processes--from the same or different programs--running concurrently. The maximum number of processes per machine is limited only by the number of available contexts.

Go to the first, previous, next, last section, table of contents.