CODEWITHSUNDEEP
javajvm
Pieter
Pieter

Reputation: 777

How can you let two JVM's communicate without RMI or Sockets?

Is it possible to let two separate JVM's communicate with each other without RMI or a Socket?

My situation is as following:

I have a server (java app) in one console, in a command line interface. I can log in to the computer with SSH, so I have got another terminal. I want now to start a little java program, which can communicate with the server. This is to control the server, so there isn't a lot of traffic (just some small strings passing around).

I'd like not to use a Socket or RMI, as it uses another port number.

Is a PipedWriter an option? But how will the other JVM now where to find it?

Thanks

Upvotes: 2

Views: 1407

Answers (1)

Donal Fellows
Donal Fellows

Reputation: 137567

You don't want a PipedWriter; that's only for communication between threads in the same process. You also can't use an unnamed OS pipe, as there's no relationship between the processes. You could use an OS fifo (assuming you're on Unix, when you'd make it with the system mkfifo command; I don't know the equivalent API for Windows well enough to help there) but I've no idea how good Java will be at handling such named pipes.

The simplest mechanisms are to use a watched file or a server socket that is only bound to a port on localhost, 127.0.0.1. (By binding it in such a way, it becomes impossible to access the socket from off the machine without some kind of local program. Or a suitably-configured SSH tunnel.) The advantage and disadvantage of the watched-file method is that it needs somewhere that both processes can see (and presumably write to). An administration socket is somewhat more exposed, but handles two-way comms much more easily; if that matters to you, do consider it as Java's got good (if a little low-level for my tastes) support for sockets.

If you're thinking about a shared file solution, consider whether to make that file a database; there's a JDBC driver for SQLite and that supports safe concurrent access (and guards against problems with concurrent writes I bet you've never thought of). It also might mean you can avoid having to write a special client; there's a wealth of existing tools.

Upvotes: 3

Related Questions