Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!fx23.iad.POSTED!not-for-mail From: Wayne User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 Newsgroups: comp.lang.java.programmer Subject: Re: java unix domain sockets ... or substitute References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Lines: 41 Message-ID: X-Complaints-To: abuse@newshosting.com NNTP-Posting-Date: Wed, 03 Sep 2014 17:36:37 UTC Organization: Newshosting.com - Highest quality at a great price! www.newshosting.com Date: Wed, 03 Sep 2014 13:36:36 -0400 X-Received-Bytes: 2499 X-Received-Body-CRC: 3700766862 Xref: csiph.com comp.lang.java.programmer:29893 On 9/3/2014 1:26 PM, 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. > Maybe you can create a Java proxy that the non-Java client can use. Then you can use Java messaging (Java EE). A simpler solution may be to use ZeroMQ: -- Wayne