qq_41278986的博客

当存在调用链时，在调用链上的每个调用的 Timeout 相同，但是其超时的时间点是不同的，因为调用的触发点不同。Deadline 则不同，Deadline 指定的时间点对每个调用来说都是相同的，所以调用链会同时超时。gRPC 允许在同一个 server 上运行多个 gRPC 服务，在一个 gRPC client 连接上使用多个 gRPC client stubs。server 在回应是总是使用 client 指定的压缩方式，如果对应的压缩器没有被注册，Unimplement 状态将会返回到 client。

它依然包含 gRPC status 和 status message，此外，它还包含其他的 header，因为只返回一个 HTTP/2 header。发送 response header 后，会使用单独的一个或几个 HTTP/2 data frame 发送 length-prefixed 消息，但是最后一个 HTTP/2 data frame 不会设置 END_STREAM flag，它在另外一个称为 trailer 的 header 中设置。gRPC 远程调用被映射到 HTTP/2 的流中。...

ProductInfo 服务的客户端和服务器交互。gRPC 使用 protocol buffer 作为接口定义语言（IDL）。ProductID 消息类型的 Protocol Buffer 定义。Product 消息类型的 Protocol Buffer 定义。1.2 Defining Services服务远程方法的定义中，Protocol Buffer 只允许一个输入参数和一个输出参数。ProductInfo 服务的 gRPC 服务定义，使用 protocol buffers指定我们使用的 p

CompletionQueueclass CompletionQueue : private ::grpc::GrpcLibraryCodegen {public: CompletionQueue() : CompletionQueue(grpc_completion_queue_attributes{ GRPC_CQ_CURRENT_VERSION, GRPC_CQ_NEXT, GRPC_CQ_DEFAULT_POLLING, nullptr}) {} explicit Comple

GRPC Connection Backoff Protocol当我们向一个失败的后端进行连接时，通常不希望立即重试(为了避免请求flooding网络或者服务器) ，而是去做一些某种形式的指数backoff。我们有几个参数：INITINAL_BACKOFF(第一次失败后的重试需要等待多长时间)MULTIPLIER(在一次失败的重试后，backoff的乘回因子)JITTER(随机backoffs的程度)MAX_BACKOFF(backoff 的上界)MIN_CONNECT_TIMEOUT(我们

1. OutlineGRPC的请求&响应消息流中的消息原子的一般序列如下：Request->Request-Headers*Length-Prefixed-Message EOSResponse->(Response-Headers*Length-Prefixed-Message Trailers)/Trailers-Only2. RequestsRequest -> Request-Headers*Length-Prefixed-Message EOSReque

本文档用于证实客户端能够以正确的backoffs重连服务器。测试服务器有一个端口(控制端口)，运行控制服务器的rpc服务，另一个端口(重试端口)来关闭任何进入的 tcp 连接。测试有下述流：服务器开始在控制端口上监听。客户端调用在服务器控制端口上调用一个rpc。服务器开始在重试端口上监听。客户端使用backoffs连接服务器的重试端口，尝试540s，也就是大约13次重试。客户端在服务器控制端口上调用停止服务器。客户端检查响应，看服务器是否认为backoffs符合规范，或者对响应种的backof

Streaming write buffering通常，每个写操作(Write()，WriteDone())意味着一个系统调用。gRPC将尝试批处理不同线程分开的写处理，但是现在不能自动推断单个流的批处理。如果流种的消息k+1不依赖消息k的响应，通过向Write传递WriteOptions参数buffer_hint_set，可能能激活写批处理。stream_writer->Write(message, WriteOptions().set_buffer_hint());write将被缓存直到

本文档描述gRPC channels 连接语义和对 RPCs 的相应影响。然后我们讨论API。States of ConnectivitygRPC Channels 提供一种抽象，在其之上客户端可以与服务器通信。客户端方面的 channel 对象仅使用一个DNS名就能够被构造。Channels 封装了一系列功能，包括名称解析，建立tco连接(包含重连和backoff) 和 TLS 握手。Channels也能在已建立的连接上处理错误或者重连，或者在HTTP/2 GO_AWAY的情况中，重新解析名称或重连。

GRPC Health Checking Protocol健康检查用于侦测是否服务器能够处理rpcs。客户端向服务器的健康检查能点到点的进行，或者通过一些控制系统。服务器可能选择回复 “unhealthy”，因为没有准备好接受请求，正在关闭或者一些其他原因。客户端可以依据在一定的time window内没有收到消息，或者响应回复unhealthy。一个简单的GRPC服务被用作健康检查机制，不论是简单的 client-to-server 情境还是其他控制系统例如load_balancing。作为一个高层级

Ordering Status and Reads in the gRPC API实现的规则：状态被传递后读写不能成功。状态仅在所有的缓存消息被读取后才能递交。在一个写操作失败后，读操作可能会接着成功。但是一旦写操作失败后，随后的写操作必须失败，同理，一旦读操作失败后，随后的读操作一定失败。从服务器接收的non-OK状态不认为是一个错误状态。当库已知一个错误状态，如果用户请求状态，库应当丢弃库中收到的消息，不向用户递交，然后递交状态。如果用户不请求状态继续读，库应当在递交状态之前递交缓存的消息

Keepalive User Guide for gRpc Core(and dependents)keepalive ping 是一种检查 channel 当前是否在工作的方式，通过在通信端口上发送HTTP2 pings 的方式。他会定期的发送，且如果在特定的时间内，对端没有确认ping，通信端口断开连接。keepalive ping 由两个重要的 channel 参数控制-GRPC_ARG_KEEPALIVE_TIME_MS这个 channel 参数在keepalive ping 在通信端口

gRPC ContextServerContextServerContext 或 CallbackServerContext 允许 code 实现一个 service handler 来：添加自定义初始化和尾部的元数据键值对，并向客户端 side 发送。控制调用设置例如压缩和权限验证。访问来自客户端的元数据。获取性能度量(例如，统计)。Context 设置仅与被提供的调用handler相关，这就是说，它们不能再多个调用中传递。这些设置中的某些，例如压缩选项，能够在服务器构造上成为永久的设置

ProtoBufferWriterprotobuf 类 ZeroCopyOutputStream的一个特化。原理是一次给予proto层一个字节的buffer，它能够被用于序列化消息的下一部分，如果上一次被分配的buffer多余需要的，使用选项"backup"。class ProtoBufferWriter : public ::grpc::protobuf::io::ZeroCopyOutputStream {public: ProtoBufferWriter(ByteBuffer* byte_b