Формат адреса¶

Адрес доменного сокета UNIX представляет собой следующую структуру:

#define UNIX_PATH_MAX    108
struct sockaddr_un {


    sa_family_t sun_family;               /* AF_UNIX */


    char        sun_path[UNIX_PATH_MAX];  /* имя пути */
};

sun_family всегда содержит AF_UNIX.

В этой структуре различают три типа адресов:

• с именем пути: доменный сокет UNIX может быть привязан к имени пути (с завершающимся null) в файловой системе с помощью bind(2). При возврате адреса сокета с помощью getsockname(2), getpeername(2) и accept(2), его длина равна offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1, а в sun_path содержится имя пути с завершающимся null.
• безымянный: Потоковый сокет, который не привязан к имени пути с помощью bind(2), не имеет имени. Аналогично, два сокета, создаваемые socketpair(2), также не имеют имён. При возврате адреса сокета с помощью getsockname(2), getpeername(2) и accept(2), его длина равна sizeof(sa_family_t), а значение sun_path не используется.
• абстрактный: абстрактный адрес сокета отличается тем, что значением sun_path[0] является байт null ('\0'). Адрес сокета в этом пространстве имён определяется дополнительными байтами в sun_path, количество которых определяется длиной указанной структуры адреса. Байты null в имени не имеют специального значения. Имя не связано с именем пути в файловой системе. При возврате адреса абстрактного сокета с помощью getsockname(2), getpeername(2) и accept(2), возвращаемое значение addrlen больше чем sizeof(sa_family_t) (т.е. больше 2), а имя сокета содержится в первых (addrlen - sizeof(sa_family_t)) байтах sun_path. Пространство имён абстрактных сокетов является непереносимым расширением Linux.

Параметры сокетов¶

В силу исторических причин эти параметры сокетов относятся к типу SOL_SOCKET, даже если они относятся к AF_UNIX. Они могут быть установлены с помощью setsockopt(2) и прочитаны с помощью getsockopt(2); тип SOL_SOCKET указывается в качестве семейства сокета.

SO_PASSCRED

Разрешает приём информационных данных (credentials) посылающего процесса во вспомогательном сообщении. Если при включении этого параметра сокет пока ещё не соединён, то в абстрактном пространстве имён будет автоматически создано уникальное имя. Ожидается целочисленный логический флаг.

Свойство автоматической привязки¶

Если в вызов bind(2) передано значение addrlen равное sizeof(sa_family_t), или для сокета, который не привязан к адресу явно, был указан параметр сокета SO_PASSCRED, то сокет автоматически привязывается к абстрактному адресу. Адрес состоит из байта null и 5 байтов символов из набора [0-9a-f]. Таким образом, максимальное количество автоматически привязываемых адресов равно 2^20 (в Linux 2.1.15, когда была добавлена автоматическая привязка, использовалось 8 байт, и, таким образом, ограничение было 2^32 адресов. В Linux 2.3.15 количество байт сократили до 5).

Программный интерфейс сокетов¶

В следующих параграфах описываются специфичные тонкости доменов и неподдерживаемые возможности программного интерфейса сокетов для доменных сокетов UNIX в Linux.

Доменные сокеты UNIX не поддерживают передачу внеполосных данных (флаг MSG_OOB у send(2) и recv(2)).

Флаг MSG_MORE у send(2) не поддерживается доменными сокетами UNIX.

Использование MSG_TRUNC в аргументе flags у recv(2) не поддерживается доменными сокетами UNIX.

Параметр сокета SO_SNDBUF учитывается в доменных сокетах UNIX, а параметр SO_RCVBUF — нет. Для датаграмных сокетов значение SO_SNDBUF считается максимальным размером для исходящих датаграмм. Это ограничение, вычисляемое как удвоенное значение (см. socket(7)) параметра, содержит меньше 32 байт накладных расходов.

Вспомогательные сообщения¶

Вспомогательные данные отправляются и принимаются с помощью sendmsg(2) и recvmsg(2). В силу исторических причин перечисленные типы вспомогательных сообщений относятся к типу SOL_SOCKET, даже если они относятся к AF_UNIX. Для того, чтобы отправить их, установите значение поля cmsg_level структуры cmsghdr равным SOL_SOCKET, а в значении поля cmsg_type укажите его тип. Дополнительная информация приведена в cmsg(3).

SCM_RIGHTS

Передать или принять набор открытых файловых дескрипторов из другого процесса. Часть с данными содержит целочисленный массив файловых дескрипторов. Переданные файловые дескрипторы действуют так, как если бы они были созданы dup(2).

SCM_CREDENTIALS

Передать или принять информацию о UNIX. Может быть использовано для аутентификации. Информация передаётся в виде структуры struct ucred вспомогательного сообщения. Эта структура определена в <sys/socket.h> следующим образом:

struct ucred {


    pid_t pid;    /* идентификатор посылающего процеса */


    uid_t uid;    /* идентификатор пользователя посылающего процесса */


    gid_t gid;    /* идентификатор группы посылающего процесса */
};

Начиная с glibc 2.8, чтобы получить определение данной структуры должен быть определён макрос тестирования свойств _GNU_SOURCE (до включения каких-либо заголовочных файлов).

Информация (credentials), указываемая отправителем, проверяется ядром. Процесс с идентификатором эффективного пользователя 0 может указывать значения, отличные от его собственных. Отправитель должен указать идентификатор своего процесса (если только он не имеет мандата CAP_SYS_ADMIN), свой идентификатор пользователя, эффективный идентификатор или сохранённый set-user-ID (если только он не имеет CAP_SETUID) и идентификатор своей группы, эффективный идентификатор группы или сохранённый set-group-ID (если только он не имеет CAP_SETGID). Для получения сообщения со структурой struct ucred для сокета нужно включить параметр SO_PASSCRED.

Вызовы ioctl¶

Следующие вызовы ioctl(2) возвращают информацию в аргументе value. Корректный синтаксис:

int value;
error = ioctl(unix_socket, ioctl_type, &value);

Значением ioctl_type может быть:

SIOCINQ

Возвращает количество непрочитанных данных в очереди в приёмном буфере. Сокет не должен быть в состоянии LISTEN, иначе возвращается ошибка (EINVAL). Значение SIOCINQ определено в <linux/sockios.h>. В качестве альтернативы вы можете использовать синоним FIONREAD, определённый в <sys/ioctl.h>.