Hi, I often read about buffering incomming network messages (client sided) and then periodically crawl through these and process them. But to me it seems like its just adding unnecesary lag that way... why wouldn't I just immediatly take the appropiate action when I receive a network update? (lets assume I have a action game that receives updates regulary, in a client/server model) I can imagine that on the server side it could be helpfull to buffer , because updates might interfer with each other when they arrive too soon after each other?

Consider a system where a thread is polling network messages and is sending them directly to the destination objects. The message may come at any time. If there is something else going on, such as update event or rendering, the incoming message may corrupt object data or lead into unpredictable results.

So in this case the problem is about multi-threading and the message buffer will make things safer and work in much more planned manner. With the buffer you know exactly when the message processing happens.

Yes you are right about the lag, but it will be at maximum the time of your update interval.

Best regards

I think this is due to that networking is usually a multi-threaded setup. So the network thread is always spinning and receiving messages and fills up a queue. Then there is a sync event somewhere to empty the queue to transfer across threads. To be thread safe and all...

But your right in some cases it does not make sence since the card is buffering up the data already. So if you are getting messages in your main thread strait from winsock for example. Then process them.

Really it depends on how long it takes to process messages and what you are doing.

The server wants to send the packet "This is a packet" except you only receive "This is ". You need to add that to your buffer until you get "a packet" and then process it, otherwise you have an incomplete packet.

If the packets have headers, and you don't buffer it, you'll process some incomplete packet, then the fragment that comes in next will make no sense, etc.