假设我们为gRPC开发了一个自定义的低级传输。我们如何将其“插入” gRPC c++ API，以便可以将其用于Channel？
我正在研究一个文档，该文档将很快出现在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传输中的使用)。