Skip to content
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

Support for ring buffers or buffer-spanning messages #32

Open
dcsommer opened this issue Dec 23, 2019 · 1 comment
Open

Support for ring buffers or buffer-spanning messages #32

dcsommer opened this issue Dec 23, 2019 · 1 comment

Comments

@dcsommer
Copy link

I've been reading through the API of untrusted and it seems great for parsing network messages in general, but there are a few edge cases I'm wondering how to handle and it seems there may be a slight gap in the API. Sometimes a logical message (e.g. a TCP frame) can be split across multiple packets and end up in different buffers. These buffers are typically chained together in some kind of ring buffer structure. I don't see a way to nicely splice together multiple slices and handle them as a contiguous Input.

Also, in network applications, handling partially received data is the norm. For instance, a single packet may include 1 complete message and half of the next. Using Input::read_all() would return incomplete_read if a packet doesn't contain exactly whole messages. So, it seems using Reader::new() directly would be the way to go, but the documentation of that function discourages its direct use.

@briansmith
Copy link
Owner

I'm open to doing this, but somebody else would need to do the design, initial implementation, and tests. Then I could try changing webpki to support such non-contiguous inputs, which might be pretty useful. (That would probably require changing ring's signature public key parser to support such non-contiguous inputs too.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants