You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.)
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 returnincomplete_read
if a packet doesn't contain exactly whole messages. So, it seems usingReader::new()
directly would be the way to go, but the documentation of that function discourages its direct use.The text was updated successfully, but these errors were encountered: