Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » Message segmentation in the legacy TCP test port
Message segmentation in the legacy TCP test port [message #1806008] Tue, 30 April 2019 10:59
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1060
Registered: January 2015
Senior Member
Dear all,


we have seen how message segmentation is handled in the IPL4 test port used in TCP mode in a previous post:
Message segmentation in the IPL4 test port used in TCP mode
https://www.eclipse.org/forums/index.php/t/1098375/

In summary, each protocol module using this port will have to have a length calculation function that will have to be registered
as a callback function to the port. When receiving a TCP stream, the port will use this calback to determine
if a complete message can be extracted.

In general, calculating the message length falls into the area of responsibility of the protocol layer using TCP as transport.

If one wonders how does this work in the early implementation of the TCP test port
https://github.com/eclipse/titan.TestPorts.TCPasp

will see that the port deploys a less flexible logic to calculate message limits: information regarding message length has to be supplied in the config file, in form of the following parameters:
( see port documentation)

packet_hdr_length_offset (O)

If there is a protocol above TCP this parameter can be used to specify the offset (in bytes) in the protocol header where the length field starts. This parameter is optional, but should be used together with packet_hdr_nr_bytes_in_length, packet_hdr_byte_order, packet_hdr_length_value_offset and packet_hdr_length_multiplier. These parameters are used to wait for a complete upper layer protocol message by the test port.

packet_hdr_nr_bytes_in_length (O)

If there is a protocol above TCP this parameter can be used to specify the length of the length field (in bytes) in the protocol header. This parameter is optional, but must be used together with packet_hdr_length_offset, packet_hdr_byte_order, packet_hdr_length_value_offset and packet_hdr_length_multiplier. These parameters are used to wait for a complete upper layer protocol message by the test port.

packet_hdr_byte_order (O)

If there is a protocol above TCP this parameter can be used to specify the byte order of the protocol. The possible values are: "MSB" or "LSB".

"MSB" is the default value.

This parameter is optional, but should be used together with packet_hdr_length_offset, packet_hdr_nr_bytes_in_length, packet_hdr_length_value_offset and packet_hdr_length_multiplier. These parameters are used to wait for a complete upper layer protocol message by the test port.

packet_hdr_length_value_offset (O)

If there is a protocol above TCP this parameter can be used to specify the offset (in bytes) of the value length which is added for the length decoded from the message. This parameter is optional, but should be used together with packet_hdr_length_offset, packet_hdr_nr_bytes_in_length, packet_hdr_byte_order and packet_hdr_length_multiplier. These parameters are used to wait for a complete upper layer protocol message by the test port.

packet_hdr_length_multiplier (O)`

If there is a protocol above TCP this parameter can be used to specify the multiplier of the decoded_length_

"1" is the default value.

This parameter is optional, but should be used together with packet_hdr_length_offset, packet_hdr_nr_bytes_in_length, packet_hdr_byte_order and packet_hdr_length_value_offset. These parameters are used to wait for a complete upper layer protocol message by the test port.

Example
Let's see how we could calculate the real message length using the previously introduced parameters:
real_length = packet_hdr_length_multiplier x decoded_length + packet_hdr_length_value_offset,

where decoded_length is calculated from the length field in the message and real_length is the real message length.

If we set the parameters as follows:
packet_hdr_length_offset := "2";
packet_hdr_nr_bytes_in_length := "2";
packet_hdr_byte_order := "MSB";
packet_hdr_length_value_offset  :=  "2";
packet_hdr_length_multiplier := "3";

and the following message arrives from the SUT:
message = 'AAAA**0002**BBBBBBBBCCCC**0002**DDDDDDDD'O

the decoded_length = "2" because the value starts from the 3rd octet while header length offset is 2 octets, the number of bytes in the header is 2 octets and the byte order is MSB. The multiplier is 3 and the value offset is 2 so real_length = "2 x 3 + 2 = 8".

We can see that two messages arrived together and the test port will split them into the following messages:
message1 = 'AAAA0002BBBBBBBB'O
message2 = 'CCCC0002DDDDDDDD'O



I hope this clarifies the issue of message segmentation for those using the legacy implementation of the TCP test port.


Best regards
Elemer
Previous Topic:Add a library C/C++ into project Titan
Next Topic:Eclipse Titan, Cygwin, EPLv2 and GPL
Goto Forum:
  


Current Time: Sat Jul 04 06:34:39 GMT 2020

Powered by FUDForum. Page generated in 0.01475 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top