Unix socket support in the standard library #1479
Conversation
sfackler
added
the
T-libs-api
| is more accurate but weirdly repetitive and the extension trait module | ||
| `std::os::linux::unix` is even weirder. `std::os::unix::socket` is an option, | ||
| but seems like too general of a name for specifically `AF_UNIX` sockets as | ||
| opposed to *all* sockets. |
There was a problem hiding this comment.
Perhaps another unresolved question for now could be whether Windows named pipes should be added in parallel? Or something along the lines of if we should hold off on stabilization until there's a suitable Windows alternative as well.
There was a problem hiding this comment.
I don't think that blocking this feature on named pipes makes a ton of sense. Named pipes do not appear to be used heavily in the Rust ecosystem, and I don't really want us to get into a habit of wanting to add platform specific feature X to the standard library and then hunting for a roughly comparable other-platform specific feature Y to implement along side it for "symmetry".
There was a problem hiding this comment.
Hm ok, but I do also want to not tip the scales too far in favor of Unix as there are lots of abstractions on Windows we could reasonably provide (e.g. named pipes, IOCP bindings, etc). While crates today may not use these much it may just be because the Windows community is a little smaller.
These are mostly just musings, though, I'd be ok if the RFC doesn't explicitly mention named pipes.
| Unix sockets can be configured with the `SOCK_STREAM`, `SOCK_DGRAM`, and | ||
| `SOCK_SEQPACKET` types. `SOCK_STREAM` creates a connection-oriented socket that | ||
| behaves like a TCP socket, `SOCK_DGRAM` creates a packet-oriented socket that | ||
| behaves like a UDP socket, and `SOCK_SEQPACKET` provides something of a hybrid |
There was a problem hiding this comment.
SOCK_DGRAM Unix sockets are reliable.
|
🔔 This RFC is now entering its week-long final comment period 🔔 |
|
Also from discussion in triage yesterday, the libs team concluded that a good way forward for now with abstract sockets is to do something like:
It at least errs on the side of being conservative for now! |
alexcrichton
added
the
final-comment-period
|
Updated to disallow use of the abstract namespace. |
|
Shouldn't there be a way to set permissions on the socket before starting to listen to it? |
|
What libc API would that use? According to the man page, the socket will inherit the permissions of the directory it's defined in on Linux, but filesystem permissions are ignored on BSD: http://man7.org/linux/man-pages/man7/unix.7.html#NOTES |
|
I had |
|
The libs team discussed this RFC during triage yesterday, an the decision was to merge. This was the original intention for how Unix sockets would reenter the standard library and the Thanks again for the RFC @sfackler! Tracking issue: rust-lang/rust#32312 |
|
Ah, also, the initial implementation: rust-lang/rust#32302 |
Centril
added
A-net
Rendered