Most inter-object communication protocols encode message into blocks with its size encoded in front. This requires that the message is fully encoded to compute the size of blocks before it is sent.
A stream oriented protocol doesn't need this. The communication process can be pipelined. As shown in the figure below, this reduces the communication latency. Note that in a two way transaction the saving is doubled.
In absence of the block size, one needs a marker to signal the end of the block. For instance SOAP uses xml tags as markers. There are two drawbacks with such encoding: the marker can't show up in regular data and the marker must be searched to locate the end of a block. When the block size is available, locating the end of the block is trivial and very fast.
IDR and DITP combines the benefits of blocks and streams encoding by introducing a new encoding called BLEAM. Here is a short list of the their properties:
- bleams have no size limits
- bleams may be encapsulated with unlimited depth
- bleams impose no constrain on contained data
- no need to search and parse contained data to locate the end of bleam
The last property is what makes the difference with SOAP and its xml encoding.
See next blog note for a description of the bleam encoding.
With most modern programming languages there is no such question because garbage collector is built-in. This is not the case with C++, and since I develop the first prototype in this language, I had to anwser it. Do I really need a garbage collector ?
IDR needs a garbage collector because it supports object aggregate encoding and IDR should impose minimal constrains on them. Cycles allowed, minimal difference with local objects, user implemented classes, etc.
Another reason result from the reliance on exception handling. This is the price to pay for using the streaming encoding model. If an exception is generated on the encoder side, it has to be propagated to the decoder. And manual memory management with exceptions can become tricky.
This is why I went into the effort of adding garbage collector support to C++. The good news is that it is planned to be added in the next version of the C++ standard. So the effort to implement IDR in C++ with a temporary solution is not a waste of time.
As beeing the most fundamental component of DIS, IDR was designed and implemented first.
IDR is fully functional and passed all the tests I did. It still need throughout testings for qualifying for production readyness.
IDR supports bleam, data and object aggregate encoding, as well as exception handling with exception encoding. Bleam encapsulation required special care to achieve this.
RSS Feed