| Ghost field in record to help RAW encoder choose union member [message #1852879] |
Thu, 09 June 2022 10:40  |
 Pau Espin Pedrol
Messages: 14
Registered: November 2021 |
Junior Member |
|
|
Hi, I was asking myself whether such a feature exist or may be desirable to have, or whether there may be another better to the problem.
The problem:
I have a UD socket protocol based on binary primitives/messages. The UD socket protocol has a generic layer which allows multiplexing several SAPIs (and negotiating version of each SAPI to use by both ends during startup). Each SAPI has its own set of primitives/messages.
So far I implemented version 0 of all SAPIs and it's running fine in TTCN3:
https://gitea.osmocom.org/ttcn3/osmo-ttcn3-hacks/src/branch/master/library/HNBLLIF_Types.ttcn
https://gitea.osmocom.org/ttcn3/osmo-ttcn3-hacks/src/branch/master/library/HNBLLIF_Templates.ttcn
I implemented it by having several levels of records/unions one inside another defining the possible axes/trees: "sapi.u.primitive.operation.{message content}"
I did it this way in order to solve limitations of the RAW encoder, see https://www.eclipse.org/forums/index.php/t/1109533/
Now, the problem comes when I want to add the possibility to add a new version "v1" of the SAPI.
See this patch upgrading from v0 to v1:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/28253/1/library/HNBLLIF_Types.ttcn
This new SAPI version is the same as v0, but with one specific "sapi.u.primitive.operation" having one extra field.
The SAPI version is known from the transmitter (the code encoding the message through RAW encoder), but the SAPI version is not transmitted over the wire in the same message (because it was negotiated by both parts previously).
If I want to add such a new message (a new "sapi.u.primitive.operation.{message contentv1}" record), I either have to find a way to let the RAW encoder/decoder know that I want to choose "sapi.u.primitive.operation.v1.{message contentv1}" or "sapi.u.primitive.operation.v0.{message contentv1}".
If that's not possible, it basically means I would need to duplicate the entire record/union structure of all the SAPIs for each new version of each of them.
So I thought maybe there's some way to specify some field in the record being encoded which can be used as a hint to the RAW encoder to choose one field or another ("v0" or "v1" message structure) based on it, but which is somehow marked to occupy 0 bits when encoding the field itself (because the bit doesn't exist at the wire level), so osme sort of "ghost field".
|
|
|
|
Powered by
FUDForum. Page generated in 0.02761 seconds
] 
Search
Help
Register
Login
Home
