TCP will not have to do reordering.

It does that, there's no way to stop it.

If your application sends (very) small chunks of data, TCP tries to collect them and send them in larger segments. There's a short timeout for collection and when no more data comes from the application, the current TCP segment is sent out. This potentially increases latency and you can use the PSH and URG flags to tell TCP to send each chunk immediately at the possible cost of increased overhead and wasted bandwidth.

If the application already takes care of data segmentation, reordering, congestion control, and delivery confirmation you might want to consider UDP which is easier to control. However, trying to reinvent TCP usually fails.

TCP will not have to do reordering.

It does that, there's no way to stop it.

If your application sends (very) small chunks of data, TCP tries to collect them and transmits them in larger segments. There's a short timeout for collection (200 ms by default, see Nagle's Algorithm) and when no more data comes from the application, the current TCP segment is sent out. This potentially increases latency and you can use the TCP_NODELAY socket option and the PSH flag to tell TCP to send and forward each chunk immediately at the possible cost of increased overhead and wasted bandwidth.

If the application already takes care of data segmentation, reordering, congestion control, and delivery confirmation you might want to consider UDP which allows total control for the application. However, trying to reinvent TCP usually fails.

TCP will not have to do reordering.

It does that, there's no way to stop it.

If your application sends (very) small chunks of data, TCP tries to collect them and send them in larger segments. There's a short timeout for collection and when no more data comes from the application, the current TCP segment is sent out. This potentially increases latency and you can use the PSH and URG flags to tell TCP to send each chunk immediately at the cost of increased overhead and wasted bandwidth.

If the application already takes care of data segmentation, reordering, congestion control, and delivery confirmation you might want to consider UDP which is easier to control. However, trying to reinvent TCP usually fails.

TCP will not have to do reordering.

It does that, there's no way to stop it.

If your application sends (very) small chunks of data, TCP tries to collect them and send them in larger segments. There's a short timeout for collection and when no more data comes from the application, the current TCP segment is sent out. This potentially increases latency and you can use the PSH and URG flags to tell TCP to send each chunk immediately at the possible cost of increased overhead and wasted bandwidth.

If the application already takes care of data segmentation, reordering, congestion control, and delivery confirmation you might want to consider UDP which is easier to control. However, trying to reinvent TCP usually fails.