Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000824Taste[All Projects] ASN.1 Compiler v4public2018-12-18 14:302019-05-05 14:57
Reportercavada@fbk.eu 
Assigned Togmamais 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Summary0000824:

Support hooks in encoding functions

Description

Having hooks in encoding functions may simplify the customization of ACN encodings.

For example, suppose you have messages containing packets:

T-Message []
{
    nid-stm [],
    length T-Message-Length [],
    packets [size length]
}

T-Packet []
{
  nid T-NID-Packet [encode-values],
  length NULL [pattern '0000000000000'B],  -- 13 bits

  pbody [determinant nid]
}

In the example, T-Packet.length is the size (in bits) of each packet.
As suggested in CRC and length computation example provided with taste's documentation, computing the length shall be done after the encoding, as a post-process step. However, that step requires traversing message structure, searching for packets, and for each packet, compute its size before writing it into the buffer in the right position. This is complex, costy and error prone, especially considering that the encoding function already knows all these information while it is encoding the message.

I propose to have a mechanims to allow inserting hooks during the encoding, only for those structures that need to be involved.

Here is an example:

T-Message [] 
-- .. like before

T-Packet [post-encoding-function my_encoding_patcher]
{
  nid T-NID-Packet [encode-values],
  length NULL [pattern '0000000000000'B],  -- 13 bits

  pbody [determinant nid]
}

my_encoding_patcher, like for mapping-functions, is a function meant to be implemented by the user, which receives: a fresh bitstream objects, set to point to the first bit in the buffer encoding the packet which need to be patched, and the number of bits that were used to encode the packet.

flag my_encoding_patcher(BitStream* bitStream, size_t bits);

The generated encoding function might be modified as follow:

///... encoding of other structures
/// here starts encoding of ith packet
< packet_start_pos := get current bit position in bitstream >
// encode ith packet
< packet_end_pos := get current bit position in bitstream >
< create bs := BitStream (start=packet_start_pos, end=packet_end_pos) >
< call ret := my_encoding_patcher(bs, packet_end_pos - packet_start_pos) >
if (ret) { 
  // keep going with other fields ...
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0003557)
gmamais (developer)
2019-01-12 17:55
edited on: 2019-01-12 18:01

I am proposing a small variation of the above approach. In particular, I 'm proposing the following:

Two new ACN properties will be introduced:
- the post-encoding-function ACN property with the functionality described above. However, this property will be applicable only to SEQUENCE types.
- the save-position ACN property that will be applicable only to NULL types that exist within a SEQUENCE with the post-encoding-function

With these two new properties the user will be able to write:

T-Packet [post-encoding-function my_encoding_patcher]
{
    dummy NULL [pattern ''B, save-position], -- this has no effect on the encoding. However, we used it to force the compiler to store the position of the bitsteam at the begining of the packet
    nid T-NID-Packet [encode-values, size 4, encoding pos-int],
    length NULL [pattern '0000000000000'B, save-position], -- 13 bits
    pbody [determinant nid],
    crc32 NULL [pattern '00000000'H, save-position] -- 32 bits
}

The ASN.1 compiler will generate another struct for T-Packet which has the post-encoding-function property.

The new struct will be as follows in this example

typedef struct {
    BitStream  dummy_pos;
    BitStream length_pos;
    BitStream crc32_pos;
} T_Packet_extention_function_potisions;

In other words, this stuct will have as many members as the NULL fields with save-position property.

The encoding function of T-Packet will be modified as follows:
a local variable of with name bitStreamPositions and type T_Packet_extention_function_potisions will declared.
E.g.
T_Packet_extention_function_potisions bitStreamPositions

Now, in the encoding function of the T_Packet, before encoding the NULL fields the position of the bitstream will be saved. E.g.

/*Encode T_Packet_length */
bitStreamPositions.length_pos = *pBitStrm; //SAVE the position of the bit stream
{
    static byte tmp[] = {0x00,0x00};
    BitStream_AppendBits(pBitStrm, tmp, 13);
}

At the end of the encoding function, the user-defined function will be called passing as parameters a pointer to the bitStreamPositions variable with the saved points and the actual bit stream.

my_encoding_patcher(&bitStreamPositions, pBitStrm);

the prototype of the function will be like following

void my_encoding_patcher(T_Packet_extention_function_potisions* pExt, const BitStream* pBitStrmAtThenEnd);

Please tell me if you agree with this approach in order to proceed with the implementation.

(0003558)
maxime (administrator)
2019-01-16 10:22

I fully agree with that approach. The name "bitStreamPosition" should be prefixed to avoid duplicates.

Also in the post-encoding function parameters, what size will you pass? The size of the SEQUENCE which has a post-encoding, or the size of the full packet in which this SEQUENCE may be contained?

(0003559)
cavada@fbk.eu (reporter)
2019-01-17 08:40

The proposed approach is fine with me.
The list bitStreamPositions may contain by default a stream pointing at the beginning of the encoded element. This allows to:
- Avoid having dummy fields like in the example to know the begin of the encoded element
- Using hooks functions also type other than SEQUENCEs.

I did not mention it, but of course a similar mechanism should be available for pre-decoding hooks. Pre-decoding hooks change the encoded stream before the decoding function get called.

(0003560)
cavada@fbk.eu (reporter)
2019-01-17 08:42

@maxime: in my example, size is the number of bits of the element which has a post-encoding function (T-Packet in the example.)

(0003562)
gmamais (developer)
2019-01-27 15:18

fixed in latest commit.
An example case can be found in the following link
https://github.com/ttsiodras/asn1scc/tree/master/mantis/0000824 [^]

(0003564)
maxime (administrator)
2019-02-13 10:17

@roberto, is the resolution ok for you? Can we close the ticket?

(0003566)
cavada@fbk.eu (reporter)
2019-02-13 10:40

About the encoding, solution is satisfying.

However, complete solution should include also similar solution for customization of decoding.

I don't know if this should be done in a separate issue, or in the scope of this one.

(0003573)
gmamais (developer)
2019-02-16 09:55

Can you provide an example where this functionality (i.e. decoding hook functions) will be useful?
I can think one case for the CRC field. For example

T-Packet [post-encoding-function my_encoding_patcher, post-encoding-function my_decoding_validator]
{
    dummy NULL [pattern ''B, save-position], -- this has no effect on the encoding. However, we used it to force the compiler to store the position of the bitsteam at the begining of the packet
    nid T-NID-Packet [encode-values, size 4, encoding pos-int],
    length NULL [pattern '0000000000000'B, save-position], -- 13 bits
    pbody [determinant nid],
    crc32 NULL [pattern '00000000'H, save-position] -- 32 bits
}

In the above example, the post-encoding-function will behave as implemented (i.e. patch bitstream with special calculated values), while the post-decoding-function will calculate the CRC (from the contents of the bitstream) and compare the value as sent by the sender. If the values match the function should return OK, otherwise an error. In this case, the post-decoding function acts as a validator and not as a "patch function".
Is this the intended behavior for the post-decoding functions or something else?

(0003593)
maxime (administrator)
2019-03-27 13:27

I think the CRC validator is the main use case, and it is fully relevant.

(0003601)
michal_kurowski_n7s (reporter)
2019-03-29 13:13

I think by
T-Packet [post-encoding-function my_encoding_patcher, post-encoding-function my_decoding_validator]
you meant
T-Packet [post-encoding-function my_encoding_patcher, post-decoding-function my_decoding_validator]

My comments are as follows ->
"If the values match the function should return OK, otherwise an error." - this is fully satisfactory behaviour, however, for a validator, not a "post-decoding-function". I would prefer to reserve the post-decoding-function keyword for some data manipulation functionality, similar to the one in post-encoding-function (this is not relevant right know, but having such power could potentially resolve some limitations regarding PUS C Service 5). If the only output of the hooked function is an OK or Error, the keyword should be something like post-decoding-validator.

(0003630)
gmamais (developer)
2019-05-05 14:57

a new ACN attribute with name post-decoding-validator was added that acts as a post validator.
See example in
asn1scc/mantis/0000824
for both C and Ada.

The generic post-decoding-function attribute was not added because there is currently no clear use case of it.


- Issue History
Date Modified Username Field Change
2018-12-18 14:30 cavada@fbk.eu New Issue
2018-12-19 08:39 maxime Assigned To

=> gmamais

2018-12-19 08:39 maxime Status

new => assigned

2018-12-19 08:41 maxime Description Updated View Revisions
2019-01-12 17:55 gmamais Note Added: 0003557
2019-01-12 17:56 gmamais Note Edited: 0003557 View Revisions
2019-01-12 17:57 gmamais Note Edited: 0003557 View Revisions
2019-01-12 17:58 gmamais Status

assigned => feedback

2019-01-12 18:01 gmamais Note Edited: 0003557 View Revisions
2019-01-16 10:22 maxime Note Added: 0003558
2019-01-17 08:40 cavada@fbk.eu Note Added: 0003559
2019-01-17 08:40 cavada@fbk.eu Status

feedback => assigned

2019-01-17 08:42 cavada@fbk.eu Note Added: 0003560
2019-01-27 15:18 gmamais Note Added: 0003562
2019-01-27 15:18 gmamais Status

assigned => resolved

2019-01-27 15:18 gmamais Resolution

open => fixed

2019-02-13 10:17 maxime Note Added: 0003564
2019-02-13 10:40 cavada@fbk.eu Note Added: 0003566
2019-02-13 10:40 cavada@fbk.eu Status

resolved => feedback

2019-02-13 10:40 cavada@fbk.eu Resolution

fixed => reopened

2019-02-16 09:55 gmamais Note Added: 0003573
2019-03-27 13:27 maxime Note Added: 0003593
2019-03-29 13:13 michal_kurowski_n7s Note Added: 0003601
2019-05-05 14:57 gmamais Note Added: 0003630
2019-05-05 14:57 gmamais Status

feedback => resolved

2019-05-05 14:57 gmamais Resolution

reopened => fixed



Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker