Reuse Framed buffers with new codec

[1tgr]

I'm attempting to use multiple codecs on a single stream: my protocol (WebSockets) has an initial handshake before the data frames are processed. I have two codecs for this, one for the handshake and one for the data frames.

After the handshake codec is done, I'd like to reuse the read and write buffers from the Framed with a new codec. In the deprecated tokio_io::codec codebase I can do this by calling Framed::from_parts(old_framed.into_parts(), new_codec). But in #394 the codec instance was moved inside the FramedParts struct and Framed::from_parts can no longer take the new_codec parameter.

How should I be doing this in terms of tokio_codec functions?

[1tgr]

I have this workaround:

fn set_codec<T: AsyncRead + AsyncWrite, C1, C2: Encoder + Decoder>(framed: Framed<T, C1>, codec: C2) -> Framed<T, C2> {
    let parts1 = framed.into_parts();
    let mut parts2 = Framed::new(parts1.io, codec).into_parts();
    parts2.read_buf = parts1.read_buf;
    parts2.write_buf = parts1.write_buf;
    Framed::from_parts(parts2)
}

But it seems like Framed<T, U> needs a set_codec method that returns Framed<T, U2>, or likewise on FramedParts<T, U>.

[carllerche]

An interesting case. It feels pretty specialized, but also that it should be better supported.

We could possibly add fn from_framed(framed, codec) that takes a framed instance and a new codec.

Thoughts?

[1tgr]

Yep, from_framed(framed, codec) would do the job.

Here is where I ended up using my workaround:
https://github.com/1tgr/rust-websocket-lite/blob/d3594c08124fcabd03ebb87a086e811e2b925ac1/src/client.rs#L187-L194

[carllerche]

One issue @seanmonstar raises is that you might want to take ownership of data form the first codec and move it into the second codec. My proposed API would not solve that.

[carllerche]

We could add map_codec(|old_codec| build_new_codec(old_codec)) instead.

[carllerche]

I think the solution for this will be to switch to using AsyncBufRead instead of a custom solution. That said, the trait needs to be tweaked to support our use case.

[bschwind]

I think the solution for this will be to switch to using AsyncBufRead instead of a custom solution.

@carllerche can you expand a bit on how the AsyncBufRead trait will solve this issue?

[carllerche]

Refs: #2428

A BufReader will contain the buffer as well as the stream. This type can be removed from the codec and passed to a new one.

I am going to close this issue as it is relatively low priority and is blocked on #2428. However, once #2428 happens (soonish), anyone should feel free to attempt this work.

[saiintbrisson]

As #2428 and #2896 have been put aside, are there any other blockers for this implementation? If not, I'd be willing to work on it.

[Darksonn]

I'm not aware of any blockers.