Андрей Робачевский - Операционная система 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.