I am currently adapting my game to use the new low level Network API, but I noticed a little problem regarding the GetRemoteDelayTimeMS function.
I am sending the timestamp to a connected client, receive it there and then I am trying to use this timestamp to find out the message delivery time with the above mentioned function - like I would’ve used NetworkMessageInfo’s timestamp to find the delay in RakNet.
NetworkTransport.GetRemoteDelayTimeMS(client.HostID, client.ConnectionID, timestamp, out error);
The “client” object is a class containing the on connect event received hostID and connectionID, timestamp is received from the message. However, this results in really high numbers like 2971368 - in local testing, where I assume it should be close to zero*.* The timestamp is definitely the same as send from the server.
Am I misunderstanding this function? If so, how would I get the delay from Sending->Receiving?
(I want to find the clock offset by sending the server utc time, adding the message delay and then subtracting the client utc time, so I can later use TimeDate to define match start times/end times and more.)
@ReiAyanami I had maybe the same problem. Here is a snippet of how I am doing it in a test for testing client latency when firing a weapon to then do hitbox rewinding on server…
When client fires weapon, send client time…
MyMessages.FireWeaponMessage shot = new MyMessages.FireWeaponMessage();
shot.timeStamp = NetworkTransport.GetNetworkTimestamp(); // timeStamp is an int in message class
NetworkManager.singleton.client.Send((short) MyMessages.MyMessageTypes.FIRE_SHOT, shot);
In the server handler for fire weapon messages calculate this clients shot latency… unpack the clients time and pass it to the GetRemoteDelayTimeMS() on server
private void OnServerShotMessage(NetworkMessage netMsg)
{
MyMessages.FireWeaponMessage msg = netMsg.ReadMessage<MyMessages.FireWeaponMessage>();
byte error;
int delay = NetworkTransport.GetRemoteDelayTimeMS(netMsg.conn.hostId, netMsg.conn.connectionId, msg.timeStamp, out error);
Debug.Log("Remote latency from client: " + delay + "ms");
}
This is logging seemingly accurate latency times. Local client/host logs “0ms”… “remote”(on same machine) is logging between “5ms” to “30ms” while bullets are flying. I’m going to hook it up with the network simulator then to make sure everything is actually accurate then. I could be do something wrong. I just threw it together
It’s exactly the way I am doing it, except that I am using the low level API so I don’t use the NetworkMessage Mine still fails with really weird delay times.
I also encountered a new problem, I have a setup message that I send to the server when the client successfully connected. When I use the ReliableSequenced channel type, it only works once - disconnecting and then reconnecting will send the message, but the server never receives it. Just using the Reliable channel type always works. It’s not a problem for this specific message, but I wonder what that would do the message where I rely on the order (other setup stuff, that requires other things to be setup before).
Any ideas about that, anyone?
Hi Rei
It was long time ago when I did implement that probably something has been broken. So, report the bug please about timestamp (and attach your project please as i will need to check other digits).
Other problem (about ReliableSequenced ) is definitely bug and it has been already fixed and will be in patch 1.
Noticed something else while creating the minimal example (changed the low level example slightly for that) - it only appears on the client, and the received delay time slowly approaches a normal value after a while. (Which is still a problem for my case, as I only need the delay once at the beginning)
I just noticed I was still encountering this same problem even after updating to 5.1.1p2. Can anyone else confirm whether this has been fixed in the latest version.
ok, timing service has been fixed and will be available in 5.1.2 patch 1.
rtt measurement and other low level statistic function have been fixed as well and most probably will be available in 5.1.2 patch 1 (or less probably patch 2)
Mine still fails with really weird delay times.