Hi Dojo,
We noticed the following behavior in these 2 versions; could you please let me know why the message is fragmented in 10.2 ?
TIA 🙂
The connector in question (Generic Gestel) is a smart-serial TCP driver with a single parameter (next-param) in a response. I believe it is setup as a smart-serial 'client' (meaning it has an IP defined in the element configuration and not "Any", though it doesn't matter too much)
The default behavior for smart-serial with a single response 'next param' is that the incoming data is considered a stream of data split into several Frames. For this reason the logic in a smart-serial connector that needs to parse data should always be developed with 'cut-up' data in mind.
in older DataMiner versions there was a 50ms buffer time where SLPort would wait until no more data came from the device within 50ms before sending the data to SLProtocol as a single packet. In 10.0.0 [CU22], 10.1.0 [CU12], 10.2.3 this was changed to 0ms due to modern demands of other connectors regarding throughputs. 50ms was too slow for some of the modern project restrictions.
I verified the connector in question was not developed correctly with TCP streamed frames in mind. This is likely because in the past 50ms was maybe enough to let SLPort combine every frame into a single response for the connector to process. So during development and testing no issues were noticed. Though it's possible that occasionally the response did get split and it caused a parsing error. With the decrease to 0ms, the connector now receives every frame separately and so the connector will always cause parsing errors.
To fix this, the connector part that parses the response needs to be fixed so that it can buffer incoming frames until it recognizes a full response has been received before doing the current parsing logic.
Hello Fernando,
This will only impact a very low % of connectors. Only connectors using smart-serial in client mode, with TCP data and that have a single Response containing a single parameter of type “next param”.
The recognition function will remain working if the connector uses Headers and Trailers defined in XML in their responses (or defined a fixed length of bytes through XML). SLPort will then look for a header, wait for a trailer and send the right data to SLProtocol as a single package of data.
If the connector does not use headers or trailers, but a single Next Param response it’s basically asking SLPort to consider the data as a stream and send everything. All recognition logic should be getting done inside of the QAction at that point.
First, the change in the SLPort process without any possibility of configuring the buffer behavior (0 ms or 50ms) is annoying because could have a huge impact on the older connector without an easy way to fix it.
If I understand well, with your proposed fix (buffer incoming frames) the recognition function will be relegated to a mechanism developed in a QAction by the developer instead of using the internal recognition functionalities provided by the response mechanism, right?
Thanks!