1
\$\begingroup\$

I am trying to implement a deterministic game after having read 1500 archers on a 28.8. The simulation uses fixed-point math and the client only sends commands to the server which sends back the commands to all clients. The server sends also a MessageTick to autorize the clients to advance one step in the simulation. I have a few questions regarding this.

First of all, I don't know if I need an acknowledgment packet (even in TCP, not UDP) to guarantee that all the clients are synchronized before the server advances one step further. I know TCP has guarantees, but if I've understood correctly not the the one that the client has read the packet. We often see numbers like 15+ ticks per second. But I don't understand how it is possible, since a ping may be 100ms, how can it be more than 10 ticks per second? (1s/100ms=10). I could see that if the server sends continuously the MessageTick packets and do not wait an aknowledgment. In this case, we could run as much ticks per seconds we want with a delay dependening on the ping (and the bandwidth). However, this would make debugging difficult since we could not recover a network error (the server can't "go back in time" when an error is encountered). So do we need an ackowledgment packet or not? Is there a preferred method, or another that I didn't mentioned?

\$\endgroup\$

1 Answer 1

1
\$\begingroup\$

No, you don't need to generate your own acknowledgement packet. TCP already guarantees the receipt and sequence order of messages below your application layer in the network stack. The protocol layer handles generating the required acknowledgements, invisible to your application.

If the server sends you "Action X happened in Tick 42" and then sends you "Action Y happened in Tick 42" and then "Now it's time to advance to Tick 43", your application will receive message X before message Y before the message for tick 43.

If the packet with message Y gets dropped, it will be re-transmitted until it's received before your application processes the Tick 43 message. So, it can delay the game and cause a noticeable stall or hiccup, but won't interfere with the correctness or determinism of the simulation.

We often see numbers like 15+ ticks per second. But I don't understand how it is possible, since a ping may be 100ms, how can it be more than 10 ticks per second? (1s/100ms=10).

The next packet can be travelling down the pipe before the previous packet is received. That means the server may have already sent you messages 5, 6, 7, 8, before it knows whether you received message 4. If you didn't, the later messages you did receive are held in a buffer on your side of the connection until the missing packet (or a re-transmission of it) eventually arrives, after which the messages are delivered to your application layer in order.

However, this does not mean you will reliably receive messages 15 times per second. It can be bursty, with delays waiting for a key packet followed by rapid processing of buffered messages. So you'll hit your tick rate only on average, and if your game updates in realtime, you might need to use interpolation/prediction tricks to mask this and present the illusion of a history evolving continuously at a steady rate.

\$\endgroup\$
2
  • \$\begingroup\$ If the connection dropped let's say 1min, and then connected again, are the lost TCP packets guaranteed to be resent in order? \$\endgroup\$
    – rafoo
    Apr 26, 2022 at 3:51
  • \$\begingroup\$ So, the tickrate should be considered carrefully, there may be a "Spiral of death" if the output is greather than the bandwidth with high ticks per second? \$\endgroup\$
    – rafoo
    Apr 26, 2022 at 3:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .