-
-
Notifications
You must be signed in to change notification settings - Fork 74
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
Allow more control over Quic channel send #775
Comments
Hi @normanmaurer. Any thoughts on this? Generally it looks like this implementation is not consistent with the Netty Framework's write/flush workflow. For example, in TCP writing to a channel simply buffers the data and does not flush it. Whereas writing to a QUIC stream channel, flushes the data. If you agree that the code needs to aligned with Netty, I would be happy to put together a few design proposals before I work on this? |
@hkhalili-ocado I am happy to review a PR. |
@normanmaurer That's great; please find below some thoughts. Current behaviourQuicStreamChannel
QuicChannel
Proposal for QuicChannel
Proposal 1 for QuicStreamChannel
Proposal 2 for QuicStreamChannel
Proposal 3 for QuicStreamChannel
I'm leaning towards proposal 2. Do you have a preference for any of them or a 4th solution? |
Currently
connectionSendAndFlush()
inQuicheQuicChannel
is called directly from within the same class and fromQuicheQuicStreamChannel
(Unsafe). This does not give any control to the user in terms of flushing. Could we instead useparent().pipeline().flush()
? This way the user can add a handler to the QuicChannel pipeline to modify flushing behaviour. If this is potentially acceptable I can start working on implementing this for review.The text was updated successfully, but these errors were encountered: