There should be no buffer for network packets on either side.

There could be a buffer for queued commands on either side. Queued commands are just a subset of all possible messages that will arrive in a given packet.

Any message that is not timestamped with "please apply me at time X" should probably be applicable right away.

I've taken a break before reconsidering this.

I still have a remaining question, if you would be so kind as to clarify for me.

Conflict between clock synchronisation and the command delay on the client. - Should I manage the "forward projection" time that the client adds to the current tick separately from the clock synchronisation system (e.g)

received_tick = synchronised_tick + projection_tick

or should I run the client ahead (so the synchronised tick itself handles the latency upstream)?

I assume that running the client ahead makes more sense.

Following from this, how best should I approach clock synchronisation (with the second suggested method, whereby we run ahead of the server)?

The most robust method for finding the RTT seems to me to be something like this

fac = 0.05
rtt = (fac * rtt_old) + ((1 - fac) * rtt)
new_time = timestamp + rtt

But then I need to include the command delay, which will likely change when the RTT measurement changes, so it will jitter around a little bit (the rtt estimate may be "off" so the server will tell the client its command was late, and therefore the client will increment the command delay. But the RTT estimate will likely compensate for the changed conditions the next time we update it).

The other option is that we don't separate the two ideas of "command latency" and "upstream latency" and just have a single latency variable. We update this by nudging it from the server.

if not_current_command:
    if command_is_late:
        self.client_nudge_forward()
    else:
        self.client_nudge_backwards()

But this seems a little to coarse grained, surely? Plus there would be some significant convergence time unless we factored in the difference in timing as a scalar. I'm not sure how large this scalar might need to be though.

difference = int((server_tick - command_tick) * convergence_factor)

if not_current_command:
    self.client_nudge(difference) 

-------------------------------

My findings:

My dejitter buffer is simply a deque structure.

The clock synchronisation relies on the "nudging technique". I have found it to be responsive and stable on local testing conditions, with simulated latency (but not with jitter as yet). I cannot use a smoothing factor because it will otherwise take too long to converge upon the "correct value".

To perform clock sync:

1. Send the command, a "received_clock_correction" boolean and the client's tick to the server. The server checks if the tick is behind the current tick, if so discarding the command and requesting a forward nudge (by the tick difference). Otherwise, we store it in the buffer.
2. In the simulation, read the first packet in the buffer. If there isn't one available, don't do anything and return.
3. If the tick is late (I can't imagine why it would be as we should have caught this, but lets say that you don't run the simulation function for a frame), we just remove it from the buffer (consume the move) and then recursively call the update function to see if we just need to catch up with the newer packets in the buffer).
4. Otherwise, If the tick is early, we check how early it is. If it is more than a safe margin (e.g 10 ticks), we send a backwards nudge to the client (by the tick difference, not the "safe" tick difference) and consume the move. Otherwise, we just skip this frame until the server catches up with the latency in the buffer (which, as aforementioned is less than or equals to 10 ticks late).
5. Otherwise we consume and run the move.

The purpose of the "received_clock_correction" boolean is to allow lockstep-like correction, This means that we won't send n correct by x RPC calls in the time it takes for the client to receive, apply the correction and send a new packet. I already have an RPC locking system in place (three functions, server_lock, server_unlock and is_locked (server side) ), but they will not be delayed by the dejitter buffer, which is what we use for clock correction.

The boolean is included in the command "packet" (RPC call) and so it is read at the same time the command is considered for execution. In my latest implementation, I have a new RPC (server_add_buffered_lock and server_remove_buffered_lock) which work like their unbuffered counterparts except they are executed in time with the dejittered commands.

Should I manage the "forward projection" time that the client adds to the current tick separately from the clock synchronisation system (e.g)

Should I manage the "forward projection" time that the client adds to the current tick separately from the clock synchronisation system (e.g)

The clocks cannot be "synchronized" perfectly. Speed of light and all that :-)

Your question is, if I hear it right, "should I keep two variables: estimated clock, and estimated latency, or should I just keep the estimated clock and bake in the latency?"

The answer is "it depends on your simulation model." The only strict requirement is that you must have a way to order all commands from clients, in order, on the server, and order all updates from the server, or each client, in order.

I typically think of this as two separate values: the estimated clock, and the estimated send latency. I find that works better for me. Your approach *may* be different and *may* work with a single clock value -- it all depends on how you arrange for the updates to be ordered.

Thanks hplus!

It seems to work fantastic at the moment, the only concern I have will be for jitter. The jitter buffer becomes such when the client's clock is forward projected.To do this, it needs to overcompensate on the clock at the moment. I think I will implement this latency myself to allow dejittering to occur by default.

The only strict requirement is that you must have a way to order all commands from clients, in order, on the server, and order all updates from the server, or each client, in order.

• Are we off by a huge amount? reset the clock to the last time/tick received from the server (line 844)
• Are we off by a large amount? jump the clock towards the last time/tick received from the server (line 851)
• Are we slightly off? nudge the clock in the correct direction (line 857 - 871)
• Are we off by nothing/almost nothing? do nothing

while (connection->simulationBuffer->next && connection->simulationBuffer->next->tick <= connection->remoteTick) {
    connection->simulationBuffer->next->process();
    connection->simulationBuffer->next = connection->simulationBuffer->next->next;
}