Use relative timestamps

[TrippleAWap]

Closer follow the logic of MCBE's RakNet implementation.

[irrld]

This is incorrect, you need to handle the pong timestamp as well.

Network/transport-raknet/src/main/java/org/cloudburstmc/netty/handler/codec/raknet/common/RakSessionCodec.java

Line 844 in 0eb940a

public void recalculatePongTime(long pingTime) {

Additionally, this is not required. The client simply sends what it has received so we can calculate round trip time by subtracting it from the current time. This makes things more complex without any reason.

[TrippleAWap]

You're correct this isn't required but the RakNet implementation used in MCBE populates the ping and pong field with a timestamp which is relative to the system or process start time (varies across platforms.)

[TrippleAWap]

You're correct this isn't required but the RakNet implementation used in MCBE populates the ping and pong field with a timestamp which is relative to the system or process start time (varies across platforms.)

The 1st provided picture was actually after the pong but you should get the idea.

[TrippleAWap]

This is incorrect, you need to handle the pong timestamp as well.

Network/transport-raknet/src/main/java/org/cloudburstmc/netty/handler/codec/raknet/common/RakSessionCodec.java

Line 844 in 0eb940a

public void recalculatePongTime(long pingTime) {

Additionally, this is not required. The client simply sends what it has received so we can calculate round trip time by subtracting it from the current time. This makes things more complex without any reason.

Also calculating round trip time would be essentially the same, we'd just be subtracting timestamp.

[irrld]

Are you sure that getPing returns the correct ping?

[irrld]

we'd just be subtracting timestamp.

Yes but you are not subtracting the same timestamp. And why do two extra subtraction operations when it already works? There is no point for this, it just adds extra complexity.

[irrld]

The correct solution is not this. Correct solution would be to use System.nanoTime() / 1_000_000, because the System.currentTimeMillis() change with the system time. Actual raknet behavior probably is using monotonic time, not subtracting start time like this.

[TrippleAWap]

This is exactly the same except we're using RakUtils.timestamp() instead of System.currentTimeMillis() not much of a change but I would like to follow the MCBE's implementation as close as possible.

[irrld]

I think you should remove the start timestamp part, nanoTime is already what you want

[TrippleAWap]

It isn't though, as seen in the screenshot provided the client and bedrock dedicated server both provide timestamps relative to the system or process start time.