c++ - 将自定义传输插入gRPC

Question

假设我们为gRPC开发了一个自定义的低级传输。我们如何将其“插入” gRPC c++ API，以便可以将其用于Channel？

Answer 1

我正在研究一个文档，该文档将很快出现在https://github.com/grpc/grpc/上，但是这里有一个预览:

gRPC transports插入核心API之下(C++ API之下的一级)。您可以使用C或C++编写传输方式；尽管习惯上使用C，但目前所有的传输都名义上都是用C++编写的。现有的传输是:

HTTP/2

Cronet

In-process

在这些过程中，进程中可能最容易理解，尽管它也与基于“套接字”的“真实”传输最不相似。

在gRPC核心实现中，基本结构是 grpc_transport_stream_op_batch，它表示发送到传输的流操作的集合。批量操作可以包括:

send_initial_metadata

客户端:启动RPC

服务器:提供响应头

recv_initial_metadata

客户端:获取响应头

服务器:接受RPC

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

的输入原型(prototype)

服务器receive_message:从RPC

获取输入原型(prototype)

客户端send_trailing_metadata:这是半关闭，表示客户端将不再发送任何消息

服务器receive_trailing_metadata:服务器从客户端看到此消息，并知道它将不再收到任何消息。如上所述，该操作尚未完成。

服务器send_initial_metadata，send_message，send_trailing_metadata:批处理可以包含多个操作，并且此批处理提供RPC响应 header ，响应内容和状态。请注意，发送尾随元数据也将完成服务器对尾随元数据的接收。

客户端recv_initial_metadata:批处理一侧的操作数与批处理另一侧的操作数无关。在这种情况下，客户端只是收集响应头。

客户端recv_message，recv_trailing_metadata:获取数据响应和状态

除了这些基本的流操作外，传输还必须在任何时候处理流的取消并将其影响传递给另一端。传输必须执行诸如ping和统计之类的操作，这些操作可用于塑造诸如流量控制之类的传输级特征(例如，请参阅它们在HTTP/2传输中的使用)。