Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #29903

Re: java unix domain sockets ... or substitute

Show all headers | View raw

Josip Almasi <joe@vrspace.org> wrote:
> On 09/03/2014 07:26 PM, Andreas Leitgeb wrote:
>> 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.
>
> IMHO domain sockets are not in java for good reason - they add little 
> value over pipes when used locally, but add complexity, as it's easier 
> to work with files/pipes than sockets.

Exactly that added complexity is what I now have to mimic with pipes and
where it ends up even more complicated than what I'd think domain sockets
would have been.
As a bonus, I'd be able to detect stale sockets, in case the server crashed,
but I cannot reliably detect a stale named pipe. Accessing it will merely 
block until someone else restarts the server.

> With domain sockets you'd also get filesystem nodes, just not two for 
> each client, with less bookkeeping of stale nodes.
> Then again, you also can create pipes in /tmp, and leave cleanup to system.

The mean-time between reboots is rather long (think of years), so I couldn't
just idly fill /tmp. The rate of client-connects is expected to be high
enough that this would cause problems.

> Now, if you want to utilize local auth, simply put your client 
> executable in a specific group, set permissions to dissallow anyone 
> outside that group to run it, and add only users allowed into that group.

or, as I'm doing it, I set up that nod with "0600" perms for the user.

> In my experience, it's always better to start with remote IPC used locally.
> Like, maybe you host becomes cluster, then your server and client become 
> cluster services, with no local IPC.

This server isn't meant for any kind of "public" access.  The server merely
hosts more or less short-lived apps, that may eventually alter local files or
spawn processes, and each of that "as the user" who started the particular server
instance. Therefore, no one else than the user ought to be able to use the server.
Essentially, the user could just as well start his own java vm to run his app,
bypassing the server process, but then he suffers from java vm startup times.

In a later stage, I'll make it a public(still localhost) server, but then
it'll delegate all the delicate stuff (file access, etc) back to the client...

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

java unix domain sockets ... or substitute Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-09-03 17:26 +0000
  Re: java unix domain sockets ... or substitute Wayne <nospam@all.invalid> - 2014-09-03 13:36 -0400
    Re: java unix domain sockets ... or substitute Fredrik Jonson <fredrik@jonson.org> - 2014-09-04 07:42 +0000
    Re: java unix domain sockets ... or substitute Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-09-04 07:52 +0000
  Re: java unix domain sockets ... or substitute Josip Almasi <joe@vrspace.org> - 2014-09-04 09:45 +0200
    Re: java unix domain sockets ... or substitute Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-09-04 09:14 +0000
      Re: java unix domain sockets ... or substitute Josip Almasi <joe@vrspace.org> - 2014-09-05 10:20 +0200
  Re: java unix domain sockets ... or substitute Fredrik Jonson <fredrik@jonson.org> - 2014-09-04 08:34 +0000
    Re: java unix domain sockets ... or substitute Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-09-05 01:06 +0000
  Re: java unix domain sockets ... or substitute Nigel Wade <nmw@ion.le.ac.uk> - 2014-09-04 11:35 +0100
  Re: java unix domain sockets ... or substitute "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-09-04 15:11 +0100
    Re: java unix domain sockets ... or substitute Nigel Wade <nmw@ion.le.ac.uk> - 2014-09-04 15:57 +0100
      Re: java unix domain sockets ... or substitute "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-09-04 16:21 +0100
        Re: java unix domain sockets ... or substitute Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-09-05 10:55 +0000
  Re: java unix domain sockets ... or substitute (SOLVED) Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-09-05 00:53 +0000
    Re: java unix domain sockets ... or substitute (SOLVED) Josip Almasi <joe@vrspace.org> - 2014-09-05 10:23 +0200

csiph-web