I have two browser clients: A and B.  They communicate through a signalling server Server.A has a clientside heartbeat that signals its ClientState to other clients.  ClientState can be one of the following: StateFooStateBarSometimes, B wants to change the state of A.  It maintains a representation of A locally.  When it says Change A to StateBar, it changes A.ClientState (local representation of a remote device state) locally first (for UX purposes), then signals through Server to change ClientState on A - the local state.This usually works, but occasionally there are timing issues where the heartbeat from A will revert the manual state change that B initiated because a heartbeat was sent sometime around when B sent the state change signal.I'm thinking about two approaches to solving this problem: Timing - see if the server is sending something that was triggered after I locally modified state.  This kind of works, but if B sends a heartbeat right after I initiate a state change from A, this will not work.Command prioritization - if the last thing that changed the state was a command, wait n seconds before allowing a heartbeat (not a command) to update state again.I don't like 2 because it involves a magic number.  Network connectivity issues might push a delay past n seconds.What kinds of patterns are out there to solve this problem?  The language doesn't really matter; though I am using C#/JS/SignalR in case it matters.
Designing a mechanism to synchronize states with commands despite timing / network inconsistencies
design;design patterns;architecture;algorithms;synchronization