Open menghanl opened 2 years ago
Moreover, the size is sent from the server in the settings frame, but the client never reads and applies it. Is that correct?
This seems fine. Our default is the minimum allowable value (16KB), so if we never send frames bigger than this (client & server), then we will never exceed the remote peer's size. We could use it and send bigger frames for potential performance gains (likely to be minimal), but it's not a correctness issue.
The frame size of the spec says the following:
The size of a frame payload is limited by the maximum size that a
receiver advertises in the SETTINGS_MAX_FRAME_SIZE setting. This
setting can have any value between 2^14 (16,384) and 2^24-1
(16,777,215) octets, inclusive.
All implementations MUST be capable of receiving and minimally
processing frames up to 2^14 octets in length, plus the 9-octet frame
header ([Section 4.1](https://datatracker.ietf.org/doc/html/rfc7540#section-4.1)).
A few things to note here:
loopyWriter
and http2.Framer
use hardcoded value of 16K for frame sizeWe probably should advertise this from the client as well, and change our loopyWriter
to make this value configurable. And we can continue to set the value to a 16K. But changing the loopyWriter
to make this configurable will be a step towards eventually making this configurable from the API.
Thoughts? @dfawley @menghanl
https://github.com/grpc/grpc-go/pull/4917 I found this change is not merged to master
See PR #3018
The max size is a const of 16k, and there doesn't seem to be a way to configure it.
Moreover, the size is sent from the server in the settings frame, but the client never reads and applies it. Is that correct?