std::io::net::unix::UnixStream does not support abstract sockets on Linux.

[canndrew]

Currently, as far as I can tell, there is no way to connect to or listen on unix domain sockets in Linux's abstract socket namespace. I see two ways to add this support:

0: Add functions connect_abstract and connect_abstract_timeout to UnixStream and bind_abstract to UnixListener.
1: Create new traits AbstractStream, AbstractListener and AbstractAcceptor that mimic their Unix* counterparts and put them in either std::io::net::unix or a new module std::io::net::abstract.

I'd be happy to write a patch for this if anyone can suggest which would be the best course of action or suggest a better way to implement this.

[alexcrichton]

I would be ok with supporting this, but as the manpage says "The abstract socket namespace is a nonportable Linux extension" I would not want this to be so intrusive of an api change such as adding AbstractXXX or foo_abstract methods.

One possible method would be creating a ToUnixAddress trait which bounds bind/connect arguments (similarly to ToCStr today), but I am wary of creating yet another trait just for this nonportable extension.

[canndrew]

The only way I can think of adding this without extending the API would be to say that paths beginning with a '@' are in the abstract namespace (think: @ for abstract). That way you could call

connect("@/this/is/an/abstract/path");

It's an ugly hack though and in my opinion an extension to the API would be much preferable.

If I understand your suggestion correctly it is to change the type of UnixStream::connect to

connect<P: ToUnixAddress>(path: P) -> IOResult<UnixStream>

That would require adding an impl ToUnixAddress to everything that currently implements ToCStr (Path, &str and &[u8]), as well as defining a new type called AbstractPath or something. This way you could call

UnixStream::connect(AbstractPath::new("/this/is/an/abstract/path"));

Is this what you had in mind?

Personally I think the cleanest way of doing this would be to add connect_abstract et al. and clearly document that these functions are Linux only. It's okay to add platform-specific functions if those functions only make sense on one platform. I'm a Linux developer and if I'm reading through an API's documentation and I see a function marked Windows only I just ignore it and keep scrolling.

I think it's important to support these one way or an other as they're used on Linux extensively. I've only just started playing around with Rust and the first two things I've gone to write are a DBus library and a GNUnet library. Both of these require abstract sockets for library<->daemon communication.

[alexcrichton]

This will be addressed by rust-lang/rfcs#807 by removing the Unix* types. If and when we add them at a future date we should be sure to allocate space in the API to support abstract sockets.

[haraldh]

Still not possible 😞

[canndrew]

I guess there hasn't been enough demand for it. We could add std::os::linux::net::{UnixListenerExt, UnixStreamExt} traits which add {bind_abstract, connect_abstract} methods. Something like probably stands a good chance of getting merged into std.

[haraldh]

Why not remove the zero byte check for the first byte and let the OS fail?
MacOS e.g. fails with "error: No such file or directory (os error 2)" if the path starts with a zero byte.