2) назначение сокету адреса привязки (функция bind);
3) перевод сокета в режим ожидания запросов (функция listen);
4) прием поступающих запросов (функция accept);
5) закрытие сокета (функция close).
Данные не записываются и не читаются напрямую через серверный сокет. Вместо этого всякий раз, когда сервер принимает запрос на соединение, ОС Linux создает отдельный сокет, используемый для передачи данных через это соединение.
Серверному сокету необходимо с помощью функции
bind
назначить адрес, чтобы клиент смог его найти. Первым аргументом функции является дескриптор сокета. Второй аргумент — это указатель на адресную структуру, формат которой будет зависеть от выбранного семейства адресов. Третий аргумент — это длина адресной структуры в байтах. После получения адреса сокет, ориентированный на соединения, должен вызвать функцию
listen
, тем самым обозначив себя как сервер. Первым аргументом этой функции также является дескриптор сокета. Второй аргумент определяет, сколько запросов может находиться в очереди ожидания. Если очередь заполнена, все последующие запросы отвергаются. Этот аргумент задает не предельное число запросов, которое способен обработать сервер. а максимальное количество клиентов, которые могут находиться в режиме ожидания.
Сервер принимает от клиента запрос на подключение, вызывая функцию
accept
. Первый ее аргумент — это дескриптор сокета. Второй аргумент указывает на адресную структуру, заполняемую адресом клиентского сокета. Третий аргумент содержит длину (в байтах) адресной структуры. Функция
accept
создает новый сокет для обслуживания клиентского соединения и возвращает его дескриптор. Исходный серверный сокет продолжает принимать запросы от клиентов. Чтобы прочитать данные из сокета, не удалив их из входящей очереди, воспользуйтесь функцией
recv
. Она принимает те же аргументы, что и функция read, плюс дополнительный аргумент
FLAGS
. Флаг
MSG_PEEK
задает режим "неразрушающего" чтения, при котором прочитанные данные остаются в очереди.
5.5.4. Локальные сокеты
Сокеты, соединяющие процессы в пределах одного компьютера, работают в локальном пространстве имен (
PF_LOCAL
или
PF_UNIX
, это синонимы). Такие сокеты называются локальными или UNIX-сокетами. Их адресами являются имена файлов, указываемые только при создании соединения.
Имя сокета задается в структуре типа
sockaddr_un
. В поле
sun_family
необходимо записать константу
AF_LOCAL
, указывающую на то, что адрес находится в локальном пространстве имен. Поле
sun_path
содержит путевое имя файла и не может превышать 108 байтов. Длина структуры
sockaddr_un
вычисляется с помощью макроса
SUN_LEN
. Допускается любое имя файла, но процесс должен иметь право записи в каталог, где находится файл. При подключении к сокету процесс должен иметь право чтения файла. Несмотря на то что файловая система может экспортироваться через NFS на разные компьютеры, только процессам, работающим в пределах одного компьютера, разрешается взаимодействовать друг с другом посредством локальных сокетов.
При работе в локальном пространстве имен допускается только протокол с номером 0.
Локальный сокет является частью файловой системы, поэтому он отображается командой
ls
(обратите внимание на букву
s
в строке режима):
% ls -l /tmp/socket
srwxrwx--x 1 user group 0 Nov 13 19:16 /tmp/socket
Если локальный сокет больше не нужен, его файл можно удалить с помощью функции
unlink
.
5.5.5. Примеры программ, работающих с локальными сокетами
Работу с локальными сокетами мы проиллюстрируем двумя программами. Первая (листинг 5.10) — это сервер. Он создает локальный сокет и переходит в режим ожидания запросов на подключение. Приняв запрос, сервер читает сообщения из сокета и отображает на на экране, пока соединение не будет закрыто. Если поступает сообщение "quit", сервер удаляет сокет и завершает свою работу. Программа