What are the required mechanisms for a reliable layer over UDP?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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