Windows/Winsock UDP packets are being grouped together?

Question

I have a test application in C++ and C where a client is constantly bombarding a server with the last number that the server sent it, when the server receives one of these packets it increments the number once and then sends the new number to the client, what happens is the client is always 1 number behind the server on a local machine where both the client and server are running from, which is totally expected.

This is fine when recvfrom and sendto expect and send 9328 byte packets, however when I drop the size of the packets to 256 the client is always 33 counts out of sync, when the client is sending a 44 byte packet and the server expects 256 bytes the client is always 212 counts out of sync, every time without fail on the same machine.

I am sending these packets using the LAN IP address, the client and server are on the same machine listening through ports 3000 and 2000 respectively.

The client sends packets at the server as fast as it can. The server will only send an updated count to the client when it receives a packet.

Interestingly, when I close the client the server still processes the packets that the client has sent, so I'm guessing this is an OS bombardment protection or Windows grouping lots of small UDP packets together into one 9328 byte UDP packet.

How can I send < 256 byte packets without this happening? I want to avoid packet fragmentation as much as I can during the packet's journey so keeping a small size is a requirement for when it enters and leaves some certain hardware.

Can you show some code, relevant to where you think the problem may be hiding? That will help to troubleshoot the issue. — ryyker
I think the problem is within the operating system I managed to resolve it by setting the buffer sizes of sending and receiving to zero. Are there any negative effects to this? How can I answer my own question? — Felix Jones
The device driver has internal buffers which will concatenate packets together so yes setting the buffers to 0 will prevent this (and slightly speed up transition times) the downside is more expensive sends per packet and the chance to miss packets if you're not fast enough. To answer just add an answer and accept it. — Serdalis
Thank you, could you expand on what you mean with "more expensive sends per packet"? — Felix Jones
This is the behavior of TCP, not UDP. You also can't send a 9328 byte packet with UDP. Easy mistake :) — Hans Passant

Felix Jones Felix Jones · Accepted Answer · 2013-09-25T22:17:57

These 3 lines will disable the packet buffer by setting it's size to zero.

const int size = 0;
setsockopt( sd, SOL_SOCKET, SO_SNDBUF, ( const char * )&size, sizeof( int ) );
setsockopt( sd, SOL_SOCKET, SO_RCVBUF, ( const char * )&size, sizeof( int ) );

Keep in mind that doing this means packets won't be stored after receiving them, so packets are more likely to be missed if the receiving end is not listening often enough.

Windows/Winsock UDP packets are being grouped together?

1 Answers