Thread: Connecting over UNIX domain sockets

Connecting over UNIX domain sockets

From
Florian Weimer
Date:
I would like to have the option to connect to the database over UNIX
domain sockets (sidestepping the question of password management).

Even though the JVM knows about UNIX domain sockets, this
functionality is not exposed to user code, so we'd have to add some
JNI code.  Would you like to integrate this in some way?  If yes,
would you prefer a socket-based or libpq-based approach?

--
Florian Weimer                <fweimer@bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

Re: Connecting over UNIX domain sockets

From
John R Pierce
Date:
On 02/08/11 6:55 AM, Florian Weimer wrote:
> I would like to have the option to connect to the database over UNIX
> domain sockets (sidestepping the question of password management).
>
> Even though the JVM knows about UNIX domain sockets, this
> functionality is not exposed to user code, so we'd have to add some
> JNI code.  Would you like to integrate this in some way?  If yes,
> would you prefer a socket-based or libpq-based approach?

socket based would require less work, as you'd just add that to the
existing socket code, while using libpq would essentially end up with an
entirely different JDBC.

managing and installing JNI based code across platforms is a pain in the
sternum.





Re: Connecting over UNIX domain sockets

From
Florian Weimer
Date:
* John R. Pierce:

> On 02/08/11 6:55 AM, Florian Weimer wrote:
>> I would like to have the option to connect to the database over UNIX
>> domain sockets (sidestepping the question of password management).
>>
>> Even though the JVM knows about UNIX domain sockets, this
>> functionality is not exposed to user code, so we'd have to add some
>> JNI code.  Would you like to integrate this in some way?  If yes,
>> would you prefer a socket-based or libpq-based approach?
>
> socket based would require less work, as you'd just add that to the
> existing socket code, while using libpq would essentially end up with
> an entirely different JDBC.

I would try to add a low-level read/write API to libpq.  libpq would
only handle configuration processing, authentication and the transport
layer (which may include TLS).

> managing and installing JNI based code across platforms is a pain in
> the sternum.

Some people do have working software distribution platforms. 8-)

--
Florian Weimer                <fweimer@bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

Re: Connecting over UNIX domain sockets

From
Phil Clay
Date:
On 02/08/11 6:55 AM, Florian Weimer wrote:

>I would like to have the option to connect to the database over UNIX
>domain sockets (sidestepping the question of password management).
>
>Even though the JVM knows about UNIX domain sockets, this
>functionality is not exposed to user code, so we'd have to add some
>JNI code.  Would you like to integrate this in some way?  If yes,
>would you prefer a socket-based or libpq-based approach?
>
>--
>Florian Weimer                <fweimer(at)bfk(dot)de>
>BFK edv-consulting GmbH       http://www.bfk.de/
>Kriegsstraße 100              tel: +49-721-96201-1
>D-76133 Karlsruhe             fax: +49-721-96201-99



Apologies for resurrecting an old thread, but I'm also interested in using
domain sockets with postgres' jdbc driver.

To any potential implementors, I wanted to point out something that might be
useful...

The junixsocket project (http://code.google.com/p/junixsocket/) provides an
implementation of java.net.Socket that uses domain sockets.  It also provides a
mysql SocketFactory so that mysql's jdbc driver can be used with domain
sockets.
However, contrary to mysql's jdbc driver, postgres' jdbc driver does not appear
to be designed in a way that a different Socket implementation could be easily
"plugged in".


If the postgres jdbc project does not want the full burden of managing the
native code required for domain socket connectivity, perhaps one approach to
take would be to refactor the postgres jdbc driver in such a way that a
different mechanism for constructing sockets could be plugged in.  Then an
implementation could be provided by junixsocket, which already has the native
distribution mechanism.

Just a thought.

Phil

Re: Connecting over UNIX domain sockets

From
Hannu Krosing
Date:
On Mon, 2011-06-27 at 12:02 -0700, Phil Clay wrote:

> Apologies for resurrecting an old thread, but I'm also interested in using
> domain sockets with postgres' jdbc driver.
>
> To any potential implementors, I wanted to point out something that might be
> useful...
>
> The junixsocket project (http://code.google.com/p/junixsocket/) provides an
> implementation of java.net.Socket that uses domain sockets.  It also provides a
> mysql SocketFactory so that mysql's jdbc driver can be used with domain
> sockets.
> However, contrary to mysql's jdbc driver, postgres' jdbc driver does not appear
> to be designed in a way that a different Socket implementation could be easily
> "plugged in".

Hmm - does pg jdbc driver support IPv6 ?

If so, is it done inside java socket library ?

> If the postgres jdbc project does not want the full burden of managing the
> native code required for domain socket connectivity, perhaps one approach to
> take would be to refactor the postgres jdbc driver in such a way that a
> different mechanism for constructing sockets could be plugged in.  Then an
> implementation could be provided by junixsocket, which already has the native
> distribution mechanism.
>
> Just a thought.
>
> Phil
>

--
-------
Hannu Krosing
PostgreSQL Infinite Scalability and Performance Consultant
PG Admin Book: http://www.2ndQuadrant.com/books/


Re: Connecting over UNIX domain sockets

From
Craig Ringer
Date:
On 06/28/2011 03:02 AM, Phil Clay wrote:

> However, contrary to mysql's jdbc driver, postgres' jdbc driver does not appear
> to be designed in a way that a different Socket implementation could be easily
> "plugged in".

There's already support for pluggable SSLSocketFactories to wrap
sockets. Adding pluggable SocketFactory support wouldn't seem to be
overly hard, I just suspect it's a combination of nobody having needed
it and nobody having wanted it enough to take the time to write a patch.

The JDBC driver is readable and not hard to understand, so maybe you
could chuck a patch together?

(Fighting very hard to say "Oh, I'll do something like that" when I've
already volunteered for way too much).

--
Craig Ringer

Re: Connecting over UNIX domain sockets

From
Bruno Harbulot
Date:
On 27/06/2011 23:20, Craig Ringer wrote:
> On 06/28/2011 03:02 AM, Phil Clay wrote:
>
>> However, contrary to mysql's jdbc driver, postgres' jdbc driver does
>> not appear
>> to be designed in a way that a different Socket implementation could
>> be easily
>> "plugged in".
>
> There's already support for pluggable SSLSocketFactories to wrap
> sockets. Adding pluggable SocketFactory support wouldn't seem to be
> overly hard, I just suspect it's a combination of nobody having needed
> it and nobody having wanted it enough to take the time to write a patch.


Hello,

I'm not sure if anyone had done any further work on this thread, but
here is a tentative patch (I've written it against the 8.4 code base) to
be able to use a custom SocketFactory (in particular for junixsocket).

This relies on two new properties:
   - socketfactory, for the class name of the SocketFactory.
   - socketfactoryarg, for the String argument of this SocketFactory
constructor.


I've changed this constructor into two:

-    public PGStream(String host, int port)
+    public PGStream(String host, int port, SocketFactory socketFactory)
+    public PGStream(String host, int port, Properties info)

The one that uses Properties reads the properties to instantiate the
SocketFactory (via a new method PGStream.createSocketFactory(Properties
info), which is a very similar to the way the SSLSocketFactory is
instantiated).

The one that uses a SocketFactory can be used directly, but the main
reason I've introduced it was for PGStreams creates from other PGStreams
(the ones called "cancelledStream").

The only glitch was in PGStream.changeSocket(...), since AFUNIXSocket
(from junixsocket) doesn't support setTcpNoDelay (and throws an
exception). I made it catch any SocketException: although it could catch
AFUNIXSocketException (which extends SocketException), this would make
the driver depend on junixsocket.

-        connection.setTcpNoDelay(true);
+        try {
+            connection.setTcpNoDelay(true);
+        } catch (SocketException e) {
+            // Ignore if the operation wasn't supported.
+        }



I'm also attaching a sample PgJdbcUnixSocketFactory to use this with
junixsocket (which needs to be on the classpath and have
'java.library.path' configured to point to its native libraries).


The following works, using a unix socket.

Properties props = new Properties();
props.setProperty("user", "name");
props.setProperty("password", "xxxxxx");
props.setProperty("socketfactory", "jdbctest.PgJdbcUnixSocketFactory");
props.setProperty("socketfactoryarg", "/tmp/.s.PGSQL.5432");
Connection jdbcConnection =
DriverManager.getConnection("jdbc:postgresql://", props)

To specify which database is to be used, it's possible to use something
like this:

DriverManager.getConnection("jdbc:postgresql://.../dbname", props)

(What's in "..." doesn't really matter, but "jdbc:postgresql:///dbname"
doesn't work.)


I'm not sure how these changes would fit with the rest of the design of
the driver, as I must admit I don't know this code very well. I suppose
there are multiple ways of implementing this feature, but I hope this
patch may be a sufficient starting point.


Best wishes,

Bruno.

Attachment