Tighter pipeline control

[TheMode]

Velocity (and other proxies as well) currently lack many guarantees that could be retrieved by hiding the Netty pipeline and introducing a new API, stricter, but still allowing custom protocols and plugins such as ViaVersion & general purpose packet listeners.

Here are the hotspots with no plugins but a lot of active connections:

1. Compression
2. Decompression
3. Pooled buffers management

Those concerns could be highly mitigated by moving some of the work to the backend and warning Velocity each time a packet has been modified by a third party. This warning is the most important part of the suggestion since it allows:

• packets not to be re-compressed if unmodified
• packets not to be re-compressed if you are using the same version as the backend and ViaVersion is installed
• packet listening (providing the payload would likely be enough) without hurting the rest of the pipeline

Decompression could be improved by allowing a third party to modify the packet header (to include the packet id) and force others to explicitly register which packets they are interested in. Compression is still about x4-5 more expensive making it a niche use-case where a fork could work just as well.

Pooled buffers are great (and pretty much mandatory when using netty handlers), but the above suggestion could change the current pipeline setup to a single class responsible for handling the current protocol & appending third party listeners, using only a few ThreadLocal buffers (Potentially Netty's FastThreadLocal)

Overall, my suggestions are to drastically improve Velocity performance by being able to trust in/outgoing traffic, while avoiding conflict when multiple plugins try to inject themselves in the pipeline.

[Janmm14]

Has there been any effort made about this issue? Also one could stop decompression early once the packet id has been decompressed and nobody wants to edit the packet. Via-Plugins on proxy are not supported by modern tight anticheats anyway.