Reduce the Probability of Message Fragmentation Across Multiple TCP Packets

The CME requires that TCP packets contain only complete SBE messages. Otherwise, fragmented messages go to additional processing, leading to latency degradation, and finally, the CME can terminate the session with the ExceededMaxNoOfSplitMsgsQueued (29) error code. To reduce the probability of SBE message fragmentation across multiple TCP packets, one can apply the following options:

• Limit the message's rate to avoid the appearance of pending messages due to overflow issues. To limit the message's rate, one can use the OnixS::CME::iLink3::Session::throttle() method. More details can be found on the Message Throttling page. To control that there are no pending messages in the Handler's outgoing buffer, one can use the OnixS::CME::iLink3::Session::outboundQueueBytes() method. If this method returns a large value and this value is increasing in time, then there is an overflow issue, and it makes sense to wait to send messages until this value is decreased.
• Use the batch send method to send a few messages at once. This method is more efficient for batch sending and have the maxPacketSize parameter. This parameter represents the maximum number of bytes written to the socket's send buffer together. The reduction of this value reduces the probability of fragmentation. This parameter's default value equals the CME's MTU (1420) and should work in most cases. However, it makes sense to try different values to find an optimal one. Additionally, please note that the OnixS::CME::iLink3::Session::messageGrouping setting contradicts the usage of batch sending, so you should not use it together.
• Keep the setting of network/kernel MTU/MSS equal to CME's (1420) and make sure that there are no routers on the way with different MTU sizes. Usually, MSS is set automatically based on minimum MTU and MSS announced by hosts during the TCP three-way handshake. But, if necessary, one can configure it at the system level via the network interface.

Note

All options above cannot 100% guarantee that there will not be message fragmentation.

The fragmentation can appear on the TCP level due to the TCP protocol's nature (stream protocol) since it is unaware of the message size and sends just bytes. Therefore, in case of any overflow issues on the TCP connection, the TCP level can send a part of the outgoing message.