IAP - Internet Application Protocol
This is the official specification for IAP (Internet Application Protocol) network protocol.
IAP is designed to replace HTTP for the many use cases where HTTP is inappropriate. I have explained in this text: Why HTTP2 and WebSocekts are not enough.
We designed IAP during our Nanosai.com project (formerly VStack.co) when we realized that HTTP was a bad fit for our platform. In fact we realized that HTTP is a bad fit for many network communication use cases. Yet we keep trying to squeeze our network communication into HTTP. Most of the time because we already have HTTP clients and servers, and we already have our firewall open on port 80.
Since we were anyways reinventing many other parts of the typical application stack, we decided we might as well take a shot at a new network protocol too. That is how the idea for IAP was born.
What Does IAP Mean?
IAP is an acronym for Internet Application Protocol. However, during the early design stages we used the pseudonym "Intelligent Agent Protocol" because we had intelligent agents in mind when we started. Since then we have broadened the focus of the protocol to be a general purpose protocol rather than a protocol targeted at a specific niche.
IoT and Web 3.0
With the Internet of Things (IoT) we will have a lot more different devices communicating via the internet. Different devices send and receive different types of data, and have different communication patterns. A new network protocol should take that into account.
Similarly the next generation of the web, being it Web 3.0 or Web 4.0 (or whatever name it gets), will most likely add new types of data and communication patterns to the ones already existing. A new network protocol should attempt to take that into consideration too.
We have attempted to address these challenges with IAP. First of all, IAP contains a very flexible data format at its core. This data format contains predefined structures for the most commonly used data types, but allows for custom data types when these are not sufficient. In the worst case a device can default to just sending raw bytes and let it be up to the communicating parties to make sense of them.
Second, IAP allows different semantic protocols to run embedded within IAP. The IAP specification will predefine a set of semantic protocols for common tasks, but an application can define its own semantic protocol if none of the predefined semantic protocols suffice.
IAP is a message based protocol meaning the communicating parties exchange messages to each other. IAP is designed for free flow message exchange meaning the message exchange can be either solely in one direction, request-response style, or bi-directional independent message exchange. Furthermore, a single request message could be answered with multiple response messages, or multiple request messages answered with a single response message.
The IAP specification has no opinion about which party is the "client" and which is the "server". IAP only cares about communicating "nodes". What roles the communicating parties have, and what message exchange patterns to use is up to the communicating parties. Typically roles and message exchange patterns depends on what semantic protocol the communicating parties use (explained in more detail later).
IAP is intended to be a stateful network protocol. That IAP is stateful means that IAP supports that the communicating parties can associate state with the connection on either side. This can be information about supported data formats, maximum message sizes and more. Exactly what state is stored on either side depends on what the two parties are communicating about.
The core of IAP consists of the IAP Object Notation, the IAP Message Structure, and the IAP Semantic Protocols. Each of these core part are introduced shortly in the sections below, and are explained in more detail in separate texts.
RION - Raw Internet Object Notation
The Raw Internet Object Notation (RION) is a binary data format that can be used to encode a wide variety of data. RION is expressive enough to contain serialized objects (e.g. Java or C# objects), CSV, JSON, XML, text and binary data. Regarding CSV, JSON and XML: You could either embed CSV, JSON or XML inside an RION object, or convert the CSV, JSON or XML to RION. RION is flexible enough to be able to mimic CSV, JSON and XML.
In addition to being very expressive, RION is fast and reasonably easy to parse and generate, more compressed on the wire than JSON and XML, and easy to handle for servers and routers (we believe).
RION is described in more detail in these texts:
IAP Message Structure
IAP messages are RION objects exchanged over the network. IAP messages contain some protocol specific fields as well as a message body. The data exchanged between the parties communicating is embedded inside the message body.
Here you can read more about the IAP Message Structure.
IAP Semantic Protocols
The IAP Object Notation and Message Structure only defines how data and network messages are encoded. By themselves they have little semantic meaning. In order for two parties to communicate properly they must agree on a protocol for that communication. In IAP we call such protocols for Semantic Protocols.
The information necessary to coordinate e.g. file exchange might be different than what is necessary for video streaming or chat services. Therefore IAP is designed to be able to support different semantic protocols. Each semantic protocol can be tailored to the exact use case it intends to support.
IAP is designed to support both predefined semantic protocols as well as allowing applications to define their own semantic protocols (if non of the predefined semantic protocols match their needs). Applications can even mix multiple semantic protocols on the same connection if that makes sense for the application.
IAP Transport Layer
IAP only defines data and message formats, as well as a set of semantic protocols (which communicates via message exchange). Exactly how these messages are exchanged is not mandatory. IAP can run over TCP/IP or QUIC, and if the messages are small enough, possibly even over UDP.
Our first toolkit for working with IAP was called IAP Tools for Java. IAP Tools for Java was intended to provide tools for working with IAP only, meaning encoding and decoding RION, and reading and writing IAP messages. However, later we decided to expand the scope of functionality and provide something closer to a full platform for distributed nodes communicating via IAP. We decided to call that toolkit Grid Ops for Java.
All the functionality of IAP Tools will eventually be merged into Grid Ops, so going forward we recommend that you use Grid Ops instead of IAP Tools. However, for historic reasons we have the links to both below.https://github.com/nanosai/grid-ops-java
We also have a set of benchmarks measuring serialized length and throughput of RION. These benchmarks are also available on GitHub:https://github.com/jjenkov/iap-tools-java-benchmarks
The following people made contributions to IAP:
|Jakob Jenkov||Initial idea
IAP Object Notation
IAP Message Structure
IAP Semantic Protocols