What are the possible problems when using UDP?

A

Anton2013-12-07 22:43:14

C++ / C#

Anton, 2013-12-07 22:43:14

Good day!

When using sockets over UDP, what are the possible problems?
Should I only care about failed and duplicated packets?
And how would you advise to deal with packets that did not reach?

TCP is not used because it will be a p2p connection. A more or less simple solution with a connection through NAT is UDP hole punching.

Reply

Answer the question

In order to leave comments, you need to log in

3 answer(s)

L

lam0x86, 2013-12-07
@Nirvano

Packets may also be garbled or arrive in the wrong order.
In general, the topic is rather complicated, you can google in the direction of "reliable UDP".

Y

Yuri Yarosh, 2013-12-08
@d00mko

Perhaps you should pay attention to the RTMFP protocol and the Cumulus server .
It uses UDP as the transport.
If you want to write your bike - read rfc, there will be a lot of good ideas.
The design of RTMFP is simply excellent.
In general, there are no normal rtmfp servers now - I somehow wanted to do it myself.
Contact Skype d00mko if interested.

N

nekipelov, 2013-12-08
@nekipelov

> When using sockets, over UDP protocol, what are the possible problems?
This is a rather strange question. If you take it literally, then there is no problem there. These are problems when working with TCP: timeouts, keep-alive, asynchrony or streams... When working with UDP, everything is much simpler: send and forget :-)
> Should I only care about missed and duplicated packets?
It already depends on the tasks. Certainly not reached packets will be. There will be duplicates and reordering. But this is a feature of the protocol, not a problem.
> And how do you advise to deal with packets that have not reached?
We need a reliable protocol, but made over UDP, did I understand correctly? Then you need to look towards projects like enet.bespin.org.There are a lot of things on github by the word rudp, maybe it will work: https://github.com/search?q=rudp. But I didn’t use any such solution, when there was a need, I had to write it myself. I immediately warn you that it is impossible to achieve an efficiency similar to TCP, if only because all the code will work in user-space, and not at the kernel level. And yes, it's a bad job...