How should a game server receive udp packets with a defined tick rate?

Question

I currently have a game server with a customizable tick rate, but for this example let's suggest that the server is only going to tick once per second or 1hz. I'm wondering what's the best way to handle incoming packets if the client send rate is faster than the server's as my current setup doesn't seem to work.

I have my udp blocking receive with a timeout inside my tick function, and it works, however if the client tick rate is higher than the server, all of the packets are not received; only the one that is being read at the current time. So essentially the server is missing packets being sent by clients. The image below demonstrates my issue.

So my question is, how is this done correctly? Is there a separate thread where packets are read constantly, queued up and then the queue is processed when the server ticks or is there a better way?

---

Image was taken from a video https://www.youtube.com/watch?v=KA43TocEAWs&t=7s but demonstrates exactly what I'm explaining

Tael

i’m pretty sure that with the UDP protocol packets aren’t guaranteed to be delivered, right? so ya you’ll have to build a system like you describe – Leucopoiesis

@Leucopoiesis Yeah they're not guaranteed, but that's not the issue I'm having. It's that if the client sends 50 packets, and then the server ticks, it only reads the latest packet and doesn't know about the others. Whether that is expected behaviour of a 1hz server I'm not sure... – Tael

i’ve not built a system using UDP but of top i’m thinking of something where you would have to do some verification of delivery between the client and server but .. maybe that would be too slow? – Leucopoiesis

oh ok then .. yeah some sort of queuing would make sense but sorry i don’t know enough to give you a solid answer – Leucopoiesis

Surprised no one has tried to answer... – Tael

Answer 1

There's a bunch going on with the scenario you describe, but here's my guidance.

If you are running a server at 1hz, having a blocking socket prevent your main logic loop from running is not a great idea. There is a chance you won't be receiving messages at the rate you expect (due to packet loss, network lag spike or client app closing)

A) you certainly could create another thread, continue to make blocking recv/recvfrom calls, and then enqueue them onto a thread safe data structure

B) you could also just use a non-blocking socket, and keep reading packets until it returns -1. The OS will buffer (usually configurable) a certain number of incoming messages, until it starts dropping them if you aren't reading.

Either way is fine, however for individual game clients, I prefer the second simple approaches when knowing I'm on a thread that is servicing the socket at a reasonable rate (5hz seems pretty low, but may be appropriate for your game). If there's a chance you are stalling the servicing thread (level loading, etc), then go with the first approach, so you don't detect it as a disconnection if you miss sending/receiving a periodic keepalive message.

On the server side, if I'm planning on a large number of clients/data, I go to great lengths to efficiently read from sockets - using IO Completion Ports on Windows, or epoll() on Linux.

Eudora

Answer 2

Your server could have to have a thread to tick every 5 seconds just like the client to receive all the packets. Anything not received during that tick would be dropped as the server was not listening for it. You can then pass the data over from the thread after 5 ticks to the server as one chunk. The more reliable option though is to set the server to 5hz just like the client and thread every packet that comes in from the client so that it does not lock up the main thread.

For example, if the client update rate is 20, and the server tick rate is 64, the client might as well be playing on a 20 tick server.

Recitative

I'm not sure... That would mean that every game out there would have to have a synced client/server tick rate and from what I've seen they don't. Majority of times the client tick rate will be faster than the server's so how does the server handle the additional packets. It's more so how to handle this in real scenarios, not the scenario I posted. For example if my client was running at 80hz and my server at 60hz, sometimes you just can't "set the server to 80hz" due to the amount of processing it needs to do within the tick window. – Tael

You client could only then just send events every 60hz then. im assuming you would then use the other 20hz of extra to process rendering elements in view not sending packets to the server. You could send eveyr 80hz but assume the rest would be dropped anyway. The same problem happens on some of my electronics sending shorter pulses and some sending longer duplicates pulses. i either dont get the signal, or i get duplicates i filter. – Recitative

I still don't think this provides a solid solution unless I'm missing something. If the server was running at 30hz and the client running at 60-70hz, it's not really a solution to simply bring down the client to 30hz, because in some cases you'd want the client to run faster. – Tael

In this article they talk about one blizzard game running at 20hz mainly because they didn't want to strain the server. kotaku.com/overwatchs-low-tick-rate-can-be-a-problem-1778708854. Although in this article they compare tick rate vs fps. although the client can run at tick rate of 240hz. does not mean the server will run that. nbnco.com.au/blog/entertainment/… – Recitative

The articles go on about server tick rates, but don't mention anything relevant to my question. I have added an image to my post which explains my question more. For example from the image, Fortnite, a popular game has a client send rate of ~75hz, but a server rate of 30hz. This is the problem I am experiencing and I am asking how do games resolve this issue if there are more packets being sent by the client than the server can process. Or even LawBreakers, where the client has 170hz but server has 60hz. – Tael