Home » Eclipse Projects » Eclipse Titan » The binary RAW encoder of Titan : part I(Basic principles)
| The binary RAW encoder of Titan : part I [message #1710497] |
Wed, 07 October 2015 07:52 |
|
Greetings,
We have seen in the previous posts that an ASN.1 protocol specification consists of two parts: an abstract syntax, which declares the structures used in messaging, and a transfer syntax, which describes how the above structures will be transferred over the wire in a binary form. For ASN.1 , standard binary codecs, such as BER or PER , the latter offering compression, can be used.
For TTCN-3 , we are facing exactly the same problem: the message structures can be comfortably described by the language;
on the other hand , the standard leaves the encoding/decoding of these structures to the latitude of implementors.
A large part of the protocols fall in the category of protocols with tabular description, meaning that the messages are represented in form of a table
( I'm sure each of you have seen at least one of these, IP being probably the most well known; RFCs abound with such tables). This table offers both a structural representation and encoding instructions. Now that we are here, let me add that this is probably not the best way to represent a protocol; in my opinion , formal schemas should be preferred whenever possible, as they leave less room to interpretation and ambiguities.
However, formal schemas are usually part of a more lengthy standardization process, which means less time to market, less flexibility etc. so we have to live with what we have been given.
Back to the tables: the structural part can be easily represented in TTCN-3, but what should we do with the encoding instructions?
In a first approach, these instructions can be embodied into external functions written in C++: if the function is called with a value of type MyType, the function will execute the steps needed to represent the value in binary form. An external function declaration in the TTCN-3 code will connect the abstract part and the transfer part.
Although technically correct, this solution suffers of two issues at least: first, a new codec has to be produced manually for each new type to be encoded.
Secondly, the structural and encoding instructions are disconnected: one has to look into the TTCN-3 code and the encoding function simultaneously to be able to trace the process for e.g. debugging purposes. Possible, but not convenient.
A lot more flexible solution, which Titan adopted, is to decorate the TTCN-3 structures with encoding instructions, which are compiled by Titan, thus generating codecs automatically.
As in the above case, an external function declaration to connect to the generated code is still needed, but that's all. Pure genius , isn't it?
Well, this is too rooted in ASN.1s ECN (Encoding control notation) , which also describes such a controllable encoder/decoder.
For example, the encoding instructions for an integer could look like this:
{
module MyModule
type integer INT1
with {
variant "COMP(signbit)";
variant "FIELDLENGTH(8)"
}
}
with { encode "RAW" }
where FIELDLENGTH specifies the length of the encoded type in bits
and COMP specifies the type of encoding of negative values
so a value
will be encoded as:
with a leading sign bit
The module containing the type declarations has to have an attribute 'encode "RAW"'.
As the structures and encoding instructions appear together, following the encoding is a lot easier. To permit Titan to distinguish between structural and encoding instructions, for the latter the standardized "variant <attribute>" mechanism is used. This also permits code portability: a different implementation than Titan can simply ignore these attributes.
Of course, if for any reason the built-in auto-generated codec is not sufficient, the possibility to write a custom one still exists, only the external function declaration has to be pointed towards the custom piece of code.
So the workflow of translating a tabular protocol into TTCN-3 of Titan is that first the structural info has to be coded into corresponding TTCN-3 structures; than this has to be decorated with appropriate encoding instructions, and finally the external function declaration has to be added.
Next , we will look into the possible attributes in detail. An extensive description of these can be found in the Titan reference guide.
Regards
|
|
|
Goto Forum:
Current Time: Sat Apr 27 01:27:47 GMT 2024
Powered by FUDForum. Page generated in 0.02826 seconds |
] 
Search
Help
Register
Login
Home
