CACrown ArchivesHistory · sources · collections
Menu
Research dossier · General Reference

Unix domain socket

socket for exchanging data between processes executing on the same OS; similar to an Internet socket, but all communication occurs within the same OS

Cross-disciplinary reference desk with index cards, atlas, dictionary and catalogue
General referenceInterpretive dossier study · Crown Archives visual atlas
Record originEnglish Wikipedia
Text licenseCC BY-SA 4.0
Source revisionMar 9, 2026
Entity authorityQ2044498
Source-derived summary

A Unix domain socket (UDS), also called a local socket or inter-process communication (IPC) socket, is a communication endpoint used for data exchange between processes running on the same Unix or Unix-like operating system.

The term Unix domain socket refers to the domain argument value AF_UNIX passed to the system call that creates the socket. The same communication domain can also be selected with AF_LOCAL.

Valid type argument values for a UDS are:

SOCK_STREAM (compare to TCP) – a stream-oriented socket

SOCK_DGRAM (compare to UDP) – a datagram-oriented socket that preserves message boundaries; on most Unix implementations, Unix domain datagram sockets are reliable and do not reorder datagrams

SOCK_SEQPACKET (compare to SCTP) – a connection-oriented sequenced-packet socket that preserves message boundaries and delivers messages in the order sent

The UDS facility is a standard component of a POSIX operating system.

The API for a UDS is similar to that of an Internet socket, but instead of using an underlying network protocol, communication takes place entirely within the operating system kernel. A UDS may use the file system as its address namespace. Some operating systems, such as Linux, provide additional namespaces. Processes refer to a UDS through a file system inode, allowing two processes to communicate by opening the same socket.

In addition to sending data, processes can pass file descriptors over a UDS connection by using the sendmsg() and recvmsg() system calls. This allows one process to grant another process access to a file descriptor that it would not otherwise be able to use. This can be used to implement a rudimentary form of capability-based security.

Editorial summary

This brief starts where responsible research should: with the source description of “Unix domain socket” as socket for exchanging data between processes executing on the same OS; similar to an Internet socket, but all communication occurs within the same OS. Everything that follows is an evidence route, not borrowed authority.

Editorial reviewA dependable orientation record for establishing vocabulary, names and a first evidence trail. The current 266-word lead offers orientation but no explicit four-digit date, so chronology should not be assumed. The selected authority fields contribute no independent date. The account is most persuasive where Unix, domain and socket can be independently traced.
Editorial analysis

Why this record matters

The subject matters to the general reference register because the source frames it as socket for exchanging data between processes executing on the same OS; similar to an Internet socket, but all communication occurs within the same OS. Its deeper value depends on whether names, dates, institutions and citations support that framing.

Evidence profile

The citation trail is more important than the brevity of the summary: it shows where individual claims can be examined in context. The source revision retrieved here is dated Mar 9, 2026. The linked authority identifier is Q2044498. None of the 0 selected statements returned an explicit reference.

Critical limits

A concise general-reference account can conceal disagreements about scope, terminology or the weight assigned to individual sources. The source lead contains qualifying language; that uncertainty should survive quotation, summary and reuse. Authority statements aid reconciliation but still require their own references, qualifiers and ranks to be checked.

How to read it

Use the entry as an orientation point, then follow its citations and revision history. Names, dates and institutional relationships should be checked against the original record.

Best used for
  • Subject orientation
  • Search vocabulary
  • Locating named sources
Verify next

The closest primary source, responsible institution and strongest cited specialist reference.

Three-step research path

  1. Establish the record: confirm the title “Unix domain socket”, its source revision and the description used here.
  2. Expand the search: follow Unix domain socket primary sources, Unix domain socket archive and Unix research across catalogues and specialist indexes.
  3. Test the account: compare the strongest cited source with the responsible institution’s current record and note any disagreement.

Questions for further research

  1. Which source most directly establishes the central claim about “Unix domain socket”?
  2. Which cited source is closest to the event, object or claim?
  3. What terminology or title could unlock a more precise catalogue search?
Subject index

Search terms from this dossier

Source & attribution

This entry incorporates text from Unix domain socket” on English Wikipedia. Contributors are listed in the page history. Text is available under the Creative Commons Attribution-ShareAlike 4.0 License. Selected authority identifiers and statements are retrieved from Wikidata under CC0; their references and qualifiers remain part of the verification path.