1

I'm working on reliable UDP networking and I have to know something. I think UDP reliable algorithm works like that (IDK, I guess);

  • Server send: (header:6)abcdef
  • Client receive: (header:6)abdf, sends back "I got 4 data, they are abdf"
  • Server send: (header:2)ce
  • Client receive: (header:2)ce, OK I'm going to combine them!

Now is this true way to reliable UDP?

EDIT (after answer, maybe this can be helpful for someone): I'm goint to use TCP because reliable UDP is not a good way to handle my operations. I'll send position like un-important, temporal variables. Maybe if I create a algorithm for reliable UDP, this reliable process will took 3-4 UDP send-recv that means I can send 3-4 other unreliable position data at this time and I'm sending small datas which is can be more efficiency than reliable UDP.

Brian Roach
  • 76,169
  • 12
  • 136
  • 161
MonoLightGS
  • 25
  • 5
  • As a note, on most OS implementations UDP will not give you a partial packet. You'll either receive all parts of it, or none of it. Note, the order of individual packets is not guaranteed, or even that you'll get a packet at all. – Dave S Jul 29 '13 at 20:44
  • @DaveS Data can completely be lost! Thanks. – MonoLightGS Jul 29 '13 at 20:47
  • 2
    If what you want is a reliable datagram-oriented protocol, consider [SCTP](http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol). – Brian Cain Jul 29 '13 at 20:50
  • I think this is called the Traveling Byzantian Problem or something like that. Basically, if your response gets lost, too, then your protocol breaks down. Look how TCP works for an inspiration for reliable communication over an unreliable medium. – Kerrek SB Jul 29 '13 at 21:02

3 Answers3

2

The "true way" to get reliable UDP is to use TCP.

If you still want to do it over UDP, you can verify the integrity of the message by sending a checksum with the message, and then recalculating the checksum at the other end to see if it matches the checksum you sent.

If it doesn't match, request the packet again. Note that this is essentially reinventing TCP.

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
1

Well, even with:

- Client receive: (header:6)abdf, sends back "I got 4 data, they are abdf"
- Server send: (header:2)ce

what if server will not receive your response (which may happen in UDP)? So switching to TCP is much better option, if you're not concerned about speed of connection.

zoska
  • 1,684
  • 11
  • 23
0

Your problem sounds like it's tailor-made for the Data Distribution Service.

I'll send position like un-important, temporal variables

In fact, location ordinates are the popular examples for many of its vendors. RTI has a demonstration which goes well with your use case.

Yeah, a lot of folks groan when they hear "IDL" but I'd recommend that you give it a fair shake. DDS is unlike very many popular pub-sub/distribution/etc protocols in that it's not a simple encapsulation/pipeline.

I think the really cool thing is that often a lot of logic and design elements go into the problem of "how do I react the underlying network or my peer(s) misbehave(s)?" DDS offers a quality of service negotiation and hooks for your code to react when the QoS terms aren't met.

I would recommend against taking this decision lightly, it's a good deal more complex than TCP, UDP, AMQP, etc. But if you can afford the complexity and can amortize it over a large enough system -- it can pay real dividends.

In the end, DDS does deliver "reliable" messages over UDP. It's designed to support many different transports, and many different dimensions of QoS. It's truly dizzying when you see all the different dimensions of QoS that are considered by this service.

Brian Cain
  • 14,403
  • 3
  • 50
  • 88