NAME

socketpair — create a pair of connected sockets

SYNOPSIS

#include <sys/socket.h>

int socketpair(int domain, int type, int protocol,
       int socket_vector[2]);


DESCRIPTION

The socketpair() function shall create an unbound pair of connected sockets in a specified domain, of a specified type, under the protocol optionally specified by the protocol argument. The two sockets shall be identical. The file descriptors used in referencing the created sockets shall be returned in socket_vector[0] and socket_vector[1]. The file descriptors shall be allocated as described in 2.6 File Descriptor Allocation.

The socketpair() function takes the following arguments:

domain

Specifies the communications domain in which the sockets are to be created.

type

Specifies the type of sockets to be created.

protocol

Specifies a particular protocol to be used with the sockets. Specifying a protocol of 0 causes socketpair() to use an unspecified default protocol appropriate for the requested socket type.

socket_vector

Specifies a 2-integer array to hold the file descriptors of the created socket pair.

The type argument specifies the socket type, which determines the semantics of communications over the socket. The following socket types are defined; implementations may specify additional socket types:

SOCK_STREAM

Provides sequenced, reliable, bidirectional, connection-mode byte streams, and may provide a transmission mechanism for out-of-band data.

SOCK_DGRAM

Provides datagrams, which are connectionless-mode, unreliable messages of fixed maximum length.

SOCK_SEQPACKET

Provides sequenced, reliable, bidirectional, connection-mode transmission paths for records. A record can be sent using one or more output operations and received using one or more input operations, but a single operation never transfers part of more than one record. Record boundaries are visible to the receiver via the MSG_EOR flag.

Additionally, the type argument can contain the bitwise-inclusive OR of flags from the following list:

SOCK_CLOEXEC

Atomically set the FD_CLOEXEC flag on the new file descriptors.

SOCK_CLOFORK

Atomically set the FD_CLOFORK flag on the new file descriptors.

SOCK_NONBLOCK

Set the O_NONBLOCK file status flag on the new file descriptions.

Implementations may define additional flags.

If the protocol argument is non-zero, it shall specify a protocol that is supported by the address family. If the protocol argument is zero, the default protocol for this address family and type shall be used. The protocols supported by the system are implementation-defined.

The process may need to have appropriate privileges to use the socketpair() function or to create some sockets.

RETURN VALUE

Upon successful completion, this function shall return 0; otherwise, -1 shall be returned and errno set to indicate the error, no file descriptors shall be allocated, and the contents of socket_vector shall be left unmodified.

ERRORS

The socketpair() function shall fail if:

[EAFNOSUPPORT]

The implementation does not support the specified address family.

[EMFILE]

All, or all but one, of the file descriptors available to the process are currently open.

[ENFILE]

No more file descriptors are available for the system.

[EOPNOTSUPP]

The specified protocol does not permit creation of socket pairs.

[EPROTONOSUPPORT]

The protocol is not supported by the address family, or the protocol is not supported by the implementation.

[EPROTOTYPE]

The socket type is not supported by the protocol.

The socketpair() function may fail if:

[EACCES]

The process does not have appropriate privileges.

[ENOBUFS]

Insufficient resources were available in the system to perform the operation.

[ENOMEM]

Insufficient memory was available to fulfill the request.

EXAMPLES

None.

APPLICATION USAGE

The documentation for specific address families specifies which protocols each address family supports. The documentation for specific protocols specifies which socket types each protocol supports.

The socketpair() function is used primarily with UNIX domain sockets and need not be supported for other domains.

RATIONALE

The use of the SOCK_CLOEXEC and SOCK_CLOFORK flags in the type argument of socketpair() is necessary to avoid a data race in multi-threaded applications. Without SOCK_CLOFORK, a file descriptor is leaked into a child process created by one thread in the window between another using socketpair() and using using fcntl() to set the FD_CLOFORK flag. Without SOCK_CLOEXEC, a file descriptor intentionally inherited by child processes is similarly leaked into an executed program if FD_CLOEXEC is not set atomically.

Since socket pairs are often used for communication between a parent and child process, SOCK_CLOFORK has to be used with care in order for the pair to be usable. If the parent will be writing and the child will be reading, SOCK_CLOFORK should be used when creating the pair, and then fcntl() should be used to clear FD_CLOFORK for the read side of the pair. This prevents the write side from leaking into other children, ensuring the child will get end-of-file when the parent closes the write side (although the read side can still be leaked). If the parent will be reading and the child will be writing, or if the socket pair will be used bidirectionally, there is no way to prevent the write side(s) being leaked (short of preventing other threads from creating child processes) in order to ensure the parent gets end-of-file when the child closes its side, and so the two processes should use an alternative method of indicating the end of communications, for example using shutdown().

Arranging for FD_CLOEXEC to be set appropriately is more straightforward. The parent should use SOCK_CLOEXEC when creating the socket pair and the child should clear FD_CLOEXEC on the side to be passed to the new program before calling an exec family function to execute it.

The SOCK_NONBLOCK flag is for convenience in avoiding additional fcntl() calls.

FUTURE DIRECTIONS

None.

SEE ALSO

2.6 File Descriptor Allocation, socket

XBD <sys/socket.h>

CHANGE HISTORY

First released in Issue 6. Derived from the XNS, Issue 5.2 specification.

Issue 7

The description of the [EMFILE] error condition is aligned with the pipe() function.

POSIX.1-2008, Technical Corrigendum 2, XSH/TC2-2008/0336 [835] and XSH/TC2-2008/0337 [483,835] are applied.

Issue 8

Austin Group Defects 411 and 1318 are applied, adding SOCK_CLOEXEC, SOCK_CLOFORK, and SOCK_NONBLOCK.