小智
5
我正在研究一个文档，该文档将很快出现在https://github.com/grpc/grpc/上，但这是一个预览：
gRPC传输插件在核心API之下（C ++ API之下的一级）。您可以使用C或C ++编写传输方式；尽管习惯上使用C语言，但目前所有的传输都名义上都是用C ++编写的。现有的传输是：
在这些过程中，进程中可能最容易理解，尽管它与基于“套接字”的“真实”传输最不相似。
在gRPC核心实现中，基本结构是，grpc_transport_stream_op_batch它表示发送到传输的流操作的集合。批量操作可以包括：
- send_initial_metadata
- recv_initial_metadata
- send_message（零个或多个）：发送数据缓冲区
- recv_message（零个或多个）：接收数据缓冲区
- send_trailing_metadata
- 客户端：半关闭，表示将不再收到任何消息
- 服务器：全封闭，为RPC提供最终状态
- recv_trailing_metadata：获取RPC的最终状态
- 额外的服务器：在服务器还发送了尾随的元数据以向另一端提供最终状态之前，实际上不应认为此操作已完成
- cancel_stream：尝试取消RPC
- collect_stats：获取统计信息
这些操作中的一个或多个被分为一组。应用程序可以在一个批次中启动所有呼叫操作，也可以将它们拆分为多个批次。每个批次的结果都通过完成队列异步返回。
在内部，我们使用回调来指示完成。开始新批处理时，表面层创建一个回调，并将其与批处理一起发送到过滤器堆栈中。批处理完成时，传输必须调用此回调，然后表面层通过完成队列将事件返回给应用程序。每批最多可以有3个回调：
- recv_initial_metadata_ready（在recv_initial_metadata操作完成时由传输调用）
- recv_message_ready（在recv_message操作完成时由传输调用）
- on_complete（在整个批处理完成时由传输调用）
运输的工作是对基本流操作的各种可能的插入进行排序和解释。例如，批次的示例时间轴将是：
- 客户端send_initial_metadata：使用路径（方法）和权限启动RPC
- 服务器receive_initial_metadata：接受RPC
- 客户端send_message：提供RPC的输入协议
- 服务器receive_message：从RPC获取输入原型
- 客户端send_trailing_metadata：这是半关闭时间，表示客户端将不再发送任何消息
- 服务器receive_trailing_metadata：服务器从客户端看到此消息，并知道它将不再收到任何消息。如上所述，该操作尚未完成。
- 服务器send_initial_metadata，send_message，send_trailing_metadata：一个批处理可以包含多个操作，并且该批处理提供RPC响应标头，响应内容和状态。请注意，发送尾随元数据也将完成服务器对尾随元数据的接收。
- 客户端recv_initial_metadata：批处理一侧的操作数与批处理另一侧的操作数无关。在这种情况下，客户端只是收集响应头。
- 客户端recv_message，recv_trailing_metadata：获取数据响应和状态
除了这些基本的流操作外，传输还必须在任何时候处理流的取消并将其影响传递给另一端。传输必须执行诸如ping和统计之类的操作，这些操作用于塑造诸如流量控制之类的传输级特征（例如，请参见HTTP / 2传输中的用法）。