Skip to content

Instantly share code, notes, and snippets.

@CMCDragonkai
Last active August 29, 2015 14:15
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save CMCDragonkai/91803ed3a776f55c3ba3 to your computer and use it in GitHub Desktop.
Save CMCDragonkai/91803ed3a776f55c3ba3 to your computer and use it in GitHub Desktop.
Features of Interprocess Communication

Stateless Protocol vs Stateful Protocol

A stateless protocol means each request is an independent transaction. They work without requiring the receiver to remember any state from previous transactions.

A stateful protocol means each request can be dependent on previous transactions. They require the receiver to keep state in a session over multiple potential requests.

For example, a stateless authentication protocol is one in which each request carries the necessary keys to authenticate the message. A stateful authentication protocol is one in which each request can be authenticated using keys from an on-going session.

Idempotent vs Non-idempotent

Idempotent means that a request can be retried multiple times, and the effect of the requests stay the same.

Non-idempotent means that requests that are retried result in compounding effects.

Synchronous vs Asynchronous

A synchronous protocol blocks the main thread from proceeding. The main thread of execution needs to wait for the call execution to finish before continuing.

An asynchornous protocol does not block the main thread from proceeding. The main thread of execution can continue executing other things.

Whether a protocol is synchronous or asynchronous does not affect whether a response is returned or not. The existence of a response is orthogonal to whether the protocol is synchronous or asynchronous. Basically there is a possibility of a request blocking even without receiving a response. It could magically know how long the execution takes and simply blocks, without listening for confirmation.

An asynchronous protocol can be forced from the sender's side, by making the sender forget about any response regardless of whether there was any response at all. However an asynchronous protocol relies on concurrency, the receiver must operate on a separate execution thread (whether over a network, or on the current CPU node).

Request/Response vs Fire and Forget

Request/Response simply means that for every request, there is a response. This can be either synchronous or asynchronous.

Fire and forget means that for every request, there may not be a response. This is always asynchronous.

Functional vs Procedure

A remote functional call (RFC) can be synchronous or asynchronous, there is always a request and response.

A remote procedure call (RPC) can be synchronous or asynchronous, however there may be no response.

Stream Oriented vs Message Oriented

Some protocols have message framing semantics. This means communication is sent over semantically discrete messages.

Other protocols are stream oriented, this means they have no conception of discrete messages, but instead just send a stream of data over. The data iself might be discretized like a bitsream, but the individual bits offer no meaning over where a message begins and ends.

Continuous vs Discrete

The stream (analog) vs message (digital) orientation is just the concrete manifestation of a more philosophical difference between continuous and discrete data.

Continuous is often modeled using linear temporal logic types. Whereas discrete is often modeled using event types. In functional reactive programming, continuous data has an signal/behaviour type, whereas discrete data has an event type.

Fault Tolerance

Fault tolerance is the ability of a system to deal with errors and carry on operations.

A key lesson to learn is:

The composition of atomic operations over heterogenous services is not atomic.

A communication protocol that is built to ensure fault tolerance can be done in many ways:

  • Atomic Transactional Rollback (Multi-phase Commit) (Possibly Distributed)
  • Reset the World
  • Idempotent Retry
  • Forward Compensation
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment