Protocols: Information Exchange

This post is part of a series. The previous post defines a protocol as a set of symbols and rules that entities in a communication system need to agree on in order to communicate effectively. A protocol is often represented as a modified finite state machine, or protocol machine (PM), for short.

This post covers the type of input that a protocol receives and how it affects the PM states.

Interfaces

A protocol’s purpose is to provide a service to another protocol in the same system. Generally, the serviced protocol is in the layer above the servicing protocol’s.

There are two types of information exchange between protocols:

1. Interface Communication: This occurs within the same system between the protocol machine (PM) and the PM that employs it. The communication is tightly coupled and often implemented through system calls or application programming interface (API).

2. Protocol Communication: This happens between PMs in different systems. It involves a looser coupling, with information exchanged in the form of self-contained data units.

Therefore, a PM has four key interactions, as shown in the figure below:

1. (N)-Interface: for interaction with the user, typically another PM or an application.
2. Peer Communication: for exchange of protocol data units (PDUs) with the peer PM to maintain shared state across systems.
3. (N-1)-Interface: for interaction with a lower PM.
4. Local Interface: for interaction with the operating system for services like timers.

An interface acts as a boundary or point of interaction between protocols (or their PMs) within the same system. Specifically, it connects the PM with an upper PM (or the (N+1)-PM). The interface hides the complexity of the PM, simplifying the task for the upper PM by treating the PM as a black box.

Levels of Information Sharing

Different levels of connection exist between systems based on how much information is shared and how tightly the systems are linked. One PM must notify the other of state changes using finite size data, a PDU. The PDU carry information that is used to update a PM’s view of its correspondent’s state. The frequent exchange of PDUs between the PMs creates a binding. The amount of shared state determine the strength of the binding. Generally, protocols may have three levels of bindings (although they may be referred to by different names):

• Minimal binding: required minimal or no exchange of updates. It involves no real connection, like sending a message without expecting a response. This is common in “connectionless” communication where there’s little to no ongoing relationship between the systems.
• Weak binding: requires some updates but communication is not affected if some updates are lost. Some protocols refer to this type of binding as a flow. There’s more shared information compared to connectionless communication, but it’s not critical if some updates are missed.
• Strong binding:  requires continuous updates to be exchanged to avoid inconsistent behaviour. The systems share more information and rely on feedback to ensure that both sides stay in sync. This is typical in “connection” protocols, where continuous interaction is necessary to maintain accurate and reliable communication.

Examples

• In UDP, data is sent without establishing a formal connection. There’s minimal shared state, and the sender doesn’t expect acknowledgment from the receiver.
• In HTTP/1.x, data flows from the client to the server without a persistent connection. There’s more shared state than in a purely connectionless protocol, but it’s not tightly coupled – data is exchanged, but individual requests are independent, with no mandatory feedback mechanism.
• TCP is a connection-oriented protocol where a connection is established before data is exchanged. The systems are tightly coupled, with continuous feedback ensuring that both sides are synchronized, and data is reliably transmitted.
• Other protocols may represent various levels of bindings as well. MQTT (Message Queuing Telemetry Transport) has varying levels of QoS, but it generally allows for loose coupling between clients and servers. gRPC (gRPC Remote Procedure Call) uses HTTP/2 for transport and Protocol Buffers for sterilizing data, ensuring strong binding between client and server.

Interpreting Input

A protocol treat the input from the four interfaces like procedure or system calls. Received PDUs are viewed as procedure calls where the PDU type represents the procedure name, and the PDU components (header and data) serve as parameters. The receiving PM’s actions depend on its state and involve interpreting parameters, updating the state vector, and potentially sending PDUs or interacting with the local system or interfaces.

The protocol’s state machine coordinates these actions, ensuring they follow the correct sequence based on the PM’s state. Protocols can consist of distinct modules, each with its own set of PDUs and state machine, forming independent sub-protocols.

References

1. J. Day, Patterns in network architecture: A return to fundamentals. 2008.