linux abstract sockets support in connect / listen

[sidorares]

libuv already supports abstract sockets in uv_pipe_getsockname

Unfortunately, there is no way to connect to abstract socket with uv_pipe_connect.

I'm currently wrapping socat binary to be able to connect to abstract socket address from node-dbus client but it would make life so much easier if abstract socket would just work from core node.

Some my notes here: sidorares/abstractsocket#3

Few problems here:
Afaik python and ruby connect to abstract sockets using "\0name". At uv level allowing zero in socket name would require changing uv_pipe_connect signature (or adding very similar one like uv_pipe_connect2(req, handle, name, name_length, cb). Possible solution: encode leading zero somehow ( "@" prefix? do we want to allow non-abstract sockets to connect to "@name"? If so, how to escape it - "@@name"? ).

I have node version which is able to connect to socat abstract-listen:somename - server by doing net.connect('\0somename'). Would you be interested in PR? Is yes, which is preferred way - add name_length parameters where required or encode "\0" at js side and decode back at uv side ( by prefixing with @ for example )?

[saghul]

Hi! Yeah, both connect and bind (for pipes) would need to be adjusted. Now, given that abstract sockets are a linux-only thing, we'd be penalyzing the API for everyone else, I'm not 100% sure I'd want to do that. You can still create the socket yourself and pass it uv_pipe_open, that will work.

As for making this work with node, I created node-abstractsocket a while ago: https://github.com/saghul/node-abstractsocket, which exposes the same API as the net module, you might find it useful.

[sidorares]

great, I searched for existing module a while ago and couldn't find any

basic support ( pipe_open only ) would be extra ~10 lines of code in terms of size and nearly zero penalty in execution speed ( extra check first byte of name ). API wise, that's extra paragraph in the doco "to connect to abstract socket you need to prefix name with '@'"

[saghul]

great, I searched for existing module a while ago and couldn't find any

I created it recently, to get my feet wet in addons development, but it should be solid, there is not much to it :-)

basic support ( pipe_open only ) would be extra ~10 lines of code in terms of size and nearly zero penalty in execution speed ( extra check first byte of name ). API wise, that's extra paragraph in the doco "to connect to abstract socket you need to prefix name with '@'"

"@" is just what Linux uses to pretty print abstract socket names, using it to delimit actual abstract sockets is a workaround. I just did a quick test and I can bind to a Unix domain socket called "@lala" just fine. Whould would use that as a name I don't know, but I'd rather not guess :-)

[sidorares]

well, that would be handled in "unescape" part of non-abstract connect :)
anyway, I tried your module and it worked perfectly ( to my surprise no big difference in speed )

another reason to support - python and ruby have abstract sockets support, so might benefit pyuv
As a node user, I don't want to see in core something linux only (in most cases, dbus only). But as a client library author, I do - no native dependencies and cross platform happiness.

[saghul]

another reason to support - python and ruby have abstract sockets support, so might benefit pyuv
As a node user, I don't want to see in core something linux only (in most cases, dbus only). But as a client library author, I do - no native dependencies and cross platform happiness.

I actually plan to add support for it in pyuv, but there it's easy because a Python string can have embedded nulls, so I can extract the C char pointer and real length and workaround this limitation.

Given that this a Linux only thing, the cross-platform argument loses a bit of strength ;-) but that doesn't mean it wouldn't be nice to have it baked in.

@indutny, @bnoordhuis, @piscisaureus: what do you guys think? Should we get the length when binding / connecting to a pipe?

[sidorares]

s/cross-platform/cross-architecture/ :) raspberry pi / android devices / routers / tizen

[txdv]

So we only need to add a length parameter alongside the the string?

Trivial solution and binding authors wouldn't be too mad about. Would add a bit more C code, but C is already tedious.

[saghul]

So we only need to add a length parameter alongside the the string?

Yes, that's all we need because strlen won't do for abstract sockets. Then well check internally if name[0] == '\0' and build the sockaddr_un struct accordingly.

[txdv]

Passing a \0 prefixed should already work for uv_pipe_connect.

We are not using strlen anywhere.

But for uv_pipe_bind we'd need a length parameter, since we are using strdup:

libuv/src/unix/pipe.c

Line 60 in 49cb40c

pipe_fname = strdup(name);

But we could just add a third parameter ssize_t length which when set to NULL, would do a normal strdup.

We also could just check in the string if the first char is == '\0'. I don't think any one would open a pipe with the name "".

[saghul]

strncpy will stop when it finds the first '\0', it doesn't work.

[txdv]

but it works for some reason even with that strncpy

[txdv]

My proposed api breakes if you pass a memory chunk with the size 1 having only "\0".

Then it will raise a memory exception.

[saghul]

That approach won't work. Abstract sockets are allowed to have embedded nulls, which you can't accommodate unless you accept the length.

Add a test with "\0uv-test\0ouch" and you'll see.