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

Make an encoder that does not require ownership of the underlying buffer #2054

Open
dlrobertson opened this issue Aug 17, 2024 · 3 comments
Open

Comments

@dlrobertson
Copy link
Contributor

See neqo-transport/src/tparams.rs:690:

    // TODO: Modify to avoid a copy.
    let mut enc = Encoder::default();
    self.local.encode(&mut enc);
    assert!(enc.len() <= d.len());
    d[..enc.len()].copy_from_slice(enc.as_ref());

It should be possible to create a codec that doesn't require ownership of the underlying buffer. My underlying long-term goal would be something akin to what we had for smoltcp, where the packet structure was able to abstract over mutability (e.g. the ipv6 Packet structure).

@dlrobertson
Copy link
Contributor Author

This TODO has bugged me for a while and I have a long flight with a good bit of time in the airport today 😆 so I'll make a first pass at doing this... Comments and critiques on this are very much appreciated.

@mxinden
Copy link
Collaborator

mxinden commented Aug 18, 2024

👍 we will need an Encoder encoding into an externally managed buffer (send buffer) as part of #1693 as well.

@dlrobertson
Copy link
Contributor Author

TL;DR

I let my enthusiasm get the better of me 😆 The current usage of the Encoder structure doesn't really play well with a backing buffer that is not growable.

Problem

There are some cases where the Encoder's capacity is treated as a limit (e.g. the neqo-thransport PacketBuilder). I think cases like this could play nice with a backing buffer of a fixed size with a managed offset. There are however many locations where this doesn't work so well, so I think it would be a significant lift to get a strict "smoltcp-like" packet structure.

Possible solution

I think the easiest solution would be to introduce a enum for the buffer backing the encoder with a Borrowed variant for slices and a Owned variant for Vec, similar to ManagedSlice. On encode, the Borrowed case could assert that the buffer still has space, and the Owned case could expand in size if needed. There may be other solutions, but I think this would be the simplest to implement. Comments and critiques would be very much welcomed.

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