Compressed Framed TCP streams

[mrd0ll4r]

Hey,
I'm running a setup in which I'm sending and receiving Framed messages via TCP. Specifically, it looks something like this:

Struct -> JSON -> Framed -> TCP -> Framed -> ...

Now, this is using quite a lot of bandwidth. I can't swap out the JSON part for legacy reasons, so I thought about compression instead.
I see two approaches, each with their own drawbacks.

This is the first:

Struct -> JSON -> gzip -> Framed -> TCP -> ...

This is relatively straightforward. I get a bunch of bytes by JSON-encoding, I compress those bytes and pass them on to be framed and sent.
However, this is probably suboptimal wrt. compression, as the compressor state is reset for each message. (see edit below, I was confused)

A solution to fix that would be this construction:

Struct -> JSON -> Framed -> gzip -> TCP -> ...

This makes sense in my head because gzip is a streaming algorithm.
The Framed docs state that:

This function returns a single object that is both Stream and Sink; grouping this into a single object is often useful for layering things like gzip or TLS, which require both read and write access to the underlying object.

Which makes me believe this is the proper way to do this. However, after searching for quite a while, I cannot find anything that provides a unified gzip reader and write. I could use the async compression crate and something like duplexify to... split the TCP stream, add gzip compression/decompression, merge it back together, and then add framing on top?

In addition to that, I'm worried about flushing the gzipped TCP stream. In particular, I'm wondering if something like this works or deadlocks:

Two hosts A and B, with the second construction from above:
A sends small handshake message to B while waiting for B's handshake message
B sends small handshake message to A while waiting for A's handshake message

EDIT: While re-reading my question and the docs, it seems the first approach is the intended one (i.e., layering gzip on top of framing). I think I was confused because Framed also wants a unified Stream/Sink, so I thought that was the one the docs were talking about.
Maybe the intended usage is to send gzipped chunks, one for each message, without resetting the encoder in between?

I am now utterly confused. Is there a recommended way of doing this?

[Darksonn]

Unfortunately, I don't know whether gzip has support to avoid the deadlock you mentioned, but using it on the message layer should work.

[mrd0ll4r]

Hmm I see. So I'd compress each message seperately? Or would frame blocks of an ongoing gzipped stream of framed messages? The latter seems better compression-wise, but I'd end up with a problem like this.
I'm thinking of a construction like this, which I'll try to implement:

Struct -> JSON -> framing -> one gzipped stream -> framed gzip chunks -> TCP

I'll let you know how that goes, maybe it can help others too :)

Thanks!