1UNIX(7) Linux Programmer's Manual UNIX(7)
2
6 unix - sockets for local interprocess communication
7
9 #include <sys/socket.h>
10 #include <sys/un.h>
11 unix_socket = socket(AF_UNIX, type, 0);
13 error = socketpair(AF_UNIX, type, 0, int *sv);
14
16 The AF_UNIX (also known as AF_LOCAL) socket family is used to communi‐
17 cate between processes on the same machine efficiently. Traditionally,
18 UNIX domain sockets can be either unnamed, or bound to a filesystem
19 pathname (marked as being of type socket). Linux also supports an ab‐
20 stract namespace which is independent of the filesystem.
21 Valid socket types in the UNIX domain are: SOCK_STREAM, for a stream-
23 oriented socket; SOCK_DGRAM, for a datagram-oriented socket that pre‐
24 serves message boundaries (as on most UNIX implementations, UNIX domain
25 datagram sockets are always reliable and don't reorder datagrams); and
26 (since Linux 2.6.4) SOCK_SEQPACKET, for a sequenced-packet socket that
27 is connection-oriented, preserves message boundaries, and delivers mes‐
28 sages in the order that they were sent.
29 UNIX domain sockets support passing file descriptors or process creden‐
31 tials to other processes using ancillary data.
32 Address format
34 A UNIX domain socket address is represented in the following structure:
35 struct sockaddr_un {
37 sa_family_t sun_family; /* AF_UNIX */
38 char sun_path[108]; /* Pathname */
39 };
40 The sun_family field always contains AF_UNIX. On Linux, sun_path is
42 108 bytes in size; see also NOTES, below.
43 Various systems calls (for example, bind(2), connect(2), and sendto(2))
45 take a sockaddr_un argument as input. Some other system calls (for ex‐
46 ample, getsockname(2), getpeername(2), recvfrom(2), and accept(2)) re‐
47 turn an argument of this type.
48 Three types of address are distinguished in the sockaddr_un structure:
50 * pathname: a UNIX domain socket can be bound to a null-terminated
52 filesystem pathname using bind(2). When the address of a pathname
53 socket is returned (by one of the system calls noted above), its
54 length is
55 offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1
57 and sun_path contains the null-terminated pathname. (On Linux, the
59 above offsetof() expression equates to the same value as
60 sizeof(sa_family_t), but some other implementations include other
61 fields before sun_path, so the offsetof() expression more portably
62 describes the size of the address structure.)
63 For further details of pathname sockets, see below.
65 * unnamed: A stream socket that has not been bound to a pathname using
67 bind(2) has no name. Likewise, the two sockets created by socket‐
68 pair(2) are unnamed. When the address of an unnamed socket is re‐
69 turned, its length is sizeof(sa_family_t), and sun_path should not
70 be inspected.
71 * abstract: an abstract socket address is distinguished (from a path‐
73 name socket) by the fact that sun_path[0] is a null byte ('\0').
74 The socket's address in this namespace is given by the additional
75 bytes in sun_path that are covered by the specified length of the
76 address structure. (Null bytes in the name have no special signifi‐
77 cance.) The name has no connection with filesystem pathnames. When
78 the address of an abstract socket is returned, the returned addrlen
79 is greater than sizeof(sa_family_t) (i.e., greater than 2), and the
80 name of the socket is contained in the first (addrlen -
81 sizeof(sa_family_t)) bytes of sun_path.
82 Pathname sockets
84 When binding a socket to a pathname, a few rules should be observed for
85 maximum portability and ease of coding:
86 * The pathname in sun_path should be null-terminated.
88 * The length of the pathname, including the terminating null byte,
90 should not exceed the size of sun_path.
91 * The addrlen argument that describes the enclosing sockaddr_un struc‐
93 ture should have a value of at least:
94 offsetof(struct sockaddr_un, sun_path)+strlen(addr.sun_path)+1
96 or, more simply, addrlen can be specified as sizeof(struct sock‐
98 addr_un).
99 There is some variation in how implementations handle UNIX domain
101 socket addresses that do not follow the above rules. For example, some
102 (but not all) implementations append a null terminator if none is
103 present in the supplied sun_path.
104 When coding portable applications, keep in mind that some implementa‐
106 tions have sun_path as short as 92 bytes.
107 Various system calls (accept(2), recvfrom(2), getsockname(2), getpeer‐
109 name(2)) return socket address structures. When applied to UNIX domain
110 sockets, the value-result addrlen argument supplied to the call should
111 be initialized as above. Upon return, the argument is set to indicate
112 the actual size of the address structure. The caller should check the
113 value returned in this argument: if the output value exceeds the input
114 value, then there is no guarantee that a null terminator is present in
115 sun_path. (See BUGS.)
116 Pathname socket ownership and permissions
118 In the Linux implementation, pathname sockets honor the permissions of
119 the directory they are in. Creation of a new socket fails if the
120 process does not have write and search (execute) permission on the di‐
121 rectory in which the socket is created.
122 On Linux, connecting to a stream socket object requires write permis‐
124 sion on that socket; sending a datagram to a datagram socket likewise
125 requires write permission on that socket. POSIX does not make any
126 statement about the effect of the permissions on a socket file, and on
127 some systems (e.g., older BSDs), the socket permissions are ignored.
128 Portable programs should not rely on this feature for security.
129 When creating a new socket, the owner and group of the socket file are
131 set according to the usual rules. The socket file has all permissions
132 enabled, other than those that are turned off by the process umask(2).
133 The owner, group, and permissions of a pathname socket can be changed
135 (using chown(2) and chmod(2)).
136 Abstract sockets
138 Socket permissions have no meaning for abstract sockets: the process
139 umask(2) has no effect when binding an abstract socket, and changing
140 the ownership and permissions of the object (via fchown(2) and fch‐
141 mod(2)) has no effect on the accessibility of the socket.
142 Abstract sockets automatically disappear when all open references to
144 the socket are closed.
145 The abstract socket namespace is a nonportable Linux extension.
147 Socket options
149 For historical reasons, these socket options are specified with a
150 SOL_SOCKET type even though they are AF_UNIX specific. They can be set
151 with setsockopt(2) and read with getsockopt(2) by specifying SOL_SOCKET
152 as the socket family.
153 SO_PASSCRED
155 Enabling this socket option causes receipt of the credentials of
156 the sending process in an SCM_CREDENTIALS ancillary message in
157 each subsequently received message. The returned credentials
158 are those specified by the sender using SCM_CREDENTIALS, or a
159 default that includes the sender's PID, real user ID, and real
160 group ID, if the sender did not specify SCM_CREDENTIALS ancil‐
161 lary data.
162 When this option is set and the socket is not yet connected, a
164 unique name in the abstract namespace will be generated automat‐
165 ically.
166 The value given as an argument to setsockopt(2) and returned as
168 the result of getsockopt(2) is an integer boolean flag.
169 SO_PASSSEC
171 Enables receiving of the SELinux security label of the peer
172 socket in an ancillary message of type SCM_SECURITY (see below).
173 The value given as an argument to setsockopt(2) and returned as
175 the result of getsockopt(2) is an integer boolean flag.
176 The SO_PASSSEC option is supported for UNIX domain datagram
178 sockets since Linux 2.6.18; support for UNIX domain stream sock‐
179 ets was added in Linux 4.2.
180 SO_PEEK_OFF
182 See socket(7).
183 SO_PEERCRED
185 This read-only socket option returns the credentials of the peer
186 process connected to this socket. The returned credentials are
187 those that were in effect at the time of the call to connect(2)
188 or socketpair(2).
189 The argument to getsockopt(2) is a pointer to a ucred structure;
191 define the _GNU_SOURCE feature test macro to obtain the defini‐
192 tion of that structure from <sys/socket.h>.
193 The use of this option is possible only for connected AF_UNIX
195 stream sockets and for AF_UNIX stream and datagram socket pairs
196 created using socketpair(2).
197 SO_PEERSEC
199 This read-only socket option returns the security context of the
200 peer socket connected to this socket. By default, this will be
201 the same as the security context of the process that created the
202 peer socket unless overridden by the policy or by a process with
203 the required permissions.
204 The argument to getsockopt(2) is a pointer to a buffer of the
206 specified length in bytes into which the security context string
207 will be copied. If the buffer length is less than the length of
208 the security context string, then getsockopt(2) returns -1, sets
209 errno to ERANGE, and returns the required length via optlen.
210 The caller should allocate at least NAME_MAX bytes for the buf‐
211 fer initially, although this is not guaranteed to be sufficient.
212 Resizing the buffer to the returned length and retrying may be
213 necessary.
214 The security context string may include a terminating null char‐
216 acter in the returned length, but is not guaranteed to do so: a
217 security context "foo" might be represented as either
218 {'f','o','o'} of length 3 or {'f','o','o','\0'} of length 4,
219 which are considered to be interchangeable. The string is
220 printable, does not contain non-terminating null characters, and
221 is in an unspecified encoding (in particular, it is not guaran‐
222 teed to be ASCII or UTF-8).
223 The use of this option for sockets in the AF_UNIX address family
225 is supported since Linux 2.6.2 for connected stream sockets, and
226 since Linux 4.18 also for stream and datagram socket pairs cre‐
227 ated using socketpair(2).
228 Autobind feature
230 If a bind(2) call specifies addrlen as sizeof(sa_family_t), or the
231 SO_PASSCRED socket option was specified for a socket that was not ex‐
232 plicitly bound to an address, then the socket is autobound to an ab‐
233 stract address. The address consists of a null byte followed by 5
234 bytes in the character set [0-9a-f]. Thus, there is a limit of 2^20
235 autobind addresses. (From Linux 2.1.15, when the autobind feature was
236 added, 8 bytes were used, and the limit was thus 2^32 autobind ad‐
237 dresses. The change to 5 bytes came in Linux 2.3.15.)
238 Sockets API
240 The following paragraphs describe domain-specific details and unsup‐
241 ported features of the sockets API for UNIX domain sockets on Linux.
242 UNIX domain sockets do not support the transmission of out-of-band data
244 (the MSG_OOB flag for send(2) and recv(2)).
245 The send(2) MSG_MORE flag is not supported by UNIX domain sockets.
247 Before Linux 3.4, the use of MSG_TRUNC in the flags argument of recv(2)
249 was not supported by UNIX domain sockets.
250 The SO_SNDBUF socket option does have an effect for UNIX domain sock‐
252 ets, but the SO_RCVBUF option does not. For datagram sockets, the
253 SO_SNDBUF value imposes an upper limit on the size of outgoing data‐
254 grams. This limit is calculated as the doubled (see socket(7)) option
255 value less 32 bytes used for overhead.
256 Ancillary messages
258 Ancillary data is sent and received using sendmsg(2) and recvmsg(2).
259 For historical reasons, the ancillary message types listed below are
260 specified with a SOL_SOCKET type even though they are AF_UNIX specific.
261 To send them, set the cmsg_level field of the struct cmsghdr to
262 SOL_SOCKET and the cmsg_type field to the type. For more information,
263 see cmsg(3).
264 SCM_RIGHTS
266 Send or receive a set of open file descriptors from another
267 process. The data portion contains an integer array of the file
268 descriptors.
269 Commonly, this operation is referred to as "passing a file de‐
271 scriptor" to another process. However, more accurately, what is
272 being passed is a reference to an open file description (see
273 open(2)), and in the receiving process it is likely that a dif‐
274 ferent file descriptor number will be used. Semantically, this
275 operation is equivalent to duplicating (dup(2)) a file descrip‐
276 tor into the file descriptor table of another process.
277 If the buffer used to receive the ancillary data containing file
279 descriptors is too small (or is absent), then the ancillary data
280 is truncated (or discarded) and the excess file descriptors are
281 automatically closed in the receiving process.
282 If the number of file descriptors received in the ancillary data
284 would cause the process to exceed its RLIMIT_NOFILE resource
285 limit (see getrlimit(2)), the excess file descriptors are auto‐
286 matically closed in the receiving process.
287 The kernel constant SCM_MAX_FD defines a limit on the number of
289 file descriptors in the array. Attempting to send an array
290 larger than this limit causes sendmsg(2) to fail with the error
291 EINVAL. SCM_MAX_FD has the value 253 (or 255 in kernels before
292 2.6.38).
293 SCM_CREDENTIALS
295 Send or receive UNIX credentials. This can be used for authen‐
296 tication. The credentials are passed as a struct ucred ancil‐
297 lary message. This structure is defined in <sys/socket.h> as
298 follows:
299 struct ucred {
301 pid_t pid; /* Process ID of the sending process */
302 uid_t uid; /* User ID of the sending process */
303 gid_t gid; /* Group ID of the sending process */
304 };
305 Since glibc 2.8, the _GNU_SOURCE feature test macro must be de‐
307 fined (before including any header files) in order to obtain the
308 definition of this structure.
309 The credentials which the sender specifies are checked by the
311 kernel. A privileged process is allowed to specify values that
312 do not match its own. The sender must specify its own process
313 ID (unless it has the capability CAP_SYS_ADMIN, in which case
314 the PID of any existing process may be specified), its real user
315 ID, effective user ID, or saved set-user-ID (unless it has
316 CAP_SETUID), and its real group ID, effective group ID, or saved
317 set-group-ID (unless it has CAP_SETGID).
318 To receive a struct ucred message, the SO_PASSCRED option must
320 be enabled on the socket.
321 SCM_SECURITY
323 Receive the SELinux security context (the security label) of the
324 peer socket. The received ancillary data is a null-terminated
325 string containing the security context. The receiver should al‐
326 locate at least NAME_MAX bytes in the data portion of the ancil‐
327 lary message for this data.
328 To receive the security context, the SO_PASSSEC option must be
330 enabled on the socket (see above).
331 When sending ancillary data with sendmsg(2), only one item of each of
333 the above types may be included in the sent message.
334 At least one byte of real data should be sent when sending ancillary
336 data. On Linux, this is required to successfully send ancillary data
337 over a UNIX domain stream socket. When sending ancillary data over a
338 UNIX domain datagram socket, it is not necessary on Linux to send any
339 accompanying real data. However, portable applications should also in‐
340 clude at least one byte of real data when sending ancillary data over a
341 datagram socket.
342 When receiving from a stream socket, ancillary data forms a kind of
344 barrier for the received data. For example, suppose that the sender
345 transmits as follows:
346 1. sendmsg(2) of four bytes, with no ancillary data.
348 2. sendmsg(2) of one byte, with ancillary data.
349 3. sendmsg(2) of four bytes, with no ancillary data.
350 Suppose that the receiver now performs recvmsg(2) calls each with a
352 buffer size of 20 bytes. The first call will receive five bytes of
353 data, along with the ancillary data sent by the second sendmsg(2) call.
354 The next call will receive the remaining four bytes of data.
355 If the space allocated for receiving incoming ancillary data is too
357 small then the ancillary data is truncated to the number of headers
358 that will fit in the supplied buffer (or, in the case of an SCM_RIGHTS
359 file descriptor list, the list of file descriptors may be truncated).
360 If no buffer is provided for incoming ancillary data (i.e., the
361 msg_control field of the msghdr structure supplied to recvmsg(2) is
362 NULL), then the incoming ancillary data is discarded. In both of these
363 cases, the MSG_CTRUNC flag will be set in the msg.msg_flags value re‐
364 turned by recvmsg(2).
365 Ioctls
367 The following ioctl(2) calls return information in value. The correct
368 syntax is:
369 int value;
371 error = ioctl(unix_socket, ioctl_type, &value);
372 ioctl_type can be:
374 SIOCINQ
376 For SOCK_STREAM sockets, this call returns the number of unread
377 bytes in the receive buffer. The socket must not be in LISTEN
378 state, otherwise an error (EINVAL) is returned. SIOCINQ is de‐
379 fined in <linux/sockios.h>. Alternatively, you can use the syn‐
380 onymous FIONREAD, defined in <sys/ioctl.h>. For SOCK_DGRAM
381 sockets, the returned value is the same as for Internet domain
382 datagram sockets; see udp(7).
383
385 EADDRINUSE
386 The specified local address is already in use or the filesystem
387 socket object already exists.
388 EBADF This error can occur for sendmsg(2) when sending a file descrip‐
390 tor as ancillary data over a UNIX domain socket (see the de‐
391 scription of SCM_RIGHTS, above), and indicates that the file de‐
392 scriptor number that is being sent is not valid (e.g., it is not
393 an open file descriptor).
394 ECONNREFUSED
396 The remote address specified by connect(2) was not a listening
397 socket. This error can also occur if the target pathname is not
398 a socket.
399 ECONNRESET
401 Remote socket was unexpectedly closed.
402 EFAULT User memory address was not valid.
404 EINVAL Invalid argument passed. A common cause is that the value
406 AF_UNIX was not specified in the sun_type field of passed ad‐
407 dresses, or the socket was in an invalid state for the applied
408 operation.
409 EISCONN
411 connect(2) called on an already connected socket or a target ad‐
412 dress was specified on a connected socket.
413 ENOENT The pathname in the remote address specified to connect(2) did
415 not exist.
416 ENOMEM Out of memory.
418 ENOTCONN
420 Socket operation needs a target address, but the socket is not
421 connected.
422 EOPNOTSUPP
424 Stream operation called on non-stream oriented socket or tried
425 to use the out-of-band data option.
426 EPERM The sender passed invalid credentials in the struct ucred.
428 EPIPE Remote socket was closed on a stream socket. If enabled, a SIG‐
430 PIPE is sent as well. This can be avoided by passing the
431 MSG_NOSIGNAL flag to send(2) or sendmsg(2).
432 EPROTONOSUPPORT
434 Passed protocol is not AF_UNIX.
435 EPROTOTYPE
437 Remote socket does not match the local socket type (SOCK_DGRAM
438 versus SOCK_STREAM).
439 ESOCKTNOSUPPORT
441 Unknown socket type.
442 ESRCH While sending an ancillary message containing credentials
444 (SCM_CREDENTIALS), the caller specified a PID that does not
445 match any existing process.
446 ETOOMANYREFS
448 This error can occur for sendmsg(2) when sending a file descrip‐
449 tor as ancillary data over a UNIX domain socket (see the de‐
450 scription of SCM_RIGHTS, above). It occurs if the number of
451 "in-flight" file descriptors exceeds the RLIMIT_NOFILE resource
452 limit and the caller does not have the CAP_SYS_RESOURCE capabil‐
453 ity. An in-flight file descriptor is one that has been sent us‐
454 ing sendmsg(2) but has not yet been accepted in the recipient
455 process using recvmsg(2).
456 This error is diagnosed since mainline Linux 4.5 (and in some
458 earlier kernel versions where the fix has been backported). In
459 earlier kernel versions, it was possible to place an unlimited
460 number of file descriptors in flight, by sending each file de‐
461 scriptor with sendmsg(2) and then closing the file descriptor so
462 that it was not accounted against the RLIMIT_NOFILE resource
463 limit.
464 Other errors can be generated by the generic socket layer or by the
466 filesystem while generating a filesystem socket object. See the appro‐
467 priate manual pages for more information.
468
470 SCM_CREDENTIALS and the abstract namespace were introduced with Linux
471 2.2 and should not be used in portable programs. (Some BSD-derived
472 systems also support credential passing, but the implementation details
473 differ.)
474
476 Binding to a socket with a filename creates a socket in the filesystem
477 that must be deleted by the caller when it is no longer needed (using
478 unlink(2)). The usual UNIX close-behind semantics apply; the socket
479 can be unlinked at any time and will be finally removed from the
480 filesystem when the last reference to it is closed.
481 To pass file descriptors or credentials over a SOCK_STREAM socket, you
483 must to send or receive at least one byte of nonancillary data in the
484 same sendmsg(2) or recvmsg(2) call.
485 UNIX domain stream sockets do not support the notion of out-of-band
487 data.
488
490 When binding a socket to an address, Linux is one of the implementa‐
491 tions that appends a null terminator if none is supplied in sun_path.
492 In most cases this is unproblematic: when the socket address is re‐
493 trieved, it will be one byte longer than that supplied when the socket
494 was bound. However, there is one case where confusing behavior can re‐
495 sult: if 108 non-null bytes are supplied when a socket is bound, then
496 the addition of the null terminator takes the length of the pathname
497 beyond sizeof(sun_path). Consequently, when retrieving the socket ad‐
498 dress (for example, via accept(2)), if the input addrlen argument for
499 the retrieving call is specified as sizeof(struct sockaddr_un), then
500 the returned address structure won't have a null terminator in
501 sun_path.
502 In addition, some implementations don't require a null terminator when
504 binding a socket (the addrlen argument is used to determine the length
505 of sun_path) and when the socket address is retrieved on these imple‐
506 mentations, there is no null terminator in sun_path.
507 Applications that retrieve socket addresses can (portably) code to han‐
509 dle the possibility that there is no null terminator in sun_path by re‐
510 specting the fact that the number of valid bytes in the pathname is:
511 strnlen(addr.sun_path, addrlen - offsetof(sockaddr_un, sun_path))
513 Alternatively, an application can retrieve the socket address by allo‐
515 cating a buffer of size sizeof(struct sockaddr_un)+1 that is zeroed out
516 before the retrieval. The retrieving call can specify addrlen as
517 sizeof(struct sockaddr_un), and the extra zero byte ensures that there
518 will be a null terminator for the string returned in sun_path:
519 void *addrp;
521 addrlen = sizeof(struct sockaddr_un);
523 addrp = malloc(addrlen + 1);
524 if (addrp == NULL)
525 /* Handle error */ ;
526 memset(addrp, 0, addrlen + 1);
527 if (getsockname(sfd, (struct sockaddr *) addrp, &addrlen)) == -1)
529 /* handle error */ ;
530 printf("sun_path = %s\n", ((struct sockaddr_un *) addrp)->sun_path);
532 This sort of messiness can be avoided if it is guaranteed that the ap‐
534 plications that create pathname sockets follow the rules outlined above
535 under Pathname sockets.
536
538 The following code demonstrates the use of sequenced-packet sockets for
539 local interprocess communication. It consists of two programs. The
540 server program waits for a connection from the client program. The
541 client sends each of its command-line arguments in separate messages.
542 The server treats the incoming messages as integers and adds them up.
543 The client sends the command string "END". The server sends back a
544 message containing the sum of the client's integers. The client prints
545 the sum and exits. The server waits for the next client to connect.
546 To stop the server, the client is called with the command-line argument
547 "DOWN".
548 The following output was recorded while running the server in the back‐
550 ground and repeatedly executing the client. Execution of the server
551 program ends when it receives the "DOWN" command.
552 Example output
554 $ ./server &
555 [1] 25887
556 $ ./client 3 4
557 Result = 7
558 $ ./client 11 -5
559 Result = 6
560 $ ./client DOWN
561 Result = 0
562 [1]+ Done ./server
563 $
564 Program source
566 /*
568 * File connection.h
569 */
570 #define SOCKET_NAME "/tmp/9Lq7BNBnBycd6nxy.socket"
572 #define BUFFER_SIZE 12
573 /*
575 * File server.c
576 */
577 #include <stdio.h>
579 #include <stdlib.h>
580 #include <string.h>
581 #include <sys/socket.h>
582 #include <sys/un.h>
583 #include <unistd.h>
584 #include "connection.h"
585 int
587 main(int argc, char *argv[])
588 {
589 struct sockaddr_un name;
590 int down_flag = 0;
591 int ret;
592 int connection_socket;
593 int data_socket;
594 int result;
595 char buffer[BUFFER_SIZE];
596 /* Create local socket. */
598 connection_socket = socket(AF_UNIX, SOCK_SEQPACKET, 0);
600 if (connection_socket == -1) {
601 perror("socket");
602 exit(EXIT_FAILURE);
603 }
604 /*
606 * For portability clear the whole structure, since some
607 * implementations have additional (nonstandard) fields in
608 * the structure.
609 */
610 memset(&name, 0, sizeof(name));
612 /* Bind socket to socket name. */
614 name.sun_family = AF_UNIX;
616 strncpy(name.sun_path, SOCKET_NAME, sizeof(name.sun_path) - 1);
617 ret = bind(connection_socket, (const struct sockaddr *) &name,
619 sizeof(name));
620 if (ret == -1) {
621 perror("bind");
622 exit(EXIT_FAILURE);
623 }
624 /*
626 * Prepare for accepting connections. The backlog size is set
627 * to 20. So while one request is being processed other requests
628 * can be waiting.
629 */
630 ret = listen(connection_socket, 20);
632 if (ret == -1) {
633 perror("listen");
634 exit(EXIT_FAILURE);
635 }
636 /* This is the main loop for handling connections. */
638 for (;;) {
640 /* Wait for incoming connection. */
642 data_socket = accept(connection_socket, NULL, NULL);
644 if (data_socket == -1) {
645 perror("accept");
646 exit(EXIT_FAILURE);
647 }
648 result = 0;
650 for (;;) {
651 /* Wait for next data packet. */
653 ret = read(data_socket, buffer, sizeof(buffer));
655 if (ret == -1) {
656 perror("read");
657 exit(EXIT_FAILURE);
658 }
659 /* Ensure buffer is 0-terminated. */
661 buffer[sizeof(buffer) - 1] = 0;
663 /* Handle commands. */
665 if (!strncmp(buffer, "DOWN", sizeof(buffer))) {
667 down_flag = 1;
668 break;
669 }
670 if (!strncmp(buffer, "END", sizeof(buffer))) {
672 break;
673 }
674 /* Add received summand. */
676 result += atoi(buffer);
678 }
679 /* Send result. */
681 sprintf(buffer, "%d", result);
683 ret = write(data_socket, buffer, sizeof(buffer));
684 if (ret == -1) {
685 perror("write");
686 exit(EXIT_FAILURE);
687 }
688 /* Close socket. */
690 close(data_socket);
692 /* Quit on DOWN command. */
694 if (down_flag) {
696 break;
697 }
698 }
699 close(connection_socket);
701 /* Unlink the socket. */
703 unlink(SOCKET_NAME);
705 exit(EXIT_SUCCESS);
707 }
708 /*
710 * File client.c
711 */
712 #include <errno.h>
714 #include <stdio.h>
715 #include <stdlib.h>
716 #include <string.h>
717 #include <sys/socket.h>
718 #include <sys/un.h>
719 #include <unistd.h>
720 #include "connection.h"
721 int
723 main(int argc, char *argv[])
724 {
725 struct sockaddr_un addr;
726 int ret;
727 int data_socket;
728 char buffer[BUFFER_SIZE];
729 /* Create local socket. */
731 data_socket = socket(AF_UNIX, SOCK_SEQPACKET, 0);
733 if (data_socket == -1) {
734 perror("socket");
735 exit(EXIT_FAILURE);
736 }
737 /*
739 * For portability clear the whole structure, since some
740 * implementations have additional (nonstandard) fields in
741 * the structure.
742 */
743 memset(&addr, 0, sizeof(addr));
745 /* Connect socket to socket address */
747 addr.sun_family = AF_UNIX;
749 strncpy(addr.sun_path, SOCKET_NAME, sizeof(addr.sun_path) - 1);
750 ret = connect(data_socket, (const struct sockaddr *) &addr,
752 sizeof(addr));
753 if (ret == -1) {
754 fprintf(stderr, "The server is down.\n");
755 exit(EXIT_FAILURE);
756 }
757 /* Send arguments. */
759 for (int i = 1; i < argc; ++i) {
761 ret = write(data_socket, argv[i], strlen(argv[i]) + 1);
762 if (ret == -1) {
763 perror("write");
764 break;
765 }
766 }
767 /* Request result. */
769 strcpy(buffer, "END");
771 ret = write(data_socket, buffer, strlen(buffer) + 1);
772 if (ret == -1) {
773 perror("write");
774 exit(EXIT_FAILURE);
775 }
776 /* Receive result. */
778 ret = read(data_socket, buffer, sizeof(buffer));
780 if (ret == -1) {
781 perror("read");
782 exit(EXIT_FAILURE);
783 }
784 /* Ensure buffer is 0-terminated. */
786 buffer[sizeof(buffer) - 1] = 0;
788 printf("Result = %s\n", buffer);
790 /* Close socket. */
792 close(data_socket);
794 exit(EXIT_SUCCESS);
796 }
797 For an example of the use of SCM_RIGHTS see cmsg(3).
799
801 recvmsg(2), sendmsg(2), socket(2), socketpair(2), cmsg(3), capabili‐
802 ties(7), credentials(7), socket(7), udp(7)
803
805 This page is part of release 5.10 of the Linux man-pages project. A
806 description of the project, information about reporting bugs, and the
807 latest version of this page, can be found at
808 https://www.kernel.org/doc/man-pages/.
809Linux 2020-11-01 UNIX(7)