[SPIGOT-7829] Configurable plugin message size limit Created: 14/Jul/24  Updated: 25/Dec/24  Resolved: 16/Jul/24

Status: Resolved
Project: Spigot
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Jim C K Flaten Assignee: Unassigned
Resolution: Fixed Votes: 1
Labels: None

Attachments: PNG File image-2024-07-15-21-42-51-683.png     PNG File image-2024-07-16-15-23-21-003.png     PNG File screenshot-1.png    
Version: 1.1 -> 1.21
Guidelines Read: Yes

 Description   

In 2012 Dinnerbone introduced the plugin message system in Bukkit, which includes a validation method for outgoing messages that checks their length against a seemingly arbitrary value of 32 kB. This limit has since been left alone and is inherited by all other major implementations that use Bukkit, including Spigot.

Dinnerbone wrote a blog post about this system where he mentions the limit and proposes that developers split their data across multiple messages if the limit is an issue.

This initially appears like a good idea to perhaps prevent a plugin from blocking the connection for too long by sending massive amounts of data, however as far as I can tell this actually has to technical benefit, and only serves to complicate the logic on both the sending and receiving side in order to reassemble the data, since rapid-firing multiple messages from the same thread still ends up blocking the connection as if they were a single big message.

Other popular systems such as Fabric and Forge have no such limit in place, and it is not enforced in the vanilla client either. It is only present in Bukkit.

I propose that this limit is either removed or at the very least made configurable.

 Comments   
Comment by Jim C K Flaten [ 16/Jul/24 ]

md_5 Thanks for the quick turnaround 🙌

EDIT: Confirmed working. No more holes in the world!

Comment by Jim C K Flaten [ 15/Jul/24 ]

Hah, yeah you're right about that.

Comment by md_5 [ 15/Jul/24 ]

I think that's fine. Also looks like the current limit is actually off by one anyway (32766 vs 32767)?

Comment by Jim C K Flaten [ 15/Jul/24 ]

md_5 Okay cool, that's sort of good news I guess! How would you feel about increasing the limit to match the client? Having 1 MB to play with is plenty for us.

Comment by md_5 [ 15/Jul/24 ]

Yes that's correct

Comment by Jim C K Flaten [ 15/Jul/24 ]

md_5 Hm, interesting. Apologies for not double checking that. Is it used when receiving data though? It was an assumption based on observing the behavior of the networked branch of Distant Horizons, which transmits large amounts of compressed binary data over plugin messages.

I am working on a Bukkit implementation of the server-side of this, since their own code currently requires either Fabric or Forge, which might not be feasible for everyone (including myself). The generated LOD data, which represents an area of 64x64 blocks, often ends up exceeding this 32 kB limit even after implementing optimizations to only send visible areas and adding compression.

The result is giant holes in the world, as shown in this screenshot:

EDIT: According to People On The Internet™️, there are 2 limits: One for client to server, and one for server to client - and they are 32 kB and 1 MB respectively. Can you confirm? If so, Bukkit is enforcing the client to server limit on server to client messages.

EDIT 2: I am not familiar with client side code at all, but can find multiple instances of `MAX_PAYLOAD_SIZE`, and the file/class names suggest the above claim might be correct:

Comment by md_5 [ 15/Jul/24 ]

The limit is absolutely in Vanilla:

    private static final int MAX_PAYLOAD_SIZE = 32767;

Technically, it means that you never have to allocate a buffer more than 32 kB, so you can cap the memory usage used by a connection that way.

I'm not aware of any Vanilla packet that sends even close to this amount of data from server->client. What's the use case?

Generated at Tue Apr 22 07:03:26 UTC 2025 using Jira 10.3.5#10030005-sha1:190c783f2bd6c69cd5accdb70f97e48812a78d14.