在以下情况下，实现C ++ / Java IPC的最佳方法是什么？
我有两个程序需要相互通信，一个是用C ++编写的，另一个是用Java编写的。两者都在同一台计算机上运行。
程序相互发送消息。消息通常很短（少于几百个字节），但是大小可能为100KB或更大。
不需要确认消息（即不需要像HTTP这样的请求/响应模型）。例如，C 程序向Java程序发送一条消息，而Java程序可以在以后的某个时间向C 程序发送一条消息进行回复，反之亦然。
理想的解决方案将具有以下优势：a）非常低的延迟，b）没有安全方面的麻烦（用户不必授权打开端口等），并且c）与平台无关。
我的第一个想法是使用 套接字 -每个程序将充当另一个的服务器。套接字比其他形式的IPC的开销更大，如果我让系统自动分配端口号，我不知道服务器如何将端口号通知客户端。我也考虑过 命名管道 ，但是跨不同平台不（至少一直不支持）它们。 JNI 看起来像一个选项，但是它可以跨越流程边界吗？
有什么建议？
谢谢！
后续问题
我建议您使用 TCP套接字 。
根据我的经验，与应用程序的其他任务的工作量相比，TCP套接字的实际开销非常低，至少是我用来开发的任务。我的意思是，即使套接字的延迟是其他IPC机制的延迟的两倍，在整个工作流程中，它们的影响也很小。而且，它省去了在Java应用程序和C ++应用程序之间进行IPC的麻烦，最终将需要您使用使用JNI的特定Java库，而这需要JNI和该库本身的开销。
实际上，在Java应用程序中，我已经测量到，垃圾收集器的影响比“ 回送 ” TCP套接字造成的延迟要重要得多。
而且，TCP套接字比传统IPC具有更高的可伸缩性（和可移植性！）。如果将来您必须在不同的计算机上运行客户端和服务器怎么办？在“ TCP套接字”方案中，您必须进行5分钟的破解，在“传统IPC”方案中，您必须重写整个IPC内容。
但是，您的应用程序的一般工作流程是什么？
即使不需要确认，我还是建议您使用TCP（而不是UDP）来避免未分类的传递（这会在重新排列您收到的内容时造成麻烦—您的某些消息为100KB，不适用于UDP数据包）。
为了回答您的最后一个问题，要让服务器通知客户端有关端口的信息，您可以使服务器使用特定的“ port”命令行参数启动客户端，或者使服务器在/ tmp下保存一个小文件（或另一个临时目录），端口号写在里面。
