Windows, UDP packets silently dropped

0
votes

I have read a lot about my particular issue and how it is related to buffers, but I am not certain I am having that kind of issue. Here's why:

I have a UDP client/server program I wrote running. I am on Windows 7, this has been tested on a couple of Windows server OS's as well all with the same effect.

I open a UDP connection between the client and server, and basically what happens is the client sends a request for information (Wireshark says the packet is 126 bytes in size) and the server receives it. The client now stays silent waiting for a reply. The server builds the response and sends it (usually between 200-600 bytes) and then waits for another request. There are no other communications happening between the client and server at all, and it always follows this sequence.

Both client and server have threads dedicated to transmit and receive (so two threads) which immediately dump the packets into a buffer for consumption, speed here does not seem to be an issue.

This runs flat out, I put a not-too-accurate delta count on incoming packets to the server and the server says on average we receive a new request every 15ms. So the turnaround time is very fast for the response which is nice.

However, the 328th packet is being dropped silently on the server, it never reaches us. However, I have a rudimentary 6 second retry timer for the request which always succeeds. If I continue to run the problem persists, a few packets go fine, then one is dropped, a retry 6 seconds later, and all is well. A restart of the server fixes the issue.

UDP buffers, changing this has zero effect. I allocated 10x the space it has by default yet same effect, same packet. I am not using MSG_PEEK on the receive function so the data should be extracted every time I request it.

If I add a delay to the client traffic when sending, the issue clears right up. I have not yet dialed in a value for the timeout, but both 1 second and half a second cause the problem to clear up so far.

This seems to be related to the volume of traffic? Is that a thing? I can't imagine my buffers are getting clogged here seeing as I don't actually receive that much and I clear out the buffer almost immediately. Am I tripping over some kind of flood protection here?

All firewalls and AV programs are completely disabled.

1
c++windowssocketsudp
Where exactly is the packet lost ? On the network ? The server OS ? The server software ? Reading your description, it looks like the packet is lost on the server software. This probably means there is a bug in the server code, but there isn't any information to help on this point. – ElderBug
Ah sorry, the packet is being dropped on the server side. The client retries and all works well. The packet is never received from the Windows IP stack at all, it is just lost/discarded. I was able to confirm this by reading out a certain unique ID in each packet and dumping it to an array. The ID's of the lost packets never appear. The thread code for the receive simply sits there and when the event is signaled it extracts the packet from the stack and passes it to an internal queue for processing while the thread waits for more. – Radius
Oh maybe I should point out the packet appears in Wireshark on the server side. That is how I know it is being sent to the server as well. – Radius
But you confirm that the raw network API call doesn't receive the packet at all ? It's not just the internal queuing that fails ? – ElderBug
I have confirmed I never receive the packet from the API call. I have a unique ID for each packet, and a bit of test code in client and server stores a list of all traffic in and out. The unique ID of the packets never show up on the server. So if the client sends ID 1, 2, 3, the server says it received 1, 3 for example. 2 is lost somewhere and yet Wireshark sees it. – Radius

1 Answers

1
votes

TCP supports transmit pacing and dropped datagram detection with retransmission and exponential backoff. If you need these features when using UDP, you have to implement them yourself.

If you need all, or almost all, of the features that TCP provides, using UDP is a huge mistake. It's unlikely in the extreme that you'll be able to implement them better than TCP does, considering that TCP has been developed and optimized by top experts both in network communication and in the details of your platform.