Книга: Операционная система UNIX

Взаимодействие с прикладными процессами

Взаимодействие с прикладными процессами

Рассмотренный ранее программный интерфейс TLI полностью реализует функциональность TPI. Легко заметить соответствие между отдельными функциями TLI и примитивами TPI, приведенными в табл. 6.10. Схема вызова функций TPI и обмена соответствующими примитивами TPI между клиентом и сервером для типичного TCP-сеанса приведена на рис. 6.32.

Рис. 6.32. Функции TLI и примитивы TPI

Программный интерфейс потоков был рассмотрен в главе 5 при обсуждении подсистемы STREAMS. Основными функциями, обеспечивающими передачу и получение сообщений, являются системные вызовы putmsg(2) и getmsg(2). Таким образом, большинство функций TLI, составляющих программный интерфейс доступа прикладных процессов к транспортным протоколам, являются удобной оболочкой (реализованной в виде библиотеки, например, libnsl.so) более фундаментальным системным вызовам putmsg(2) и getmsg(2).

В качестве примера рассмотрим функцию t_connect(3N). Ее реализация может иметь следующий вид:

int t_connect(int fd, struct t_call *sndcall,
struct t_call *recvcall) {
 struct T_conn_req *connreq;
 struct T_conn_con* conncon;
 struct T_ok_ack *okack;
 struct T_error_ack *errack;
 struct strbuf connect, ack, confirm, m_data;
 struct netbuf addr, opt, udata;
 char *buf;
 int flags;
 ...
 /* Сохраним адреса буферов netbuf запроса sndcall */
 addr = sndcall->addr; opt = sndcall->opt;
 udata = sndcall->udata;
 /* Заполним поля структуры strbuf для формирования
    управляющей части (блок M_PROTO) сообщения T_CONN_REQ */
 connect.len =
  sizeof(struct T_conn_req) + addr.len + opt.len;
 connect.maxlen =
  sizeof(struct Т_conn_req) + addr.maxlen + opt.maxlen;
 buf = (char*)malloc(connect.maxlen);
 connect.buf = buf;
 /* Заполним поля заголовка блока M_PROTO сообщения T_CONN_REQ в
    соответствии с форматом структуры T_conn_req */
 connreq = (struct T_conn_req*)buf;
 connreq->PRIM_type = T_CONN_REQ;
 connreq->DEST_length = addr.len;
 connreq->DEST_offset = sizeof (struct T_conn_req);
 buf += sizeof(struct T_conn_req);
 memcpy(buf, addr.buf, addr.len);
 connreq->OPT_length = opt.len;
 connreq->OPT_offset = connreq->DEST_offset + opt.len;
 buf += addr.len;
 memcpy(buf, opt.buf, opt.len);
 /* Заполним поля структуры strbuf для формирования блока данных
    (блок M_DATA) */
 m_data.len = udata.len;
 m_data.maxlen = udata.maxlen;
 m_data.buf = udata.buf;
 /* Отправим запрос Т_CONN_REQ поставщику транспортных услуг
    по потоку fd */
 putmsg(fd, &connect, &m_data, 0);
 /* Подготовимся к приему подтверждения. Выделим максимальный
    размер для получения негативного подтверждения, поскольку
    примитив T_ERROR_ACK занимает больше места */
 ack.len = ack.maxlen = sizeof(struct T_error_ack);
 ack.buf = udata.buf;
 /* Подтверждение является приоритетным, поэтому установим флаг
    RS_HIPRI. До получения подтверждения не предпринимаем
    никаких действий */
 flags = RS_HIPRI;
 getmsg(fd, &ack, (struct strbuf*)0, &flags);
 free(connect.buf);
 okack = (struct T_ok_ack*)ack.buf;
 /* Проверим получено ли положительное или
    негативное подтверждение */
 if (okack->PRIM_type == T_OK_ACK) {
  /* Если подтверждение положительное, подготовимся к получению
     согласия удаленного пользователя на установление связи
     (примитив T_CONN_CON) */
  free(ack.buf);
  if (recvcall != NULL) {
   addr = recvcall->addr;
   opt = recvcall->opt;
   udata = recvcall->udata;
   confirm.len = sizeof(struct T_conn_con) + addr.len + opt.len;
   confirm.maxlen =
    sizeof(struct T_conn_con) + addr.maxlen + opt.maxlen;
   buf = (char*)malloc(confirm.maxlen);
   confirm.buf = buf;
   m_data.len = udata.len;
   m_data.maxlen = udata.maxlen;
   m_data.buf = udata.buf;
   /* Получим примитив T_CONN_CON */
   getmsg(fd, &confirm, &m_data, &flags);
   free(buf);
   conncon = (struct T_conn_con*)confirm.buf;
   if (conncon->PRIM_type == T_CONN_CON) {
    /* Если это действительно согласие, заполним
       структуру rcvcall для пользователя TLI */
    addr.len = conncon->OPT_length;
    opt.len = conncon->OPT_length;
    memcpy(addr.buf, conncon+conncon->RES_offset, addr.len);
    memcpy(opt.buf, conncon+conncon->OPT_offset, opt.len);
    free(confirm.buf);
    /* Все закончилось удачно — возвращаем 0 */
    return 0;
   }
  } else {
   /* В случае отказа мы готовы обработать примитив
      T_DISCON_IND */
   ...
   return -1;
  }
 } else {
  /* Если получен примитив T_ERROR_ACK — обработаем его */
  errack = (struct T_error_ack*)ack.buf;
  ...
  return -1;
 }
}

Подобным образом реализовано большинство функций TLI. Заметим, что в конкретном случае использования транспортного протокола TCP прием и передача данных осуществляются в виде потока, не содержащего каких-либо логических записей. В этом случае не требуется формирование примитивов типа T_DATA_REQ и T_DATA_IND. В то же время, для передачи и получения экстренных данных будут использованы примитивы T_EXDATA_REQ и T_EXDATA_IND. При использовании протокола UDP все данные будут передаваться с помощью примитивов T_UNITDATA_REQ и T_UNITDATA_IND.

Описанная реализация программного интерфейса TLI имеет один существенный недостаток — операции функций не являются атомарными. Другими словами, выполнение функции t_connect(3N) может быть прервано другими процессами, которые могут также связываться с удаленным узлом. Это возможно, поскольку выполнение значительной части операций происходит в режиме задачи. Если для функции t_connect(3N) нарушение атомарности допустимо, то ряд функций, таких, например, как связывание (t_bind(3N)), получение информации (t_open(3N), t_getinfo(3N)) и установка или получение опций протокола (t_optmgmt(3N)) должны быть защищены от возможного нарушения целостности данных по причине прерывания операции. Единственным способом гарантировать атомарность является перевод выполнения критических участков (например, между отправлением примитива и получением подтверждения от поставщика транспортных услуг) в режим ядра. Для этого подсистема STREAMS предлагает механизм обмена управляющими командами с помощью вызова ioctl(2).

Однако с помощью ioctl(2), как было показано в разделе "Подсистема STREAMS" главы 5, можно формировать лишь сообщения типа M_IOCTL. Для преобразования этих сообщений в примитивы TPI служит дополнительный модуль timod(7M), встраиваемый в поток между головным и транспортным модулями. На рис. 6.33 показано местоположение модуля timod(7M) и схематически отображены его функции.

Рис. 6.33. Архитектура доступа к транспортным услугам

Для всех сообщений STREAMS, за исключением сообщений M_IOCTL, которые генерируются головным модулем в ответ на системный вызов ioctl(fd, I_STR, ...), модуль timod(7M) является прозрачным, т.е. он просто передает эти сообщения следующему модулю вниз по потоку без какой-либо обработки. Несколько сообщений M_IOCTL обрабатываются модулем и преобразуются в соответствующие примитивы TPI.

При этом вызов ioctl(2) имеет следующий формат:

#include <sys/stropts.h>
struct strioctl my_strioctl
...
strioctl.ic_cmd = cmd;
strioctl.ic_timeout = INFTIM;
strioctl.ic_len = size;
strioctl.ic_dp = (char*)buf;
ioctl(fd, I_STR, &my_strioctl);

При вызове ioctl(2) поле size устанавливается равным размеру соответствующего примитива TPI, определенного полем cmd и расположенного в буфере buf. При возврате из функции поле size содержит размер примитива, возвращенного поставщиком транспортных услуг и расположенного в буфере buf.

Модуль timod(7M) служит для обработки следующих команд cmd:

Оглавление книги