Sign in to follow this  
Jvlaple

Extreme lag... (Movement packet)

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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".

Share this post


Link to post
Share on other sites
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?


^

Share this post


Link to post
Share on other sites
Quote:
Original post by Leaedas
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?


^


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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
Quote:
Original post by Jvlaple
x = int
y = int
frame = byte
stance = byte
directon = byte


Always determine how fine-grained it has to be. Do you really need a resolution of 1/4294967296 for x and y? Or would it be enough to have just 1/65536? This reduction/quantisation would already gain you 4 bytes less (7/11=36% percent reduction). How many frames can there be? 16? Would 16 directions be enough? Then use bitfields or bitwise operations, and combine both:

struct { int frame : 4; int direction : 4; }


And you gain another byte.

Share this post


Link to post
Share on other sites
Quote:
Original post by Jvlaple
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.


Having the client do the work is a security mistake. All operations should be done on the server. The client should simply graphically represent/interpret the numbers sent by the server.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this