Книга: UNIX: разработка сетевых приложений
14.5. Функции recvmsg и sendmsg
14.5. Функции recvmsg и sendmsg
Эти две функции являются наиболее общими для всех операций ввода-вывода. Действительно, мы можем заменить все вызовы функций ввода read
, readv
, recv
и recvfrom
вызовами функции recvmsg
. Аналогично, все вызовы различных функций вывода можно заменить вызовами функции sendmsg
.
#include <sys/socket.h>
ssize_t recvmsg(int sockfd, struct msghdr *msg, int flags);
ssize_t sendmsg(int sockfd, struct msghdr *msg, int flags);
Обе функции возвращают: количество прочитанных или записанных байтов в случае успешного выполнения, -1 в случае ошибки
Большинство аргументов обеих функций скрыто в структуре msghdr
:
struct msghdr {
void *msg_name; /* адрес протокола */
socklen_t msg_namelen; /* размер адреса протокола */
struct iovec *msg_iov; /* массив буферов */
size_t msg_iovlen; /* количество элементов в массиве msg_iov */
void *msg_control; /* вспомогательные данные: должны быть
выровнены для структуры cmsghdr */
socklen_t msg_controllen; /* размер вспомогательных данных */
int msg_flags; /* флаги, возвращенные функцией recvmsg() */
};
ПРИМЕЧАНИЕ
Показанная нами структура msghdr восходит к 4.3BSD Reno и определяется POSIX. Некоторые системы (например, Solaris 2.5) используют более раннюю структуру msghdr, которая появилась в 4.2BSD. У более ранней структуры нет элемента msg_flags, а элементы msg_control и msg_controllen называются msg_accrights и msg_accrightslen. В этой системе поддерживается только одна форма вспомогательных данных — передача дескрипторов файлов (так называемые права доступа). При появлении протоколов OSI в 4.3BSD Reno были добавлены новые формы вспомогательных данных, вследствие чего были обобщены имена элементов структуры.
Элементы msg_name
и msg_namelen
используются, когда сокет не является присоединенным (например, неприсоединенный сокет UDP). Они аналогичны пятому и шестому аргументам функций recvfrom
и sendto
: msg_name
указывает на структуру адреса сокета, в которой вызывающий процесс хранит адрес протокола получателя для функции sendmsg
или функция recvmsg
хранит адрес протокола отправителя. Если нет необходимости задавать адрес протокола (например, сокет TCP или присоединенный сокет UDP), элемент msg
_name должен быть пустым указателем. Элемент msg_namelen
является аргументом типа «значение» для функции sendmsg
, но для функции recvmsg
это аргумент типа «значение-результат».
Элементы msg_iov
и msg_iovlen
задают массив буферов ввода и вывода (массив структур iovec
), аналогичный второму и третьему аргументам функций readv
и writev
.
Элементы msg_control
и msg_controllen
задают расположение и размер необязательных вспомогательных данных. Элемент msg_controllen
— это аргумент типа «значение-результат» функции recvmsg
. Вспомогательные данные мы рассматриваем в разделе 14.6.
Работая с функциями recvmsg
и sendmsg
, следует учитывать различие между двумя флаговыми переменными: это аргумент flags
, который передается по значению, и элемент msg_flags
структуры msghdr
, который передается по ссылке (поскольку функции передается адрес этой структуры).
? Элемент msg_flags
используется только функцией recvmsg
. Когда вызывается функция recvmsg
, аргумент flags
копируется в элемент msg_flags
[128, с. 502], и это значение используется ядром для управления приемом данных. Затем это значение обновляется в зависимости от результата функции recvmsg
.
? Элемент msg_flags
игнорируется функцией sendmsg
, поскольку эта функция использует аргумент flags
для управления выводом данных. Это значит, что если мы хотим установить флаг MSG_DONTWAIT
при вызове функции sendmsg
, то мы должны присвоить это значение аргументу flags
, а присваивание значения MSG_DONTWAIT
элементу msg_flags
не имеет никакого эффекта.
В табл. 14.2 показано, какие флаги проверяются ядром для функций ввода и вывода и какие элементы msg_flags
может возвращать функция recvmsg
. Для элемента sendmsg.msg_flags
нет колонки, потому что, как мы отмечали, он не используется.
Таблица 14.2. Флаги для различных функций ввода-вывода
Флаг | Проверяются функциями send flags sendto flags sendmsg flags | Проверяются функциями recv flags recvfrom flags recvmsg flags | Возвращаются функцией recvmsg msg_flags |
---|---|---|---|
MSG_DONTROUTE | • | ||
MSG_DONTWAIT | • | • | |
MSG_PEEK | • | ||
MSG_WAITALL | • | ||
MSG_EOR | • | ||
MSG_OOB | • | • | • |
MSG_BCAST | • | ||
MSG_MCAST | • | ||
MSG_TRUNC | • | ||
MSG_CTRUNC | • |
Первые четыре флага только проверяются и никогда не возвращаются, вторые два проверяются и возвращаются, а последние четыре флага только возвращаются. Следующие ниже комментарии относятся к шести флагам, возвращаемым функцией recvmsg
.
? MSG_BCAST
. Этот флаг введен в BSD/OS и возвращается, если дейтаграмма была получена как широковещательная дейтаграмма канального уровня или если ее IP-адрес получателя является широковещательным адресом. Этот флаг предоставляет более удачную возможность определить, что дейтаграмма UDP была отправлена на широковещательный адрес, чем параметр сокета IP_RECVDSTADDR
.
? MSG_MCAST
. Этот флаг введен в BSD_OS и возвращается, если дейтаграмма была получена как дейтаграмма многоадресной передачи канального уровня.
? MSG_TRUNC
. Этот флаг возвращается, если дейтаграмма была усечена: у ядра имеется больше данных для возвращения, чем позволяет пространство в памяти, выделенное для них процессом (сумма всех элементов iov_len
). Более подробно мы рассмотрим это в разделе 22.3.
? MSG_CTRUNC
. Этот флаг возвращается, если были усечены вспомогательные данные: у ядра имеется больше вспомогательных данных для возвращения, чем позволяет выделенное для них процессом пространство в памяти (msg_controllen
).
? MSG_EOR
. Этот флаг означает конец записи. Он сбрасывается, если возвращаемые данные не заканчивают запись. Если же возвращаемые данные заканчивают логическую запись, этот флаг устанавливается. TCP не использует этот флаг, поскольку это потоковый протокол.
? MSG_OOB
. Этот флаг никогда не возвращается для внеполосных данных TCP. Он возвращается другими наборами протоколов (например, протоколами OSI).
Реализации могут возвращать некоторые из входных аргументов flags
в элементе msg_flags
, поэтому мы должны проверять только те значения флагов, которые нас интересуют (например, последние шесть в табл. 14.2).
На рис. 14.1 представлена структура msghdr
и информация, на которую она указывает. На этом рисунке отражена ситуация, предшествующая вызову функции recvmsg
для сокета UDP.
Рис. 14.1. Структуры данных в тот момент, когда функция recvmsg вызывается для сокета UDP
Для адреса протокола в памяти выделяется 16 байт, а для вспомогательных данных — 20 байт. Инициализируется массив из трех структур iovec: первая задает 100-байтовый буфер, вторая — 60-байтовый буфер, третья — 80-байтовый буфер. Мы также предполагаем, что был установлен параметр сокета IP_RECVDSTADDR
для получения IP-адреса получателя из дейтаграммы UDP.
Затем будем считать, что с адреса 198.6.38.100, порт 2000, приходит 170-байтовая дейтаграмма UDP, предназначенная для нашего сокета UDP с IP-адресом получателя 206.168.112.96. На рис. 14.2 показана вся информация, содержащаяся в структуре msghdr
в момент завершения функции recvmsg
.
Рис. 14.2. Изменение рис. 14.1 при завершении функции
Затемненными показаны поля, изменяемые функцией recvmsg
. По сравнению с рис. 14.1 на рис. 14.2 изменяется следующее:
? В буфер, на который указывает элемент msg_name
, записывается структура адреса сокета Интернета, содержащая IP-адрес и UDP-порт отправителя, определенные по полученной дейтаграмме.
? Обновляется аргумент msg_namelen
, имеющий тип «значение-результат». Его новым значением становится количество данных, хранящихся в msg_name
. Но на самом деле его значение как перед вызовом функции recvmsg
, так и при ее завершении равно 16.
? Первые 100 байт данных записываются в первый буфер, следующие 60 байт — во второй буфер и последние 10 байт — в третий буфер. Последние 70 байт третьего буфера не изменяются. Возвращаемое значение функции recvmsg
— это размер дейтаграммы (170).
? Буфер, на который указывает msg_control
, заполняется как структура cmsghdr
. (Более подробно о вспомогательных данных мы поговорим в разделе 14.6, а об этом параметре сокета — в разделе 22.2.) Значение cmsg_len
равно 16, cmsg_level
— IPPROTO_IP
, cmsg_type
— IP_RECVDSTADDR
, а следующие 4 байта 20-байтового буфера содержат IP-адрес получателя из полученной дейтаграммы UDP. Последние 4 байта 20-байтового буфера, которые мы предоставили для хранения вспомогательных данных, не изменяются.
? Обновляется элемент msg_controllen
— его новым значением становится фактический размер записанных вспомогательных данных. Этот аргумент также является аргументом типа «значение-результат», и его результат по завершении функции равен 16.
? Элемент msg_flags
изменяется функцией recvmsg
, но процессу никакие флаги не возвращаются.
В табл. 14.3 показаны различия между рассмотренными пятью группами функций ввода-вывода.
Таблица 14.3. Сравнение пяти групп функций ввода-вывода
Функция | Произвольный дескриптор | Только дескриптор сокета | Один буфер для чтения и записи | Распределяющее чтение, объединяющая запись | Наличие флагов | Указание адреса собеседника | Управляющая информация |
---|---|---|---|---|---|---|---|
read, write | • | • | |||||
readv, writev | • | • | |||||
recv, send | • | • | • | ||||
recvfrom, sendto | • | • | • | • | |||
recvmsg, sendsg | • | • | • | • | • |
- 14.3. Функции recv и send
- Глава 14 Дополнительные функции ввода-вывода
- Аргументы функции в Python
- 3. Функции
- Новые функции API для работы с Blob и массивами
- Математические функции
- Размытые функции
- 7.3. Финансовые функции
- 4.3. Логические функции и таблицы истинности
- B1.7. Функции обработки ошибок
- 9.1.4.2. Функции-оболочки: execl() и др.
- 11.5. Функции getservbyname и getservbyport