Improve synchronization system stability on environments with fluctuating tick rates about husksync HOT 7 CLOSED

Set a master server, simulate the registration center, and track the status of all sub-server players on a regular basis. During the cross-server period, only after the sub-server publishing data is set, can the data be actively queried

from husksync.

Set a master server, simulate the registration center, and track the status of all sub-server players on a regular basis. During the cross-server period, only after the sub-server publishing data is set, can the data be actively queried

Sorry, could you clarify what you mean by this? :) A master server? A registration center? I'm not totally sure what you mean

from husksync.

My English is not good,

I mean, this may require a centralized management

All sub-servers passively query player data, and players should attach a timer (timeOut) when joining the server. Only when timeout, can they query mysql,
Otherwise, wait for the Redis data setting completion notification.

///
Need to deal with the data acquisition method when the player first connects to the server

from husksync.

For data stability, it may be necessary to sacrifice the game experience...........

from husksync.

I sort of see what you're saying, but it's not the approach I'm looking into at this time. HuskSync version 1 operated under a central cache-on-the-proxy approach and was flawed for various reasons.

The approach described in the original post is something I'd like to work on in the future to alleviate issues with fluctuating delay, but in the case of the vast majority of servers where that's not a concern, the current approach is sufficient.

from husksync.

He will suspend players who are crossing servers and wait for data
https://github.com/liaojinmin/GeekScheduler/blob/master/src/main/kotlin/me/geek/scheduler/service/RegistrationCenter.kt

from husksync.

The lockstep-syncing branch refactors the syncing process into a modular system, and introduces a lockstep syncing approach inspired by the specification originally proposed in the OP :)

This also introduces a mandate for implementing a server config per-server; which also paves the way for probably saving the server where data was saved into the snapshot in the future (very handy for admins, of course!).

I'd also like to probably introduce API in this branch to let devs implement their own syncing method if they so wish.

Comments welcome in #husksync-dev on Discord.

from husksync.