IDR is the data encoding used with DITP. It is to DITP what XML is to SOAP. IDR uses bleams that combines the benefits of block and stream encoding:
- no need to specify total size in front of it
- no upper size limit
- may be encapsulated without depth limit
- no constrain on data and doesn't rely on markers or tags
- no need to parse and search payload data to locate the end of bleam
A bleam is encoded as a sequence of byte blocks of at most 16KB. Each block is preceded by an unsigned short value whose 14 less significant bits encodes the number of bytes of data that follow. Its most significant bit is set to one if the block is not first, and its second most significant bit is set to one if the block is not last.
When encapsulating a bleam, its sequence of blocks is simply inserted in the sequence of blocks of the encapsulating bleam. The encapsulated bleam can be stored in the data of the the encapsulating bleam block if it fully fits in one of its block.
The maximum payload size is 16382 so that the biggest block will be 2^14 byte long. The invalid size value 16383 (0x3FFF) is then used as a signal. A signal block has no payload data.
The signal is used in IDR to inform the receiver that the expected sequence of data is interrupted because an exception or an error occured. If the signal block is flagged as end of bleam, the interruption is anonymous. Otherwise subsequent bleam data provides information on the reason of the interruption. In IDR it is the serialized exception object and the objects it may be referencing. Such interruption will eventually propagate to encloding bleams and be encoded as anonymous interruptions.
Encoding and decoding bleams require some care, but the effort is worth it because of its multiple benefits. With small messages DITP is as performant as common inter-object communication protocols. With bigger message, DITP benefits from the stream oriented encoding and reduced latency and memory usage requirements. DITP can thus be used to send huge files, streamed films, etc.