UNIX: разработка сетевых приложений - Уильям Стивенс

Таблица 31.1. Типы потоковых сообщений, генерируемые функциями write и putmsg

Функция Управляющая информация? Данные? Флаги Генерируемый тип сообщения write Да M_DATA putmsg Нет Да 0 M_DATA putmsg Да Все равно 0 M_PROTO putmsg Да Все равно MSG_HIPRI M_PCPROTO

31.3. Функции getmsg и putmsg

Данные, передаваемые в обоих направлениях по потоку, состоят из сообщений, а каждое сообщение содержит данные, управляющую информацию или и то и другое. Если мы используем функции read или write, то мы можем передавать только данные. Для того чтобы процесс мог записывать и считывать как данные, так и управляющую информацию, необходимо добавить две новые функции.

#include <stropts.h>

int getmsg(int fd, struct strbuf *ctlptr, struct strbuf *dataptr, int *flagsp);

int putmsg(int fd, const struct strbuf *ctlptr,

 const struct strbuf *dataptr, int flags);

Обе функции возвращают: неотрицательное значение в случае успешного выполнения (см. пояснения в тексте), -1 в случае ошибки

Обе составляющие сообщения — и сами данные, и управляющая информация — описываются структурой strbuf:

struct strbuf {

 int  maxlen; /* максимальный размер буфера buf */

 int  len;    /* фактическое количество данных в buf */

 char *buf;   /* данные */

};

ПРИМЕЧАНИЕ

Обратите внимание на аналогию между структурами strbuf и netbuf. Имена элементов обеих структур одинаковы.

Однако обе длины в структуре netbuf относятся к типу данных unsigned int (целое без знака), тогда как обе длины в структуре srtbuf — к типу int (целое со знаком). Причина в том, что некоторые потоковые функции используют значение -1 элементов len и maxlen для указания на определенные специальные ситуации.

С помощью функции putmsg мы можем отправлять или данные, или управляющую информацию, или и то и другое вместе. Для указания на отсутствие управляющей информации мы можем или задать ctlptr как пустой указатель, или установить значение ctlptr->len равным -1. Этот же способ используется для указания на отсутствие данных.

При отсутствии управляющей информации функцией putmsg генерируется сообщение типа M_DATA (см. табл. 31.1), в противном случае генерируется сообщение типа M_PROTO либо M_PCPROTO в зависимости от значения аргумента flags. Этот аргумент функции putmsg имеет нулевое значение для обычных сообщений, а для сообщений с высоким приоритетом его значение равно RS_HIPRI.

Последний аргумент функции getmsg имеет тип «значение-результат». Если при вызове функции целочисленное значение, на которое указывает аргумент flagsp, — это 0, то возвращается первое сообщение из потока (которое может быть как обычным, так и имеющим высокий приоритет). Если при вызове функции целочисленное значение соответствует RS_HIPRI, то функция будет ждать появления в головном модуле потока сообщения с высоким приоритетом. В обоих случаях в зависимости от типа возвращенного сообщения значение, на которое указывает аргумент flagsp, будет либо 0, либо RS_HIPRI.

Предположим, что мы передаем функции getmsg непустые указатели ctlptr и dataptr. Тогда указанием на отсутствие управляющей информации (возвращается сообщение типа M_DATA) является значение ctlptr->len, установленное в -1. Аналогично, если отсутствуют данные, указанием на это является значение -1 элемента dataptr->len.

Если функция putmsg выполнилась успешно, то она возвращает нулевое значение, а в случае ошибки возвращается значение -1. Но функция getmsg возвращает нулевое значение только в том случае, если вызывающему процессу было доставлено все сообщение целиком. Если буфер, предназначенный для приема управляющей информации, слишком мал, то возвращается значение MORECTL (о котором заранее известно, что оно является неотрицательным). Аналогично, если буфер для приема данных оказывается слишком мал, возвращается значение MOREDATA. Если же оба эти буфера оказываются слишком малы, то возвращается логическая сумма этих двух флагов.

31.4. Функции getpmsg и putpmsg

Когда с выпуском SVR4 к потоковым системам была добавлена поддержка различных полос приоритета, появились новые варианты функций getmsg и putmsg.

#include <stropts.h>

int getpmsg(int fd, struct strbuf *ctlptr,

 struct strbuf *dataptr, int *bandp, int *flagsp);

int putpmsg(int fd, const struct strbuf *ctlptr,

 const struct strbuf *dataptr, int band, int flags);

Обе функции возвращают: неотрицательное значение в случае успешного выполнения, -1 в случае ошибки

Аргумент band функции putpmsg должен иметь значение в пределах от 0 до 255 включительно. Если аргумент flags имеет значение MSG_BAND, то генерируется сообщение в соответствующей полосе приоритета. Присваивание аргументу flags значения MSG_BAND и задание полосы 0 эквивалентно вызову функции putmsg. Если значение аргумента flags равно MSG_HIPRI, то аргумент band должен быть равен нулю, и тогда генерируется сообщение с высоким приоритетом. (Обратите внимание на то, что этот флаг имеет название, отличающееся от названия RS_HIPRI, используемого в случае функции putmsg.)

Два целочисленных значения, на которые указывают аргументы bandp и flagsp функции getpmsg, являются аргументами типа «значение-результат». Целочисленное значение, на которое указывает аргумент flagsp функции getpmsg, может соответствовать MSG_HIPRI (для чтения сообщений с высоким приоритетом), MSG_BAND (для чтения сообщений из полосы приоритета, по меньшей мере равной целочисленному значению, на которое указывает аргумент bandp) или MSG_ANY (для чтения любых сообщений). По завершении функции целочисленное значение, на которое указывает аргумент bandp, указывает на полосу приоритета прочитанного сообщения, а целое число, на которое указывает аргумент flagsp, соответствует MSG_HIPRI (если было прочитано сообщение с высоким приоритетом) или MSG_BAND (если было прочитано иное сообщение).

31.5. Функция ioctl

Говоря о потоках, мы снова возвращаемся к функции ioctl, которая уже была описана в главе 17.

#include <stropts.h>

int ioctl(int fd, int request, ... /* void *arg */ );

Возвращает: 0 в случае успешного выполнения, -1 в случае ошибки

Единственным изменением относительно прототипа функции, приведенного в разделе 17.2, является включение заголовочного файла, необходимого для работы с потоками.

Существует примерно 30 запросов (request), так или иначе влияющих на головной модуль потока. Каждый из запросов начинается с I_, и обычно документация на них приводится на странице руководства streamio.

31.6. TPI: интерфейс поставщика транспортных служб

На рис. 31.3 мы показали, что TPI — это интерфейс, предоставляющий доступ к транспортному уровню для расположенных выше уровней. Этот интерфейс используется в потоковой среде как сокетами, так и XTI. Из рис. 31.3 видно, что комбинация библиотеки сокетов и sokmod, а также комбинация библиотеки XTI и timod обмениваются сообщениями TPI с TCP и UDP.

TPI является интерфейсом, основанным на сообщениях (message-based). Он определяет сообщения, которыми обменивается приложение (например, XTI или библиотека сокетов) и транспортный уровень. Точнее, TPI задает формат этих сообщений и то, какое действие производит каждое из сообщений. Во многих случаях приложение посылает запрос поставщику (например, «Связать данный локальный адрес»), а поставщик посылает обратно ответ («Выполнено» или «Ошибка»). Некоторые события, происходящие асинхронно на стороне поставщика (например, прибытие запроса на соединение с сервером), инициируют отправку сигнала или сообщения вверх по потоку.