-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use composite buffers where possible #3737
Conversation
This should reduce memory allocations
This should crash for native encryption for packets with size smaller than encryption threshold, as native encryption also requires a singular memory address which a composite bytebuf cannot deliver. |
oh you're probably right i tested it on an arm server (custom natives are not supported) |
The naming of
https://github.com/SpigotMC/BungeeCord/blob/master/proxy/src/main/java/net/md_5/bungee/netty/ChannelWrapper.java#L172 (i would just leave out the logic to re-enable canUseComposite on compress removal if cipher not present tho) |
sounds logic and simple, i will change it. |
why isn't it simple to just set useComposite to true again? |
The prepender is an instance (its shared), should we create a new one per connection, or should we add another class and switch them in the pipeline. I prefer per channel Varint21LengthFieldPrepender |
Yeah I would un-share it (change to per-connection) instead of replacing the impl.
I thought that, as the minecraft protocol does not support this and when it was supported it could cause problems due to missing acknowledgement packet (as the threshold applies both ways), we could just not care about this potential performance penalty when compression is removed. |
I don't think that it could break anything. As there are no raceconditions because evey operation is performed on the same thread right? (its not possible that somehow this boolean is changed while a packet write or read in the pipeline is processed) But i will test what happens if i change the compression multiple times |
Oh yeah then the prepender should be per-channel.
Well its possible, doesn't care, but as its a code path that's essentially unused |
purely codewise looks good to me now! |
{ | ||
ByteBuf buf = ctx.alloc().directBuffer( headerLen ); | ||
DefinedPacket.writeVarInt( bodyLen, buf ); | ||
list.add( ctx.alloc().compositeBuffer( 2 ).addComponents( true, buf, msg.retain() ) ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason why this isn't a direct composite but the compressor is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By default it should use direct in the impl but i can just call directCompositeBuffer method.
I will change it
@md-5 this commit is causing all sorts of issues with various plugins, as has been reported to me by a few other server owners, not to mention it broke floodgate as well, thus I can't even properly test myself. |
If it's a plugin not using the API then it's not really a bungee issue. Given that networking isn't exposed to plugins this is almost certainly the case. |
Floodgate accessed a private static final field that does not exist anymore. |
@andrewkm i fixed the floodgate issue |
Thank you! :) |
i think this should reduce memory allocations
I have tested it, its running without any issues for me.
But i did no perfromace tests for now, so they are welcome.