question

Upvotes
Accepted
Gordon Hunn avatar image
67 ●3 ●1 ●8

How to ensure backward compatibility when encoding UPA 8.0 nanosecond resolution TIME/DATATIME fields

As part of upgrading to UPA8.0 (C++) I have added microsecond/nanosecond support when encoding/decoding TIME/DATETIME fields.

In an environment running TREP 3.0 platform components UPA 8.0 consumers decode UPA 8.0 Publisher TIME fields as expected. No problem there.

However whilst performing tests with UPA 7.6 consumers on the same environment. I found that the 7.6 consumers cannot decode the TIME fields published by a UPA 8.0 publisher.

2016-04-15 10:00:41.322  WARN: FieldListInspector.cpp:182: Failed to decode fid 18 [TRDTIM_1]: RSSL_RET_INCOMPLETE_DATA

So my questions are:

1. Is this expected behaviour?

2. If so, how should I encode the high res time field in a UPA 8.0 publisher in such a way to ensure backward compatibility with older UPA clients?

elektronelektron-sdkrrteta-apielektron-transport-api
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Gordon Hunn avatar image Gordon Hunn

I've just performed the same test in a TREP 2.6.1 environment without issue.

So this is looking more like a TREP 3.0 platform problem rather than a backward compatibility issue.

Steven McCoy avatar image Steven McCoy Gordon Hunn

TREP 2.6.2 is built with UPA 7.6.0.L1, TREP 3.0.0 is built with UPA 8.0.0.L1, TREP 3.0.2 is built with ETA 3.0.1.L1+

1 Answer

Upvote
Accepted
Steven McCoy avatar image
1.2k ●23 ●28 ●42

This is an expected limitation, UPA 8 introduces a new message version with new data sizes and features which cannot be understood by earlier versions. For TIME field in particular you can manually decode the field in UPA 7.6 but the negatives outweigh the positives to simply moving to UPA 8.

For full backward compatibility only use the basic field types that are published on Elektron which surprisingly does not include DATETIME but separate DATE and TIME fields and microseconds or smaller are provided in another INT field, e.g. SALTIM_MS. Consult the RDMFieldDictionary file for the list of common fields that will be understood by all consumers.

Theoretically with a non-caching TREP a provider can inspect the version information of a request and encode the response appropriately for the features understood, such as nanoseconds. Practically though TREP is sending the request with the version information it was built with and not what the client sent and thus the information is lost.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Click below to post an Idea Post Idea