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

Gordon Hunn

...elds

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?

Steven McCoy

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.