Implement TransactionOrder

[c0dingnoobi]

This check looks for transactions being cancelled by the client.
Vanilla will never cancel sent transactions.
When client cancels a transaction and starts to resend them, the order will be off. By implementing

This has been tested from 1.8 to 1.19 on different servers without falses (has been running the past two months). I have still added this as expiremntal check to make sure.
Credits to @iFlamingoz for making this 1.8+ compatible
Additional credits to @f4n74z14 for making this extremely simplified

[f4n74z14]

Hello! This check needs to verify if transaction initialy sent by player (server should anwser the transaction), I think it can be done by not processing ID if its higher than 0, or checking if player sent not accepted transaction.

[c0dingnoobi]

needs to verify

can u explain why u think this should be needed
the initial thought of this check is to be sure that a client received and responded to a sent transaction
not the other way around
some bypasses (as the velocity explained in #1056) only work by cancelling (so not responding) them

it shouldnt also be a problem to check for all send transactions by the server and not only grims since every sent transaction will get received and responded by vanilla (unless there is something i am missing)

[f4n74z14]

can u explain

Sure, because when client interacting with inventory it sends transaction to server for synchronization. In that case client sends thansaction that does not expected by the server and flags.

I tested this on a 1.12.2 server, joining from a 1.8.9 vanilla client. (With ViaBackwards, ViaRewind and ViaVersion installed)

Small PoC (i changed messages for a bit): https://i.imgur.com/D8OSkDy.png

[MWHunter]

vanilla only sends positive transaction ID's and grim only sends negative.

[SamB440]

Did you test this on a proxy? Between switching servers sometimes a transaction packet can leak over to the server they switched to when it was intended for the other server (at least I encountered this issue on Velocity).

[ItsClairton]

Yes, this problem happens because of packets leaking during server switching, and this happens on Velocity and bungee.

An alternative would be to set it to disregard transaction errors for a few seconds after entering the server.

[c0dingnoobi]

Implemented both suggestions (join exception and only tracking grims transactions)
anyone able to test if latest commit falses?

[AoElite]

@c0dingnoobi Can you rename the field name so its not named atomic boolean & make sure the check is set to experimental. You could add the check to the configuration as well if you want.

[c0dingnoobi]

Done, was already set to experimental sooo didn't had to change it

[c0dingnoobi]

@AoElite
anything left?

[c0dingnoobi]

Imo having LinkedHashSet instead of ArrayList is kind of redundant since i am using ArrayList to get the first element of that LinkedHashSet to avoid iterator
Still did it since you once mentioned in discord to use it instead of an ArrayList

[AoElite]

Transaction order is a bit strange. Sometimes the transactions are not being sent in the correct order sometimes even for vanilla clients.

[c0dingnoobi]

Transaction order is a bit strange. Sometimes the transactions are not being sent in the correct order sometimes even for vanilla clients.

Never came across to something like that, check has been running for months on 1.8 and 1.19 (since last month even 1.20).
Can you show some examples where you experienced any kind of order falses/issues.