Unix域套接字 UNIX domain sockets 本地套接字

 小结：

1、Unix domain socket 和 TCP socket相比 

IPC with UDS looks very similar to IPC with regular TCP sockets

2、

UDS支持面向流的TCP协议、面向数据报的UDP协议。

 UNIX domain sockets support both stream-oriented, TCP, and datagram-oriented, UDP, protocols. 

但是不支持 raw socket protocols。

 

  • SOCK_STREAM (compare to TCP) – for a stream-oriented socket
  • SOCK_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

SOCK_DGRAM  UNIX domain sockets 可靠的，不会重排数据报；

SOCK_SEQPACKET ： 面向连接。

 

 

 

 

 performance 性能 应用场景：日志投递

UNIX domain sockets - IBM Documentation https://www.ibm.com/docs/en/ztpf/2023?topic=considerations-unix-domain-sockets

UNIX domain sockets

上次更新时间: 2023-02-24

UNIX domain sockets enable efficient communication between processes that are running on the same z/TPF processor. UNIX domain sockets support both stream-oriented, TCP, and datagram-oriented, UDP, protocols. You cannot start a UNIX domain socket for raw socket protocols.

You can issue all of the socket application programming interfaces (APIs) that are supported by the z/TPF system for UNIX domain sockets.

To create a UNIX domain socket, use the socket function and specify AF_UNIX as the domain for the socket. The z/TPF system supports a maximum number of 16,383 active UNIX domain sockets at any time. After a UNIX domain socket is created, you must bind the socket to a unique file path by using the bind function. Unlike internet sockets in the AF_INET domain where the socket is bound to a unique IP address and port number, a UNIX domain socket is bound to a file path.

To specify the address of a UNIX domain socket, use the following SOCKADDR_UN address structure. In the address structure, the SUN_FAMILY field specifies the protocol family that is used and the SUN_PATH field specifies the path name of the socket. The SOCKADDR_UN structure is defined in the sys/un.h header file. 
#define UNIX_PATH_MAX 108
struct sockaddr_un {
       unsigned short int sun_family; /* AF_UNIX */
       char sun_path[UNIX_PATH_MAX]; /* pathname */
};

When you bind a unique name to a UNIX domain socket by using the bind function, a file is created on the file system for the socket. The socket file is at the path that you specify in the SUN_PATH field of the SOCKADDR_UN structure. When the program closes and the file is no longer required, you must manually delete the socket file from the file system.

Because UNIX domain sockets are processor-unique, specify a socket address that uses a path name of one of the following processor-unique file systems in loosely coupled environments:
  • Memory file system (MFS)
  • Pool file system (PFS)
  • Fixed file system (FFS)
In a loosely coupled environment, do not use a path name that belongs to the z/TPF collection support file system (TFS) for the address of a UNIX domain socket.

If you create UNIX domain sockets, the sockets can be inherited by a child process that is created by using the fork function. For internet sockets, the z/TPF system has a concept of kernel-based sockets, which means that the internet sockets are not bound to a process. However, UNIX domain sockets are treated as process scoped; that is, the socket is cleaned up when the last process exits or when all processes issue a close function on the socket.

If you issue the ZIPDB command, the ZSTAT command, or the ZTTCP DISPLAY command with the STATS parameter specified, information about the messages, bytes, and packet counters of the network services database are not updated for UNIX domain sockets. Messages that are sent across UNIX domain sockets are also not displayed in the IP trace facility.

Examples: Server programs that use UNIX domain sockets

The following code example shows a server program for connection-oriented, stream UNIX domain sockets. In the server program, the socket function creates a stream socket in the UNIX domain, and then the bind function assigns a unique name for the socket. The listen function then accepts incoming client connections and creates a connection queue for further incoming requests. 
/************************************************************/
/* This is a stream socket server sample program for UNIX   */
/* domain sockets. This program listens for a connection    */
/* from a client program, accepts it, reads data from the   */
/* client, then sends data back to connected UNIX socket.   */
/************************************************************/

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>

#define SOCK_PATH  "tpf_unix_sock.server"
#define DATA "Hello from server"

int main(void){

    int server_sock, client_sock, len, rc;
    int bytes_rec = 0;
    struct sockaddr_un server_sockaddr;
    struct sockaddr_un client_sockaddr;     
    char buf[256];
    int backlog = 10;
    memset(&server_sockaddr, 0, sizeof(struct sockaddr_un));
    memset(&client_sockaddr, 0, sizeof(struct sockaddr_un));
    memset(buf, 0, 256);                
    
    /**************************************/
    /* Create a UNIX domain stream socket */
    /**************************************/
    server_sock = socket(AF_UNIX, SOCK_STREAM, 0);
    if (server_sock == -1){
        printf("SOCKET ERROR: %d\n", sock_errno());
        exit(1);
    }
    
    /***************************************/
    /* Set up the UNIX sockaddr structure  */
    /* by using AF_UNIX for the family and */
    /* giving it a filepath to bind to.    */
    /*                                     */
    /* Unlink the file so the bind will    */
    /* succeed, then bind to that file.    */
    /***************************************/
    server_sockaddr.sun_family = AF_UNIX;   
    strcpy(server_sockaddr.sun_path, SOCK_PATH); 
    len = sizeof(server_sockaddr);
    
    unlink(SOCK_PATH);
    rc = bind(server_sock, (struct sockaddr *) &server_sockaddr, len);
    if (rc == -1){
        printf("BIND ERROR: %d\n", sock_errno());
        close(server_sock);
        exit(1);
    }
    
    /*********************************/
    /* Listen for any client sockets */
    /*********************************/
    rc = listen(server_sock, backlog);
    if (rc == -1){ 
        printf("LISTEN ERROR: %d\n", sock_errno());
        close(server_sock);
        exit(1);
    }
    printf("socket listening...\n");
    
    /*********************************/
    /* Accept an incoming connection */
    /*********************************/
    client_sock = accept(server_sock, (struct sockaddr *) &client_sockaddr, &len);
    if (client_sock == -1){
        printf("ACCEPT ERROR: %d\n", sock_errno());
        close(server_sock);
        close(client_sock);
        exit(1);
    }
    
    /****************************************/
    /* Get the name of the connected socket */
    /****************************************/
    len = sizeof(client_sockaddr);
    rc = getpeername(client_sock, (struct sockaddr *) &client_sockaddr, &len);
    if (rc == -1){
        printf("GETPEERNAME ERROR: %d\n", sock_errno());
        close(server_sock);
        close(client_sock);
        exit(1);
    }
    else {
        printf("Client socket filepath: %s\n", client_sockaddr.sun_path);
    }
    
    /************************************/
    /* Read and print the data          */
    /* incoming on the connected socket */
    /************************************/
    printf("waiting to read...\n");
    bytes_rec = recv(client_sock, buf, sizeof(buf), 0);
    if (bytes_rec == -1){
        printf("RECV ERROR: %d\n", sock_errno());
        close(server_sock);
        close(client_sock);
        exit(1);
    }
    else {
        printf("DATA RECEIVED = %s\n", buf);
    }
    
    /******************************************/
    /* Send data back to the connected socket */
    /******************************************/
    memset(buf, 0, 256);
    strcpy(buf, DATA);      
    printf("Sending data...\n");
    rc = send(client_sock, buf, strlen(buf), 0);
    if (rc == -1) {
        printf("SEND ERROR: %d", sock_errno());
        close(server_sock);
        close(client_sock);
        exit(1);
    }   
    else {
        printf("Data sent!\n");
    }
    
    /******************************/
    /* Close the sockets and exit */
    /******************************/
    close(server_sock);
    close(client_sock);
    
    return 0;
}
The following code example shows a server program for connectionless, datagram UNIX domain sockets. In the server program, the socket function creates a datagram socket in the UNIX domain, and then the bind function assigns a unique name for the socket. For connectionless sockets, you do not have to issue the listen function to accept incoming requests from a client. 
/************************************************************/
/* This is a datagram socket server sample program for UNIX */
/* domain sockets. This program creates a socket and        */
/* receives data from a client.                             */
/************************************************************/

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>

#define SOCK_PATH "tpf_unix_sock.server"

int main(void){

    int server_sock, len, rc;
    int bytes_rec = 0;
    struct sockaddr_un server_sockaddr, peer_sock;
    char buf[256];
    memset(&server_sockaddr, 0, sizeof(struct sockaddr_un));
    memset(buf, 0, 256);
    
    /****************************************/
    /* Create a UNIX domain datagram socket */
    /****************************************/
    server_sock = socket(AF_UNIX, SOCK_DGRAM, 0);
    if (server_sock == -1){
        printf("SOCKET ERROR = %d", sock_errno());
        exit(1);
    }
    
    /***************************************/
    /* Set up the UNIX sockaddr structure  */
    /* by using AF_UNIX for the family and */
    /* giving it a filepath to bind to.    */
    /*                                     */
    /* Unlink the file so the bind will    */
    /* succeed, then bind to that file.    */
    /***************************************/
    server_sockaddr.sun_family = AF_UNIX;
    strcpy(server_sockaddr.sun_path, SOCK_PATH); 
    len = sizeof(server_sockaddr);
    unlink(SOCK_PATH);
    rc = bind(server_sock, (struct sockaddr *) &server_sockaddr, len);
    if (rc == -1){
        printf("BIND ERROR = %d", sock_errno());
        close(server_sock);
        exit(1);
    }
    
    /****************************************/
    /* Read data on the server from clients */
    /* and print the data that was read.    */
    /****************************************/
    printf("waiting to recvfrom...\n");
    bytes_rec = recvfrom(server_sock, buf, 256, 0, (struct sockaddr *) &peer_sock, &len);
    if (bytes_rec == -1){
        printf("RECVFROM ERROR = %d", sock_errno());
        close(server_sock);
        exit(1);
    }
    else {
       printf("DATA RECEIVED = %s\n", buf);
    }
    
    /*****************************/
    /* Close the socket and exit */
    /*****************************/
    close(server_sock);

    return 0;
}

Examples: Client programs that use UNIX domain sockets

The following code example shows a client program for connection-oriented, stream UNIX domain sockets. In the program, the socket function is called to create a socket in the UNIX domain, and then the bind function assigns a unique name for the socket. The connect function then establishes a connection to the server. 
/************************************************************/
/* This is a stream socket client sample program for UNIX   */
/* domain sockets. This program creates a socket, connects  */
/* to a server, sends data, then receives and prints a      */
/* message from the server.                                 */
/************************************************************/

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>

#define SERVER_PATH "tpf_unix_sock.server"
#define CLIENT_PATH "tpf_unix_sock.client"
#define DATA "Hello from client"

int main(void){

    int client_sock, rc, len;
    struct sockaddr_un server_sockaddr; 
    struct sockaddr_un client_sockaddr; 
    char buf[256];
    memset(&server_sockaddr, 0, sizeof(struct sockaddr_un));
    memset(&client_sockaddr, 0, sizeof(struct sockaddr_un));
     
    /**************************************/
    /* Create a UNIX domain stream socket */
    /**************************************/
    client_sock = socket(AF_UNIX, SOCK_STREAM, 0);
    if (client_sock == -1) {
        printf("SOCKET ERROR = %d\n", sock_errno());
        exit(1);
    }

    /***************************************/
    /* Set up the UNIX sockaddr structure  */
    /* by using AF_UNIX for the family and */
    /* giving it a filepath to bind to.    */
    /*                                     */
    /* Unlink the file so the bind will    */
    /* succeed, then bind to that file.    */
    /***************************************/
    client_sockaddr.sun_family = AF_UNIX;   
    strcpy(client_sockaddr.sun_path, CLIENT_PATH); 
    len = sizeof(client_sockaddr);
    
    unlink(CLIENT_PATH);
    rc = bind(client_sock, (struct sockaddr *) &client_sockaddr, len);
    if (rc == -1){
        printf("BIND ERROR: %d\n", sock_errno());
        close(client_sock);
        exit(1);
    }
        
    /***************************************/
    /* Set up the UNIX sockaddr structure  */
    /* for the server socket and connect   */
    /* to it.                              */
    /***************************************/
    server_sockaddr.sun_family = AF_UNIX;
    strcpy(server_sockaddr.sun_path, SERVER_PATH);
    rc = connect(client_sock, (struct sockaddr *) &server_sockaddr, len);
    if(rc == -1){
        printf("CONNECT ERROR = %d\n", sock_errno());
        close(client_sock);
        exit(1);
    }
    
    /************************************/
    /* Copy the data to the buffer and  */
    /* send it to the server socket.    */
    /************************************/
    strcpy(buf, DATA);                 
    printf("Sending data...\n");
    rc = send(client_sock, buf, strlen(buf), 0);
    if (rc == -1) {
        printf("SEND ERROR = %d\n", sock_errno());
        close(client_sock);
        exit(1);
    }   
    else {
        printf("Data sent!\n");
    }

    /**************************************/
    /* Read the data sent from the server */
    /* and print it.                      */
    /**************************************/
    printf("Waiting to recieve data...\n");
    memset(buf, 0, sizeof(buf));
    rc = recv(client_sock, buf, sizeof(buf));
    if (rc == -1) {
        printf("RECV ERROR = %d\n", sock_errno());
        close(client_sock);
        exit(1);
    }   
    else {
        printf("DATA RECEIVED = %s\n", buf);
    }
    
    /******************************/
    /* Close the socket and exit. */
    /******************************/
    close(client_sock);
    
    return 0;
}
The following code example shows a client program for connectionless, datagram UNIX domain sockets. In the program, the socket function is called to create a socket in the UNIX domain, and then the bind function assigns a unique name for the socket. For connectionless sockets, you do not have to issue the connect function to connect to the server. 
/************************************************************/
/* This is a datagram socket client sample program for UNIX */
/* domain sockets. This program creates a socket and sends  */
/* data to a server.                                        */
/************************************************************/

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>

#define SERVER_PATH "tpf_unix_sock.server"
#define DATA "Hello from client\n"

int main(void)
{
    int client_socket, rc;
    struct sockaddr_un remote; 
    char buf[256];
    memset(&remote, 0, sizeof(struct sockaddr_un));
    
    /****************************************/
    /* Create a UNIX domain datagram socket */
    /****************************************/
    client_socket = socket(AF_UNIX, SOCK_DGRAM, 0);
    if (client_socket == -1) {
        printf("SOCKET ERROR = %d\n", sock_errno());
        exit(1);
    }

    /***************************************/
    /* Set up the UNIX sockaddr structure  */
    /* by using AF_UNIX for the family and */
    /* giving it a filepath to send to.    */
    /***************************************/
    remote.sun_family = AF_UNIX;        
    strcpy(remote.sun_path, SERVER_PATH); 
    
    /***************************************/
    /* Copy the data to be sent to the     */
    /* buffer and send it to the server.   */
    /***************************************/
    strcpy(buf, DATA);
    printf("Sending data...\n");
    rc = sendto(client_socket, buf, strlen(buf), 0, (struct sockaddr *) &remote, sizeof(remote));
    if (rc == -1) {
        printf("SENDTO ERROR = %d\n", sock_errno());
        close(client_sock);
        exit(1);
    }   
    else {
        printf("Data sent!\n");
    }
    
    /*****************************/
    /* Close the socket and exit */
    /*****************************/
    rc = close(client_sock);

    return 0;
}
 

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

From Wikipedia, the free encyclopedia
 
 
 
Jump to navigationJump to search

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 socket
  • SOCK_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
          ('\0').  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','\0'} 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\n", ((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.\n");
               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\n", 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.

 
Why do we need sockets? Well, because one process can’t normally talk to another process; this is true when the processes are on the same computer or on different computers. On a related note, there are two main domains of sockets: Unix domain sockets, which allow processes on the same computer to communicate (IPC), and Internet domain sockets, which allow processes to communicate over a network. If that’s confusing, just think of “Unix domain” and “Internet domain” as adjectives that describe the communication range of a socket.
 

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.

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).

  1. 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.

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.

  1. 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 using socket() is marked as active, and can be used in a connect() call to connect to a passive socket.

 

 

 Appendix A UNIX Domain Sockets (Network Interface Guide) https://docs.oracle.com/cd/E19455-01/806-1017/6jab5di3d/index.html

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

 

 

 

posted @ 2017-03-31 15:42  papering  阅读(629)  评论(0)  编辑  收藏  举报