title: Low-latency IPC between C++ and Java
body: <p>What is the best way to implement C++/Java IPC for the following situation?</p>
  
  <p>(Someone recently asked a <a href="https://stackoverflow.com/questions/5900887/ipc-between-java-and-c-applications">similar question</a>, but my requirements are more specific)</p>
  
  <ol>
  <li><p>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.</p></li>
  <li><p>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.</p></li>
  <li><p>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.</p></li>
  <li><p>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.</p></li>
  </ol>
  
  <p>My first thought was using <strong>sockets</strong> -- 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 <strong>named pipes</strong>, but they are not supported (at least not consistently) across different platforms.  <strong>JNI</strong> looks like an option, but can it cross process boundaries?</p>
  
  <p>Any suggestions?</p>
  
  <p>Thanks!    </p>
  
  <p><strong>FOLLOW-UP QUESTIONS</strong></p>
  
  <ol>
  <li>If I go with sockets, would I need to open <em>two</em> sockets to allow for asynchronous communication as described above? </li>
  </ol>