1

I've been working on writing my own networking engine for my own game development side projects. This requires the options of having unreliable, reliable, and ordered reliable messages. I have not, however, been able to identify all of the mechanisms necessary for reliable and ordered reliable protocols.

What are the required mechanisms for a reliable layer over UDP? Additional details are appreciated.

So far, I gather that these are requirements:

  • Acknowledge received messages with a sequence number.
  • Resend unacknowledged messages after a retransmission time expires.
  • Track round trip times for each destination in order to calculate an appropriate retransmission time.
  • Identify and remove duplicate packets.
  • Handle overflowing sequence numbers looping around.

This has influenced my architecture to have reliable message headers with sequences and timestamps, acknowledge messages that echo a received sequence and timestamp, a system for tracking appropriate retransmission times based on address, and a thread that a) receives messages and queues them for user receipt, b) acknowledges reliable messages, and c) retransmits unacknowledged messages with expired retransmission timers.

NOTE: Reliable UDP is not the same as TCP. Even ordered reliable UDP is not the same as TCP. I am not secretly unaware that I really want TCP. Also, before someone plays the semantics games, yes... reliable UDP is an "oxymoron". This is a layer over UDP that makes for reliable delivery.

Qantas 94 Heavy
  • 15,750
  • 31
  • 68
  • 83
Sion Sheevok
  • 4,057
  • 2
  • 21
  • 37

3 Answers3

2

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

I'd add 'flow control' to your list. You want to be able to control the amount of data you're sending on a particular link depending on the round trip time's you're getting or you'll flood the link and just be throwing datagrams away.

Community
  • 1
  • 1
Len Holgate
  • 21,282
  • 4
  • 45
  • 92
  • Aye, I'd seen the question. Alas, the majority of the answers don't give any suggestions as to how to implement reliability or open source examples of reliable layers on top of UDP. UDT looks to be one option to research though. – Sion Sheevok Feb 20 '11 at 09:44
  • ENet's free, it doesn't cover everything and the code can be a bit hard to get into but it's good and works... – Len Holgate Feb 20 '11 at 12:37
  • 1
    If you want to develop your their OWN reliable UDP then you should definitely take a look at the Google QUIC spec as this covers lots of complicated corner cases and potential denial of service attacks. I haven't played with an implementation of this yet, and you may not want or need everything that it provides, but the document is well worth reading before embarking on a new "reliable" UDP design. A good jumping off point for QUIC is http://blog.chromium.org/2013/06/experimenting-with-quic.html, and do read the QUIC design doc. – Len Holgate Aug 01 '13 at 08:57
1

Note that depending on the overall protocol, it might be possible to dispense with retransmission timers. See, for example, the Quake 3 network protocol.

In Q3 reliable packets are simply sent until an ack is seen.

Nuoji
  • 3,438
  • 2
  • 21
  • 35
0

Why are you trying to re-invent TCP? It provides all of the features you originally stated, and has been show to work well.

EDIT - Since your comments show that you have additional requirements not originally stated, you should consider whether a hybrid model using multiple sockets would be better than trying to fulfill all of those criteria in a single application-layer protocol.

Actually it seems that what you really need is SCTP.

SCTP supports:

  1. message based (rather than byte stream) transmissions
  2. multiple streams over a single netsock socket
  3. ordered or unordered receipt of packets

... message ordering is optional in SCTP; a receiving application may choose to process messages in the order they are received instead of the order they were sent

Alnitak
  • 334,560
  • 70
  • 407
  • 495
  • 2
    Another common misconception. TCP != Reliable UDP. TCP is stream based, TCP can't multi-cast or broadcast, TCP is always ordered, always reliable. I do not need all of those features, all the time, for every message. I even want to be able to have different sets of ordered reliable messages: Messages that are ordered relative to each other, but not ordered relative to another set of messages that might be relative to each other. – Sion Sheevok Feb 19 '11 at 23:01
  • Yes, I know the difference. However all of the specific requirements you listed are solved by using TCP instead of UDP. You didn't mention broadcast or multicast in your question. – Alnitak Feb 19 '11 at 23:08
  • TCP does not offer unreliable, reliable, and ordered reliable messages, the three requirements I'm looking for in a the application level protocol I'm implementing. It only offers one of those three requirements and does so by offering a single channel. I do not need multicast or broadcast at this time, but was simply listing various differentiating factors between TCP and a reliable UDP layer. – Sion Sheevok Feb 20 '11 at 09:48