New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unix socket support in the standard library #1479

Merged
merged 4 commits into from Mar 17, 2016

Conversation

Projects
None yet
5 participants
@sfackler
Member

sfackler commented Jan 26, 2016

@sfackler sfackler added the T-libs label Jan 26, 2016

@sfackler sfackler self-assigned this Jan 26, 2016

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.

This comment has been minimized.

@alexcrichton

alexcrichton Jan 26, 2016

Member

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.

@alexcrichton

alexcrichton Jan 26, 2016

Member

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.

This comment has been minimized.

@sfackler

sfackler Jan 27, 2016

Member

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".

@sfackler

sfackler Jan 27, 2016

Member

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".

This comment has been minimized.

@alexcrichton

alexcrichton Jan 28, 2016

Member

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.

@alexcrichton

alexcrichton Jan 28, 2016

Member

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.

/// This function will cause all pending and future I/O calls on the
/// specified portions to immediately return with an appropriate value
/// (see the documentation of `Shutdown`).
pub fn shutdown(&self, how: Shutdown) -> io::Result<()> {

This comment has been minimized.

@alexcrichton

alexcrichton Jan 26, 2016

Member

This function isn't currently on UdpSocket, which I seem to recall is because it doesn't do much for datagram-oriented services, but do you know if it works well with Unix datagrams?

@alexcrichton

alexcrichton Jan 26, 2016

Member

This function isn't currently on UdpSocket, which I seem to recall is because it doesn't do much for datagram-oriented services, but do you know if it works well with Unix datagrams?

This comment has been minimized.

@sfackler

sfackler Jan 26, 2016

Member

I think I probably just added it for completeness, but I'd expect it to bounce any pending recv calls at least. I'll see if it actually does anything.

@sfackler

sfackler Jan 26, 2016

Member

I think I probably just added it for completeness, but I'd expect it to bounce any pending recv calls at least. I'll see if it actually does anything.

This comment has been minimized.

@sfackler

sfackler Jan 27, 2016

Member

It looks like shutdown does do what you'd expect for a datagram socket: rust-lang-nursery/unix-socket@63650be#diff-b4aea3e418ccdb71239b96952d9cddb6R1252

@sfackler

sfackler Jan 27, 2016

Member

It looks like shutdown does do what you'd expect for a datagram socket: rust-lang-nursery/unix-socket@63650be#diff-b4aea3e418ccdb71239b96952d9cddb6R1252

Differences from `UdpSocket`:
* `bind` takes an `AsRef<Path>` rather than a `ToSocketAddrs`.
* The `unbound` method creates an unbound socket, as a Unix socket does not need
to be bound to send messages.

This comment has been minimized.

@alexcrichton

alexcrichton Jan 26, 2016

Member

This method differs somewhat from the planned strategy of UdpSocket which is to perhaps introduce a UdpBuilder, but does this mean that an unbound UnixDatagram is useful in its own right for sending/receiving data?

@alexcrichton

alexcrichton Jan 26, 2016

Member

This method differs somewhat from the planned strategy of UdpSocket which is to perhaps introduce a UdpBuilder, but does this mean that an unbound UnixDatagram is useful in its own right for sending/receiving data?

This comment has been minimized.

@sfackler

sfackler Jan 26, 2016

Member

It can't receive any data since you can't address it, but it can send: https://github.com/rust-lang-nursery/unix-socket/blob/master/src/lib.rs#L1159-L1173. This was added explicitly in a PR, so I believe it's a thing that's used in practice: rust-lang-nursery/unix-socket#14

@sfackler

sfackler Jan 26, 2016

Member

It can't receive any data since you can't address it, but it can send: https://github.com/rust-lang-nursery/unix-socket/blob/master/src/lib.rs#L1159-L1173. This was added explicitly in a PR, so I believe it's a thing that's used in practice: rust-lang-nursery/unix-socket#14

This comment has been minimized.

@alexcrichton

alexcrichton Jan 28, 2016

Member

Hm ok, seems reasonable to at least come in as unstable-to-start-out-with

@alexcrichton

alexcrichton Jan 28, 2016

Member

Hm ok, seems reasonable to at least come in as unstable-to-start-out-with

While there is precedent for platform specific components in the standard
library, this will be the by far the largest platform specific addition.

This comment has been minimized.

@alexcrichton

alexcrichton Jan 26, 2016

Member

One drawback that may want to be mentioned here is the lack of a smooth migration path from unix-socket to the standard library. For example users of Unix sockets will currently have to decide whether to support older versions of Rust (and use unix-socket) or newer versions (use std::os::unix::net). Additionally, we'll have to duplicate the code when unix-socket is compiled against a standard library that also has Unix sockets.

We have ideas for implementing such a migration path, but none of these ideas have an RFC or have been implemented.

@alexcrichton

alexcrichton Jan 26, 2016

Member

One drawback that may want to be mentioned here is the lack of a smooth migration path from unix-socket to the standard library. For example users of Unix sockets will currently have to decide whether to support older versions of Rust (and use unix-socket) or newer versions (use std::os::unix::net). Additionally, we'll have to duplicate the code when unix-socket is compiled against a standard library that also has Unix sockets.

We have ideas for implementing such a migration path, but none of these ideas have an RFC or have been implemented.

This comment has been minimized.

@sfackler

sfackler Jan 27, 2016

Member

I'm not particularly worried about this specific case - there's not all that much code and these kinds of objects aren't typically going to be passed around between crates like Durations might be.

The migration path ideas we've had seem to me to be a bit like the ideas to store fully elaborated source on crates.io - probably never going to happen :).

@sfackler

sfackler Jan 27, 2016

Member

I'm not particularly worried about this specific case - there's not all that much code and these kinds of objects aren't typically going to be passed around between crates like Durations might be.

The migration path ideas we've had seem to me to be a bit like the ideas to store fully elaborated source on crates.io - probably never going to happen :).

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

This comment has been minimized.

@DemiMarie

DemiMarie Feb 1, 2016

SOCK_DGRAM Unix sockets are reliable.

@DemiMarie

DemiMarie Feb 1, 2016

SOCK_DGRAM Unix sockets are reliable.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 3, 2016

Member

🔔 This RFC is now entering its week-long final comment period 🔔

Member

alexcrichton commented Mar 3, 2016

🔔 This RFC is now entering its week-long final comment period 🔔

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 3, 2016

Member

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:

  • Validate no nul bytes are found in strings
  • Perhaps eventually add a linux-specific extension trait to manage abstract sockets.

It at least errs on the side of being conservative for now!

Member

alexcrichton commented Mar 3, 2016

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:

  • Validate no nul bytes are found in strings
  • Perhaps eventually add a linux-specific extension trait to manage abstract sockets.

It at least errs on the side of being conservative for now!

@sfackler

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Mar 4, 2016

Member

Updated to disallow use of the abstract namespace.

Member

sfackler commented Mar 4, 2016

Updated to disallow use of the abstract namespace.

@gkoz

This comment has been minimized.

Show comment
Hide comment
@gkoz

gkoz Mar 7, 2016

Shouldn't there be a way to set permissions on the socket before starting to listen to it?

gkoz commented Mar 7, 2016

Shouldn't there be a way to set permissions on the socket before starting to listen to it?

@sfackler

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Mar 7, 2016

Member

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

Member

sfackler commented Mar 7, 2016

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

@gkoz

This comment has been minimized.

Show comment
Hide comment
@gkoz

gkoz Mar 7, 2016

I had chmod in mind ;) Okay, while I doubt any modern BSDs ignore "file" permissions I totally missed that the portable way is to rely on directory-level permissions.

gkoz commented Mar 7, 2016

I had chmod in mind ;) Okay, while I doubt any modern BSDs ignore "file" permissions I totally missed that the portable way is to rely on directory-level permissions.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 17, 2016

Member

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 unix-socket crate is doing well enough that moving it in almost wholesale seems good at this time (it's quickly becoming a vetted API).

Thanks again for the RFC @sfackler!

Tracking issue: rust-lang/rust#32312

Member

alexcrichton commented Mar 17, 2016

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 unix-socket crate is doing well enough that moving it in almost wholesale seems good at this time (it's quickly becoming a vetted API).

Thanks again for the RFC @sfackler!

Tracking issue: rust-lang/rust#32312

@alexcrichton alexcrichton merged commit 97780a7 into rust-lang:master Mar 17, 2016

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 17, 2016

Member

Ah, also, the initial implementation: rust-lang/rust#32302

Member

alexcrichton commented Mar 17, 2016

Ah, also, the initial implementation: rust-lang/rust#32302

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment