xref: /openbsd/share/man/man4/unix.4 (revision d415bd75)
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