geforkt von Mirrors/Paper
c5a10665b8
Spigot still maintains some partial implementation of "tick skipping", a practice in which the MinecraftServer.currentTick field is updated not by an increment of one per actual tick, but instead set to System.currentTimeMillis() / 50. This behaviour means that the tracked tick may "skip" a tick value in case a previous tick took more than the expected 50ms. To compensate for this in important paths, spigot/craftbukkit implements "wall-time". Instead of incrementing/decrementing ticks on block entities/entities by one for each call to their tick() method, they instead increment/decrement important values, like an ItemEntity's age or pickupDelay, by the difference of `currentTick - lastTick`, where `lastTick` is the value of `currentTick` during the last tick() call. These "fixes" however do not play nicely with minecraft's simulation distance as entities/block entities implementing the above behaviour would "catch up" their values when moving from a non-ticking chunk to a ticking one as their `lastTick` value remains stuck on the last tick in a ticking chunk and hence lead to a large "catch up" once ticked again. Paper completely removes the "tick skipping" behaviour (See patch "Further-improve-server-tick-loop"), making the above precautions completely unnecessary, which also rids paper of the previous described incompatibility with non-ticking chunks.
28 Zeilen
2.2 KiB
Diff
28 Zeilen
2.2 KiB
Diff
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
|
|
From: Gegy <gegy.dev@gmail.com>
|
|
Date: Mon, 26 Aug 2024 19:45:07 +0200
|
|
Subject: [PATCH] Fix: synchronise sending chat to client with updating message
|
|
signature cache
|
|
|
|
In the case where multiple messages from different players are being processed in parallel, there was a potential race condition where the messages would be sent to the client in a different order than the message signature cache was updated. However, the cache relies on the fact that the client and server get the exact same updates in the same order. This race condition would cause the caches to become corrupted, and any future message received by the client would fail to validate.
|
|
|
|
This also applies to the last seen state of the server, which becomes inconsistent in the same way as the message signature cache and would cause any messages sent to be rejected by the server too.
|
|
|
|
diff --git a/src/main/java/net/minecraft/server/network/ServerGamePacketListenerImpl.java b/src/main/java/net/minecraft/server/network/ServerGamePacketListenerImpl.java
|
|
index 589214abe82c2acf6bbfda54b25f9385a6b575c4..fcccf989c25f0a259b160c4ff7873f7009e64d14 100644
|
|
--- a/src/main/java/net/minecraft/server/network/ServerGamePacketListenerImpl.java
|
|
+++ b/src/main/java/net/minecraft/server/network/ServerGamePacketListenerImpl.java
|
|
@@ -2715,8 +2715,12 @@ public class ServerGamePacketListenerImpl extends ServerCommonPacketListenerImpl
|
|
return;
|
|
}
|
|
// CraftBukkit end
|
|
+ // Paper start - Ensure that client receives chat packets in the same order that we add into the message signature cache
|
|
+ synchronized (this.messageSignatureCache) {
|
|
this.send(new ClientboundPlayerChatPacket(message.link().sender(), message.link().index(), message.signature(), message.signedBody().pack(this.messageSignatureCache), message.unsignedContent(), message.filterMask(), params));
|
|
this.addPendingMessage(message);
|
|
+ }
|
|
+ // Paper end - Ensure that client receives chat packets in the same order that we add into the message signature cache
|
|
}
|
|
|
|
public void sendDisguisedChatMessage(Component message, ChatType.Bound params) {
|