Messages

Messages are independent of platform and programming language. Essentially, they are a set of key+value pairs, whereby the values must come from a pool of types.

Messages can be divided into two parts: the message envelope (Envelope) and the payload (one or more Records).

The Envelope

The data in the envelope is used to transmit the message to its destination. It contains the sender and receiver addresses, the priority, information about whether the message is to be encrypted or compressed, times, bits, debug information, and so on.

The Record

The payload, usually a single record, consists of the content to be transmitted. The most important one is the record ID of type IId. At the receiver, it decides which message handler processes the message.

The data itself is hidden in typed slots. Slots in turn consist of a key and the data value.

The following slot types are supported:

Type Description
BYTE A byte (byte).
BYTEARRAY A byte array (byte[]).
CHAR A character (char).
CHARARRAY A character array (char[]).
BOOLEAN A boolean (boolean).
BOOLEANARRAY A boolean array (boolean[]).
SHORT A short (short).
SHORTARRAY A short array (short[]).
INT An integer (int).
INTARRAY An integer array (int[]).
LONG A long integer (long).
LONGARRAY A long integer array (long[]).
FLOAT A float (float).
FLOATARRAY A float array (float[]).
DOUBLE A double (double).
DOUBLEARRAY A double array (double[]).
STRING A string (String, packed encoded as UTF-8).
STRINGARRAY A string array (String[], packed encoded as UTF-8).
ID An ID (IId).
IDARRAY An ID array (IId[]).
NODEID A NODE ID (INodeID).
NODEIDARRAY A NODE ID array (INodeID[]).
TARGETADDRESS A target address (ITargetAddress).
TARGETADDRESSARRAY A target address array (ITargetAddress[]).
UUID An UUID (UUID).
UUIDARRAY An UUID array (UUID[]).
RECORD A message record (CRecord).
RECORDARRAY A message record array (CRecord[]).
MESSAGE A message (CMessage).
BITFIELD A bitfield (CBitField).
OBJECT An object (Object - not routable, only local use).

The Slot Keys

The slot keys consist of two IId objects. Two IDs are more flexible in use than one. The use of schemata like in the Windows™ registry (path+key=value) is possible as well as e. g. (type+id=value) or (id+subId=value). Whoever gets by with a single ID just uses only one ID. The other ID remains empty and costs packed only 1 byte.

Why do we use this format?

devel.one is generally independent of the programming language. For example, there are (not yet available as a product) derivatives in other languages such as C and C++, which have to deal with the data. The world is a little bigger than JAVA™. But even if it were only JAVA™: We don't want to send slow XML because it would have to be parsed on the reception side. We also don't want to serialize objects because we prefer small and fast messages. And we can't expect that our JAVA™ interfaces are known at the other end of the line. And even if the interfaces were known, we would still have the problem that different versions would collide.

In other words, slot messages are the solution and strength of devel.one.

Packed - i. e. on the way between two devel.one NODES - the data of the slots are stored in small format. An integer contains 4 bytes, a byte of course 1 byte etc. We use compressed integer for the slot type, length, type, etc., where the first two bits encode the number of bytes used. The integers have a length of 1-4 bytes and transport between 8-30 bit payload. Less is not possible. The same applies to the slot keys and the message envelope. Most fields of the envelope consist of bits in a bit field. Only the addresses for sender and recipient are more voluminous, since 17 bytes are used for the UUIDs of the NODE IDs.

Decoding a packed message is therefore lightning fast and requires little resources, as is encoding itself. This ensures best utilization of the available bandwidth and high performance. In addition, we are platform-independent and can easily implement the framework in other programming languages.

The system can easily be supplemented by other types of slots, as the slot classes can be easily registered. However, it should be noted that the use of proprietary types severely restricts interoperability with other tools. At least for the exchange with foreign tools one should limit oneself to the built in types. We will certainly expand the types, and whoever has a suggestion should just say so; -)

Why is it possible to transport several records with one message?

The envelope has a certain overhead, as the addresses in particular take up space. Therefore, it is possible to send multiple records to a remote target in one go. On the receiver side, this is not noticed because the message envelope is passed to the message handler with a single record.

In the local instance, almost 100% of all messages are single-record messages.