| Heads up on the upcoming release of Titan version 6.3.0 [message #1777644] |
Fri, 01 December 2017 09:06 |
|
Dear all,
This is a non-comprehensive list of the larger new features introduced by Titan 6.3.0 to be soon released .
New compiler flags and their recommended usage
As the multiple encoding feature changes the interpretation of codec attributes,
it is a strong compatibility recommendation that you add the "-e" flag to your Makefile:
# Flags for the TTCN-3 and ASN.1 compiler:
COMPILER_FLAGS = -L ...other flags here... -e
Again, this is a legacy requirement, if you start a new project please boldly neglect the -e flag.
If you continue to encounter compilation problems, especially involving ASN.1 files, switch off the generation of OER codecs by using the "-O" flag.
Adding the flags to the Makefile can be done either by editing it manually,
or adding them to a *.tpd (Titan Project Descriptor) file and generating the Makefile either with makefilegen or with Eclipse.
The multiple encoding feature
Variants of the TTCN-3 core language standard published before version 4.9.1 assumed that a certain type can have only one associated codec. This was a sensible assumption for a while, however changes in technology enforced a different approach: to give you an example, web services can use JSON or XML encodings of the same structures interchangeably.
To reflect these changes, ETSI ES 201 873-1 version 4.9.1 published in May 2017 introduced the possibility of multiple encodings for the same type, mixed encodings within a type etc.
see chapter 27: Specifying attributes.
Invoking codecs can be done explicitly, by calling the encoding/decoding function directly buy name, or implicitly, by invoking the encvalue/decvalue function.
As long as there's only one codec for a given type, the type reference
in encvalue/decvalue lead unequivocally to the associated codec; with several possible codecs, a new parameter for encvalue/decvalue is needed to choose between codecs.
Paragraph 4.22.5 of the reference guide charts the differences between the legacy and new codec handling and differences of the implementation compared to the standard.
If a type has only one possible codec, that will be assumed as the default codec for the type. In such a case, encvalue/decvalue and the like ( encvalue_unichar, decvalue_unichar, decmatch, @decoded)
can be invoked without the extra parameter indicating the codec.
OER encoding support in Titan
OER (Octet Encoding rules) was designed to be easy to implement
and to produce encodings more compact than those produced by the Basic Encoding Rules (BER).
In addition to reducing the effort of developing encoder/decoders, the use of OER can decrease bandwidth utilization (though not as much as the Packed Encoding Rules), save CPU cycles, and lower encoding/decoding latency.
OER was published in 2014 as ISO/IEC 8825-7 | Rec. ITU-T X.696: https://www.itu.int/rec/T-REC-X.696/en
see also: http://www.oss.com/asn1/resources/books-whitepapers-pubs/Overview%20of%20OER.pdf
The Titan implementation is described in the Reference guide par. 4.27: OER Encoder and Decoder, also covering unsupported parts of the standard.
OER codec generation can be restricted with the "-O" flag;
OER, as well as BER and the TTCN-3 codecs, can be subjected to negative testing and fuzzing.
Note : support for extension (ellipsis) of ASN.1 structure is not part of 6.3.0; we intend to publish soon a corrective release 6.3.1
that will cover it. Please keep an eye on the changes in github.
Stateful translation ports
The current standard for translation ports describes a stateless port: any message received encoded/decoded and then immediately sent to the upper or lower layer respectively. With a small addition the user can implement full state machines in the translation ports.
As this represents a complex behaviour that might need some clarification I will come back in a later post with examples.
JSON and CBOR encoding
CBOR (or Concise Binary Representation) is a data format that builds on the JSON data model while offering a smaller message size through binary encoding.
This is important e.g. in IoT applications sensitive to memory usage,
energy consumption and so on. CBOR is supported in form of conversion functions json2cbor and cbor2json.
For details please visit the below forum post:
Support for JSON binary encodings in Titan:
CBOR https://www.eclipse.org/forums/index.php/t/1087595/
MongoDB support in Titan
MongoDB is a NoSQL document database that has been enthusiastically embraced by the IoT community.
Support for MongoDB in Titan comes in several parts: BSON serialization of JSON documents (see this forum link)
and the MongoDB protocol module (http://git.eclipse.org/c/titan/titan.ProtocolModules.MongoDB.git ),
-to be used together with a TCP/TLS transport, e.g. the IPL4 test port- representing an implementation of the MongoDB wire protocol : https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/ .
For details, please check:
Support for JSON binary encodings in Titan: BSON
https://www.eclipse.org/forums/index.php/t/1087762/
and
Support for MongoDB (TITAN protocol module of MongoDB wire protocol)
https://www.eclipse.org/forums/index.php/t/1087892/
Best regards
Elemer
|
|
|
Powered by
FUDForum. Page generated in 0.01496 seconds
] 
Search
Help
Register
Login
Home
