Re: java unix domain sockets ... or substitute
On 03/09/14 18:26, Andreas Leitgeb wrote:
I've googled for the terms java unix domain sockets, and it seems like
this cannot be done with plain Java (and its JSL) alone.
There are a few 3rd party libs (junixsocket & JUDS) which unfortunately
both need native libs, which is a non-starter for me.
My current approach is to use named pipes intead, where the server
blockingly reads on a "main" pipe (opened just like a plain file).
Clients first create a new pair of named pipes, and pass the names to
the server, who in response creates a new thread to communicate over
those pipes and serve client's task that way.
This is somewhat awkward (especially cleaning up of stale named pipes),
and named pipes do not prohibit two readers erroneously on the same pipe.
I wonder, if there is:
- a new way to do unix domain sockets in Java (that google doesn't yet
find, or only for non-obvious-to-me keyword). This also includes
solutions that involve execution of standard unix tools, just no JNI.
- a way to negotiate a bidirectional channel between a client and
the server that doesn't involve creating pipe nodes in the
filesystem.
The client is non-Java, but otherwise quite flexible.
I don't want to use inet sockets (not even localhost), because not every
user on that machine should be able to connect, and I don't want to stick
any authorization stuff into the protocol.
Can't you achieve what you want using simple files and ownership/permissions?
A simple solution might be for the server to listen on a randomly assigned port. When the server has been assigned the
port it creates a well-known file in the filesystem (in /tmp would be a suitable place), and writes the port number to
that file. The file should be owned by the server's userid, and only accessible by that user (permissions 0x300). The
File should be set to deleteOnClose().
When a client wants to connect to the server it attempts to read the port number from the well-known file. If the file
doesn't exist it can assume the server isn't running. If it can't open the file then it doesn't have permission to talk
to the server. If it successfully reads the port number it can attempt to connect to the server on that port.
It's still possible for a malicious client to connect to the server by port-scanning. You could feasibly include a
random "key" in the file along with the port number, and the client needs to know both the port and the key. How much
security do you need on your system?