Do UDP game clients/servers block for receive calls?

Question

One way to implement a client/server relationship is to have the server simulate the whole game based on the clients input and send updates back to each client, while the client is is simulating the game for the player and sending back input and game state messages that the server can use to process the whole state of the game.

My question is, since a ReceiveFrom() call blocks till it receives data and a Select() call blocks for a set period of time, does that mean all clients and servers block for a certain amount of time each frame? I am aware that a call to Select() can be set to zero which would be an effective poll to the read write states of the current sockets, but wouldn't you miss out on new data if it comes in just microseconds later? How is this problem solved now a days? Pro select() method handling? Asynchronously? Separate thread completely? Other?

I may be over thinking this, but I would like to know more information so I can write an effective client/sever relationship. -Haywire

Answer 1

I am aware that a call to Select() can be set to zero which would be an effective poll to the read write states of the current sockets, but wouldn't you miss out on new data if it comes in just microseconds later?

No. When a remote computer sends you data, it first goes onto your network adapter which has its own data buffers, and from there into your operating system which again has data buffers. Reading data pulls it from the buffer - it doesn't poll data that is sitting on the wire at that precise moment (which is lucky, since the information on the wire at any instantaneous point of time can be measured in bits, not bytes, certainly not kilobytes).

The only time you can 'miss' data is if you allow the buffer to overflow, which is unlikely to happen unless you are not reading at all or you are being flooded with data. If select says there's no data, but then data comes in microseconds later, select will just tell you the next time that you call it that there is now data available.

Answer 2

Whether your functions block or not, depends on the specific implementation (library/language). It is however safe to assume that the function will block at least as long as it takes to fetch/write the data.

The simplest solution is a second thread that does nothing but reading/writing. Instead of working with that data immediately, push it into a queue so it can be consumed by another thread(like your main game loop). Writing works the same way in the other direction. If the function call is blocking, call it with a small timeout, so you can switch between read/write fast and with minimal delay.

Depending on what you are doing you should really think of using TCP instead of UDP. Unless you really need the speed and a lost packet does not need to be resent, TCP is usually the better choice.