如何不从 C++ 连接到 gRPC C++ InProcessChannel？

Posted 2023-02-22

【中文标题】如何不从 C++ 连接到 gRPC C++ InProcessChannel？

【英文标题】：How to connect to gRPC C++ InProcessChannel not from C++?

【发布时间】：2020-12-21 08:16:14

【问题描述】：

我是trying gRPC 作为 JNI 替代方案，其想法是在 C++ 端提供 gRPC 服务，在 Java/android 端连接客户端。为了获得最佳性能，我更喜欢使用进程内通道（欢迎您的建议）。

如何使用InProcessChannel() 连接到 C++ gRPC 服务器？问题是我需要pass 一个name 用于Java 的InProcessServerBuilder。

在 C++ gRPC 测试中（例如 here）我找不到它的设置，这让我觉得 InProcessChannel 只能在纯 C++ 中使用（服务器和客户端都在 C++ 中）。 C++服务和Java客户端还能用吗？

PS。我能够为 Java-server + Java-client 做到这一点。

PPS。我发现了几个类似的 QnAs eg. here，但我想知道是否还有办法让它一起工作（可能与一些 3rd-party channel impl）。它可以在 Unix 域套接字上工作吗？

【参考方案1】：

C++ 和 Java 的“进程内”传输未针对多种语言在同一进程中的情况正确命名。进程内传输仅适用于每种单独的语言； C++ 和 Java 进程内传输无法交互。

您应该使用普通的 HTTP/2 客户端/服务器。

虽然可能存在您想要的东西，例如“共享内存”传输，但它的工作量很大，维护负担的使用量相对较少。

【讨论】：

看来 Unix Domain Socket 应该可以工作。据报道它是supported by gRPC C++，根据your answer 应该可以在Java 中实现。对？当前的问题是 Android 共享库是必需的，netty-transport-native-epoll 还没有为 Android afaik 做好准备

“普通 HTTP/2 客户端/服务器”慢了 ~ 100 倍（Socket 与 InProcess 相比）

Netty 对 Android 的优化很差，虽然它可能工作，但 gRPC 并没有正式支持它，因为我们认为它不会达到我们的期望。我通常不建议尝试让 netty-transport-native-epoll 在 Android 上运行（但似乎你做到了！）。 Android 有 LocalSocket，它在传递给 OkHttpChannelBuilder.socketFactory() 之前需要一个适配器。可能有点烦人，但这是我通常建议为 UDS 尝试的路径。

InProcess 在 Java 中非常快，部分原因是它不需要序列化 ​​protobuf 消息，并且可以通过多线程实现一些捷径。这两种优化仅适用于 Java-to-Java RPC。因此，它当前的性能并不代表您所看到的“跨语言进程内传输”的性能。我们预计这种传输只会适度提高速度，主要与减少 1-2 个 memcpy()s 有关。

我会试试OkHttpChannelBuilder.socketFactory()

【参考方案2】：

我已经接受 Eric 的 Anderson 回答是正确的。不过，了解我是如何使用 Unix 域套接字实现 working 的可能会很有用。

我必须 patch netty 对于 Android 和 use it。请注意一些特定于 Android 的权限 notes。