Tech and Media Labs
This site uses cookies to improve the user experience.

IAP - Message Flows

Jakob Jenkov
Last update: 2016-01-06

IAP is intended to be a general purpose network protocol. For that to be possible we must first analyze common communication patterns and message flows of network communication. That is what this text attempts to do.

Basic Terms

Just to avoid confusion we will define a few basic terms that are used throughout the rest of this text.


We refer to a communicating party as a "node". A node can be a desktop computer, server, mobile phone or any other device that is capable of communicating with other devices via some kind of network (land line, WIFI, radio, satellite link etc.). Nodes typically assume the roles of "senders" and "receivers", and may assume both roles during communication.


A "message" is the basic unit of communication. A message contains an block of data which is to be used together by the receiver. Messages can be small or large.

Basic Communication Patterns

We have identified the following basic communication patterns of network communication (radio or internet):

  • Message Emission
  • Message Delivery
  • Message Delivery With Response
  • Combinations of the Above

Each of these basic communication patterns will be explained in more detail in the following sections.

Message Emission

Message emission means that a node (computer or some kind of device) emits a message without caring who receives it. Messages are simply emitted to whoever might have interest in them.

Message Emission

Message emission is useful for certain types of radio communication. For instance, a buoy in the water sending its position (and/or other data) to nearby ships, a satellite sending is position in space, a radio station broadcasting its programs, planes broadcasting their position and altitude to nearby planes, cars that broadcast their position and speed to nearby vehicles etc.

Message Delivery

Message delivery means that a node sends a message to a known receiver, and the receiver acknowledges the successful arrival of the message. The receiver does not send any additional response back beyond the simple acknowledgement.

Message Delivery

Message delivery is useful for some types of data streaming where the receiver needs to stay in sync with the stream (e.g. receive all data in the stream), but where the receiver does not need to respond to the received data.

Message delivery could take place in two directions at the same time between two nodes. Such two-way message delivery would typically look like two separate one-way message delivery processes, as the message sent in each direction are not related to each other.

Message Delivery With Response

Message delivery with response means that a node sends a message to a known receiver, and the receiver responds to that message. The response contains more information than just an acknowledgement of delivery. Message deliver with response is also known as "request-response".

Message Delivery With Response

Message delivery with response is useful for client-server communication where the server is expected to respond to the incoming message. This is typically the case for file exchange (like HTTP, FTP etc.) and remote procedure calls (RPC).

Message Subscription

Message subscription means that the sender sends a message to the receiver, signaling that the sender wants to subscribe to messages of some kind. This could be notifications from other systems, messages that are part of a video stream, sound stream etc.

The receiver returns the messages matching the subscription to the sender.

Message Subscription

Combinations of the Above

Some applications may use combinations of the above basic communication patterns.

Application Communication Patterns

Nodes typically run applications and most often it is the applications running on the nodes that communicate. Communication between applications will typically follow the basic communication patterns, but applications may use modifications of the basic patterns. This section will explain these variations.


When an application A wants to communicate with an application B on another machine, it is common for application A to open a connection to application B. This is what TCP does (and HTTP because it runs on top of TCP). Application A can then send messages to application B over this connection.


Note that the concept of connections primarily makes sense with the message delivery and message delivery with response communication patterns. Message emission does not need the concept of a connection to work.


Setting up connections (e.g. TCP connections) can be expensive. Therefore applications may want to be able to communicate about different "topics" over the same connection. For instance, a browser might have two tabs open which are both loading data from the same web server. Instead of opening one connection per tab to keep the data separated, the browser might want to use the same connection.

To be able to distinguish between data for the two different tabs, the browser and server need to be able to mark the messages according to which tab they belong to. In IAP we call this "channels". Multiple channels can be multiplexed over the same connection.


HTTP 2 has a similar concept called "streams". However, the term "stream" is well known to mean "a sequence of data" meaning there is an order in the data. In IAP by default there is no guarantee about the delivery sequence of messages. Messages are considered to be independent of each other, unless explicitly marked as connected (see the description of "sequences" below). Therefore we felt that "channels" is a better name.

Just to be clear - a message is marked with a "channel" id. In the example with the browser, the browser could use a different channel for messages belonging to different tabs.

The lack of guarantee of the delivery sequence of messages belonging to the same channel makes sense if, for instance, the messages were requests for different files used within the same web page. It doesn't really matter in what sequence the web server receives the requests for those files, and it doesn't really matter in what sequence the browser receives the responses for those files.


Sometimes an application may actually want a guarantee about the sequence that certain messages are delivered in. For instance, if first message updates data in a database and the second message reads data from the database where the updates from the first message might be visible. In this case the sender might want a guarantee that the database update message is delivered first, and the database read message delivered second.

A sender can group a set of messages into a "sequence". Each message in a sequence is given an index specifying its position in the sequence of messages. If messages arrive out of order (the order given by the sequence indexes) the receiver must guarantee that later messages are not processed before earlier messages. If a later message arrives before an earlier message in the same sequence, the receiver must wait with processing the later message until all earlier messages have arrived and been processed.


Note, that only the sequence of messages within the same sequence is guaranteed. There is no guarantee that messages sent after the last message of a sequence is not delivered and processed before the messages in the sequence. The messages in a sequence are thus seen as a unit. Sequence is guaranteed within the sequence, but the sequence as a whole is considered like a single message compared to other messages. Thus there is no sequence guarantee in relation to messages outside the sequence.

Sequences are typically associated with a channel, and via the channel also a connection.

Message Routing

In the communication examples mentioned above two nodes communicate directly with each other. However, this may not always be the case. Messages from a sender might have to be routed through one or more intermediate nodes before they reach the receiver. Furthermore, the request and response routing paths may not be the same. These routing cases are illustrated here:

Message Routing

These situations may look a bit strange when you just look at the diagrams, but there are several situations in which they may occur. A normal situation is that a message is written to a message queue by the sender, and later be forwarded to the receiver.

Another situation is the flow of messages in a P2P (Peer-to-Peer) network. A message may have to be routed through several hubs before it reaches the final receiver. Furthermore, the route from sender to receiver may not be the same route a message takes the other way back from the receiver to the sender (e.g. a response to the first message). The P2P network routing is illustrated here:

Message Routing in a P2P Network

Jakob Jenkov

Copyright  Jenkov Aps
Close TOC