Environment: Windows XP Pro and Win 7, Visual Studio 2008, MFC, C++

I have an message application that fetches telemetry data from some hardware, processes it, and sends the data to a display application on a nearby computer. (The display cannot accept UDP.) The packet rate is always at least three per millisecond and sometimes ten. The message app extracts what I call messages from the telemetry stream and sends them out one message to a packet. Some of the messages sent out are longer than the maximum size (MTU). I presume, pretty sure, the OS and Winsock breaks them up into multiple packets and re-assembles them before delivery to the display application.

The application knows which packets will be too large. Because of the nature of the messages it would not be real difficult to create two or more packets for the really long messages and send them out separately. The long messages may contain over 2000 parameters and the protocol between the message app and the display app requires eight bytes per parameter plus standard TCP/IP overhead. That is more than 16,000 bytes for a single message.

Both computers have dual CPUs with quad core each, and there are two gigabyte switches between the two, one on the “telemetry” side of the room and one on the “server” side of the room. With one app running the network usage as seen by either computer is about 2.5% so no sweat on bandwidth.

It would take a moderate programming effort, but once running it would be almost no impact during run time. For the large packets there would be a short for loop calling the send function as needed.

Sometimes there will be two or more copies of my application output data from different streams at one time. Each will be sending from three to ten packets per millisecond.

Question:
Would it be worth the effort to break up the larger packets into smaller ones so Winsock and the OS does not have to do this?