4

I know the protocol doesn't support this but is it common for clients that require some level of reliability to build into their application a method for requesting retransmission of a packet if found to be corrupt?

edwinNosh
  • 389
  • 3
  • 9
  • 16

4 Answers4

7

It is common for clients to implement reliability on top of UDP if they need reliability (or sometimes just some reliability) but not any of the other things that TCP offers, for example strict in-order delivery, and if they want, at the same time, low latency (or multicast, where it works).

In general, you will only want to use reliable UDP if there are urgent reasons (very low latency and high speed needed, e.g. for a twitch game). In every "normal" case, simply using TCP will serve you equally well or better.
Also note that it is easy to implement your own stack on top of UDP that performs worse than TCP.

See enet for an example of a library that implements reliability (and some other features) on top of UDP (Raknet or HawkNL would be other examples).

Alexis Wilke
  • 19,179
  • 10
  • 84
  • 156
Damon
  • 67,688
  • 20
  • 135
  • 185
  • 4
    +1 just for **Also note that it is easy to implement your own stack on top of UDP that performs worse than TCP.**, that's just too true. – Konerak Mar 30 '11 at 11:49
  • One reason for using UDP, though, is for distribution, where you send one packet to a group of listeners. In that case, TCP is not practical since you could otherwise have to repeat the same packet many times. – Alexis Wilke Mar 28 '18 at 00:27
3

You might want to look at the answers to this question: What do you use when you need reliable UDP?

Community
  • 1
  • 1
Len Holgate
  • 21,282
  • 4
  • 45
  • 92
2

Of course. You can build a reliable protocol (like TCP) on top of UDP.

Example

Imagine you are building a fileserver: * read the file using blocks of 1024 bytes * construct an UDP packet with payload: 4 bytes for the "position" in the file, 4 bytes for the "length" of the contents of the packet.

The receiver now receives UDP packets. If he gets following packets: * 0-1024: DATA * 1024-2048: DATA * 3072-4096: DATA

it realises a packet got missing, and asks the sending application to resend the part between 2048 and 3072.

This is a very basic example to explain your application code needs to deal with the packet construction and payload interpretation. Don't use it, it does not take edge cases (last packet, checksums for corrupted packets, ...) into account.

Alexis Wilke
  • 19,179
  • 10
  • 84
  • 156
Konerak
  • 39,272
  • 12
  • 98
  • 118
  • This is building a protocol on top of UDP. This isn't adding a mechanism to request retransmission upon a failed checksum. I'm interested in knowing if there is a way to request retransmission from the sender via UDP? – edwinNosh Mar 30 '11 at 11:52
  • No, UDP is send and forget. If you want the sender to store the packets and treat resend-requests, you have to implement it yourself. – Konerak Mar 30 '11 at 12:06
  • And that is what I was trying to explain: you start with bare UDP, and you implement all the extra features you need yourself. You can take this to the point where you have a full TCP implementation. – Konerak Mar 30 '11 at 12:08
  • But how would it be possible to recover a lost packet if UDP doesn't make a copy after sending. From a client perspective it would be lost and you cannot retrieve it? – edwinNosh Mar 30 '11 at 12:42
0

Short answer: No.

Long answer: UDP doesn't care for packet loss. If an UDP packet arrives and has a bad checksum, it is simply dropped. Neither the sender of the packet is informed about this, nor the recipient is informed. It is only dropped, that's all that happens. Also UDP packets are not numbered, so if you send four packets and only three arrive at the recipient, the recipient cannot know that there used to be four and one is missing. Last but not least, packets are not acknowledged, so the sender will never know if a packet it was sending out ever made it to the recipient or not.

Contrary to this, TCP breaks data into segments, each segment is numbered, so the recipient can know if a segment is missing. Also all segments must be acknowledged to the sender. If the sender receives no acknowledgment for a segment after a certain period of time, it will assume the segment was lost and send it again.

Of course, you can add an own frame header on top of every data fragment you sent over UDP, that way your application code can number the sent fragments and you can implement an acknowledgement-resent strategy in your code but the question is: Will this really be better than what TCP is already offering for free? Even if it would be equally good, save yourself the time and just use TCP. A lot of people already thought they can do better than TCP and usually they realize in the end, actually they cannot. TCP has its weaknesses but in general it is pretty good at what it does.

Mecki
  • 125,244
  • 33
  • 244
  • 253