Avoiding UDP client-side packet loss

[jupiter11]

Hi,

I'm trying to write a simple UDP client application which receives UDP
packets from a server, each the size of 384 bytes. Unfortunately, I'm
encountring what seems to be client-side packet loss, which gets only worse
when multiple threads are added to the application. This is not a result of
high CPU usage, since the CPU usage is only a few percent. I can only assume
that the packet loss is a result of context switching done by the OS, and my
application not being able to receive the packets on time.
I'm using VC++ on win2k, and the winsock2 functions in the platform SDK to
create a socket and receive UDP packets from a specified port. I've tried
setting the process & thread to time critical, which does have an
improvement, but the packet loss continues.
Is there any way to avoid client-side UDP packet loss ??
Ideas / code examples would be greatly appreciated !


Danny

[DanM]

How much data do you transfer between server and client (bytes/second) ?
Are your socket receive buffers properly sized ?
Can you please post some code ?

Dan

[Major Major]

The solution is to read the packets asynchronously and provide your own buffers to winsock. To ensure no loss of packets you need a number of buffers (I had to use up to 15 buffers in a specific case)

[filthy_mcnasty]

as Major said you probably should use something like
WSAAsyncSelect() and process data through that.

that said however, i have never had a problem with sending or receiving UDP packets up to 4kb. the documented "reliable" packet size is 64kb but i've never chosen to use a packet (with TCP either) greater than 4kb. my point here is that i would imagine something else is going on if you are truely losing packets. using a dialup modem with win98 has not given any different a result than using a T3 line and a winxp machine.

how are you receiving the data now? that might make a difference.

[Major Major]

I have seen such problems, and they are not necessarily due to packet size. There are several reasons:
1. network traffic (On the one side collisions on Ethernet and in slow connections the bandwidth might be taken by other traffic)
2. Hardware unable to handle data coming in bursts.
And I'm sure this is just the beginning of the list..

[filthy_mcnasty]

that was my point. if he's losing packets it's probably due to some external factor.

[jupiter11]

Some more notes regarding the issue :
- I am connected to the server through a cross cable, and there is no other traffic between them, so there is no chance I'm loosing data because of network problems / traffic.
I'm almost certain I'm loosing the packets on the client side, since the packet loss is affected by mouse movement, opening programs, etc...

- The transfer rate is 8Mbps.

- The packet is of fixed size - 384 bytes.

- I've tried using WSARecv with overlapped sockets, and used WSAWaitForMultipleEvents to wait for the receive event, but the packet loss continues. I suspect this might be due to the fact that I'm not getting the packets in the correct order when waiting on the events (comments on this issue would be appreciated).

Major - if you can supply more information / code regarding your solution I'd be very grateful, it sounds like the right direction...

Danny

[DanM]

What is the size of your socket receive buffer(s) ?
If you cannot process the incoming data at the rate it is generated and the buffers are not big enough to accomodate the unprocessed data, you will end up with the IP layer discarding packets (I don't really believe it is a matter of H/W not being able to cope with so much data).

Dan

[jupiter11]

As far as I know, winsock does not buffer UDP packets. I've tried playing with some of the socket attributes and make the buffer larger, but this had no effect at all. Are you sure winsock can buffer UDP packets ? Makes sense it does, but as far as I checked - it dosen't...
If you're certain this can be done, please include some code example of how this can be done...

Thanks.

[DanM]

It does buffer UDP datagrams.
Use setsockopt with SO_RCVBUF.

Dan

[jupiter11]

I tried that, seems to have no effect at all.
Are you certain this buffers UDP packets as well ? Does setting a large buffer with this option assure that there will be no packet loss on the client side ?

[DanM]

Yes, I used it in fact to drop packets (setting it to a lower value) :)
No, there is no guarantee. When you write an UDP application you should also build the logic to handle packet loss. Otherwise, use TCP.

Dan

[Major Major]

Surprise, the solution might be set the rcvbuf size to 0. As far as I remember (it's been a while..) this is the way to make the socket your own buffers.
Anyway, the idea is that instead of using the stack's buffers, you should provide your own buffers. This way you can provide as many buffers as you want and whatever size you need (ok - I guess there must be some limit on the numebr of buffer, but I don't know what it is).

Another idea - can you control the transmitter side? If so try and set some small delay between transmissions and see if that helps. If it does it is possible that there is a problem with the hardware on the receiving side that is unable to handle bursts (it takes longer to process a packet than to send it).

And I must agree with what Dan said: If you work with UDP you MUST be able to handle/accept packet loss. If you see a big amount of packet loss expect some bug, but there is always the chance of packet loss.