View Full Version : How often to send packets?

Super Vegeta
06-01-2012, 11:17 AM
Since I could not really find my answer on Googles, I'll try asking here.

Right now I am working on a multiplayer game. So far all of my testing is done either on localhost, or LAN, so bandwidth is not a matter right now - but it is something I am worrying about.

As of this moment, the player sends information about input change - be it a keystroke, or mouse movement (yep, the game's a shooter), limited to 100 packets/second. The server then broadcasts this change to all players. Simple and nice, but given 16 players sending 100 p/s, with a 64-byte packet, that gives 100KiB of information sent per second.

I was wondering about a different way to do it. My thought was to use a request - response behaviour, that is, the client sends an information request to the server - server answers it - client receives the response and instantly launches another request. However, this approach has one great weakness - the request packet may get lost in the vast jungle of the internets. So, to counter this - what about the client resending the request if, say, 3x average ping has passed with no response?

06-01-2012, 01:31 PM
Do you need to send packet on every tick? Maybe just send the tick number in the pack too, and then only when the input changes. I mean, no human does 100 input changes per second, more like 6 when its fast situation.

the request packet may get lost in the vast jungle of the internets
This should never happen with TCP, maybe does with UDP.

Super Vegeta
10-01-2012, 12:26 PM
I'm using UDP, so packet loss is always some risk.

After giving it a thought - at least for now - I'll do it like this: the client can send packets to the server as often as he wishes (100 input changes per second is possible, since we aim with the mouse), but the server will broadcast player info only when direction of movement changes. After all, the client needs other players' AimX & AimY only for drawing.

10-01-2012, 06:10 PM
Why do you need 100 packets in 1 second when you game probably runs on 30 FPS (frames per secnd). It is usles in sending more packets than teh usual framerate is (unles you do some realtime physics).

10-01-2012, 07:55 PM
You should not send more than 3-4 packets per second and make sure to send self-sufficient information, so you can reconstruct the necessary part of the scene based on the information you have. If one packet gets lost, then you should be able to get latest information from the next packet. Plan your dead-reckoning accordingly to interpolate the frames between packet reception intervals (linear interpolation, cubic splines, etc.)

I would recommend that both server and client keep sending packets. If no useful information is to be send, just send acknowledgement. This way, if client and/or server does not deceive anything within some time interval, it assumes that the remote party has been disconnected.

10-01-2012, 09:36 PM
Just out of curiosity, what library/interface are you using for your networking?

Super Vegeta
11-01-2012, 07:07 PM
Since I do graphics in SDL, I went with SDL_net.

12-01-2012, 05:59 PM
Cool, whats the stability on sdl_net if you don't mind my asking? I tried the low level units supplied by the LCL but linux can be dodgy at times so I'm reviewing a better way of going abouts it without needing any dll/so files :D

Super Vegeta
15-01-2012, 09:44 AM
So far I did not have any major problems. Reading from UDP packets via typecasts didn't really work, so I had to use a for, and I could not really find a way to determine TCP connection status (that is, detect disconnects) - but other than that, everything seems to work quite fine.