Protocol Buffers support in TTCN-3 Titan

Question

Greetings.
ASN.1 is a language for describing structured information and the way this information is sent across dissimilar communication systems. The structured information is encoded in binary. ASN.1 used to be popular in telecommunications but nowadays is not considered to be cool. In comparison, Protocol Buffers are a mechanism to describe structured information and encoding it in binary, and yes, unlike ASN.1 ,Protocol Buffers are hot.
For years, the Earth was ruled by so called human-readable protocols , such as XML and JSON. It appears that humanity got bored of reading all that stuff, so we experience a return to binary encodings. (Either that, or machine-to-machine communication outweighs machine-to-human, and machines don't want us to meddle.)
Anyhow, let's see how Protocol Buffers are supported in the Titan implementation of TTCN-3.
Support comes in the form of scripts, PBPMG.sh and PBPMG.awk (see https://github.com/eclipse/titan.ProtocolModules.ProtoBuff )
(where PBMG resolves as Protocol Buffer Protocol Module Generator -the PBPMG is currently based on the version 2.5.0 version of the Google Protocol Buffers);
the PBMG.sh , when invoked, generates the TTCN-3 equivalent of the ProtoBuff file:
For example
PBPMG.sh protobuf.proto
where the content of protobuf.proto is:
package protobuf;
message Request {
required int32 command_id = 1;
required int32 request_data_length = 2;
required bytes request_data = 3;
optional bytes attachment = 4;
repeated string properties = 5;
message Response {
required int32 command_id = 1;
required int32 response_status = 2;
required int32 response_data_length = 3;
required bytes response_data = 4;
optional bytes attachment = 5;
repeated string properties = 6;
will generate the following protobuf.ttcn file:
// TTCN-3 module generated from protobuf.proto
module protobuf {
// imports
import from ProtoBuff_Types all;
// public imports
// encoder/decoder function declaration
external function f_encode_protobuf_Request(in protobuf_Request pdu) return octetstring
external function f_decode_protobuf_Request(in octetstring pdu) return protobuf_Request
external function f_encode_protobuf_Response(in protobuf_Response pdu) return octetstring
external function f_decode_protobuf_Response(in octetstring pdu) return protobuf_Response
// definitions for enums
// definitions for messages
type record protobuf_Request{ // Request
int32 command_id,
int32 request_data_length,
bytes request_data,
bytes attachment optional,
record of string properties
type record protobuf_Response{ // Response
int32 command_id,
int32 response_status,
int32 response_data_length,
bytes response_data,
bytes attachment optional,
record of string properties
plus the codecs protobuf_EncDec.cc, protobuf_EncDec.hh.
The codecs are not based on the built-in binary codec , they are custom functions.
Now we have everything to represent and encode/decode Protocol Buffers structures.
module protobuff_test {
// imports
import from ProtoBuff_Types all;
import from protobuf all;
template protobuf_Request t_Request:= { // Request
command_id := 10,
request_data_length:= 20,
request_data := 'AABBCCDDEEFF'O ,
attachment:= 'AAAAAABBBBBB'O ,
properties := {"AA","BB"}
template protobuf_Response t_Response:= { // Response
command_id := 10,
response_status:= 100,
response_data_length:= 20,
response_data := 'AABBCCDDEEFF'O ,
attachment:= 'AAAAAABBBBBB'O ,
properties := {"AA","BB"}
control
log(f_encode_protobuf_Request(valueof(t_Request)))
log(f_decode_protobuf_Request(f_encode_protobuf_Request(valueof(t_Request))))
log(f_encode_protobuf_Response(valueof(t_Response)))
log(f_decode_protobuf_Response(f_encode_protobuf_Response(valueof(t_Response))))
The above code, when extracted, compiled and executed:
cd ProtoBuff
cd /bin
../install.script
make
./proto
will encode/decode back and forth the messages , as seen in the log file:
13:12:06.020216 protobuff_test.ttcn:30 Execution of control part in module protobuff_test started.
13:12:06.020256 protobuff_test.ttcn:33 '080A10141A06AABBCCDDEEFF2206AAAAAABBBBBB2A0241412A024242'O
13:12:06.020345 protobuff_test.ttcn:34 { command_id := 10, request_data_length := 20, request_data := 'AABBCCDDEEFF'O, attachment := 'AAAAAABBBBBB'O, properties := { "AA", "BB" } }
13:12:06.020405 protobuff_test.ttcn:36 '080A106418142206AABBCCDDEEFF2A06AAAAAABBBBBB3202414132024242'O
13:12:06.020448 protobuff_test.ttcn:37 { command_id := 10, response_status := 100, response_data_length := 20, response_data := 'AABBCCDDEEFF'O, attachment := 'AAAAAABBBBBB'O, properties := { "AA", "BB" } }
13:12:06.020489 protobuff_test.ttcn:37 Execution of control part in module protobuff_test finished.
Using the appropriate transport, Protocol Buffers messages encoded in binary can be sent across to other machines that can understand the lingo.
Makefile was generated with
makefilegen -s -e proto *.ttcn *.cc *.hh
Best regards
Elemer

Answer 1

Hi Jeff,
Are you using JDevelopers internal client? The internal client does not support all authentication methods just the most popular ones (ext, pserver, ssh2).
If you select an external cvs client in preferences on the Versioning -> CVS page :sspi should now be one of the default access methods.
Thanks,
Geoff