[nio] Provide support for gzip compression?

Question Checklist

• Updated grpc-swift to the latest version
• I read the Contribution Guidelines
• I read README
• I searched for existing GitHub issues (especially, there are many resolved issues related to SSL)

Question Subject

The question is whether you plan to implement support for gzip compression for nio at an upcoming release 1.0.0 or nearest future?

Question Description

Currently, the nio implementation does not support gzip compression mechanism. For applications with intense usage of networking (such as messenger) the lack of support of this compression mechanism can result in high Network and CPU consumption, as well as higher battery draining on iOS devices. This prevents nio implementation from being ready for production usage for such applications.

Implementation notes

I have my guesses on where to look at first:

• Include gzip in list of supported mechanisms
• Switch over compression in LengthPrefixedMessageWriter's write function and compress data properly according to algorithm
• Switch over compression in LengthPrefixedMessageReader's and unzip data properly, than append unzipped chunk to ByteBuffer

If you guys do not plan to do it in any nearest future, I would like to write implementation of gzip support myself, if you'll support me with a little guidance.

[MrMage]

I guess we would be open to a patch that adds gzip compression, provided that is:

1. Compatible to gRPC's compression spec,
2. Well-tested (including support for non-compressed messages on the same stream),
3. Easy to maintain,
4. Does not include our dependency surface area too much. (I guess depending on zlib should be fine, but would like to hear @glbrntt and @weissi on that.)

You might want to wait until @glbrntt's refactorings towards a state machine are finished, however.

On a more fundamental note, I would expect a messaging application to have very small payloads in general. For these, gzip might actually not improve payload sizes that much; did you verify that?

Also, how would not compressing data use more CPU time (besides slightly increasing the amount of data that might need to be copied from the networking stack).

On a more fundamental note, I would expect a messaging application to have very small payloads in general. For these, gzip might actually not improve payload sizes that much; did you verify that?

In our case there are a lot more data sent over gRPC than just text messages - updates on contacts, search results, updating chat list state etc. So the compression is more of a requirement for us. We are sure that using no compression would increase network load significantly, but may check that in profiling using current (non-nio) SwiftGRPC identity vs gzip compression.

Also, how would not compressing data use more CPU time (besides slightly increasing the amount of data that might need to be copied from the networking stack).

Yep, mistaken here, as when compressing the CPU time only increases for compression and decompression tasks.

But still, sending and receiving larger chunks of data over network increases battery drain and for an app with a lot of users we must ensure good experience and robust performance for all users, even for ones with slow download/upload speed.

[glbrntt]

If you guys do not plan to do it in any nearest future, I would like to write implementation of gzip support myself, if you'll support me with a little guidance.

This is absolutely something we would like, but it isn't a high priority at the moment. More than happy to give you guidance though!

I guess we would be open to a patch that adds gzip compression, provided that is:

1. Compatible to gRPC's compression spec,
2. Well-tested (including support for non-compressed messages on the same stream),
3. Easy to maintain,
4. Does not include our dependency surface area too much. (I guess depending on zlib should be fine, but would like to hear @glbrntt and @weissi on that.)

You might want to wait until @glbrntt's refactorings towards a state machine are finished, however.

+1 on all of this.

Regarding 4.: NIO Extras includes Zlib and has recently grown a NIOHTTPCompression module. I haven't had a chance to look into this yet but I imagine we can make use of it and it's probably the best place to start.

As a footnote: we'd also want to add the interoperability test cases for compression. This can be done at a later date though.

[glbrntt]

Hey @be4rd, FYI I just pushed up a PR to support gzip and deflate compression on the client. Hoping to work on the server component of this next week 😄

@glbrntt Very nice, thanks 😎
Waiting for an upcoming release to test out and probably migrate...

[MrMage]

@glbrntt do we have this on the server now; i.e. can we close this?

[glbrntt]

We do, and it's just been tagged in 1.0.0-alpha.10