Open TheMode opened 2 years ago
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.
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:
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:
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.