1.\" $OpenBSD: unix.4,v 1.15 2021/08/21 18:18:05 jmc Exp $ 2.\" $NetBSD: unix.4,v 1.3 1994/11/30 16:22:43 jtc Exp $ 3.\" 4.\" Copyright (c) 1991, 1993 5.\" The Regents of the University of California. All rights reserved. 6.\" 7.\" Redistribution and use in source and binary forms, with or without 8.\" modification, are permitted provided that the following conditions 9.\" are met: 10.\" 1. Redistributions of source code must retain the above copyright 11.\" notice, this list of conditions and the following disclaimer. 12.\" 2. Redistributions in binary form must reproduce the above copyright 13.\" notice, this list of conditions and the following disclaimer in the 14.\" documentation and/or other materials provided with the distribution. 15.\" 3. Neither the name of the University nor the names of its contributors 16.\" may be used to endorse or promote products derived from this software 17.\" without specific prior written permission. 18.\" 19.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND 20.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 21.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 22.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE 23.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 24.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 25.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 26.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 27.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 28.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 29.\" SUCH DAMAGE. 30.\" 31.\" @(#)unix.4 8.1 (Berkeley) 6/9/93 32.\" 33.Dd $Mdocdate: August 21 2021 $ 34.Dt UNIX 4 35.Os 36.Sh NAME 37.Nm unix 38.Nd UNIX-domain protocol family 39.Sh SYNOPSIS 40.In sys/types.h 41.In sys/un.h 42.Sh DESCRIPTION 43The 44.Ux Ns -domain 45protocol family is a collection of protocols 46that provides local (on-machine) interprocess 47communication through the normal 48.Xr socket 2 49mechanisms. 50The 51.Ux Ns -domain 52family supports the 53.Dv SOCK_STREAM , 54.Dv SOCK_SEQPACKET , 55and 56.Dv SOCK_DGRAM 57socket types and uses 58filesystem pathnames for addressing. 59.Sh ADDRESSING 60.Ux Ns -domain 61addresses are variable-length filesystem pathnames of 62at most 104 characters. 63The include file 64.In sys/un.h 65defines this address: 66.Bd -literal -offset indent 67struct sockaddr_un { 68 u_char sun_len; 69 u_char sun_family; 70 char sun_path[104]; 71}; 72.Ed 73.Pp 74Binding a name to a 75.Ux Ns -domain 76socket with 77.Xr bind 2 78causes a socket file to be created in the filesystem. 79This file is 80.Em not 81removed when the socket is closed\(em\c 82.Xr unlink 2 83must be used to remove the file. 84.Pp 85The 86.Ux Ns -domain 87protocol family does not support broadcast addressing or any form 88of 89.Dq wildcard 90matching on incoming messages. 91All addresses are absolute- or relative-pathnames 92of other 93.Ux Ns -domain 94sockets. 95Normal filesystem access-control mechanisms are also 96applied when referencing pathnames; e.g., the destination 97of a 98.Xr connect 2 99or 100.Xr sendto 2 101must be writable. 102.Sh PROTOCOLS 103The 104.Ux Ns -domain 105protocol family is comprised of simple 106transport protocols that support the 107.Dv SOCK_STREAM , 108.Dv SOCK_SEQPACKET , 109and 110.Dv SOCK_DGRAM 111abstractions. 112.Dv SOCK_STREAM 113and 114.Dv SOCK_SEQPACKET 115sockets also support the communication of 116.Ux 117file descriptors through the use of the 118.Ar msg_control 119field in the 120.Ar msg 121argument to 122.Xr sendmsg 2 123and 124.Xr recvmsg 2 . 125.Pp 126Any valid descriptor may be sent in a message. 127The file descriptor(s) to be passed are described using a 128.Ar struct cmsghdr 129that is defined in the include file 130.In sys/socket.h . 131The type of the message is 132.Dv SCM_RIGHTS , 133and the data portion of the messages is an array of integers 134representing the file descriptors to be passed. 135The number of descriptors being passed is defined 136by the length field of the message; 137the length field is the sum of the size of the header 138plus the size of the array of file descriptors. 139.Pp 140The received descriptor is a 141.Em duplicate 142of the sender's descriptor, as if it were created with a call to 143.Xr dup 2 . 144Per-process descriptor flags, set with 145.Xr fcntl 2 , 146are 147.Em not 148passed to a receiver. 149Descriptors that are awaiting delivery, or that are 150purposely not received, are automatically closed by the system 151when the destination socket is closed. 152.Sh SEE ALSO 153.Xr socket 2 , 154.Xr netintro 4 155.Rs 156.\" 4.4BSD PSD:20 157.%A S. Sechrest 158.%T \&An Introductory 4.4BSD Interprocess Communication Tutorial 159.%B 4.4BSD Programmer's Supplementary Documents (PSD) 160.Re 161.Rs 162.\" 4.4BSD PSD:21 163.%A S. J. Leffler 164.%A R. S. Fabry 165.%A W. N. Joy 166.%A P. Lapsley 167.%A S. Miller 168.%A C. Torek 169.%T \&An Advanced 4.4BSD Interprocess Communication Tutorial 170.%B 4.4BSD Programmer's Supplementary Documents (PSD) 171.Re 172