1
\$\begingroup\$

I have a two processes - a client sending player input data to the server, via TCP.

Right now, it's sending 60 input updates per second. The first update arrives promptly in my test system, where both processes are in the same machine. They print "frame 1" at the same time.

Over time though, the client is at frame 120, and ostensibly sending frame 120, but the server is only just receiving frame 60. The gap goes wider and wider as time goes.

The packets themselves are quite small - 100 bytes per update. This doesn't seem like a big amount?

Is there something built into TCP that is causing this slowdown? I adapted my webserver TCP code to use for game development, and would rather not have to implement UDP..

\$\endgroup\$
2
  • \$\begingroup\$ Perhaps it's a simple queuing problem - your server can't process the packets fast enough? \$\endgroup\$
    – otoomey
    Commented Dec 28, 2022 at 21:52
  • \$\begingroup\$ It is network delay, out of order packet arrival, and retry delay accumulating. Normal TCP behaviour. \$\endgroup\$
    – user122973
    Commented Dec 29, 2022 at 7:29

2 Answers 2

Reset to default
1
\$\begingroup\$

This is why game servers always use UDP instead of TCP for time sensitive data.

TCP is used for initial connections, game lobbies, and parameters, shared variables... Once TCP crosses a multi-homed router, timing becomes unimportant.

The negotiation, reliability, sequencing are all the trademarks of TCP. TCP requires acknowledgements for every packet(within a window), and anything received out of order will wait until it is in order.

Use UDP and ignore out of order sequence packet numbers. The usual solution is to include the last couple of frames deltas from and with the current frames absolute data.

Many papers have been written on the topic, that includes anti-cheating.

Solve the problem by adding timestamps, and ignoring or blending late frames.

The accumulation problem cannot be solved without a separate connection or 2 or 3...

You could look into WebRTC it is a broswer based protocol that leverages the advantages of UDP and provides a more simplistic interface. This solution assumes your client is browser based.

\$\endgroup\$
0
\$\begingroup\$

That sort of latency could come from Nagle's Algorithm buffering the data behind your back. Try disabling it using TCP_NODELAY.

See: https://en.wikipedia.org/wiki/Nagle%27s_algorithm#Interactions_with_real-time_systems

\$\endgroup\$

You must log in to answer this question.

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