diff options
| author | Piotr Morgwai Kotarbinski <foss@morgwai.pl> | 2021-09-08 04:07:56 +0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2021-09-07 14:07:56 -0700 |
| commit | 483e11ddc3d90fb902b7759dd88477ec61ed5a68 (patch) | |
| tree | 1e3c0f26b27cbd825d8d05bfd6a1cbb5f2fd7286 /CONCEPTS.md | |
| parent | 17174976b6b613bf6d2e41d8b17a75b57252d8ae (diff) | |
| download | grpc-grpc-483e11ddc3d90fb902b7759dd88477ec61ed5a68.tar.gz | |
Tiny update to protocol overview doc. (#26396)
* Tiny update to protocol overview doc.
Clarify client stream closing and link to more detalied HTTP/2 specific doc.
* apply review comments
* add brief HTTP/2 client stream closing mechanism explenation
* reword to differentiate HTTP/2 stream from gRPC message stream
* apply review comments
Diffstat (limited to 'CONCEPTS.md')
| -rw-r--r-- | CONCEPTS.md | 5 |
1 files changed, 3 insertions, 2 deletions
diff --git a/CONCEPTS.md b/CONCEPTS.md index f78be0ce64..c85974ed87 100644 --- a/CONCEPTS.md +++ b/CONCEPTS.md @@ -54,10 +54,11 @@ clients and servers. A concrete embedding over HTTP/2 completes the picture by fleshing out the details of each of the required operations. ## Abstract gRPC protocol -A gRPC call comprises of a bidirectional stream of messages, initiated by the client. In the client-to-server direction, this stream begins with a mandatory `Call Header`, followed by optional `Initial-Metadata`, followed by zero or more `Payload Messages`. The server-to-client direction contains an optional `Initial-Metadata`, followed by zero or more `Payload Messages` terminated with a mandatory `Status` and optional `Status-Metadata` (a.k.a.,`Trailing-Metadata`). +A gRPC call comprises of a bidirectional stream of messages, initiated by the client. In the client-to-server direction, this stream begins with a mandatory `Call Header`, followed by optional `Initial-Metadata`, followed by zero or more `Payload Messages`. A client signals end of its message stream by means of an underlying lower level protocol. The server-to-client direction contains an optional `Initial-Metadata`, followed by zero or more `Payload Messages` terminated with a mandatory `Status` and optional `Status-Metadata` (a.k.a.,`Trailing-Metadata`). ## Implementation over HTTP/2 -The abstract protocol defined above is implemented over [HTTP/2](https://http2.github.io/). gRPC bidirectional streams are mapped to HTTP/2 streams. The contents of `Call Header` and `Initial Metadata` are sent as HTTP/2 headers and subject to HPACK compression. `Payload Messages` are serialized into a byte stream of length prefixed gRPC frames which are then fragmented into HTTP/2 frames at the sender and reassembled at the receiver. `Status` and `Trailing-Metadata` are sent as HTTP/2 trailing headers (a.k.a., trailers). +The abstract protocol defined above is implemented over [HTTP/2](https://http2.github.io/). gRPC bidirectional streams are mapped to HTTP/2 streams. The contents of `Call Header` and `Initial Metadata` are sent as HTTP/2 headers and subject to HPACK compression. `Payload Messages` are serialized into a byte stream of length prefixed gRPC frames which are then fragmented into HTTP/2 frames at the sender and reassembled at the receiver. `Status` and `Trailing-Metadata` are sent as HTTP/2 trailing headers (a.k.a., trailers). A client signals end of its message stream by setting `END_STREAM` flag on the last DATA frame. +For a detailed description see [doc/PROTOCOL-HTTP2.md](doc/PROTOCOL-HTTP2.md). ## Flow Control gRPC uses the flow control mechanism in HTTP/2. This enables fine-grained control of memory used for buffering in-flight messages. |