- for TCP:
TCP is a data stream. In case a too long frame shall be transmitted, the TCP/IP stack fragments it into several single tcp frames of each maximal possible length. There is no transmission of the total frame length. This transport management has to be done by the higher protocol layer that uses TCP.
- for UDP:
In case of UDP a real fragmentation management is done. The TCP/IP Stack builds at reception the received fragments together.
According to the standard, an Ethernet Packet contains max. 1,514 bytes that are allocated like following in case of a UDP frame:
14 byte Ethernet Header + 40 byte IPv6 header + 8 byte UDP header + 1,452 byte UDP data = 1,514 byte Ethernet Frame
If more data shall be transferred, then a fragmentation will automatically be done by the TCP/IP Stack. In this case, there will be an additional 8 byte fragmentation header added after the IPv6 header. Because the fragmented data has to be a multiple of 8 bytes the payload will be reduced to 1,440 bytes Therefor the Ethernet Packets have only a size of 1,510 bytes. In the following IPv6 fragments no UDP header is needed any more so that the payload might then be max. 1,448 byte/fragment.
This small example configuration for IPv6 shows how a client (Client) can send 10,000 bytes data using UDP and how a UDP server (Server) can receive it. The fragmentation is managed on the IPv6 level by CANoe's TCP/IP Stack.
The maximal buffer size for a data frame that can be sent/received by a socket is per default 8,192 byte. Therefor the socket option has to be explicitly adapted for data above this limit, using the CAPL function IpSetSocketOption in both client and server.
It is possible to send UDP frames of maximum 64 Kbytes including the 8 byte UDP header due to the 16 bit field containing the length in the IP header.
The sending function is triggered by key 's' after measurement starts. Because the stack doesn't know which IP address corresponds to the MAC ID, only the last fragment is sent at the first transmission request (typical FreeBSD behavior). In this case the UDP datagram must be sent once more. (UDP is not reliable and gives no guarantee for the delivery of a datagram. This must be handled by the application.)