LinuxDoc.Ruunix, PF_UNIX, AF_UNIX, PF_LOCAL, AF_LOCAL - сокеты для локальной связи процессов
НАЗВАНИЕunix, PF_UNIX, AF_UNIX, PF_LOCAL, AF_LOCAL - сокеты для
локальной связи процессов.
СИНТАКСИС
#include
#include unix_socket = socket(PF_UNIX, type,
0);
error = socketpair(PF_UNIX, type, 0, int *sv);
ОПИСАНИЕ
Семейство сокетов PF_UNIX (также известное, как PF_LOCAL)
используется для связи процессов в одной машине.
Unix-сокеты могут быть как безымянными (созданными socket-
pair(2)), так и связанными с файлом класса "сокет". Кроме
того, Linux поддерживает абстрактное пространство имен, не
зависимое от файловой системы.
Возможным типом сокетов, ориентированных на поток,
является SOCK_STREAM , а SOCK_DGRAM является типом
сокетов, ориентированных на датаграммы, сохраняющие
границы сообщений. Unix-сокеты всегда надежны и не путают
датаграммы.
Unix-сокеты поддерживают передачу файловых описателей и
информации о процессе другому процессу в виде
вспомогательных данных датаграмм.
ФОРМАТ АДРЕСА
Адрес Unix определен как имя файла в файловой системе или
уникальная строка в абстрактном пространстве имен. Сокеты,
созданные с помощью socketpair(2), являются безымянными.
Безымянным сокетам могут быть заданы адреса назначения с
помощью connect(2). Локальный адрес может быть задан с
помощью bind(2). Если сокет соединен и не имеет
локального адреса, то в абстрактном пространстве имен
автоматически будет создано уникальное имя.
struct sockaddr_un {
sa_family_t sun_family; /* AF_UNIX */
char sun_path[UNIX_PATH_MAX]; /* имя пути */
};
sun_family всегда содержит AF_UNIX. sun_path содержит
оканчивающееся нулем имя сокета в файловой системе. Если
sun_path начинается с нулевого байта, то оно ссылается на
абстрактное пространство имен, поддерживаемое модулем
протокола Unix. Адрес сокета в этом пространстве имен
задается оставшимися байтами sun_path. Обратите внимание,
что имена в абстрактном пространстве имен не оканчиваются
нулем.
ОПЦИИ СОКЕТОВ
В силу исторических причин эти опции сокета указывают на
тип SOL_SOCKET, даже если данные опции специфичны для
PF_UNIX. Они могут быть установлены с помощью setsock-
opt(2) и прочитаны с помощью getsockopt(2); тип SOL_SOCKET
указывается в качестве семейства сокета.
SO_PASSCRED разрешает прием информации о посылающем
процессе во вспомогательном сообщении. Если при включении
этой опции сокет не соединен, то в абстрактном
пространстве имен будет автоматически создано уникальное
имя. Ожидается целочисленный логический флаг.
ВСПОМОГАТЕЛЬНЫЕ СООБЩЕНИЯ
В силу исторических причин типом этих вспомогательных
собщений является SOL_SOCKET, даже если сообщения
специфичны для PF_UNIX. Для того, чтобы отправить их,
установите значение поля cmsg_level структуры cmsghdr
равным SOL_SOCKET, а значение поля cmsg_type равным его
типу. Дополнительная информация приведена в cmsg(3).
SCM_RIGHTS
Передать или принять набор описателей открытых
файлов другого процесса. Часть с данными содержит
целочисленный массив файловых описателей.
Переданные файловые описатели действуют так, как
если бы они были созданы dup(2).
SCM_CREDENTIALS
Передать или принять информацию о Unix. Может быть
использовано для аутентификации. Информация
передается в виде структуры struct ucred
вспомогательного сообщения.
struct ucred {
pid_t pid; /* идентификатор посылающего процеса */
uid_t uid; /* идентификатор пользователя посылающего процесса */
gid_t gid; /* идентификатор группы посылающего процесса */
};
Информация, указываемая отправителем, проверяется ядром.
Процесс с идентификатором эффективного пользователя,
равным нулю, может указывать на значения, отличные от его
собственных. Отправитель должен указать идентификатор
своего процесса (если только он не имеет CAP_SYS_ADMIN),
свой идентификатор пользователя (если только он не имеет
CAP_SETUID) и идентификатор своей группы (если только он
не имеет CAP_SETGID). Для получения сообщения структуры
struct ucred для сокета должна быть запущена опция
SO_PASSCRED.
ВЕРСИИ
SCM_CREDENTIALS и абстрактное пространство имен появились
в Linux 2.2 и не должны использоваться в переносимых в
другие системы программах.
ЗАМЕЧАНИЯ
В реализации Linux есть права доступа к каталогу, в
котором находятся сокеты. Владелец, группа и права,
присвоенные сокетам, могут быть изменены. Если процесс не
имеет прав на запись и поиск (запуск) в каталоге, то
создать новых сокет в нем не удастся. Соединение сокетных
объектов требует права на запись/чтение. Это действие
отличается от действий большинства клонов BSD,
игнорирующих права сокетов Unix. Переносимые программы не
должны зависеть от этой возможности из соображений
безопасности.
Подключение сокета к имени файла создает сокет в файловой
системе, который должен быть удален создателем, когда
необходимость в нем отпадет (с помощью unlink(2)).
Обычная система ссылок Unix также подходит для работы с
сокетами; сокет может быть удален в любое время, а
реальное удаление из файловой системы будет произведено
при снятии последней на него ссылки.
Для передачи файловых описателей или информации необходимо
передать/принять, по меньшей мере, один байт.
КОДЫ ОШИБОК
ENOMEM Hе хватает памяти.
ECONNREFUSED
Функция connect(2) вызвана для сокета, который не
является слушающим. Это может случится, если
удаленный сокет не существует или имя файла не
является сокетом.
EINVAL Передан неправильный аргумент. Основная причина -
отсутствие установленного AF_UNIX в поле sun_type
переданного адреса (или сокет находится в не совсем
подходящем для производимой операции состянии).
EOPNOTSUPP
Потоковая операция вызвана для сокета, не
ориентированного на потоки, или произведена попытка
использования опции внепоточных данных.
EPROTONOSUPPORT
Указанный протокол не является PF_UNIX.
ESOCKTNOSUPPORT
Hеизвестный тип сокета.
EPROTOTYPE
Удаленный сокет не совпадает с типом локального
сокета (SOCK_DGRAM против SOCK_STREAM).
EADDRINUSE
Выбранный локальный адрес уже присвоен, или
сокетный объект файловой системы уже существует.
EISCONN
Функция connect(2) вызвана для уже соединенного
сокета, или адрес назначения указывает на
соединенный сокет.
ENOTCONN
Сокетная операция требует адрес назначения, а сокет
не соединен.
ECONNRESET
Удаленный сокет был неожиданно закрыт.
EPIPE Удаленный сокет был закрыт в потоковом сокете. Если
разрешено, то будет послан сигнал SIGPIPE. Этого
можно избежать, передав флаг MSG_NOSIGNAL функции
sendmsg(2) или recvmsg(2).
EFAULT Указанный пользователем адрес неверен.
EPERM Отправитель указал неправильную информацию в
структуре struct ucred.
Остальные ошибки могут генерироваться уровнем сокетов или
файловой системой при создании сокетного объекта. За
дополнительной информацией обращайтесь к соответствующей
странице руководства.
ОСОБЫЕ БЛАГОДАРНОСТИ
Эта страница была написана Энди Клином (Andi Kleen).