The system as described in the issue is OK for me as it permit server owner the ability to change the values.

But when I read pmmp/BinaryUtils@8cfa34c we are agree that some cost read/write ops are missing ? (like: strings, bytes, int) And that this PR is not ready to be merged in its current state?

The system as described in the issue is OK for me as it permit server owner the ability to change the values.

But when I read pmmp/BinaryUtils@8cfa34c we are agree that some cost read/write ops are missing ? (like: strings, bytes, int) And that this PR is not ready to be merged in its current state?

Fixed size types are accounted for in get(). String is 2 operations: getVarInt() and get(). It's not dependent on the size of the type but rather the number of calls needed to decode it.

Right

I'm hung on this for now only because I'm not sure about the exact parameters to use for the accounting and limiting. May be necessary to just throw it into the wild to collect data.

If we launch it into the wild, we'll need a way of determining whether the values are globally correct or whether, on the contrary, server owners are obliged to increase them all the time.

Yeah, well unfortunately I've found that server owners tend not to engage with experiments unless I just release them as stable and wait for people to start screaming.

I can't test on my own with a large server. Could be a good idea to release it as stable and see what happened :/ (this sound very creepy).

I can't test on my own with a large server. Could be a good idea to release it as stable and see what happened :/ (this sound very creepy).

later i will test it on 2 servers with about ~80 online on each

I can't test on my own with a large server. Could be a good idea to release it as stable and see what happened :/ (this sound very creepy).

later i will test it on 2 servers with about ~80 online on each

so far I've noticed only one problem, it's the player's FPS

2025-03-24 [17:00:02.047] [Server thread/WARNING]: [NetworkSession: karikashka] Decoding InventoryTransactionPacket exceeded read ops budget! 94 > 33
2025-03-24 [17:00:04.463] [Server thread/WARNING]: [NetworkSession: kostamax27] Decoding InventoryTransactionPacket exceeded read ops budget! 94 > 31
2025-03-24 [17:00:06.053] [Server thread/WARNING]: [NetworkSession: kostamax27] Decoding InventoryTransactionPacket exceeded read ops budget! 94 > 68
2025-03-24 [17:00:06.657] [Server thread/WARNING]: [NetworkSession: kostamax27] Decoding InventoryTransactionPacket exceeded read ops budget! 94 > 60
2025-03-24 [17:00:07.965] [Server thread/WARNING]: [NetworkSession: kostamax27] Decoding InventoryTransactionPacket exceeded read ops budget! 94 > 4
2025-03-24 [17:00:08.710] [Server thread/WARNING]: [NetworkSession: kostamax27] Decoding InventoryTransactionPacket exceeded read ops budget! 94 > 28
2025-03-24 [17:00:10.360] [Server thread/WARNING]: [NetworkSession: karikashka] Decoding InventoryTransactionPacket exceeded read ops budget! 94 > 7
2025-03-24 [17:00:17.156] [Server thread/WARNING]: [NetworkSession: karikashka] Decoding InventoryTransactionPacket exceeded read ops budget! 94 > 11

but it's possible to "fix" it by simply increasing: session-budget-ticks and session-budget-per-tick

thanks mojang

Should have figured that the FPS issue would show up here too. Thanks @kostamax27

Since we're now using ext-encoding for packets, this will need to be reworked under the hood. ext-encoding doesn't currently support read ops limiting.