CODEWITHSUNDEEP
javacsocketsipc
so.very.tired
so.very.tired

Reputation: 3086

Socket to communicate between two processes (originated from C and Java) on the same machine

I need to transfer data from one process to another.
I'm quite familiar with the subject when the two processes were originated from C code - not once I used files, signals and pipes in C-code to accomplish it, but never have I tried to do it between two processes where one was originated from Java code, and the other from C code.

Since all the above methods require the (Linux) native API, and the JVM is on the way, I have decided to use a socket to communicate between these two processes, and I have a couple of questions:

  1. How common is it to use socket to communicate between two processes on the same machine?
  2. Does the fact that there is no designated "Server" and "Client" can set any obstacles (implementation-wise)?

The reason I'm asking is that everywhere I read online, there is always one process defined as 'server', and one as 'client'. This is not the case in my situation. Plus, I never tried to use socket for this purpose.

Upvotes: 0

Views: 6379

Answers (3)

John Bollinger
John Bollinger

Reputation: 180058

  1. How common is it to use socket to communicate between two processes on the same machine?

It's quite common for a certain class of interaction patterns: when two independently-launched programs need a bidirectional communication channel. You cannot easily use pipes for that ("independently-launched" interferes). You can use FIFOs, but you need two, someone needs to set them up, and there are other quirks.

  1. Does the fact that there is no designated "Server" and "Client" can set any obstacles (implementation-wise)?

The distinction between "client" vs. "server" is first and foremost about roles in establishing communication: the server sets up the communication interface and waits for one or more clients to open a connection to it. Being a "server" does not necessarily imply supporting multiple clients (neither concurrently nor serially), nor does it necessarily imply anything about communication passing over the socket connection after it is established. If you use sockets then you do have client and server, but if you have no other way to designate which process should have which role then you can choose arbitrarily.

One trick with sockets in Java is that although the Java standard library supports them, it supports only network sockets, not UNIX-domain sockets. The latter are more commonly used in UNIX and Linux applications where communication is inherently restricted to processes running on the same machine, but network sockets listening to (only) the loopback interface can nevertheless serve that purpose, too.

On modern systems, local TCP connections are just as fast as UNIX-domain sockets, so using them is not a problem.

Upvotes: 4

Kayaman
Kayaman

Reputation: 73528

Connecting 2 processes together in a language and platform agnostic way can easily be achieved with a Socket. It's supported by all languages and platforms, and can easily be replaced with another method if wanted.

From your explanation I gathered that the Java process would be the server. Sockets are quite risk-free, since they don't require special permissions (for ports over 1024 at least) or any other special handling.

Just pay attention when designing the (application level) protocol your processes will be communicating through.

Upvotes: 2

manf
manf

Reputation: 338

  1. You might want to use the Java Native Interface. It might be exactly what you want. - Based on your aproach to use sockets on both programs.

  2. You might want to look into shared memory on linux.

BUT: Using sockets is not a bad thing here in general, but i doubt it is common practice*.

*I lack proof, that this is not common practice tho.

Upvotes: -1

Related Questions