Improving UDP reliability

Question

I am building a small UDP based server. the server is based on .Net and uses the Socket class it self. I'm using completion ports through ReceiveMessageFromAsync, and the async send.

My problem is I'm loosing around 5%-10% of my traffic. Now i understand this is normal, but is there any way of improving this statistic?

It can be buffer/hardware related. http://stackoverflow.com/questions/2402944/why-i-cant-get-all-udp-packets — kevpie, Dec 14 '10 at 14:17

score 4 · Accepted Answer · edited May 23 '17 at 12:18

4

You might want to look at the answers to this question before rolling your own reliability layer on top of UDP... What do you use when you need reliable UDP?

Alternatively you can try and increase the amount of data that gets through by making the socket's send and recv buffers as large as possible by setting the appropriate socket options before you start to recv.

edited May 23 '17 at 12:18

Community

1
1

answered Dec 14 '10 at 15:21

Len Holgate

21,282
4
45
92

increasing the buffers helped some what. – AK_ Dec 14 '10 at 17:06
If you're using async reads then post several of them at once, that will also likely help... – Len Holgate Dec 14 '10 at 17:10

score 3 · Answer 2 · answered Dec 15 '10 at 03:39

Ensure that you do not send UDP datagrams larger than the path MTU (which is typically no more than ~1400 bytes, and sometimes less). Such packets will be fragmented into multiple IP packets and reassembled at the destination - and if any one of those fragments is lost, then the entire UDP datagram will be discarded.

This has an amplification effect on the packet loss rate - this table shows how the UDP datagram loss rate goes up dramatically as the number of fragments used to carry it increases:

Underlying Fragment Loss Rate: 1.00%

Fragments   UDP Datagram Loss Rate
--------------------------------------
1           1.00%
2           1.99%
3           2.97%
4           3.94%
5           4.90%
6           5.85%
7           6.79%
8           7.73%
9           8.65%
10          9.56%
15          13.99%
20          18.21%
30          26.03%
40          33.10%

score 1 · Answer 3 · answered Dec 29 '10 at 04:47

Windows architecture for sockets seems to be adverse to good UDP performance from multiple copying of packet buffers from the kernel through protocol handlers to the application. MSDN seems to prefer pointing developers to the Winsock Kernel (WSK), replacing the former Transport Driver Interface (TDI), if they want reasonable datagram performance such as implementing a reliable UDP protocol.

However it might just be non-stellar Windows drivers for your NIC hardware, for I see great performance on Linux with Broadcom hardware but less than 25% of the performance in Windows. Some of this I can see is due to lack of transmit interrupt coalescing, Windows performance monitoring always reports 0 coalesces for transmits but a variable range for receives. On Linux I can tune the coalescing and see distinct performance changes. The driver software from Broadcom only appears to support transmit coalescing on later hardware releases.

Coalescing means that packets are being sent in batches into and out of the NIC, batching packets will usually mean lower CPU usage and less chance of dropping due to full buffers or other system activity.

So whilst it looks like it would be impractical to change OS you can try different hardware to minimize the impact of limited drivers.

score 0 · Answer 4 · answered Dec 14 '10 at 14:05

0

About all you can do is something on the same general order as TCP uses -- keep track of which packets were received, and send back something to ACK/NAK packets to get those that didn't arrive re-sent.

answered Dec 14 '10 at 14:05

Jerry Coffin

476,176
80
629
1,111

im kinda doing that. it's aside the point. loosing traffic is not a real problem for me, i just want to minimize the amount of traffic im loosing. – AK_ Dec 14 '10 at 14:08
@acron: no, it doesn't. If you did *exactly* the same as TCP, it might negate the point -- but there's room for lots of variations that maintain nearly the latency of normal UDP, while giving nearly the reliability of TCP. One source of possibilities is to look at old modem-based file-transfer protocols (e.g., ymodem, ymodem-G, zmodem, etc.) These all worked, and most were heavily optimized to keep from adding latency like TCP does (at the expense of greater complexity, especially in the case of zmodem). – Jerry Coffin Dec 14 '10 at 14:12
@Hellfrost: there's not really *much* you can do to reduce packet loss. If you want to badly enough, you can play around with router tables to try to find more reliable links, but 1) it's complex, and 2) over the Internet, you usually don't control enough of the route to make a significant difference anyway. – Jerry Coffin Dec 14 '10 at 14:16

score 0 · Answer 5 · answered Dec 15 '10 at 23:10

Another aspect of reducing packet loss is to mediate the rate at which you send packets. If you are sending data faster than the bottleneck point on the path can handle, this will become apparent as dropped packets. Even if your average data rate is quite low, you may still be sending bursts of packets in quick succession.

TCP handles this by limiting the number of outstanding, unacknowledged data bytes to a value called the congestion window. The congestion window starts off small, and is slowly increased until packet loss occurs, at which point it is scaled back (progressively more so if packet loss continues to occur). You could implement something similar, if in your protocol the sender is notified of packet loss.

Improving UDP reliability

5 Answers5

Linked