Large chunk packets prevent players from logging in

Steps to produce

1. Fill a chunk from y 0 to y 255 with furnances
2. Have your victim walk into the area where the chunk will be sent to them

 

Once the above steps are completed, the victim player will be disconnected, with these logs in the console:

```

[13:24:49] [Server thread/INFO]: searchndstroy lost connection: Internal Exception: io.netty.handler.codec.EncoderException: java.lang.IllegalArgumentException: Packet too big (is 3442471, should be less than 2097152): qw@907b583

```

 

They can try to reconnect, however they will be greeted with a disconnect when the chunk is sent to them again.

Server administrators only solution to this problem is to remove the whole regionfile corresponding to the chunk. They cannot delete it by travelling there and using a tool like WorldEdit because they will also be disconnected.

 

Solutions

In 1.16.5 I used this patch:

https://github.com/Tuinity/Tuinity/blob/ver/1.16.5/patches/server/0022-Improved-oversized-chunk-data-packet-handling.patch

to resolve the issue. Basically, it split up chunk packets into several sub chunk packets corresponding to chunk sections for chunk packets that were at risk of tripping the 2MB packet limit. Not exactly the greatest fix, but I had zero other options.

 

What about 1.17? Doesn't the patch above fix it?

No. The chunk packet is now always considered to be a "full" packet, so I can no longer use it to split up the sections. I cannot use the multi set block packet, as it does not have proper handling of tile entities that the full chunk packet has (and no, the update tile entity packet will not work). The server also cannot modify the packet size limit, as the client has its own.

So in 1.17 there are ZERO workarounds that the server can apply, other than clobbering entire regionfiles. Only Mojang can fix this now.

 

Suggestions

Greatly increase the packet limit for full chunk packets. This might have to be modified later, so it would be nice to let the server control this.

 

Notes

This is a subset of the problems caused by the packet limit. Perhaps the packet limit should be per packet type? Currently the solutions to these problems is to literally just split up packets to bypass it, so I don't think increasing the limit for some packets should be off the table.