Extreme lag... (Movement packet)
Author
Is there a way to send movement packets better? Right now I send a movement packet every 130 milliseconds for a player and 160 milliseconds for a monster. This causes extreme lag on even a VPS (Virtual Private Server). I spawned about 20 chickens, and bam, you can't even see anything move anymore. Is there a better way to send movement packets? Like maybe sending a larger packet then parsing it on the client?
By the way, what was sent was like this:
x = int
y = int
frame = byte
stance = byte
directon = byte
That adds up to.. 11 bytes.
Thanks.
You shouldn't get much lag on LAN, although sending at 130ms will basically add roughly > 200 ms roundtrip lag.
Note that there is an overhead sending packets, so the less packets you send, the less overhead you get. Usually it is best to fill up a packet up to the MTU size to reduce overheads, but with 20 packets each with 11 bytes payload, that shouldn't be a problem. 11 bytes payload is pretty small and very manageable.
What transport method you use? TCP-IP? UDP? non-blocking sockets? Is your socket buffer filling up?
Note that there is an overhead sending packets, so the less packets you send, the less overhead you get. Usually it is best to fill up a packet up to the MTU size to reduce overheads, but with 20 packets each with 11 bytes payload, that shouldn't be a problem. 11 bytes payload is pretty small and very manageable.
What transport method you use? TCP-IP? UDP? non-blocking sockets? Is your socket buffer filling up?
It would help if we also knew what kind of game this is. A tile-based game is going to be much different than a fast-spaced shooter, both in design and what is considered "laggy".
Are you sending movement packets for each monster every 160 seconds, or just one monster?
And are you extrapolating positions between receiving updates on the client?
And are you extrapolating positions between receiving updates on the client?
Quote:Original post by Jvlaple
umm... each monster sends its own packet.
Ok 1 down 3 to go.
Quote:Original post by oliii
What transport method you use? TCP-IP? UDP? non-blocking sockets? Is your socket buffer filling up?
Quote:Original post by Spodi
It would help if we also knew what kind of game this is. A tile-based game is going to be much different than a fast-spaced shooter, both in design and what is considered "laggy".
Quote:Original post by hplus0603
And are you extrapolating positions between receiving updates on the client?
^
Author
Quote:Original post by LeaedasQuote:Original post by Jvlaple
umm... each monster sends its own packet.
Ok 1 down 3 to go.Quote:Original post by oliii
What transport method you use? TCP-IP? UDP? non-blocking sockets? Is your socket buffer filling up?Quote:Original post by Spodi
It would help if we also knew what kind of game this is. A tile-based game is going to be much different than a fast-spaced shooter, both in design and what is considered "laggy".Quote:Original post by hplus0603
And are you extrapolating positions between receiving updates on the client?
^
1) TCP - Apache MINA
2) Platform/Adventure
3) Nope.. Client calculates all movement, server simply broadcasts it and registers autoban if the distance moved is too much.
Since you're using TCP, did you make sure that the Nagle's algorithm is turned off for your TCP sockets? You'll want it off to decrease latency, at the cost of decreased max bandwidth.
Quote:
cfg.setTcpNoDelay(true);
That sounds about right.
Using TCP, you have to consider when the send buffer gets full If you keep pushing data on the buffer (you are pushing 11 x (1000 / 160) x 20 = 1.375 kBytes/s).
I don't really know how your socket behave when it starts to overflow on sendto(), but you can check the value sendto() returns, and make sure it is equal to the datasize you specify (11 bytes). The socket might crash if it overflows, or block...
If it starts chugging after a set number of chickens (say, 10 is fine, then 11 is not), it's possible there is just too much data being sent with regards to the client's bandwidth. But 1.3 KB/s, that should not be too much of a problem (also, remember you have packet overheads as well).
Sending states, UDP would be more suited, but it's a different architecture. There, the packet gets sent and not cached, however, it might never arrive to the destination. Which should be fine if you send full states (the client will snap to the next full state received).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement