static boolean isMoreRecentInSequence( int previous, int current )
{
return current – previous > 0;
}

stupid me

btw. in case your language of choice doesn’t support unsigned types (e.g. java/scala) or you simply try to avoid them (http://anteru.net/2010/05/17/736/):

static boolean isMoreRecentInSequence( int previous, int current)
{
return ( current > previous && current-previous >= 0 ) ||
( current < previous && previous-current < 0 );
}

http://udt.sourceforge.net/

Also check out the papers on the site for a description of their congestion avoidance algorithm

As presented in this article, the ack bitfield starts with ack – 1, but in reality the ack bitfield should start at ack. Otherwise, it’s possible for the first few packets being sent out indicating acks where nothing was really acked at all, which can mess up reliable event queues driven by this system.

In other words, if you have a 16|16|32 header as described in this article, you can really only represent 32 acks per-packet, not 33.

cheers

When I said that TCP uses a sliding window vs. what is done in this article, I meant only to highlight a few differences between what is presented in this article compared with TCP sequence numbers and acks.

This article assumes a constant bidirectional rate of packets being sent. This is why the sequence/ack/ackbits header works. It breaks down if you don’t have a constant stream of packets.

Because of the constant flow assumption, this algorithm keeps sending packets even when the other side is not responding. The idea is that any lost data can be resent in a new packet (with a new sequence number). This is different from TCP, which will resend a specific packet with the same sequence number and gives much finer-grain control to the application over how it chooses to resend lost data (if at all).

The cost of this flexibility is that it is possible to “lose” acks. In other words for a packet to get through, but for the sender to not receive the corresponding ack! Making the ack bitfield wider lessens the chance of this occuring, and theoretically you could dynamically widen the ack bits in the header to make losing acks impossible, assuming some finite timeout value, but in general if you have about 2 seconds of redundant acks in my experience I’ve found that is enough for average network conditions (so consider widening the ack bitfield in this article to 64, IMO)

In summary, the algorithm presented in this article is designed for constant flows and does not have any congestion avoidance or flow control built in. It’s useful for situations when you can make assumptions about minimum bandwidth and maximum latency (eg. console games, PC broadband games). Also, you need to be aware that it’s possible, although rare, for the sender to not receive an ack for packets that actually got through, resulting in redundantly resending data (and an additional bandwidth cost per-unit of data sent, in order to filter out duplicates events etc.)

cheers

Could you elaborate a little more on when it is good or bad to use a sliding window?

Under “Reliable Acks” section you were talking about this:

“So in our reliability system, we never resend a packet with a given sequence number. We sequence n exactly once, then we send n+1, n+2 and so on. We never stop and resend packet n if it was lost, we leave it up to the application to compose a new packet containing the data that was lost, if necessary, and this packet gets sent with a new sequence number.”

Lets say a client sends chat message to sever. Server sends out the chat message to everyone including the client. For the client who sent the message, this reply packet should contain the ack. But what happens if the server’s packet was dropped? The client would resend the message to the server after a timeout occured. This message would have a new seq_num so the server would send out the chat message to everyone a second time.

I think what I got out of the article is that this algorithm assumes a constant packet flow back and forth. Which means that even if the servers packet with the ack was dropped the next packet to be sent will likely arrive and it too will contain the ack. However, there are times in all games where there is not much network traffic. (Waiting in a lobby for the next game to start). In these cases would you need to send a keepalive packet?
How would you determine when to send keepalive’s? You would need to send a keepalive before the timeout for the chat message. There is a possibility of the keepalive being dropped as well. Which means that the chat message timeout might occur…

in “Detecting Lost Packets” section you seemed to hint at a work around for this:

“The implication of this is that any data which you resend using this reliability technique needs to have its own message id so that if you receive it multiple times, you can discard it. This can be done at the application level.”

Are the message id and packet seq_num two seperate fields? i.e. [seq_num,ack,ack_bits,msg_id,chat_msg]. So you recieve the same message again but you can now check the msg_id against prev message ids and not send the chat message again? Is this a replacement for timeouts or would both be needed?

Sorry this is so long winded but I have been thinking very hard how to implement my own code.

I downloaded the other samples (Node mesh, Lan Matchmaking and Real world networking) and I’m trying to figure out how to write a server/client resending lost packets…