[MUD-Dev] Fighting Lag

[Nicolai Hansen]

Elia Morlin wrote:

> In a perfect world all relayed messages would stick to the
> estimated fps for excellent perceived performance. It is not the
> general "lag" that proposes the largest challenge, it is an
> inconsistent "lag" which is the problem. The problems cloud when
> messages arrive too early and too late, causing jagged/unreliable
> animation. Up to this point we have tried:
 
>   1. Dropping frames (causing jumps of character location)
 
>   2. Catching up frames (causing speedy-gonzales effects)
 
> I'm currently working on a solution where the client adopts its
> estimation of the servers current frame periodically based on
> current lag/round-trip.  This will cause the client to "rewind"
> and "fastforward" time to make up for the current lag, as the
> quality of the players connection is far from constant during an
> entire session and we need it to be as consitent as possible.

Have you tried a solution using a datagram socket instead of a
stream?  Stream sockets got one big problem: if a package of
information is lagged somewhere, the receiving PC will wait for it
until dropping the link. This means that no packages sent after the
lagged one will be accessed by the receiving PC before this package
gets there, thus causing a lot of information to be processed at the
same time.  With a datagram socket (and the right package design,
including a frame number and package number in each package) your
receiving client would be able to read whatever comes in, and just
drop all packages arriving out of schedule (or from the wrong
frame); this will cause the receiving PC to 'catch up' ten times per
second even if it receives only one package sent.

Nic


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev