Increase the max capacity for decompressed packets #3775
Conversation
do not use size as max capacity, as its possible that the entity rewritter increases the size afterwarts this would result in a kick (it happens rarely as the entity ids size must differ)
|
@md-5 the latest compression optimization causes disconnects so this PR has semly high priority The owner of a cracked 1.8 server encounter this issues they reverted the changes for now in their fork |
|
can we provide a more meaningful max capacity, like size + min( 5% of the size, 10) or sth like that? |
i guess the 8mb is meaningful, its the max amount of data allowed in the protocol, the player will be disconnected anyways if something missmatches. Also i am not really sure how much the packet can grow while rewritting, so i made it the protocol maximum. As its the maximum capacity not the initial size it doesn't matter anyways Also assuming the compression thresshold is 1 (every packet is compressed) And we receive a packet with length 10 and it contains a varint entity id for example 1 (should be 1 byte) and we need to rewrite it to the entityid 10000000 it may add 2 or 3 bytes but the maximum capacity is now 11 as 10% increase for a 10 bytes packet is only 1, so it will fail anyways. What i want to say is, % is only reasonable for big compression thressholds. 8mb is just 100% fail safe |
Do not use size as max capacity, as its possible that the entity rewriter increases the size afterwards. This would result in a kick (it happens rarely as the entity ids size must differ).
|
Thanks |
|
@Outfluencer Oops I meant to use max, not min in my suggestion |
do not use size as max capacity, as its possible that the entity rewritter increases the size afterwarts this would result in a kick (it happens rarely as the entity ids size must differ)