auto">My notes for this feature.

We need the compression to happen in the context of the thread requesting things.

This means:

on the write path, we should compress in the grpc_call_start_batch call tree
on the read path, we should decompress in the grpc_completion_queue_next call tree

One idea to do this cleanly (my preferred currently):

grpc_byte_buffer_type picks up a GRPC_BB_COMPRESSED_SLICE_BUFFER type
grpc_call_start_batch passes these buffer types through when it sees them, and tries to compress based upon channel configuration if not
grpc_byte_buffer_reader learns to decompress

Please make grpc_byte_buffer_reader stack allocated (change grpc_byte_buffer_reader_create to grpc_byte_buffer_init as part of this work).

The grpc_call_start_batch API will need a bit when writing indicating that a particular message is NOT to be compressed. This is a security requirement to prevent CRIME/BEAST style attacks.

We will want a channel level option to enable/disable compression.

grpc_begin_message will need a bit to specify compressed or not. stream_encoder.c will need to be updated to interpret it. frame_data.c and grpc_sopb_add_begin_message will need to act upon this bit. Probably http_client_filter.c will also need to act upon this bit.

Actual support for compression. #1795

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions