Server sends many packets to one client example 100 packets/one second when client can receive only 40 packets/one second because client is handling packets in render function which reaches 40fps. In some minutes it makes big lag and client can't apply these packets to the game (can not keep up). I can't at the same time receive packets in thread and apply these informations to the game because it makes some problems in client's program and does crashes. I would receive packets in thread (it's much faster than game render function) and apply informations from packets received in thread to the game, but it's some strange method and makes a lot of not needed redirects thread->gameRenderFunction. What can I do with this? How work other multiplayer games, these receive packets in thread and apply them to the game render function? How it looks like?
Receive packets in the thread or in game render.
There should be nothing stopping you from receiving more than one packet per frame. So a 40fps game should not be limiting you to 40 packets per second.
The server sending 100 packets per frame sounds wrong though. It could consolidate multiple game messages into a single packet and save a lot of bandwidth and CPU. Although if you're targeting desktop hardware then this is probably not a significant issue.
To receive messages on a thread, you probably just want to have the thread receive the message and just add it into some sort of thread safe queue, so that the main thread can consume the messages at an appropriate time.
To receive messages on a thread, you probably just want to have the thread receive the message and just add it into some sort of thread safe queue, so that the main thread can consume the messages at an appropriate time.
Exactly. I have done some tests. In 10 seconds I can:
- receive 390 packets in the game render function
- receive 4000 packets in the thread
It's very big difference. 390 packets in 10 seconds its very little and it can make some lags example for 20 players. Server sends to one client 100 packets per second, not per frame, so client can receive only 390 packets in 10 seconds (should receive 1000 packets) which I could process them. My only option is just receive in the thread and make safe queue?
I meant to say that the server sending 100 packets to a single client in a second is excessive (100 packets per frame would be crazily high). Ideally you should consolidate your messages into fewer packets. e.g. If you're sending positions for 10 entities 10 times per second, then you can package that information up into 10 packets instead of 100.
However, I'm still not sure why there would be a limit of one packet receive per frame on the client when you're handling the messages in the render thread. I suspect there's something wrong with your code if you find that's the case.
Receiving messages on a worker thread and sticking them into a thread safe queue would be a good approach, but I suspect there's no good reason that receiving messages on the main thread couldn't also be made to work.
Hm.. I had call to Receiver function 10-50 times per frame in Game Render function and there aren't any lags. Thank you very much for help :)
C0lumbo is pretty much on track. Process all messages that have arrived rather than just one, and look at your frequency of messages.
I have moved this question to the Networking forum where it belongs. Check the Forum FAQ and the links it contains, especially Q12 and Q14.
The packets are already received by the computer and buffered in the kernel. All that your "receive" function does is copy the received data out of the kernel to your application. If you write the code correctly, you should be able to receive hundreds of thousands of packets a second from a single thread (be it main thread or other thread.)
