-
Notifications
You must be signed in to change notification settings - Fork 631
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
unbuffered: After Closed
no WriteTraffic
state arrives
#1895
Comments
Thanks for the report. Yes, the current API treats a half-close as a full-close. I think we should add additional
(This arrangement retains |
Will this need semver-incompatible changes? If so, it might take us a while to get this released. |
The |
Thanks for the quick response. There is no rush from my point of view as I also have it working with the buffered interface, and I can continue to use that. So if it's a breaking change for 0.24 that's not a problem. The API changes you suggested sound fine, but I'll code against whatever you come up with. If you want me to test against a pre-release version of Rustls I can do that. Also it would be helpful to have some guidance about buffer-sizing requirements, either in the docs or as API calls. For example I'm allowing 18KiB for |
Checklist
Describe the bug
I've updated my
pipebuf
crate Rustls wrapper in cratepipebuf_rustls
to add unbuffered Rustls support. However my tests which succeed in the buffered mode fail for the unbuffered mode. The failing test does the following:The byte sent by the server cannot be processed through the unbuffered interface because the
process_tls_records
call does not give aWriteTraffic
state again afterClosed
. Without access toWriteTraffic
, I can't send the data. The buffered interface does not have this limitation.To Reproduce
Check out
pipebuf_rustls
from github (https://github.com/uazu/pipebuf_rustls). Run a single test usingcargo test --no-default-features --features unbuffered byte_each_way
. There is an assertion failure due to 1 byte sent but 0 bytes received.Applicable Version(s)
0.23.4 on Linux
Expected behavior
I'd expect this case to be supported. I don't know how you'd want to support it with your unbuffered API though.
Additional context
The reason I added unbuffered support to
pipebuf_rustls
was that this is a much better fit to thepipebuf
model. I addedPBufRd::data_mut
topipebuf
0.3.1 to support Rustls unbuffered mode (which requires&mut [u8]
for incoming data). So I support the unbuffered effort. Just it doesn't cover all necessary cases yet.The text was updated successfully, but these errors were encountered: