Users has asked us… “Why do we get this error”?
That is usually the result of having a kbmMW based server compiled with an older version of kbmMW, than the kbmMW version used for compiling a client.
It is not an unusual scenario, if you have a production server that has been running faithfully for perhaps years, and you start to design new clients for it later on.
So what is a “stream” in this case?
It is, what in kbmMW is called, a transport stream, which is a package of data containing all the relevant information for any type of communication between kbmMW clients and servers, or between kbmMW nodes in a messaging setup.
Since kbmMW has existed for many years, and has evolved over time, the transport stream has also evolved.
So you can, by using legacy kbmMW servers or clients, end up with an older client not understanding a newer server, or an older server not understanding a newer client.
kbmMW automatically mitigate the first issue, where a newer server will understand older clients and provide transport streams matching those older clients, at least when it is in a request/response scenario.
The response transport stream will default always be generated using the same transport stream version, as the request transport stream was made.
However the second issue and in messaging scenarios, where messages may be one way messages, and not simple and direct request/response type scenarios, there is no automatic mitigation possible.
In such cases, you, as a developer will have to define the transport stream version to use on new clients/nodes, compiled with a newer kbmMW version.
It is pretty easy to do though.
Each transport instance, like the TkbmMWTCPIndyClientTransport or the kbmMW native TkbmMWTCPClientTransport and server components too, have a property called Params. Its a key/value string list, which can be used to change internal settings of the transport layer that you would often not want to play with.
Commanding the transport always to understand and produce transport stream formats not newer than a specific version, can be done by setting the key KBMMW_STREAM_FORMATTER_PARAM_STREAMVERSION to a relevant value. eg.
transport.Params.Values[KBMMW_STREAM_FORMATTER_PARAM_STREAMVERSION]:=’506′;
This means that the transport will only understand and produce transport streams that match the one introduced in kbmMW v. 5.06. Now, you can’t simply use any value here, since only select kbmMW versions introduced changes to the transport stream formats, but those that did, are documented in the kbmMWCustomTransport.pas file. Search for KBMMW_STREAM_FORMATTER_PARAM_STREAMVERSION to get to the area of interest.
Currently (as of the date this blog post is made), the following valid values exist:
| Version | kbmMW version | Info |
|---|---|---|
| 101 | 1.00 beta 2.2 | First time a transport stream version was introduced. Earlier on, there have been changes in the format, but it was not given a version number. This version adds support for streaming StateID and Data of the TkbmMWCustomTransportStream class. StateID is important for handling of statefull service requests. |
| 102 | 1.02 | The version that the server should minimum understand, if kbmMW Spider is being used. It adds support for piggy backing transport stream attributes along with the general streamed packet. Transport stream attributes are a key/value string list on the TkbmMWCustomTransportStream class. |
| 200 | 2.00 | This version adds support for streaming a RequestID along with a transport stream. The request id is used for tracking requests in a response scenario in messaging transports. |
| 203 | 2.03 | This version adds support for streaming a Sync flag along with a transport stream.. The sync flag indicates if a request is blocking awaiting a synchronous response in messaging transports. |
| 250 | 2.50 | This version adds support for streaming a Priority value along with the transport stream. The Priority value is relevant for messaging transports, and is also found in the messaging transports streams subject header, but is, from this version, also part of the transport streams core for performance purposes. |
| 290 | 2.90 | This version changes the transport stream identifier value. The identifier value must match and be understood in both ends for the stream to be attempted to be parsed in more detail. |
| 300 | 3.00 | This version introduces streaming of strings in Unicode format as default. It is possible to alter to streaming of old code page byte sized strings, by changing the Options property of the transport stream. |
| 320 | 3.20 | This version changes streaming of numerical types (long words, integers, single byte) from string to native binary value in the STANDARD transport stream format. Long words were however streamed as 32 bit signed values, not 32 bit unsigned values. Further this version adds the ability to batch multiple transport stream packets (messages) into one packet. |
| 410 | 4.10 | A version that was quickly introduced and superseded, why there are no actual references to this version anywhere in the code today. |
| 490 | 4.90.01 | This version changes how date/time values are streamed. Before they were streamed as a local date/time. From this version, they are streamed as a UTC date/time value. |
| 494 | 4.94.00 | This version changes that long words are now streamed as 32 bit unsigned values instead of 32 bit signed values. |
| 505 | 5.05.00 | This version adds streaming of an integer duration value, that provides information about the duration taken for, for example a request/response scenario. It is not filled automatically at the current time of this blog post. |
| 506 | 5.06.00 | This version changes the streaming of date/time values to use a very compact variant called temporenc instead of ISO8601 strings when streaming actual Delphi object instances (introduced in 5.01.00 which did not change the header of the transport stream format, but did change the data types that could be in the body of the message). |
| 508 | 5.08.00 | Supports transfer of other types of TValue in the body than already supported objects and interfaced object and native values. Records are now also supported. |
| 509 | 5.09.00 | Only used for the JSON/RPC transport stream format. |
Messaging transports adds another header, the subject header, which allows for the transport stream (and its header) to be encrypted while leaving the subject header unencrypted for message routing purposes.
The subject header has also evolved over time, and the specific version to use can be set like this:
transport.Params.Values[KBMMW_TRANSPORT_PARAM_SUBJECTHEADERVERSION]:=’4′;
The versions until the date of this blog post:
| Subject header version | kbmMW version | Info |
|---|---|---|
| 1 | 2.54 | Messaging was first introduced. |
| 2 | 3.60 | Supports info about number of batched messages (4 bytes) |
| 3 | 4.80.00 | Added support for distribution list, QoS setting |
| 4 | 4.90.00 | Added support for retransmit count and unique message ID |
| 5 | 5.16.00 | Added support for body size. |
