[ENet-discuss] Running, Jumping, Shooting, Reloading.. reliable or not?

[Lee Salzman]

I always did the smoothing on the client end, and it only really kept 
one updates worth of data behind, and interpolated between that. It's 
just a tad annoying when you have to reproduce it on the server end to 
make sure the server reproduces the client's aim.

Never really attempted to buffer anything on the server end (in terms of 
having the server wait for a certain minimum watermark) because of that, 
but it does make sense if you want to avoid having to back-patch stuff a 
lot, and can do it without introducing too much latency (though latency 
worries me).

One thing I do in Sauerbraten, since it's only semi-server-side 
(movement is client-side, but shooting and stuff is not), is if there is 
nothing in the queue that would effect timing, I reset the server's view 
of what is "now" for the client to whatever packet comes in next. So 
pretty much the clock is resynced every time the server has nothing in 
the queue and something new comes in. This combats a client's clock 
being way faster than the server, with the clock being slower not being 
much of an issue for Sauerbraten.

But you might conceivably employ an analogous, although a bit different 
strategy. In that, if they have too much stuff in the queue, then just 
clear it out, force the client to snap back to some not too jarring 
position, and send a clock speed correction to the client estimated by 
how fast he was sending in frames relative to how fast the server was 
executing them. Similarly for excessive underflow, snap them ahead and 
clear out their credits. You might even want to just do this 
proactively/periodically before the queue even overflows, i.e. keep 
track of the relative rates and very frequently (once every 30 seconds? 
maybe sooner?) send the clock speed corrections to the client, which 
scale the client's time accordingly. This way you can avoid snapping 
unless there is truly an overflow, which hopefully will be rarer, and 
this will even take care of underflow.  Clock drift  would also be taken 
care of.

For the proactive scheme,  you'd want to overcorrect, i.e. so that if 
the client has say a lot of credits, get it to speed up faster than the 
server (just not so much the player notices) over the next 30 seconds or 
however often you choose, so that it clears out the backlog, then gets 
slowed down a bit once the backlog is clear.

Lee

Martin Sherburn wrote:
> Lee,
>
> Thanks for your explanations, I read your original "long-winded post" 
> when you first posted it. I only just got round to implementing your 
> "Co-simulation" idea very recently. And so far it works a treat. I 
> just have one more aspect I'm not quite sure how to handle very well 
> which I don't think you explained:
>
> The server buffers the client's inputs so that when some packets get 
> lost or take a little longer to arrive the server doesn't run out of 
> input and doesn't have to assign a credit to the player which would 
> lead to jerky looking movement. But buffering too much introduces 
> artificial lag. So the question is, how much should be buffered? I'm 
> thinking about 50ms sounds like a good value. But more importantly, 
> how to ensure that on average the buffer stores 50ms worth of input? I 
> can imagine that if two computers have slightly differing clock speeds 
> things would get messed up over long periods of time. Is it not 
> necessary at some point to trim the buffer length or extend the buffer 
> a little to ensure the desired average buffer length is kept 
> (especially at the start when the player entity is actually created)?
>
> I remember Half-Life was vulnerable to speed hacks. Somebody had 
> written a program to modify the clock speed on the client computer and 
> this would actually allow the player to run at extremely fast speeds, 
> or run in slow motion (but this wasn't much use for the cheaters :)). 
> Since the netcode in HL seems quite similar to what you described, it 
> seems they just process all the client input as it comes with some 
> kind of smoothing I guess. Any thoughts on this?
>
> Martin.
>