ICoordinatedClock giving different values to peers in the same session

  • Issue category: Multiplayer / Networking
  • Device type & OS version: Android
  • Host machine & OS version: Windows
  • Issue Environment : On Device
  • Xcode version:
  • ARDK version: 1.1.0
  • Unity version: 2019.4.32f1

A few days ago I was able to query IMultipeerNetworking.CoordinatedClock.CurrentCorrectedTime to adjust the clocks of all the peers in the networking session. I got the exact same value in all of them, and everything worked like charm.

But today I get very different values for each of the peers, even when CoordinatedClock.SyncStatus is “stable”, so I cannot use it anymore. For instance, one peer gets a CCT of 483748261 and at the same time another gets 482624973. Has something changed during the last few days?

Bug reproduction steps:

  1. Two peers connect to the same IMultipeerNetworking
  2. Query CoordinatedClock.CurrentCorrectedTime with CoordinatedClock.SyncStatus = “stable”
  3. Compare values of both of them

I just connected both phones to the same WIFI and now I get the same CurrentCorrectedTime. But if one of them is connected to WIFI, and the other to a 4G network, the difference between them is close to 19minutes. Is that the expected behavior?

Chankeiro,

Updates made to the ARDK are made available with new version releases, and there haven’t been any publicly released changes in the past few days. A Multipeer Networking object can only be used to join one session. After leaving the current session, dispose of the existing MultipeerNetworking object and create a new one to join a new session (or rejoin the previous session). CurrentCorrectedTime itself has no guarantees of epoch or standard — it is a timestamp in milliseconds. It is better used as a stopwatch or timer, rather than used to represent a real world time (though this can be done by locally comparing it to another known clock). Are connections being attempted on an existing session?

Related Links:

https://lightship.dev/docs/low_level_networking_additional.html

Thanks Erik. Yes, I’m experiencing the problem once both players connect to the Multipeer Networking for the first time. I don´t reuse the networking object.

Yes, I’m only using CurrentCorrectedTime as a timer reference for my game.

My code goes roughly like this (in a MonoBehavior):

private IMultipeerNetworking _networking;
private bool _stableNetworkingClock;
private long _serverTime;

MultipeerNetworkingFactory.NetworkingInitialized += OnNetworkingInitialized;
private void OnNetworkingInitialized(AnyMultipeerNetworkingInitializedArgs args)
{
    if (_networking != null)
        return;
    _networking = args.Networking;
}

// This object can only be enabled after enabling the network session manager
// when this happens, both players are connected to a networking session
// with the same SessionIdentifier
void OnEnable()
{
    Observable.Interval(TimeSpan.FromSeconds(3)).StartWith(0).Subscribe(_ =>
    {
        _stableNetworkingClock = (_networking.CoordinatedClock.SyncStatus == CoordinatedClockTimestampQuality.Stable) ? true : false;
        if (_stableNetworkingClock)
            _serverTime = _networking.CoordinatedClock.CurrentCorrectedTime;
    });
}

What I don’t understand is that two players in the same WIFI get the same CCT, but if one of them uses a 4G network, the CCT is very different for each of them (almost 19 minutes). I’m probably doing something wrong, but I have no idea what.

Thanks in advance.

Thanks for the quick response and for providing a code example. Unfortunately, when using CoordinatedClock to synchronize time-dependent behaviors between devices, there are no promises on what the epoch of the timestamps are. But the timespan tracked will be synced between all devices, so when using it, you’ll want to establish your own epoch based on the timestamp. Additionally, over-internet network connections aren’t currently supported in the ARDK. While there may be information available through the community on ways to work around it, from what I’ve heard the lag is considerable.

This topic was automatically closed 2 hours after the last reply. New replies are no longer allowed.