Blink has the following essential properties.

An integrated, easy to use protocol specification language

A protocol layered on Blink is defined by specifying messages and their structure in a well defined schema format. This means that the process of creating and later extending the interface between applications and systems is an integral part of Blink. Blink makes the definition of new interfaces interoperable. Changing the interface requires only the part of an application that wants to make use of the change be modified. Blink minimizes the time it takes to define, implement, and deploy new interfaces.

Compact - a straightforward, efficient, and compact binary transfer format

• straightforward - Blink minimizes the number of encoding artifacts, primitive constructs, and the ways they can be combined,
• efficient - encoders and decoders can be efficiently implemented in software or hardware, and
• compact - encoded messages are reasonably compact due to the extensive use of variable length encoded data fields and the lack of inline meta data.

Native - a binary transfer format that trades compactness for speed

The native format results in less compact messages compared to the compact binary format in the core Blink specification. The advantage is that the encoding and decoding overhead is lower. This means that this format is suitable in situations where bandwidth or storage size is not a limiting factor and encoding and decoding speed is of essence.

The native format was designed to meet the following goals:

• Full fidelity to the core specification: any message encoded in the core binary format can also be represented by a message in the native format as long as the contained types are defined by a schema.
• Zero overhead to produce and access static content in environments that allow efficient access to misaligned data, also in messages that have dynamic content. This is why the format is called native.
• Minimal overhead to produce and access dynamic content.
• Make the producer of a message spend the effort of calculating the offsets to dynamic content. Allow a producer that has prior knowledge about the dynamic content to pre-calculate the offsets.

Self‐describing message streams

For efficiency reasons, a Blink message does not include the inline meta data required to make it self describing. However, a stream of Blink messages can be self-describing thanks to the Blink Schema Exchange layer that encodes the schema itself into ordinary Blink messages.

Note: An unreliable transport layer requires a session layer that makes the stream self-describing so that meta data does not have to be included in every datagram.

A separate Blink specification for a session layer over unreliable transports is being developed.

Platform independence

The Blink Compact wire format works on the byte level and makes no assumptions on, e.g., byte order.

Suitability for FPGA implementation

The Blink protocol can be implemented in a straightforward way with minimal FPGA resources due to its simplicity, orthogonal design and small runtime footprint.

Transport Independence

Blink can be used as an efficient presentation layer on top of middleware solutions like message queues and messaging platforms. However, Blink is also well-suited to be layered on TCP and UDP without any need for encapsulating headers, thanks to its built in message type system.

Middleware implementations can be layered on Blink, potentially boosting their performance and making previously closed solutions open.

Blink is suitable as a storage format as it is compact, self describing, and can be serialized quickly.