unsigned char *CMSG_DATA(struct cmsghdr *<i>cmsgptr</i>);

<i>Возвращает: указатель на первый байт данных, связанных со структурой cmsghdr</i>

unsigned int CMSG_LEN(unsigned int <i>length</i>);

<i>Возвращает: значение, которое записывается в cmsg_len</i>

unsigned int CMSG_SPACE(unsigned int <i>length</i>);

<i>Возвращает: общий размер объекта вспомогательных данных</i>

В POSIX определены первые пять макросов, а в [113] определены последние два.

Эти макросы могли бы быть использованы в следующем псевдокоде:

struct msghdr msg;

struct cmsghdr *cmsgptr;

/* заполнение структуры msg */

/* вызов recvmsg() */

for (cmsgptr = CMSG_FIRSTHDR(&amp;msg); cmsgptr != NULL;

 cmsgptr = CMSG_NXTHDR(&amp;msg, cmsgptr)) {

 if (cmsgptr-&gt;cmsg_level == ... &amp;&amp;

  cmsgptr-&gt;cmsg_type == ...) {

  u_char *ptr;

  ptr = CMSG_DATA(cmsgptr);

  /* обработка данных, на которые указывает ptr */

 }

}

Макрос CMSG_FIRSTHDR возвращает указатель на первый объект вспомогательных данных или пустой указатель, если в структуре msghdr нет вспомогательных данных (или msg_control является пустым указателем, или cmsg_len меньше размера структуры cmsghdr). Макрос CMSG_NXTHDR возвращает пустой указатель, когда в буфере управления нет другого объекта вспомогательных данных.

Многие существующие реализации макроса CMSG_FIRSTHRD никогда не используют элемент msg_controllen и просто возвращают значение cmsg_control. В листинге 22.2 мы проверяем значение msg_controllen перед вызовом макроопределения.

Разница между макросами CMSG_LEN и CMSG_SPACE заключается в том, что первый возвращает длину объекта вместе с дополняющими нулями (это значение хранится в cmsg_len), а последний возвращает длину собственно объекта (это значение может использоваться для динамического выделения памяти под объект).

14.7. Сколько данных находится в очереди?

Иногда требуется узнать, сколько данных находится в очереди для чтения данного сокета, не считывая эти данные. Для этого имеется три способа.

1. Если нашей целью не является блокирование в ядре (поскольку мы можем выполнять другие задачи, пока данные для чтения еще не готовы), может использоваться неблокируемый ввод-вывод. Мы обсуждаем его в главе 16.

2. Если мы хотим проверить данные, но при этом оставить их в приемном буфере для считывания какой-либо другой частью процесса, мы можем использовать флаг MSG_PEEK (см. табл. 14.1). Если мы не уверены, что какие-либо данные готовы для чтения, мы можем объединить этот флаг с отключением блокировки для сокета или с флагом MSG_DONTWAIT.

Помните о том, что для потокового сокета количество данных в приемном буфере может изменяться между двумя последовательными вызовами функции recv . Например, предположим, что мы вызываем recv для сокета TCP, задавая буфер длиной 1024 и флаг MSG_PEEK, и возвращаемое значение равно 100. Если затем мы снова вызовем функцию recv, возможно, возвратится более 100 байт (мы задаем длину буфера больше 100), поскольку в промежутке между двумя нашими вызовами recv могли быть получены дополнительные данные.

А что произойдет в случае сокета UDP, когда в приемном буфере имеется дейтаграмма? При вызове recvfrom с флагом MSG_PEEK, за которым последует другой вызов без задания MSG_PEEK, возвращаемые значения обоих вызовов (размер дейтаграммы, ее содержимое и адрес отправителя) будут совпадать, даже если в приемный буфер сокета между двумя вызовами добавляются дополнительные дейтаграммы. (Мы считаем, конечно, что никакой другой процесс не использует тот же дескриптор и не осуществляет чтение из данного сокета в это же время.)

3. Некоторые реализации поддерживают команду FIONREAD функции ioctl. Третий аргумент функции ioctl — это указатель на целое число, а возвращаемое в этом целом числе значение — это текущее число байтов в приемном буфере сокета [128, с. 553]. Это значение является общим числом установленных в очередь байтов, которое для сокета UDP включает все дейтаграммы, установленные в очередь. Также помните о том, что значение, возвращаемое для сокета UDP, в Беркли-реализациях включает пространство, требуемое для структуры адреса сокета, содержащей IP-адрес отправителя и порт для каждой дейтаграммы (16 байт для IP4, 24 байта для IP6).

14.8. Сокеты и стандартный ввод-вывод

Во всех наших примерах мы применяли то, что иногда называется вводом-выводом Unix, вызывали функции read и write и их разновидности (recv, send и т.д.). Эти функции работают с дескрипторами и обычно реализуются как системные вызовы внутри ядра Unix.

Другой метод выполнения ввода-вывода заключается в использовании стандартной библиотеки ввода-вывода. Она задается стандартом ANSI С и была задумана как библиотека, совместимая с не-Unix системами, поддерживающими ANSI С. Стандартная библиотека ввода-вывода обрабатывает некоторые моменты, о которых мы должны заботиться сами при использовании функций ввода- вывода Unix, таких как автоматическая буферизация потоков ввода и вывода. К сожалению, ее обработка буферизации потока может представить новый ряд проблем, о которых следует помнить. Глава 5 [110] подробно описывает стандартную библиотеку ввода-вывода, а в [92] представлена полная реализация стандартной библиотеки ввода-вывода и ее обсуждение.

При обсуждении стандартной библиотеки ввода-вывода используется термин «поток» в выражениях типа «мы открываем поток ввода» или «мы очищаем поток вывода». Не путайте это с подсистемой потоков STREAMS, которую мы обсуждаем в главе 31.