Quote from The Quake3 Networking Model (www.bookofhook.com) " For exmaple, let's say the client last ACKed sequence 14. The server is sending out new game states with incrementing sequences. It may be up to seq 20 when it gets an ack from the client that it has received seq 17. The server has to have t eh state that was sent as part of seq 17 in order to rebase the delta compression"(1) Playing the village idiot: In order of incrementing questioning: Does the server only receive ACKs when the client has something useful to say as well? What is to say the reply from the client isn't delayed by the fact it had not quite received all the servers updates, causing an incorrect rebasing upon server send, when really the client has received that information? What is stored as part of state information? and from this, what is 'rebased'? //edit To reduce network bandwidth, the server only transmits changes to entities within a visible range using delta compression. For each server frame update, the server would first determine what entities the client can see, followed by transmitting changes to the visible entities based on the previous frame the client received (delta compression (2) ). -- basicaly the definition of delta compression. Are these changes truly absolutes? Such as position. Or would it be relative off the last client ack? There are conflicting statements (in my mind anyway) between these two posted paragraphs. Rebasing sounds relative. ~~>> yadda yadda still crunching .. if it is relative, then does the server reply with what frame these values are based from.. ( considering part of my second question being the delay and incorrect views due to latency between send/recieve?) If it is delayed, we lose resolution of client data? //~edit ref links: 1: http://www.bookofhook.com/Article/GameDevelopment/TheQuake3NetworkingModel.html 2:http://www.csse.monash.edu.au/~timf/bottim/q2net/q2network-0.03-4.html Still rolling all these things around in my mind, but would def love some expertise. +) Much thanks, ^sf. [Edited by - skillfreak on June 6, 2005 4:39:15 PM]

Delta Compression can mean several things. It can mean that you send a bitmask of what parts of data you actually include (position/velocity/orientation/etc, maybe even individual components of those values), and then only send those pieces of data. It can mean that you use the previous value as a baseline, and use a variable-length encoding of data you send, to take advantage of small changes being small to transmit. It can mean other things as well.

Each time the client receives a packet, it saves away the decoded (uncompressed) state for that packet, and sends an ack. When receiving an update packet, the client removes all saved packets older than the packet which the update packet references. The server, when receiving an ack for a specific packet, knows that the next packet being sent can be encoded based on that packet. The actual packet used as base for data is part of the next update.

Typically, you'll truncate packet sequence numbers to some small number of bits, enough to cover only some number of seconds or minutes of uptime, to avoid sending redundant bits -- at some point, if you had lots of dropped packets in a row, you'd drop the client anyway.

Ok. This greatly clarifies the blips coming up all over the documents i've been reading.
However, what can you tell me about the following statement:

'Dropped packets are handled implicitly, and specific commands are never acknowledged independently -- last known state acks are piggy backed on regular incoming/outgoing traffic.'

Found in the bottom of the 3rd paragraph of this article
http://www.bookofhook.com/Article/GameDevelopment/TheQuake3NetworkingModel.html

Where you say ACKs are sent in response to every received frame, this claims otherwise, and seems more refined and simplified.

Your input is greatly received.

What I mean, and what that sentence means, is that each side, when sending a packet to the other side, adds an indication of what the last known acked message was. That way, both sides know what a late-ish, useable baseline would be. Even with packet loss, it doesn't matter, because the client will never drop old baseline data until data based on a newer baseline is received, and the server won't start baselining on newer data until it has positive confirmation the client actually got it.

At its core, here's what gets sent, assuming only server->client uses delta compression:

server packet to client:  cur packet id  base packet id  data, delta-encoded based on the base packetclient packet to server:  last received cur packet id  client messages to server (controller input, say)

These can be sent independently of each other, and don't even need to be sent at the same rate.

Excellent. You mopped up my question completely. Really appreciate it.
Thanks a lot. Andy