Talk:Unix domain socket

Filesystem

They are referenced by processes as inodes in the file system.

This is not quite correct. On several OS you can set the first byte of the pathname to 0, causing the following name to be looked up in a filesystem independent namespace (without any filesystem access control checks). Even from within a chroot. -- (unknown)

This comment seems to reference specific text of the article, but that text is not there; surely changed at some point in the past.Stevebroshar (talk) 11:33, 12 August 2024 (UTC)

Notes

The PF_UNIX (also known as PF_LOCAL) socket family is used to communicate between processes on the same machine efficiently. Unix sockets can be either anonymous (created by socketpair) or associated with a file of type socket. Linux also supports an abstract namespace which is independent of the file system.

Valid types are SOCK_STREAM for a stream oriented socket and SOCK_DGRAM for a datagram oriented socket that preserves message boundaries. Unix sockets are always reliable and don't reorder datagrams.

Unix sockets support passing file descriptors or process credentials to other processes using ancillary data. 220.225.70.2 04:58, 4 April 2007

This text is almost identical to what's at https://www.unix.com/man-page/linux/7/PF_UNIX/ although oddly it's AF_UNIX, not PF_UNIX. None-the-less, this info is already covered in the article.Stevebroshar (talk) 11:30, 12 August 2024 (UTC)

Advertising based resources

Why do the external links point to copies of the Linux documentation on an ad-covered page, rather than the authoritative source? --David Chisnall (talk) 18:35, 19 November 2007 (UTC)

Today, 17 years later, this does not seem to be an issue. Stevebroshar (talk) 11:25, 12 August 2024 (UTC)

Name

What does domain in Unix domain socket stand for? --Abdull (talk) 20:52, 9 March 2015 (UTC)

It's essentially the standard English meaning of the word. It's the first parameter of socket(2). The Linux manpage calls it the "communication domain", if that helps, though I've never heard anyone call it that. — Preceding unsigned comment added by 2601:602:A080:1240:45D4:8FC9:967D:6C67 (talk) 02:41, 22 January 2023 (UTC)

The info from (unknown) is good, but leaves me with more questions that I started with. I assumed that domain means in this context what it means normally (in English!), so that part is not helpful. I see at https://man7.org/linux/man-pages/man2/socket.2.html that socket is a function that accepts an arg called domain. Further, there is a value AF_UNIX for that arg that I assume is what "Unix domain" is referring to. The manual does use communication domain to describe domain. Also, uses protocol family and format. Make up your mind guys! Stevebroshar (talk) 17:53, 8 August 2024 (UTC)

I think one thing that's confusing about the term Unix domain socket is that socket is a concept in the domain (as in context) of Unix. Therefore, the term Unix domain socket could mean two different things. It could mean a socket created with AF_UNIX or it could mean socket(2) (any sub-type). But, the normal meaning is the former. The confusion would be less if instead of Unix domain socket we called it local domain socket (note that AF_LOCAL is another name for AF_UNIX). Oh well. Stevebroshar (talk) 18:10, 8 August 2024 (UTC)

History or naming

I think a section on the historical derivation of "Unix domain sockets", or else an explanation of the name, is warranted. They are often called just "sockets" or "socket files" as well. The common synonyms (even if incorrect) and differentiation from commonly conflated entities would be a good addition. DouglasHeld (talk) 17:47, 24 January 2022 (UTC)

It seems that a Unix domain socket is what you get by passing AF_UNIX for the domain arg to the function socket() -- i.e. socket(AF_UNIX, type, protocol). You can create other kinds of sockets by passing a different value for the domain arg. So socket refers to any type/kind whereas Unix domain socket refers to a subset. If the context is clearly Unix domain socket (or any particular sub-type), then could use just socket as a short form. I did update the article to try to make this clearer.Stevebroshar (talk) 18:03, 8 August 2024 (UTC)

What does UDS have to do with TCP, UDP, SCTP

Article says SOCK_STREAM is like TCP, SOCK_DGRAM is like UDP and SOCK_SEQPACKET is like SCTP. But does not expound on that. I see no relation myself. Either this info is wrong, or it should be described in more (any!) detail. Stevebroshar (talk) 11:43, 12 August 2024 (UTC)

UDS facility

WRT The UDS facility is a standard component of a POSIX operating system Is USD a facility? I think socket is a facility, but USD is just a part of that facility. Maybe I'm splitting hairs. IDK. Stevebroshar (talk) 11:46, 12 August 2024 (UTC)

Reversion

I have reverted this article to its form from August. Around that time a succession of edits were made, which turned a small but accurate article into a long and terribly confused article. The faults in that article were legion: it failed to distinguish a Unix domain socket from a socket as a general concept and talked at great length about the latter, it repeatedly talked about specifically internet domain sockets instead of about Unix domain sockets, and then concluded with giant blocks of example code (is this a Wikipedia article or a tutorial?)

In short it was irredeemable and in every way the inferior of the article as it previously stood - so reversion was the only reasonable course of action. Netbsdusers (talk) 17:53, 25 March 2025 (UTC)

It looks to me like the vast majority of the content you have taken issue with (particularly this edit) is by a single user, so I'll ping Timhowardriley here. Pink Bee (talk) 18:40, 25 March 2025 (UTC)

Regarding turned a small but accurate article into a long and terribly confused article.: I disagree. The additions to the small article are sourced and the examples execute correctly. Timhowardriley (talk) 08:53, 26 March 2025 (UTC)

To be fair, MOS:CODE says: While there's nothing inherently wrong with including sample code, excessive amounts of it can detract from the content of the article itself; avoid writing sample code unless it contributes significantly to a fundamental understanding of the encyclopedic content. Several of the examples could be removed in accordance with this guideline. I think there needs to be some example code, but only to illustrate the basics of working with Unix domain sockets in particular – general examples of API usage are given in Berkeley sockets.

A lot of the discussion of the socket API that does not relate specifically to Unix domain sockets would be better suited to the article on Berkeley sockets as well, although it already has a lot of the information. This article should focus on what is special about Unix domain sockets over other types of sockets accessed via the same API (which would be the implementation, I guess).

Netbsdusers: As above, I tend to agree with your points about the scope of the article. That said, reverting 6 months of others' work is always unlikely to be popular, and re-reverting when there is already a talk page discussion (and without engaging) is discouraged.

Pink Bee (talk) 15:55, 26 March 2025 (UTC)

While I agree that the content added in the aforementioned edit is indeed sourced, some of the added information contradicts the sources. In particular, the "Socket instantiation" section used to state that data was carried using UDP and TCP regardless of whether it was a internet domain socket or not. I corrected this in a sequence of edits (as well as the conflation of SOCK_SEQPACKET with a domain), although the article presents a lot of information only relevant to internet domain sockets.

This seems to be a general issue with the article. It talks a lot about sockets in general, conflating UNIX domain sockets with internet domain sockets. In addition there's other issues:

• Some of the code snippets seem to be questionable. For example: where does the 92 come from? The cited reference states 108.

struct sockaddr_un {
    sa_family_t sun_family; /* AF_UNIX */
    char sun_path[ 92 ];
}

• The lead section mentions something about a "lock file semaphore", which seems to make no sense to me, and I can't find anything about it in the cited reference for that paragraph: "The server will create /path/filename on the filesystem to act as a lock file semaphore."
• This may be slightly misleading, as it suggests the IP address and port number are passed as a string analogous to a file path, when in actuality they are passed as integers: "Because the socket address may be either a /path/filename or an IP_address:Port_number, the socket application programming interface requires the address to first be set into a structure."
• This may be nitpicky, but an internet domain sockets doesn't need to be between just two hosts, it can any number of hosts.

In addition, the latter half of the article seems more like a tutorial, and even slips into the imperative. And the use of code samples seems excessive to me.

P.S: Sorry for repeating stuff that was already said by Pink Bee. That response was sent while I was composing this. --Lukflug (talk) 15:57, 26 March 2025 (UTC)