Sign in to follow this  
Eralp

Why do my clients get spiked?

Recommended Posts

I made a client/server based application.The problem is that my clients get "spiked".I don't know what causes this. Here is what I do: I timestamp every packet that I send. I reset clients and server that their "time"s are synchronised. For example if server gets a "move" packet from a player. It calculates the difference between the packet time and server time. I backtrack player for that diffence based on current direction. And I "fast forward" player based on the new direction in the packet. Every 2 seconds server sends generalupdate packet which include location besides direction(other packets contain only directions).This is timestamped too. I do the same proccess. note: I multiply frametimes with speed, so this shouldn't cause differences between server and client updates. So I think that this is the proper way how to do this, but my clients get spiked,if you for example push and release a key really fast it doesn't even move. And when you push and hold the key the character "spikes"(teleports) back a little bit. Do you know where could be the problem ? Thanks.

Share this post


Link to post
Share on other sites
TCP or UDP?

If UDP do you account for messages showing up out of order, being duplicated, etc?
What do you do to account for the non zero transit time for messages(especially if you use TCP)?

Share this post


Link to post
Share on other sites
I am using ENet library for networking(UDP but packets cannot get duplicated etc.)
Also I am checking the packets with a debug window so this can't be a problem.

What do you mean by the second question?If you mean what do I do when the difference is 0, same proccess works,doesn't it ? I just change the direction, no backtracking and no fastforwarding since they are multiplied by 0.

Share this post


Link to post
Share on other sites
you claim to be synchronizing clocks based on timestamps in a packet.

packet 1 takes 100ms to go from a to b. time gets synchronized 100ms out of true synch.
packet 2 takes 600ms to go from a to b. time gets synchronized 600ms out of true synch.
packet 3 takes 50ms to go from a to b. time gets synchronized 50ms out of true synch.

Rather sounds like a good place for your issue to occur.

Share this post


Link to post
Share on other sites
Oh no, I didn't mean that.Timestamps are used for backtracking and fastforwarding.

At the beginning Server resets its time and send a packet to clients,
clients send back the same packet as they receive that,
server sends its current time as it receives that packet,
clients multiply that time with 3/2 and set their time to that.

This is how I synchronise and this is done only at the beginning.

Share this post


Link to post
Share on other sites
Quote:
Original post by Eralp
So I think that this is the proper way how to do this, but my clients get spiked,if you for example push and release a key really fast it doesn't even move. And when you push and hold the key the character "spikes"(teleports) back a little bit.


I am just guessing right now but it might be possible that the problem isn't located at the packets itself.

For example with the "push and release a key really fast". Is there a triggering condition which could be not met, or is your moving distance to small to notice a movement.

For the teleports it rather sound like you are not completely in sync which is also not possible because of the uncertainity stonemetal mentioned. On a network you can almost never synchronize up to a milisecond accuracy (not even close).
If your movement is to strictly based on "being synchronized", you will most likely get those teleports and glitches.

Share this post


Link to post
Share on other sites
I know the packets are being sent when you push and release a key really fast but time between them being very short it MIGHT result something like that, I am not sure and I don't know why it might be so.I'm out of ideas.

So can anyone suggest me what to do ? I think that I can get the arithmetic mean of current player location and the location which is calculated according to the packet(it is not the location in the packet, because time difference must be taken into account) and set players location there, but this brings unsynchronisation and this will grow after each general update.It will neither prevent the spikes ..

Share this post


Link to post
Share on other sites
It may be better to use a send frequency and send all common data in one packet every x cycles. Your direction/movement/position packets all being seperate could make a mess prety quick, and just sounds hard to manage on the receiving end, not to mention seperating them could actually increase your bandwidth footprint just because of the extra header info on each packet.

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