Message passing provides asynchronous, indirect IPC: senders and receivers need not know each other. Semantics vary: blocking vs. non-blocking send/receive, FIFO vs. priority ordering, and reliability guarantees (at-most-once, at-least-once, exactly-once).
From your study of inter-process communication, you know that processes need mechanisms to exchange data across isolated address spaces. Message passing is a style of IPC where processes communicate by explicitly sending and receiving discrete messages rather than sharing memory. The key advantage is decoupling: the sender deposits a message into a channel (a mailbox, port, or queue) and the receiver retrieves it from the channel. Neither process needs a pointer into the other's address space, and they need not even run at the same time.
The first major design choice in any message passing system is blocking behavior. A blocking send (synchronous) means the sender waits until the receiver picks up the message — the two processes are synchronized at the point of communication, like handing someone a letter in person. A non-blocking send (asynchronous) means the sender deposits the message and continues immediately, like dropping a letter in a mailbox. Similarly, a blocking receive waits until a message arrives, while a non-blocking receive returns immediately with either a message or an indication that none is available. Most systems use asynchronous send with synchronous receive: the sender fires and forgets, and the receiver blocks until work arrives. This combination balances producer freedom with consumer simplicity.
The second design axis is ordering guarantees. The simplest guarantee is FIFO ordering: messages from a single sender arrive at the receiver in the order they were sent. This seems obvious but requires implementation effort — messages might traverse different network paths or be processed by different kernel threads. Stronger guarantees include causal ordering (if message A causally preceded message B, A is delivered first) and total ordering (all receivers see all messages in the same order). Weaker systems offer no ordering guarantee at all, leaving reordering to the application. Some systems support priority ordering, where higher-priority messages jump ahead in the queue regardless of arrival time.
The third axis — and often the trickiest — is delivery reliability. At-most-once semantics mean each message is delivered zero or one times: if something goes wrong, the message is lost rather than duplicated. This is the simplest to implement (just send and hope) but can lose data. At-least-once semantics guarantee delivery but may deliver duplicates — the sender retransmits until it gets an acknowledgment, so a message might arrive twice if the acknowledgment was lost. Exactly-once semantics are the gold standard — each message is delivered precisely once — but are expensive to implement, requiring sequence numbers, deduplication, and persistent state. In practice, many systems settle for at-least-once delivery combined with idempotent message handlers that produce the same result regardless of how many times the message is processed.
These three axes — blocking behavior, ordering, and reliability — define the semantics of a message passing system. Choosing weaker semantics yields simpler, faster implementations; choosing stronger semantics shifts complexity from the application into the communication layer. Understanding these tradeoffs is essential because the choice propagates through the entire system design: a message queue with at-most-once delivery demands different application logic than one with exactly-once guarantees, even though the API calls might look identical.