Tracking Issue for feature(unix_socket_ancillary_data)

[LinkTed]

Tracking issue for feature(unix_socket_ancillary_data) to extend UnixStream and UnixDatagram to send and receive ancillary data. For example file descriptors.

Unresolved Questions

• Review the SocketAncillary struct before stabilization to ensure it is compatible with all OSes.
• fuchsia, haiku, illumos, ios, macos and solaris does not have MSG_CMSG_CLOEXEC constant in libc
• fuchsia and uclibc(x86_64) does not have cmsghdr struct in libc
• The current version of rust libc does not have ucred struct for the target OS emscripten, but emscripten has this struct in the standard C library

Known bugs/issues

• SocketAncillary doesn't ensure the control buffer is aligned at least as much as cmsghdr #139861

Implementation history

• unix: Extend UnixStream and UnixDatagram to send and receive file descriptors #69864
• unix: Non-mutable bufs in send_vectored_with_ancillary_to #82589
• unix: Fix feature(unix_socket_ancillary_data) on macos and other BSDs #83374
• Add types for inspecting control messages in Unix socket ancillary data #117196

[tadeokondrak]

send_vectored_with_ancillary should switch to non-mutable references for its parameters, since sendmsg doesn't write through them.

#79753 changes just the bufs parameter, but it was closed for inactivity.

(Edit: Hmm, actually changing the ancillary data too would require both a SocketAncillary and SocketAncillaryMut, like IoSlice. Probably not worth it there)

[LinkTed]

@tadeokondrak I open a new PR #82589.

[LinkTed]

I create a new PR to send and receive TTL for UdpSocket from the ancillary interface. #82858

[reyk]

Hi @LinkTed, I posted a fix in #83374 for macOS, OpenBSD, and possibly other BSDs.

[LinkTed]

What has to be done to stabilize this API?

[the8472]

I think the API still needs polish. All those niche socket features are tricky and right now it's probably not extensible enough for 3rd party libraries to fill platform-specific gaps such as flags or cmsgs only supported on one particular OS. These basically are wrappers for the recvmsg and sndmsg syscalls, we should expose them in a way that's forwards-compatible so we don't have to add recv_vectored_with_ancillary_from_with_flags or something like that in the future.

Before stabilizing we should consider whether recv_vectored_with_ancillary_from should gain another argument. I would recommend adding a ReceiveOptions argument that allows one to specify flags, similar to OpenOptions. The options could then be used to set linux' MSG_DONTWAIT, MSG_PEEK or MSG_ERRQUEUE for example, maybe via custom_flags() similar to OpenOptions. That way we don't have to support all OS-specific peculiarities.

Or we could put the flags into SocketAncillary or at least reserve the right to do that in the future, but in that case the struct would need to be renamed because it would serve several purposes at once.

Similar could be done for sending.

Additionally the AncillaryData enum should be marked as #[non_exhaustive] and maybe gain a Unknown variant for things that the standard library doesn't support. And a way to get the raw ancillary message. That way one could for example decode struct sock_extended_err in a 3rd party crate without waiting for std to implement it.

[LinkTed]

@the8472 Thank you for your feedback. If this PR request is #82858 merged I will start implementing your suggestions.