Using ping to correct for lag?
Author
I have a server sending infrequent positional updates to the client for objects on screen. The client maintains its own update loop and uses these server messages to reset position (and velocity). It works OK, but I think the fact the server message obviously takes time to reach the client is now the main issue.
Let's consider Pong as a simple example, with the ball position/velocity. My idea is that if we can know how long it takes a message from the server to reach us, we can factor that in when an update is received. i.e if we get told "ball at (x,y) moving at velocity (dx,dy) and we know the message is 0.3s old when we receive it, we actually set the ball's new position to (x+dx*.3, y+dy*.3). To do this, the obvious thing might be to build our own ping functionality... every second we fire a request to the server and note the time. When the response is returned we use it to estimate lag.
Is this sensible? I'm not expecting to remove all lag-related issues, just reduce them somewhat...
think about maybe sending a timestamp. If the client knows when the event occurred it can use the information to compensate.
Author
What use is a timestamp when there's no guarantee the PCs have synchronised clocks? And I can't measure the difference between clocks to compensate, because every server/client call has lag. Hence the idea of measuring the lag using ping :)
Or did I miss something?
Or did I miss something?
The client is surely sending some data to the server. Why not just measure response time from that?
Quote:every server/client call has lag
Game networking is not like traditional service RPC (at least it shouldn't be). Game networking is a bidirectional sequence of messages, where those messages are typically state updates or events.
Typically, you decide on a rate of message updates (say, 10 messages a second) for client->server, and for sever->client (they don't need to be the same).
To measure round-trip time, you can send the following information:
client->server messages: "This is message sequence Nc"
server->client messages: "I received message sequence Nc at server time Ts1; I generated this message as server time Ts2"
The client can then remember when it sent the previous messages, and measure when the incoming message comes in. You then have the following variables:
Message A sent from client to server at time Tc1.
Message A received at server time Ts1.
Response B sent at server time Ts2.
Response B received at client time Tc2.
The total processing time is (Ts2-Ts1).
The total round-trip time, without processing, is (Tc2-Tc1)-(Ts2-Ts1).
Author
I'm using an egine that doesn't really work that way. It's more event-based. So I click on something and it sends an event to the server, and the server responds.
I guess this could be made to use a fixed packet rate but the way the engine is documented doesn't make it look sensible.
I guess this could be made to use a fixed packet rate but the way the engine is documented doesn't make it look sensible.
Why couldn't you generate a "packet with timing information and current state" event 10 times a second (or whatever)? Assuming you're in charge of generating events, and have timers or an idle loop available to you.
Here's a link that might add some useful info:
http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/IntroductionToMultiplayerGameProgramming?#ConnectionQuality
http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/IntroductionToMultiplayerGameProgramming?#ConnectionQuality
Author
Quote:Original post by hplus0603My approach is to have specific messages sent between client and server, more like RPC I guess.
Why couldn't you generate a "packet with timing information and current state" event 10 times a second (or whatever)? Assuming you're in charge of generating events, and have timers or an idle loop available to you.
Would it be sensible instead of sending messages immediately to simply push them into a queue, and a separate thread pushes the contents of the queue 10 times a second? That way I can easily refactor...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
