Home » Eclipse Projects » Eclipse Titan » Message segmentation in the IPL4 test port used in TCP mode(TCP segmentation, IP fragmentation, MTU , MSS, IPL4)
| Message segmentation in the IPL4 test port used in TCP mode [message #1805067] |
Fri, 05 April 2019 08:13 |
|
Basics (MTU, MSS)
Maximum Transmission Unit (MTU) is the largest size in bytes that a certain layer can forward.
The MTU is different for each protocol and medium that we use. Ethernet for example has a MTU of 1500 bytes by default.
This means that a single Ethernet frame can carry up to 1500 bytes of data. On top of this data we add the Ethernet header.
Typical header sizes are 14 bytes for Ethernet (add another 4 bytes if you use 802.1Q tagging).
Below there is a picture with the different MTU fields that you might encounter:
One can see that a typical Ethernet header is 14 bytes, IP is 20 bytes and TCP is also 20 bytes.
The maximum amount of payload that TCP can use is called the TCP MSS (Maximum Segment Size).
This MSS value is the largest amount of data that a host can receive in a single TCP segment.
TCP will usually determine the MSS based on the MTU of Layer 3 (IP layer).
This value is used to set a limit on the payload in order to prevent fragmentation and is sent
in the SYN packet during the 3 way handshake.
The MSS value isn't synchronized between hosts, it can be different for each direction.
TCP segmentation, IP fragmentation
TCP segmentation occurs at layer 4 of the OSI model. TCP will take the data received from the upper layers and separate it into segments.
The header of each segment will include information such as source and destination ports, sequence numbers, acknowledgement numbers, window size,
checksum and others that are necessary for the correct re-ordering of segments at the other end.
It's important to remember here that it is not up to TCP to reassemble the protocol message.
TCP handles a stream of bytes and its' job is to make sure the segments arrive in order(seq, ack) and it does not care about the upper layer protocols.
For instance in the case of a long HTTP response(e.g. download of a large file),
TCP does not know or care where the end of the HTTP message is, because that's the job of the HTTP layer.
The size of the segments depends on several factors. In general, the larger the segments, the more efficient the transmission
(the less overhead from headers). If however, the segment is too big, it won't fit within an IP packet at Layer 3,
and something called IP fragmentation will occur (which can also reduce efficiency).
As for IP fragmentation, the logic is similar. If a TCP segment is encapsulated into an IP packet, this IP packet in turn must be encapsulated into a frame.
The MTU is the maximum size of a frame on the medium.
If an IP packet does not fit in the frame, it must be fragmented for the fragments to be sent separately.
Re-assembly of fragmented IP packets
is done automatically by the IP stack which is used by the IPL4 test port, so there's nothing we need to do.
Re-assembly of messages segmented by TCP
As we have established earlier, the re-assembly of TCP segments is the responsibility of the upper layer protocol.
In the context of Titan this means that if we want to receive complete protocol messages and not segments from a TCP port,
somehow the upper layer will have to help the TCP port in delimiting the messages.
This is being done in the case of the IPL4 test port (used in TCP mode) by registering a callback function that assists in calculating the length of the messages in alignment with the protocol logic.
See the documentation of the IPL4 port for details.
Each protocol module to use TCP as transport will have to have a message length calculation function to be used in this manner.
Some examples:
1.
//register message length function of HTTP with ipl4:
//*************************************************************************
var f_ipl4_getMsgLen getMsg_Func := refers(f_HTTPMessage_len);
f_ipl4_setGetMsgLen(p,v_cid, getMsg_Func, {});
//*************************************************************************
where f_HTTPMessage_len is part of the HTTP protocol declaration
2.
//register message length function of websocket with ipl4:
//*************************************************************************
var f_ipl4_getMsgLen getMsg_Func := refers(f_HTTPMessage_len_ws);
f_ipl4_setGetMsgLen(p,v_cid, getMsg_Func, {});
//*************************************************************************
where f_HTTPMessage_len_ws is part of the Websocket protocol module
3.
//register message length function of HTTP/2 with ipl4:
//*************************************************************************
var f_ipl4_getMsgLen getMsg_Func := refers(f_HTTP2_Message_len);
f_ipl4_setGetMsgLen(p,v_cid, getMsg_Func, {});
//*************************************************************************
where f_HTTP2_Message_len is part of the HTTP/2 protocol module
What happens if we omit to register the callback function? Here's the tricky thing: for short messages you may not notice any difference, as these might not be subjected to segmentation;
but longer messages will not be properly extracted; the user protocol will receive partial messages.
This can be especially devious for protocols typically using short messages, such as MQTT:
it may happen that only a small number of testcases - implying somewhat longer messages - will fail for mysterious reasons.
So to summarize the above:
-if you write a protocol module that will use TCP as transport you will need to add a message length calculation function
-if you use a TCP test port, don't forget to register the above function as your callback
I hope this helps
Best regards
Elemer
[Updated on: Tue, 09 April 2019 09:38] Report message to a moderator |
|
|
Goto Forum:
Current Time: Mon May 13 18:03:04 GMT 2024
Powered by FUDForum. Page generated in 0.03240 seconds |
] 
Search
Help
Register
Login
Home
