Jump to content
  • Advertisement
Sign in to follow this  
Jvlaple

Extreme lag... (Movement packet)

This topic is 3601 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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
Advertisement
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
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?

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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!