C ++和Java之间的低延迟IPC [英] Low-latency IPC between C++ and Java

查看:197
本文介绍了C ++和Java之间的低延迟IPC的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

对于以下情况,实现C ++ / Java IPC的最佳方法是什么?



(有人最近问过一个类似问题,但我的要求更具体)


  1. 我有两个程序 - 一个用C ++编写,另一个用Java编写 - 需要彼此通信。两者都在同一台计算机上运行。


  2. 程序向对方发送消息。邮件通常很短(少于几百个字节),但可能大小为100KB或更多。


  3. 邮件不需要确认,而不是HTTP之类的请求/响应模型)。例如,C ++程序向Java程序发送消息,Java程序可以通过稍后向C ++程序发送消息来回复 - 反之亦然。


  4. 一个理想的解决方案将具有a)非常低的延迟,b)没有安全麻烦(用户不必授权端口被打开等)和c)将是平台无关的。

    / li>

我的第一个想法是使用套接字 - 每个程序都可以作为另一个服务器。套接字比其他形式的IPC有更多的开销,我不知道如果我让系统自动分配端口号,服务器如何通知客户端的端口号。我也考虑过命名管道,但不支持(至少不一致)跨不同平台。 JNI 看起来像一个选项,但它可以跨越流程边界吗?



有任何建议吗?



谢谢!



后续问题


  1. 请使用套接字,我需要打开两个套接字以允许异步通信,如上所述?


解决方案

我建议您使用 TCP套接字



根据我的经验,TCP套接字的实际开销与应用程序的其他任务工作负载相比非常低,至少是我用来开发。我的意思是,有时即使套接字的延迟是其他IPC机制的延迟的两倍,在整个工作流中它们也几乎没有影响。并且它节省了在Java应用程序和C ++之间进行IPC的麻烦,最终将需要您使用使用JNI的特定Java库,以及JNI和库本身的开销。



我实际测得,在我的Java应用程序中,垃圾收集器的影响比由 loopback TCP套接字引起的延迟更重要。 p>

此外,TCP套接字比传统的IPC更可扩展(和便携!)。如果将来你必须在不同的机器上运行客户端和服务器怎么办?在TCP套接字的情况下,你必须做一个5分钟的黑客,在传统IPC的情况下,你必须重写整个IPC的东西。



但是,您的应用程序的一般工作流程是什么?



即使不需要确认,使用TCP(而不是UDP)来避免未分类的传递(这导致在重新排列你收到的东西的痛苦 - 一些你的消息是100KB,这不适合在UDP包)。



在回答您的最后一个问题时,为了让服务器通知客户端端口,您可以使服务器使用特定的端口命令行参数启动客户端,或者使服务器在/ tmp(或另一个临时目录)下面保存一个小文件,并将端口号写入其中。


What is the best way to implement C++/Java IPC for the following situation?

(Someone recently asked a similar question, but my requirements are more specific)

  1. I have two programs -- one written in C++, the other in Java -- that need to communicate with each other. Both are running on the same machine.

  2. The programs send messages to each other. Messages are typically short (less than a few hundred bytes), but could potentially be 100KB or more in size.

  3. Messages do not need to be acknowledged (i.e., not a request/response model like HTTP). For example, the C++ program sends a message to the Java program, and the Java program may reply by sending a message to the C++ program at a later time -- and vice versa.

  4. An ideal solution would have a) very low latency, b) no security hassles (user does not have to authorize ports to be opened etc.) and c) will be platform-agnostic.

My first thought was using sockets -- each program would act as a server to the other. Sockets have more overhead than other forms of IPC, and I don't know how the server would inform the client of the port number if I let the system auto-assign port numbers. I've also considered named pipes, but they are not supported (at least not consistently) across different platforms. JNI looks like an option, but can it cross process boundaries?

Any suggestions?

Thanks!

FOLLOW-UP QUESTIONS

  1. If I go with sockets, would I need to open two sockets to allow for asynchronous communication as described above?

解决方案

I'd suggest you to use TCP sockets.

The actual overhead of TCP sockets, as of my experience, is very very low compared to the other tasks' workload of the applications, at least the ones I use to develop. I mean, sometimes even if sockets' latency is twice as the latency of other IPC mechanisms, in the overall workflow they have very little impact. And it saves you the hassle of making IPC between a Java application and a C++ one, that will eventually require you to use a specific Java library that uses JNI, with the overhead of JNI and the one of the library itself.

I've actually measured, in my Java applications, that Garbage Collector impact is far more important than the latency caused by "loopback" TCP sockets.

Moreover, TCP sockets are more scalable (and portable!) than traditional IPC. What if in the future you'll have to run the client and the server on different machines? In the 'TCP sockets' scenario, you'll have to do a 5-minute hack, in the 'traditional IPC' scenario, you'll have to rewrite the whole IPC stuff.

However, what is the general workflow of your application?

Even if the acknowledgement is not required, I'd suggest to use TCP (and not UDP) to avoid unsorted delivery (which leads to pain in the ass when it comes to rearrange the stuff you received - some of your messages are 100KB and this doesn't fit in a UDP packet).

In reply to your last question, for the server to inform the client about the port, you can just make the server launch the client with a specific 'port' command line parameter, or make the server save a small file under /tmp (or another temporary directory) with the port number written inside.

这篇关于C ++和Java之间的低延迟IPC的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆