Peer.ServerTimeInMilliseconds == 0

corr

I encountered problem with ServerTimeInMilliseconds if use Photon from Unity3d. It returns 0 on some connections. Seems that it happens randomly. Some Peers have it 0, and FetchServerTimestamp() doesn't help. More - if I call FetchServerTimestamp() ( with hope to get server time at some point in future ) say, 10 times per second ( or 1 time per second - it doesn't matter ), after some time QueueOutgoingReliableWarning begins to pop at PeerStatusCallback.

I use Photon SDK 2.6.11 on Windows7 Ultimate 64bit and start server from deploy/bin_win64 or deploy/bin_win64_xp

I just checked that same happens with demo-litelobby-chatroom sample for Unity.
I have modified Update() in PhotonClient.cs that way ( strings added by me starts with '*' ):

public virtual void Update() 
    {
        if (Environment.TickCount > this.NextSendTickCount)
        {
*            Debug.Log("Server time - " + Peer.ServerTimeInMilliSeconds);
*            if (Peer.ServerTimeInMilliSeconds == 0)
*                Peer.FetchServerTimestamp();
            this.Peer.Service();
            this.NextSendTickCount = Environment.TickCount + this.SendIntervalMs;
        }
    }

On average 1 of 5 runs get Peer.ServerTimeInMilliSeconds == 0 all the time ( and QueueOutgoingReliableWarning in PeerStatusCallback after some time ), but communication with server is OK.

Tobias

I think I found the cause for this. The server time is only accepted if the rountrip for the "fetch" was lower than the current roundtrip time (rtt). If you have constantly low roundtrips, this might not resolve.

The solution if to accept the timestamp also when the rtt of the "fetch" is equal the current time.
This is the only explanation I have and I fixed this in the upcoming SDK.


Can you verify that the rtt is very stable and low in your cases? You could also try to apply some network-simulated jitter.
Alternatively, give me a few days until the update SDK is out and check again there.

corr

Yes, RTT was low and stable, as server is on LAN currently. After I have enabled network conditions simulation, time fetch resolves after few attempts, but it would be better if it can be fixed to resolve in one attempt or have correct time after connect without fetches.

Tobias

As said: it's changed but not yet released. It should resolve quickly now but it does not make sense to accept just any value, cause when the rtt is high, the timestamp is less accurate.

Thanks for the affirmation of the situation!