小结：
1、Unix domain socket 和 TCP socket相比 优势在哪里
IPC with UDS looks very similar to IPC with regular TCP sockets
performance 性能 应用场景：日志投递
Unix域套接字
https://zh.wikipedia.org/wiki/Unix域套接字
Unix domain socket 或者 IPC socket是一种终端，可以使同一台操作系统上的两个或多个进程进行数据通信。与管道相比，Unix domain sockets 既可以使用字节流，又可以使用数据队列，而管道通信则只能使用字节流。Unix domain sockets的接口和Internet socket很像，但它不使用网络底层协议来通信。Unix domain socket 的功能是POSIX操作系统里的一种组件。
Unix domain sockets 使用系统文件的地址来作为自己的身份。它可以被系统进程引用。所以两个进程可以同时打开一个Unix domain sockets来进行通信。不过这种通信方式是发生在系统内核里而不会在网络里传播。
Unix domain socket - Wikipedia https://en.wikipedia.org/wiki/Unix_domain_socket
Unix domain socket
A Unix domain socket or IPC socket (inter-process communication socket) is a data communications endpoint for exchanging data between processes executing on the same host operating system. Valid socket types in the UNIX domain are:[1]
SOCK_STREAM(compare to TCP) – for a stream-oriented socketSOCK_DGRAM(compare to UDP) – for a datagram-oriented socket that preserves message boundaries (as on most UNIX implementations, UNIX domain datagram sockets are always reliable and don't reorder datagrams)SOCK_SEQPACKET(compare to SCTP) – for a sequenced-packet socket that is connection-oriented, preserves message boundaries, and delivers messages in the order that they were sent
The Unix domain socket facility is a standard component of POSIX operating systems.
The API for Unix domain sockets is similar to that of an Internet socket, but rather than using an underlying network protocol, all communication occurs entirely within the operating system kernel. Unix domain sockets may use the file system as their address name space. (Some operating systems, like Linux, offer additional namespaces.) Processes reference Unix domain sockets as file system inodes, so two processes can communicate by opening the same socket.
In addition to sending data, processes may send file descriptors across a Unix domain socket connection using the sendmsg() and recvmsg() system calls. This allows the sending processes to grant the receiving process access to a file descriptor for which the receiving process otherwise does not have access.[2][3] This can be used to implement a rudimentary form of capability-based security.[4] For example, this allows the Clam AntiVirus scanner to run as an unprivileged daemon on Linux and BSD, yet still read any file sent to the daemon's Unix domain socket.
See also[edit]
unix(7) - Linux manual page https://man7.org/linux/man-pages/man7/unix.7.html
unix(7) — Linux manual page
|
NAME | SYNOPSIS | DESCRIPTION | ERRORS | VERSIONS | NOTES | BUGS | EXAMPLES | SEE ALSO | COLOPHON |
UNIX(7) Linux Programmer's Manual UNIX(7)
NAME top
unix - sockets for local interprocess communication
SYNOPSIS top
#include <sys/socket.h>
#include <sys/un.h>
unix_socket = socket(AF_UNIX, type, 0);
error = socketpair(AF_UNIX, type, 0, int *sv);
DESCRIPTION top
The AF_UNIX (also known as AF_LOCAL) socket family is used to
communicate between processes on the same machine efficiently.
Traditionally, UNIX domain sockets can be either unnamed, or bound to
a filesystem pathname (marked as being of type socket). Linux also
supports an abstract namespace which is independent of the
filesystem.
Valid socket types in the UNIX domain are: SOCK_STREAM, for a stream-
oriented socket; SOCK_DGRAM, for a datagram-oriented socket that
preserves message boundaries (as on most UNIX implementations, UNIX
domain datagram sockets are always reliable and don't reorder
datagrams); and (since Linux 2.6.4) SOCK_SEQPACKET, for a sequenced-
packet socket that is connection-oriented, preserves message
boundaries, and delivers messages in the order that they were sent.
UNIX domain sockets support passing file descriptors or process
credentials to other processes using ancillary data.
Address format
A UNIX domain socket address is represented in the following
structure:
struct sockaddr_un {
sa_family_t sun_family; /* AF_UNIX */
char sun_path[108]; /* Pathname */
};
The sun_family field always contains AF_UNIX. On Linux, sun_path is
108 bytes in size; see also NOTES, below.
Various systems calls (for example, bind(2), connect(2), and
sendto(2)) take a sockaddr_un argument as input. Some other system
calls (for example, getsockname(2), getpeername(2), recvfrom(2), and
accept(2)) return an argument of this type.
Three types of address are distinguished in the sockaddr_un struc‐
ture:
* pathname: a UNIX domain socket can be bound to a null-terminated
filesystem pathname using bind(2). When the address of a pathname
socket is returned (by one of the system calls noted above), its
length is
offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1
and sun_path contains the null-terminated pathname. (On Linux,
the above offsetof() expression equates to the same value as
sizeof(sa_family_t), but some other implementations include other
fields before sun_path, so the offsetof() expression more portably
describes the size of the address structure.)
For further details of pathname sockets, see below.
* unnamed: A stream socket that has not been bound to a pathname us‐
ing bind(2) has no name. Likewise, the two sockets created by
socketpair(2) are unnamed. When the address of an unnamed socket
is returned, its length is sizeof(sa_family_t), and sun_path
should not be inspected.
* abstract: an abstract socket address is distinguished (from a
pathname socket) by the fact that sun_path[0] is a null byte
(' '). The socket's address in this namespace is given by the
additional bytes in sun_path that are covered by the specified
length of the address structure. (Null bytes in the name have no
special significance.) The name has no connection with filesystem
pathnames. When the address of an abstract socket is returned,
the returned addrlen is greater than sizeof(sa_family_t) (i.e.,
greater than 2), and the name of the socket is contained in the
first (addrlen - sizeof(sa_family_t)) bytes of sun_path.
Pathname sockets
When binding a socket to a pathname, a few rules should be observed
for maximum portability and ease of coding:
* The pathname in sun_path should be null-terminated.
* The length of the pathname, including the terminating null byte,
should not exceed the size of sun_path.
* The addrlen argument that describes the enclosing sockaddr_un
structure should have a value of at least:
offsetof(struct sockaddr_un, sun_path)+strlen(addr.sun_path)+1
or, more simply, addrlen can be specified as sizeof(struct sock‐
addr_un).
There is some variation in how implementations handle UNIX domain
socket addresses that do not follow the above rules. For example,
some (but not all) implementations append a null terminator if none
is present in the supplied sun_path.
When coding portable applications, keep in mind that some implementa‐
tions have sun_path as short as 92 bytes.
Various system calls (accept(2), recvfrom(2), getsockname(2),
getpeername(2)) return socket address structures. When applied to
UNIX domain sockets, the value-result addrlen argument supplied to
the call should be initialized as above. Upon return, the argument
is set to indicate the actual size of the address structure. The
caller should check the value returned in this argument: if the out‐
put value exceeds the input value, then there is no guarantee that a
null terminator is present in sun_path. (See BUGS.)
Pathname socket ownership and permissions
In the Linux implementation, pathname sockets honor the permissions
of the directory they are in. Creation of a new socket fails if the
process does not have write and search (execute) permission on the
directory in which the socket is created.
On Linux, connecting to a stream socket object requires write permis‐
sion on that socket; sending a datagram to a datagram socket likewise
requires write permission on that socket. POSIX does not make any
statement about the effect of the permissions on a socket file, and
on some systems (e.g., older BSDs), the socket permissions are ig‐
nored. Portable programs should not rely on this feature for secu‐
rity.
When creating a new socket, the owner and group of the socket file
are set according to the usual rules. The socket file has all per‐
missions enabled, other than those that are turned off by the process
umask(2).
The owner, group, and permissions of a pathname socket can be changed
(using chown(2) and chmod(2)).
Abstract sockets
Socket permissions have no meaning for abstract sockets: the process
umask(2) has no effect when binding an abstract socket, and changing
the ownership and permissions of the object (via fchown(2) and
fchmod(2)) has no effect on the accessibility of the socket.
Abstract sockets automatically disappear when all open references to
the socket are closed.
The abstract socket namespace is a nonportable Linux extension.
Socket options
For historical reasons, these socket options are specified with a
SOL_SOCKET type even though they are AF_UNIX specific. They can be
set with setsockopt(2) and read with getsockopt(2) by specifying
SOL_SOCKET as the socket family.
SO_PASSCRED
Enabling this socket option causes receipt of the credentials
of the sending process in an SCM_CREDENTIALS ancillary message
in each subsequently received message. The returned creden‐
tials are those specified by the sender using SCM_CREDENTIALS,
or a default that includes the sender's PID, real user ID, and
real group ID, if the sender did not specify SCM_CREDENTIALS
ancillary data.
When this option is set and the socket is not yet connected, a
unique name in the abstract namespace will be generated auto‐
matically.
The value given as an argument to setsockopt(2) and returned
as the result of getsockopt(2) is an integer boolean flag.
SO_PASSSEC
Enables receiving of the SELinux security label of the peer
socket in an ancillary message of type SCM_SECURITY (see be‐
low).
The value given as an argument to setsockopt(2) and returned
as the result of getsockopt(2) is an integer boolean flag.
The SO_PASSSEC option is supported for UNIX domain datagram
sockets since Linux 2.6.18; support for UNIX domain stream
sockets was added in Linux 4.2.
SO_PEEK_OFF
See socket(7).
SO_PEERCRED
This read-only socket option returns the credentials of the
peer process connected to this socket. The returned creden‐
tials are those that were in effect at the time of the call to
connect(2) or socketpair(2).
The argument to getsockopt(2) is a pointer to a ucred struc‐
ture; define the _GNU_SOURCE feature test macro to obtain the
definition of that structure from <sys/socket.h>.
The use of this option is possible only for connected AF_UNIX
stream sockets and for AF_UNIX stream and datagram socket
pairs created using socketpair(2).
SO_PEERSEC
This read-only socket option returns the security context of
the peer socket connected to this socket. By default, this
will be the same as the security context of the process that
created the peer socket unless overridden by the policy or by
a process with the required permissions.
The argument to getsockopt(2) is a pointer to a buffer of the
specified length in bytes into which the security context
string will be copied. If the buffer length is less than the
length of the security context string, then getsockopt(2) re‐
turns -1, sets errno to ERANGE, and returns the required
length via optlen. The caller should allocate at least
NAME_MAX bytes for the buffer initially, although this is not
guaranteed to be sufficient. Resizing the buffer to the re‐
turned length and retrying may be necessary.
The security context string may include a terminating null
character in the returned length, but is not guaranteed to do
so: a security context "foo" might be represented as either
{'f','o','o'} of length 3 or {'f','o','o',' '} of length 4,
which are considered to be interchangeable. The string is
printable, does not contain non-terminating null characters,
and is in an unspecified encoding (in particular, it is not
guaranteed to be ASCII or UTF-8).
The use of this option for sockets in the AF_UNIX address fam‐
ily is supported since Linux 2.6.2 for connected stream sock‐
ets, and since Linux 4.18 also for stream and datagram socket
pairs created using socketpair(2).
Autobind feature
If a bind(2) call specifies addrlen as sizeof(sa_family_t), or the
SO_PASSCRED socket option was specified for a socket that was not ex‐
plicitly bound to an address, then the socket is autobound to an ab‐
stract address. The address consists of a null byte followed by 5
bytes in the character set [0-9a-f]. Thus, there is a limit of 2^20
autobind addresses. (From Linux 2.1.15, when the autobind feature
was added, 8 bytes were used, and the limit was thus 2^32 autobind
addresses. The change to 5 bytes came in Linux 2.3.15.)
Sockets API
The following paragraphs describe domain-specific details and unsup‐
ported features of the sockets API for UNIX domain sockets on Linux.
UNIX domain sockets do not support the transmission of out-of-band
data (the MSG_OOB flag for send(2) and recv(2)).
The send(2) MSG_MORE flag is not supported by UNIX domain sockets.
Before Linux 3.4, the use of MSG_TRUNC in the flags argument of
recv(2) was not supported by UNIX domain sockets.
The SO_SNDBUF socket option does have an effect for UNIX domain sock‐
ets, but the SO_RCVBUF option does not. For datagram sockets, the
SO_SNDBUF value imposes an upper limit on the size of outgoing data‐
grams. This limit is calculated as the doubled (see socket(7)) op‐
tion value less 32 bytes used for overhead.
Ancillary messages
Ancillary data is sent and received using sendmsg(2) and recvmsg(2).
For historical reasons, the ancillary message types listed below are
specified with a SOL_SOCKET type even though they are AF_UNIX spe‐
cific. To send them, set the cmsg_level field of the struct cmsghdr
to SOL_SOCKET and the cmsg_type field to the type. For more informa‐
tion, see cmsg(3).
SCM_RIGHTS
Send or receive a set of open file descriptors from another
process. The data portion contains an integer array of the
file descriptors.
Commonly, this operation is referred to as "passing a file de‐
scriptor" to another process. However, more accurately, what
is being passed is a reference to an open file description
(see open(2)), and in the receiving process it is likely that
a different file descriptor number will be used. Semanti‐
cally, this operation is equivalent to duplicating (dup(2)) a
file descriptor into the file descriptor table of another
process.
If the buffer used to receive the ancillary data containing
file descriptors is too small (or is absent), then the ancil‐
lary data is truncated (or discarded) and the excess file de‐
scriptors are automatically closed in the receiving process.
If the number of file descriptors received in the ancillary
data would cause the process to exceed its RLIMIT_NOFILE re‐
source limit (see getrlimit(2)), the excess file descriptors
are automatically closed in the receiving process.
The kernel constant SCM_MAX_FD defines a limit on the number
of file descriptors in the array. Attempting to send an array
larger than this limit causes sendmsg(2) to fail with the er‐
ror EINVAL. SCM_MAX_FD has the value 253 (or 255 in kernels
before 2.6.38).
SCM_CREDENTIALS
Send or receive UNIX credentials. This can be used for au‐
thentication. The credentials are passed as a struct ucred
ancillary message. This structure is defined in
<sys/socket.h> as follows:
struct ucred {
pid_t pid; /* Process ID of the sending process */
uid_t uid; /* User ID of the sending process */
gid_t gid; /* Group ID of the sending process */
};
Since glibc 2.8, the _GNU_SOURCE feature test macro must be
defined (before including any header files) in order to obtain
the definition of this structure.
The credentials which the sender specifies are checked by the
kernel. A privileged process is allowed to specify values
that do not match its own. The sender must specify its own
process ID (unless it has the capability CAP_SYS_ADMIN, in
which case the PID of any existing process may be specified),
its real user ID, effective user ID, or saved set-user-ID (un‐
less it has CAP_SETUID), and its real group ID, effective
group ID, or saved set-group-ID (unless it has CAP_SETGID).
To receive a struct ucred message, the SO_PASSCRED option must
be enabled on the socket.
SCM_SECURITY
Receive the SELinux security context (the security label) of
the peer socket. The received ancillary data is a null-termi‐
nated string containing the security context. The receiver
should allocate at least NAME_MAX bytes in the data portion of
the ancillary message for this data.
To receive the security context, the SO_PASSSEC option must be
enabled on the socket (see above).
When sending ancillary data with sendmsg(2), only one item of each of
the above types may be included in the sent message.
At least one byte of real data should be sent when sending ancillary
data. On Linux, this is required to successfully send ancillary data
over a UNIX domain stream socket. When sending ancillary data over a
UNIX domain datagram socket, it is not necessary on Linux to send any
accompanying real data. However, portable applications should also
include at least one byte of real data when sending ancillary data
over a datagram socket.
When receiving from a stream socket, ancillary data forms a kind of
barrier for the received data. For example, suppose that the sender
transmits as follows:
1. sendmsg(2) of four bytes, with no ancillary data.
2. sendmsg(2) of one byte, with ancillary data.
3. sendmsg(2) of four bytes, with no ancillary data.
Suppose that the receiver now performs recvmsg(2) calls each with a
buffer size of 20 bytes. The first call will receive five bytes of
data, along with the ancillary data sent by the second sendmsg(2)
call. The next call will receive the remaining four bytes of data.
If the space allocated for receiving incoming ancillary data is too
small then the ancillary data is truncated to the number of headers
that will fit in the supplied buffer (or, in the case of an
SCM_RIGHTS file descriptor list, the list of file descriptors may be
truncated). If no buffer is provided for incoming ancillary data
(i.e., the msg_control field of the msghdr structure supplied to
recvmsg(2) is NULL), then the incoming ancillary data is discarded.
In both of these cases, the MSG_CTRUNC flag will be set in the
msg.msg_flags value returned by recvmsg(2).
Ioctls
The following ioctl(2) calls return information in value. The cor‐
rect syntax is:
int value;
error = ioctl(unix_socket, ioctl_type, &value);
ioctl_type can be:
SIOCINQ
For SOCK_STREAM sockets, this call returns the number of un‐
read bytes in the receive buffer. The socket must not be in
LISTEN state, otherwise an error (EINVAL) is returned.
SIOCINQ is defined in <linux/sockios.h>. Alternatively, you
can use the synonymous FIONREAD, defined in <sys/ioctl.h>.
For SOCK_DGRAM sockets, the returned value is the same as for
Internet domain datagram sockets; see udp(7).
ERRORS top
EADDRINUSE
The specified local address is already in use or the
filesystem socket object already exists.
EBADF This error can occur for sendmsg(2) when sending a file
descriptor as ancillary data over a UNIX domain socket (see
the description of SCM_RIGHTS, above), and indicates that the
file descriptor number that is being sent is not valid (e.g.,
it is not an open file descriptor).
ECONNREFUSED
The remote address specified by connect(2) was not a listening
socket. This error can also occur if the target pathname is
not a socket.
ECONNRESET
Remote socket was unexpectedly closed.
EFAULT User memory address was not valid.
EINVAL Invalid argument passed. A common cause is that the value
AF_UNIX was not specified in the sun_type field of passed
addresses, or the socket was in an invalid state for the
applied operation.
EISCONN
connect(2) called on an already connected socket or a target
address was specified on a connected socket.
ENOENT The pathname in the remote address specified to connect(2) did
not exist.
ENOMEM Out of memory.
ENOTCONN
Socket operation needs a target address, but the socket is not
connected.
EOPNOTSUPP
Stream operation called on non-stream oriented socket or tried
to use the out-of-band data option.
EPERM The sender passed invalid credentials in the struct ucred.
EPIPE Remote socket was closed on a stream socket. If enabled, a
SIGPIPE is sent as well. This can be avoided by passing the
MSG_NOSIGNAL flag to send(2) or sendmsg(2).
EPROTONOSUPPORT
Passed protocol is not AF_UNIX.
EPROTOTYPE
Remote socket does not match the local socket type (SOCK_DGRAM
versus SOCK_STREAM).
ESOCKTNOSUPPORT
Unknown socket type.
ESRCH While sending an ancillary message containing credentials
(SCM_CREDENTIALS), the caller specified a PID that does not
match any existing process.
ETOOMANYREFS
This error can occur for sendmsg(2) when sending a file
descriptor as ancillary data over a UNIX domain socket (see
the description of SCM_RIGHTS, above). It occurs if the
number of "in-flight" file descriptors exceeds the
RLIMIT_NOFILE resource limit and the caller does not have the
CAP_SYS_RESOURCE capability. An in-flight file descriptor is
one that has been sent using sendmsg(2) but has not yet been
accepted in the recipient process using recvmsg(2).
This error is diagnosed since mainline Linux 4.5 (and in some
earlier kernel versions where the fix has been backported).
In earlier kernel versions, it was possible to place an
unlimited number of file descriptors in flight, by sending
each file descriptor with sendmsg(2) and then closing the file
descriptor so that it was not accounted against the
RLIMIT_NOFILE resource limit.
Other errors can be generated by the generic socket layer or by the
filesystem while generating a filesystem socket object. See the
appropriate manual pages for more information.
VERSIONS top
SCM_CREDENTIALS and the abstract namespace were introduced with Linux
2.2 and should not be used in portable programs. (Some BSD-derived
systems also support credential passing, but the implementation
details differ.)
NOTES top
Binding to a socket with a filename creates a socket in the
filesystem that must be deleted by the caller when it is no longer
needed (using unlink(2)). The usual UNIX close-behind semantics
apply; the socket can be unlinked at any time and will be finally
removed from the filesystem when the last reference to it is closed.
To pass file descriptors or credentials over a SOCK_STREAM socket,
you must to send or receive at least one byte of nonancillary data in
the same sendmsg(2) or recvmsg(2) call.
UNIX domain stream sockets do not support the notion of out-of-band
data.
BUGS top
When binding a socket to an address, Linux is one of the
implementations that appends a null terminator if none is supplied in
sun_path. In most cases this is unproblematic: when the socket
address is retrieved, it will be one byte longer than that supplied
when the socket was bound. However, there is one case where
confusing behavior can result: if 108 non-null bytes are supplied
when a socket is bound, then the addition of the null terminator
takes the length of the pathname beyond sizeof(sun_path).
Consequently, when retrieving the socket address (for example, via
accept(2)), if the input addrlen argument for the retrieving call is
specified as sizeof(struct sockaddr_un), then the returned address
structure won't have a null terminator in sun_path.
In addition, some implementations don't require a null terminator
when binding a socket (the addrlen argument is used to determine the
length of sun_path) and when the socket address is retrieved on these
implementations, there is no null terminator in sun_path.
Applications that retrieve socket addresses can (portably) code to
handle the possibility that there is no null terminator in sun_path
by respecting the fact that the number of valid bytes in the pathname
is:
strnlen(addr.sun_path, addrlen - offsetof(sockaddr_un, sun_path))
Alternatively, an application can retrieve the socket address by
allocating a buffer of size sizeof(struct sockaddr_un)+1 that is
zeroed out before the retrieval. The retrieving call can specify
addrlen as sizeof(struct sockaddr_un), and the extra zero byte
ensures that there will be a null terminator for the string returned
in sun_path:
void *addrp;
addrlen = sizeof(struct sockaddr_un);
addrp = malloc(addrlen + 1);
if (addrp == NULL)
/* Handle error */ ;
memset(addrp, 0, addrlen + 1);
if (getsockname(sfd, (struct sockaddr *) addrp, &addrlen)) == -1)
/* handle error */ ;
printf("sun_path = %s
", ((struct sockaddr_un *) addrp)->sun_path);
This sort of messiness can be avoided if it is guaranteed that the
applications that create pathname sockets follow the rules outlined
above under Pathname sockets.
EXAMPLES top
The following code demonstrates the use of sequenced-packet sockets
for local interprocess communication. It consists of two programs.
The server program waits for a connection from the client program.
The client sends each of its command-line arguments in separate
messages. The server treats the incoming messages as integers and
adds them up. The client sends the command string "END". The server
sends back a message containing the sum of the client's integers.
The client prints the sum and exits. The server waits for the next
client to connect. To stop the server, the client is called with the
command-line argument "DOWN".
The following output was recorded while running the server in the
background and repeatedly executing the client. Execution of the
server program ends when it receives the "DOWN" command.
Example output
$ ./server &
[1] 25887
$ ./client 3 4
Result = 7
$ ./client 11 -5
Result = 6
$ ./client DOWN
Result = 0
[1]+ Done ./server
$
Program source
/*
* File connection.h
*/
#define SOCKET_NAME "/tmp/9Lq7BNBnBycd6nxy.socket"
#define BUFFER_SIZE 12
/*
* File server.c
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>
#include "connection.h"
int
main(int argc, char *argv[])
{
struct sockaddr_un name;
int down_flag = 0;
int ret;
int connection_socket;
int data_socket;
int result;
char buffer[BUFFER_SIZE];
/* Create local socket. */
connection_socket = socket(AF_UNIX, SOCK_SEQPACKET, 0);
if (connection_socket == -1) {
perror("socket");
exit(EXIT_FAILURE);
}
/*
* For portability clear the whole structure, since some
* implementations have additional (nonstandard) fields in
* the structure.
*/
memset(&name, 0, sizeof(name));
/* Bind socket to socket name. */
name.sun_family = AF_UNIX;
strncpy(name.sun_path, SOCKET_NAME, sizeof(name.sun_path) - 1);
ret = bind(connection_socket, (const struct sockaddr *) &name,
sizeof(name));
if (ret == -1) {
perror("bind");
exit(EXIT_FAILURE);
}
/*
* Prepare for accepting connections. The backlog size is set
* to 20. So while one request is being processed other requests
* can be waiting.
*/
ret = listen(connection_socket, 20);
if (ret == -1) {
perror("listen");
exit(EXIT_FAILURE);
}
/* This is the main loop for handling connections. */
for (;;) {
/* Wait for incoming connection. */
data_socket = accept(connection_socket, NULL, NULL);
if (data_socket == -1) {
perror("accept");
exit(EXIT_FAILURE);
}
result = 0;
for (;;) {
/* Wait for next data packet. */
ret = read(data_socket, buffer, sizeof(buffer));
if (ret == -1) {
perror("read");
exit(EXIT_FAILURE);
}
/* Ensure buffer is 0-terminated. */
buffer[sizeof(buffer) - 1] = 0;
/* Handle commands. */
if (!strncmp(buffer, "DOWN", sizeof(buffer))) {
down_flag = 1;
break;
}
if (!strncmp(buffer, "END", sizeof(buffer))) {
break;
}
/* Add received summand. */
result += atoi(buffer);
}
/* Send result. */
sprintf(buffer, "%d", result);
ret = write(data_socket, buffer, sizeof(buffer));
if (ret == -1) {
perror("write");
exit(EXIT_FAILURE);
}
/* Close socket. */
close(data_socket);
/* Quit on DOWN command. */
if (down_flag) {
break;
}
}
close(connection_socket);
/* Unlink the socket. */
unlink(SOCKET_NAME);
exit(EXIT_SUCCESS);
}
/*
* File client.c
*/
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>
#include "connection.h"
int
main(int argc, char *argv[])
{
struct sockaddr_un addr;
int ret;
int data_socket;
char buffer[BUFFER_SIZE];
/* Create local socket. */
data_socket = socket(AF_UNIX, SOCK_SEQPACKET, 0);
if (data_socket == -1) {
perror("socket");
exit(EXIT_FAILURE);
}
/*
* For portability clear the whole structure, since some
* implementations have additional (nonstandard) fields in
* the structure.
*/
memset(&addr, 0, sizeof(addr));
/* Connect socket to socket address */
addr.sun_family = AF_UNIX;
strncpy(addr.sun_path, SOCKET_NAME, sizeof(addr.sun_path) - 1);
ret = connect(data_socket, (const struct sockaddr *) &addr,
sizeof(addr));
if (ret == -1) {
fprintf(stderr, "The server is down.
");
exit(EXIT_FAILURE);
}
/* Send arguments. */
for (int i = 1; i < argc; ++i) {
ret = write(data_socket, argv[i], strlen(argv[i]) + 1);
if (ret == -1) {
perror("write");
break;
}
}
/* Request result. */
strcpy(buffer, "END");
ret = write(data_socket, buffer, strlen(buffer) + 1);
if (ret == -1) {
perror("write");
exit(EXIT_FAILURE);
}
/* Receive result. */
ret = read(data_socket, buffer, sizeof(buffer));
if (ret == -1) {
perror("read");
exit(EXIT_FAILURE);
}
/* Ensure buffer is 0-terminated. */
buffer[sizeof(buffer) - 1] = 0;
printf("Result = %s
", buffer);
/* Close socket. */
close(data_socket);
exit(EXIT_SUCCESS);
}
For an example of the use of SCM_RIGHTS see cmsg(3).
SEE ALSO top
recvmsg(2), sendmsg(2), socket(2), socketpair(2), cmsg(3), capabilities(7), credentials(7), socket(7), udp(7)
COLOPHON top
This page is part of release 5.09 of the Linux man-pages project. A
description of the project, information about reporting bugs, and the
latest version of this page, can be found at
https://www.kernel.org/doc/man-pages/.
Linux 2020-11-01 UNIX(7)
Principle of Unix Domain Socket. How does it work? - Stack Overflow https://stackoverflow.com/questions/14919441/principle-of-unix-domain-socket-how-does-it-work#
Unix sockets are used as any other socket types. This means, that socket system calls are used for them. The difference between FIFOs and Unix sockets, is that FIFO use file sys calls, while Unix sockets use socket calls.
Unix sockets are addressed as files. It allows to use file permissions for access control.
Unix sockets are created by socket sys call (while FIFO created by mkfifo). If you need client socket, you call connect, passing it server socket address. If you need server socket, you can bind to assign its address. While, for FIFO open call is used. IO operation is performed by read/write.
Unix socket can distinguish its clients, while FIFO cannot. Info about peer is provided by accept call, it returns address of peer.
Unix sockets are bidirectional. This means that every side can perform both read and write operations. While, FIFOs are unidirectional: it has a writer peer and a reader peer.
Unix sockets create less overhead and communication is faster, than by localhost IP sockets. Packets don't need to go through network stack as with localhost sockets. And as they exists only locally, there is no routing.
If you need more details about, how Unix sockets work at kernel level, please, look at net/unix/af_unix.c file in Linux kernel source.
Getting Started With Unix Domain Sockets | by Matt Lim | The Startup | Medium https://medium.com/swlh/getting-started-with-unix-domain-sockets-4472c0db4eb1
Sockets provide a means of communication between processes, i.e. a way for them to exchange data. The way it usually works is that process_a has socket_x, process_b has socket_y, and the two sockets are connected. Each process can then use its socket to receive data from the other process and/or send data to the other process. One way to think about sockets is that they open up a communication channel where both sides can read and write.
In this post, we’re going to focus on Unix domain sockets, and I’ll try to keep it simple.
- First, we’ll take a look at how clients and servers typically communicate via sockets. Specifically, we’ll go over the system calls involved, and how they’re generally used.
- Second, we’ll take a look at some actual code. Of course, you’ll be able to run this code yourself.
Let’s get started.
Note: Each socket has two important attributes: a communication domain and a type. There are two main types, stream and datagram. In this post, I’m going to focus on the former. That is, I’m going to focus on streaming Unix domain sockets.
Socket Lifecycle
Let’s say we want to use sockets to send some data from one process to another. What are the main steps required for each process?
Server Process (AKA the server)
This process binds its socket to a known location and accepts incoming connection requests from clients. For each connection request that is received, a new socket is created that is used to communicate with the peer socket (peer socket = the socket at the other end of the connection, in this case the socket created by some client process).
- The server creates a new socket using the
socket()system call. This returns a file descriptor that can be used to refer to the socket in future system calls. - The server uses the
bind()system call to bind the socket to a well-known address, so that the client can connect to it (more on that below). - The server calls the
listen()system call to mark the socket as passive, i.e. as a socket that will accept incoming connection requests. - The server calls the
accept()system call to accept an incoming connection. This call blocks until a connection request arrives. Note that this function will error out iflisten()is not called beforehand. Importantly, this call creates a new socket that is connected to the peer socket and returns a file descriptor associated with it. So, if you want to communicate with the peer socket, you should use the file descriptor returned fromaccept(), not the file descriptor returned from the call tosocket()in step #1. The latter socket remains open and is used to accept further connection requests. - After this, the
read()andwrite()system calls can be used to communicate with the peer socket (i.e. to communicate with the client). - Finally, when the server is done with the socket, it should call
close().
Client Process (AKA the client)
This process connects its socket to a passive socket, after which it is free to communicate with the peer socket. Again, note that these two sockets — the passive socket and the peer socket — are different. The former is the one created by calling socket() in step #1 above, the latter is the one returned by calling accept() in step #4 above.
- This is the same as #1 above — the process creates a new socket using the
socket()system call, which returns a file descriptor that can be used to refer to the socket in future system calls. Note that by default, a socket created usingsocket()is marked as active, and can be used in aconnect()call to connect to a passive socket. - The client calls the
connect()system call, which connects to a passive socket. Remember that the server bound its socket to a well-known address — this is the address that should be used forconnect(). Note thatconnect()should be called afterlisten()is called on the server socket, otherwise it will error. However, it can be called beforeaccept().
Appendix A UNIX Domain Sockets
Introduction
UNIX domain sockets are named with UNIX paths. For example, a socket might be named /tmp/foo. UNIX domain sockets communicate only between processes on a single host. Sockets in the UNIX domain are not considered part of the network protocols because they can only be used to communicate between processes on a single host.
Socket types define the communication properties visible to a user. The Internet domain sockets provide access to the TCP/IP transport protocols. The Internet domain is identified by the value AF_INET. Sockets exchange data only with sockets in the same domain.
Socket Creation
The socket(3SOCKET) call creates a socket in the specified family and of the specified type.
s = socket(family, type, protocol);
If the protocol is unspecified (a value of 0), the system selects a protocol that supports the requested socket type. The socket handle (a file descriptor) is returned.
The family is specified by one of the constants defined in sys/socket.h. Constants named AF_suite specify the address format to use in interpreting names as shown in Table 2-1.
The following creates a datagram socket for intramachine use:
s = socket(AF_UNIX, SOCK_DGRAM, 0);
Use the default protocol (the protocol argument is 0) in most situations.
Binding Local Names
A socket is created with no name. A remote process has no way to refer to a socket until an address is bound to it. Communicating processes are connected through addresses. In the UNIX family, a connection is composed of (usually) one or two path names. UNIX family sockets need not always be bound to a name, but, when bound, there can never be duplicate ordered sets such as: local pathname or foreign pathname. The path names cannot refer to existing files.
The bind(3SOCKET) call allows a process to specify the local address of the socket. This provides local pathname, while connect(3SOCKET) and accept(3SOCKET) complete a socket's association by fixing the remote half of the address. bind(3SOCKET) is used as follows:
bind (s, name, namelen);
The socket handle is s. The bound name is a byte string that is interpreted by the supporting protocol(s). UNIX family names contain a path name and a family. The example shows binding the name /tmp/foo to a UNIX family socket.
#include <sys/un.h> ... struct sockaddr_un addr; ... strcpy(addr.sun_path, "/tmp/foo"); addr.sun_family = AF_UNIX; bind (s, (struct sockaddr *) &addr, strlen(addr.sun_path) + sizeof (addr.sun_family));
When determining the size of an AF_UNIX socket address, null bytes are not counted, which is why strlen(3C) use is fine.
The file name referred to in addr.sun_path is created as a socket in the system file name space. The caller must have write permission in the directory where addr.sun_path is created. The file should be deleted by the caller when it is no longer needed. AF_UNIX sockets can be deleted with unlink(1M).
Connection Establishment
Connection establishment is usually asymmetric. One process acts as the client and the other as the server. The server binds a socket to a well-known address associated with the service and blocks on its socket for a connect request. An unrelated process can then connect to the server. The client requests services from the server by initiating a connection to the server's socket. On the client side, the connect(3SOCKET) call initiates a connection. In the UNIX family, this might appear as:
struct sockaddr_un server;
server.sun.family = AF_UNIX;
...
connect(s, (struct sockaddr *)&server, strlen(server.sun_path)
+ sizeof (server.sun_family));
See "Connection Errors" for information on connection errors. "Data Transfer" tells you how to transfer data. "Closing Sockets" tells you how to close a socket.
- © 2010, Oracle Corporation and/or its af
https://golangnews.org/2019/02/unix-domain-sockets-in-go/
When it comes to inter-process communication (IPC) between processes on the same
Linux host, there are multiple options: FIFOs, pipes, shared memory, sockets and
so on. One of the most interesting options is Unix Domain Sockets that combine
the convenient API of sockets with the higher performance of the other
single-host methods.
This post demonstrates some basic examples of using Unix domain sockets with Go
and explores some benchmarks comparing them to TCP loop-back sockets.
UNIX DOMAIN SOCKETS (UDS)
Unix domain sockets (UDS) have a long history, going back to the original BSD
socket specification in the 1980s. The Wikipedia definition is:
A Unix domain socket or IPC socket (inter-process communication socket) is a
data communications endpoint for exchanging data between processes executing
on the same host operating system.
UDS support streams (TCP equivalent) and datagrams (UDP equivalent); this
post focuses on the stream APIs.
IPC with UDS looks very similar to IPC with regular TCP sockets using the
loop-back interface (localhost or 127.0.0.1), but there is a key
difference: performance. While the TCP loop-back interface can skip some of the
complexities of the full TCP/IP network stack, it retains many others (ACKs, TCP
flow control, and so on). These complexities are designed for reliable
cross-machine communication, but on a single host they’re an unnecessary burden.
This post will explore some of the performance advantages of UDS.
There are some additional differences. For example, since UDS use paths in the
filesystem as their addresses, we can use directory and file permissions to
control access to sockets, simplifying authentication. I won’t list all the
differences here; for more information feel free to check out the Wikipedia link
and additional resources like Beej’s UNIX IPC guide.
The big disadvantage of UDS compared to TCP sockets is the single-host
restriction, of course. For code written to use TCP sockets we only have to
change the address from local to remote and everything keeps working. That said,
the performance advantages of UDS are significant enough, and the API is similar
enough to TCP sockets that it’s quite possible to write code that supports both
(UDS on a single host, TCP for remote IPC) with very little difficulty.
Unix Sockets http://beej.us/guide/bgipc/html/multi/unixsock.html