Книга: UNIX: разработка сетевых приложений

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

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

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

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

Мы можем обойти как XTI, так и сокеты, и использовать непосредственно TPI. В этом разделе мы заново перепишем код нашего простого клиента времени и даты с использованием TPI вместо сокетов (сокетная версия представлена в листинге 1.1). Если провести аналогию с языками программирования, то использование XTI или сокетов можно сравнить с программированием на языках высокого уровня, таких как С или Pascal, а непосредственно TPI — с программированием на ассемблере. Мы не являемся сторонниками непосредственного использования TPI в реальной жизни. Но понимание того, как работает TPI, и написание примера с использованием этого протокола позволит нам глубже понять, как работает библиотека сокетов в потоковой среде.

В листинге 31.1[1] показан наш заголовочный файл tpi_daytime.h.

Листинг 31.1. Наш заголовочный файл tpi_daytime.h

//streams/tpi_daytime.h
 1 #include "unpxti.h"
 2 #include <sys/stream.h>
 3 #include <sys/tihdr.h>
 4 void tpi_bind(int, const void*, size_t);
 5 void tpi_connect(int, const void*, size_t);
 6 ssize_t tpi_read(int, void*, size_t);
 7 void tpi_close(int);

Нам нужно включить еще один дополнительный заголовочный файл помимо <sys/tihdr.h>, содержащего определения структур для всех сообщений TPI.

Листинг 31.2. Функция main для нашего клиента времени и даты с использованием TPI

//streams/tpi_daytime.c
 1 #include "tpi_daytime.h"
 2 int
 3 main(int argc, char **argv)
 4 {
 5  int fd, n;
 6  char recvline[MAXLINE + 1];
 7  struct sockaddr_in myaddr, servaddr;
 8  if (argc != 2)
 9   err_quit("usage: tpi_daytime <Ipaddress>");
10  fd = Open(XTI_TCP, O_RDWR, 0);
11  /* связываем произвольный локальный адрес */
12  bzero(&myaddr, sizeof(myaddr));
13  myaddr.sin_family = AF_INET;
14  myaddr.sin_addr.s_addr = htonl(INADDR_ANY);
15  myaddr.sin_port = htons(0);
16  tpi_bind(fd, &myaddr, sizeof(struct sockaddr_in));
17  /* заполняем адрес сервера */
18  bzero(&servaddr, sizeof(servaddr));
19  servaddr.sin_family = AF_INET;
20  servaddr.sin_port = htons(13); /* сервер времени и даты */
21  Inet_pton(AF_INET, argv[1], &servaddr.sin_addr);
22  tpi_connect(fd, &servaddr, sizeof(struct sockaddr_in));
23  for (;;) {
24   if ((n = tpi_read(fd, recvline, MAXLINE)) <= 0) {
25    if (n == 0)
26     break;
27    else
28    err_sys("tpi_read error");
29   }
30   recvline[n] = 0; /* завершающий нуль */
31   fputs(recvline, stdout);
32  }
33  tpi_close(fd);
34  exit(0);
35 }

10-16 Мы открываем устройство, соответствующее поставщику транспортных служб (обычно /dev/tcp). Мы заполняем структуру адреса сокета Интернета значениями INADDR_ANY и 0 (для порта), указывая тем самым TCP связать произвольный локальный адрес с нашей точкой доступа. Мы вызываем свою собственную функцию tpi_bind (которая будет приведена чуть ниже) для выполнения этого связывания.

17-22 Мы заполняем другую структуру адреса сокета Интернета, внося в нее IP-адрес сервера (из командной строки) и порт (13). Мы вызываем нашу функцию tpi_connect для установления соединения.

23-33 Как и в случае других клиентов времени и даты, мы просто копируем данные, пришедшие по соединению, в стандартный поток вывода, останавливаясь при получении признака конца файла, присланного сервером (например, сегмент FIN). Мы сделали этот цикл похожим на тот, который использовался в коде сокетного клиента (см. листинг 1.1), поскольку наша функция tpi_read при нормальном завершении соединения на стороне сервера будет возвращать нулевое значение. Затем мы вызываем нашу функцию tpi_close для того, чтобы закрыть эту точку доступа.

Наша функция tpi_bind показана в листинге 31.3.

Листинг 31.3. Функция tpi_bind: связывание локального адреса с точкой доступа

//streams/tpi_bind.c
 1 #include "tpi_daytime.h"
 2 void
 3 tpi_bind(int fd, const void *addr, size_t addrlen)
 4 {
 5  struct {
 6   struct T_bind_req msg_hdr;
 7   char addr[128];
 8  } bind_req;
 9  struct {
10   struct T_bind_ack msg_hdr;
11   char addr[128];
12  } bind_ack;
13  struct strbuf ctlbuf;
14  struct T_error_ack *error_ack;
15  int flags;
16  bind_req.msg_hdr.PRIM_type = T_BIND_REQ;
17  bind_req.msg_hdr.ADDR_length = addrlen;
18  bind_req.msg_hdr.ADDR_offset = sizeof(struct T_bind_req);
19  bind_req.msg_hdr.CONIND_number = 0;
20  memcpy(bind_req.addr, addr, addrlen); /* sockaddr_in{} */
21  ctlbuf.len = sizeof(struct T_bind_req) + addrlen;
22  ctlbuf.buf = (char*)&bind_req;
23  Putmsg(fd, &ctlbuf, NULL, 0);
24  ctlbuf.maxlen = sizeof(bind_ack);
25  ctlbuf.len = 0;
26  ctlbuf.buf = (char*)&bind_ack;
27  flags = RS_HIPRI;
28  Getmsg(fd, &ctlbuf, NULL, &flags);
29  if (ctlbuf.len < (int)sizeof(long))
30   err_quit("bad length from getmsg");
31  switch (bind_ack.msg_hdr.PRIM_type) {
32  case T_BIND_ACK:
33   return;
34  case T_ERROR_ACK:
35   if (ctlbuf.len < (int)sizeof(struct T_error_ack))
36    err_quit("bad length for T_ERROR_ACK");
37   error_ack = (struct T_error_ack*)&bind_ack.msg_hdr;
38   err_quit("T_ERROR_ACK from bind (%d, %d)",
39    error_ack->TLI_error, error_ack->UNIX_error);
40  default:
41   err_quit("unexpected message type: %d", bind_ack.msg_hdr.PRlM_type);
42  }
43 }

16-20 Заголовочный файл <sys/tihdr.h> определяет структуру T_bind_req:

struct T_bind_req {
 long          PRIM_type;     /* T_BIND_REQ */
 long          ADDR_length;   /* длина адреса */
 long          ADDR_offset;   /* смещение адреса */
 unsigned long CONIND_number; /* сообщения о соединении */
 /* далее следует адрес протокола для связывания */
};

Все запросы TPI определяются как структуры, начинающиеся с поля типа long. Мы определяем свою собственную структуру bind_req, начинающуюся со структуры T_bind_req, после которой располагается буфер, содержащий локальный адрес для связывания. TPI ничего не говорит о содержимом буфера — оно определяется поставщиком. Поставщик TCP предполагает, что этот буфер содержит структуру sockaddr_in.

Мы заполняем структуру T_bind_req, устанавливая элемент ADDR_length равным размеру адреса (16 байт для структуры адреса сокета Интернета), а элемент ADDR_offset — равным байтовому сдвигу адреса (он следует непосредственно за структурой T_bind_req). У нас нет гарантии, что это местоположение соответствующим образом выровнено для записи структуры sockaddr_in, поэтому мы вызываем функцию memcpy, чтобы скопировать структуру вызывающего процесса в нашу структуру bind_req. Мы присваиваем элементу CONIND_number нулевое значение, потому что мы находимся на стороне клиента, а не на стороне сервера.

21-23 TPI требует, чтобы только что созданная нами структура была передана поставщику как одно сообщение M_PROTO. Следовательно, мы вызываем функцию putmsg, задавая структуру bind_req в качестве управляющей информации, без каких-либо данных и с флагом 0.

24-30 Ответом на наш запрос T_BIND_REQ будет либо сообщение T_BIND_ACK, либо сообщение T_ERROR_ACK. Сообщения, содержащие подтверждение, отправляются как сообщения с высоким приоритетом (M_PCPROTO), так что мы считываем их при помощи функции getmsg с флагом RS_HIPRI. Поскольку ответ является сообщением с высоким приоритетом, он получает преимущество перед всеми обычными сообщениями в потоке.

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

struct T_bind_ack {
 long          PRIM_type;     /* T_BIND_ACK */
 long          ADDR_length;   /* длина адреса */
 long          ADDR_offset;   /* смещение адреса */
 unsigned long CONIND_number; /* индекс подключения для помещения
                                 в очередь */
};
 /* затем следует связанный адрес */
struct T_error_ack {
 long PRIM_type;  /* T_ERROR_ACK */
 long ERROR_prim; /* примитивная ошибка ввода */
 long TLI_error;  /* код ошибки TLI */
 long UNIX_error; /* код ошибки UNIX */
};

В начале каждого сообщения указан его тип, так что мы можем начать считывать ответ, предполагая, что это сообщение T_BIND_ACK, а затем, прочитав его тип, обрабатывать его тем или иным способом. Мы не ждем никаких данных от поставщика, поэтому третий аргумент функции getmsg мы задаем как пустой указатель.

31-33 Если ответ — это сообщение T_BIND_ACK, то связывание прошло успешно, и мы возвращаемся. Фактический адрес, связанный с точкой доступа, возвращается в элементе addr нашей структуры bind_ack, которую мы игнорируем.

34-39 Если ответ — это сообщение T_ERROR_ACK, мы проверяем, было ли сообщение получено целиком, и выводим три значения, содержащиеся в возвращенной структуре. В этой простой программе при возникновении ошибки мы просто прекращаем выполнение и ничего не возвращаем вызывающему процессу.

Чтобы увидеть ошибки, которые могут возникнуть в результате запроса на связывание, мы слегка изменим нашу функцию main и попробуем связать какой- либо порт, отличный от 0. Например, если мы попробуем связать порт 1 (что требует прав привилегированного пользователя, так как это порт с номером меньше 1024), мы получим следующий результат:

solaris % tpi_daytime 127.0.0.1
T_ERROR_ACK from bind (3, 0)

В этой системе значение константы EACCESS равно 3. Если мы поменяем номер порта, задав значение большее 1023, но используемое в настоящий момент другой точкой доступа TCP, мы получим:

solaris % tpi_daytime 127.0.0.1
T_ERROR_ACK from bind (23, 0)

В данной системе значение константы EADDRBUSY равно 23.

Следующая функция показана в листинге 31.4. Это функция tpi_connect, устанавливающая соединение с сервером.

Листинг 31.4. Функция tpi_connect: установление соединения с сервером

//streams/tpi_connect.c
 1 #include "tpi_daytime.h"
 2 void
 3 tpi_connect(int fd, const void *addr, size_t addrlen)
 4 {
 5  struct {
 6   struct T_conn_req msg_hdr;
 7   char addr[128];
 8  } conn_req;
 9  struct {
10   struct l_conn_con msg_hdr;
11   char addr[128];
12  } conn_con;
13  struct strbuf ctlbuf;
14  union T_primitives rcvbuf;
15  struct T_error_ack *error_ack;
16  struct T_discon_ind *discon_ind;
17  int flags;
18  conn_req.msg_hdr.PRIM_type = T_CONN_REQ;
19  conn_req.msg_hdr.DEST_length = addrlen;
20  conn_req.msg_hdr.DEST_offset = sizeof(struct T_conn_req);
21  conn_req.msg_hdr.OPT_length = 0;
22  conn_req.msg_hdr.OPT_offset = 0;
23  memcpy(conn_req.addr, addr, addrlen); /* sockaddr_in{} */
24  ctlbuf.len = sizeof(struct T_conn_req) + addrlen;
25  ctlbuf.buf = (char*)&conn_req;
26  Putmsg(fd, &ctlbuf, NULL, 0);
27  ctlbuf.maxlen = sizeof(union T_primitives);
28  ctlbuf.len = 0;
29  ctlbuf.buf = (char*)&rcvbuf;
30  flags = RS_HIPRI;
31  Getmsg(fd, &ctlbuf, NULL, &flags);
32  if (ctlbuf.len < (int)sizeof(long))
33   err_quit("tpi_connect: bad length from getmsg");
34  switch (rcvbuf.type) {
35  case T_OK_ACK:
36   break;
37  case T_ERROR_ACK:
38   if (ctlbuf.len < (int)sizeof(struct T_error_ack))
39    err_quit("tpi_connect: bad length for T_ERROR_ACK");
40   error_ack = (struct T_error_ack*)&rcvbuf;
41   err_quit("tpi_connect: T_ERROR_ACK from conn %d, %d)",
42    error_ack->TLI_error, error_ack->UNIX_error);
43  default:
44   err_quit("tpi connect, unexpected message type: &d", rcvbuf.type);
45  }
46  ctlbuf.maxlen = sizeof(conn_con);
47  ctlbuf.len = 0;
48  ctlbuf.buf = (char*)&conn_con;
49  flags = 0;
50  Getmsg(fd, &ctlbuf, NULL, &flags);
51  if (ctlbuf.len < (int)sizeof(long))
52   err_quit("tpi_connect2: bad length from getmsg");
53  switch (conn_con.msg_hdr.PRIM_type) {
54  case T_CONN_CON:
55   break;
56  case T_DISCON_IND:
57   if (ctlbuf.len < (int)sizeof(struct T_discon_ind))
58    err_quit("tpi_connect2: bad length for T_DISCON_IND");
59   discon_ind = (struct T_discon_ind*)&conn_con.msg_hdr;
60   err_quit("tpi_connect2: T_DISCON_IND from conn (%d)",
61   discon_ind->DISCON_reason);
62  default:
63   err_quit("tpi_connect2: unexpected message type. %d",
64   conn_con.msg_hdr PRIM_type);
65  }
66 }

18-26 В TPI определена структура T_conn_req, содержащая адрес протокола и параметры для соединения:

struct T_conn_req {
 long PRIM_type;   /* T_CONN_REQ */
 long DEST_length; /* длина адреса получателя */
 long DEST_offset; /* смещение адреса получателя */
 long OPT_length;  /* длина параметров */
 long OPT_offset;  /* смещение параметров */
 /* затем следуют адреса протокола и параметры соединения */
};

Как и в случае функции tpi_bind, мы определяем свою собственную структуру с именем conn_req, которая включает в себя структуру T_conn_req, а также содержит место для адреса протокола. Мы заполняем структуру conn_req, обнуляя поля OPT_length и OPT_offset. Мы вызываем функцию putmsg только с управляющей информацией и флагом 0 для отправки сообщения типа M_PROTO вниз по потоку.

27-45 Мы вызываем функцию getmsg, ожидая получить в ответ либо сообщение T_OK_ACK, если было начато установление соединения, либо сообщение T_ERROR_ACK (которые мы уже показывали выше). В случае ошибки мы завершаем выполнение программы. Поскольку мы не знаем, сообщение какого типа мы получим, то определяем объединение с именем T_primitives для приема всех возможных запросов и ответов и размещаем это объединение в памяти как входной буфер для управляющей информации при вызове функции getmsg.

struct T_ok_ack {
 long PRIM_type;    /* T_OK_ACK */
 long CORRECT_prim; /* корректный примитив */
};

46-65 Сообщение T_OK_ACK, полученное нами на предыдущем этапе, указывает лишь на то, что соединение успешно начало устанавливаться. Теперь нам нужно дождаться сообщения T_CONN_CON, указывающего на то, что другой конец соединения подтверждает получение запроса на соединение.

struct T_conn_con {
 long PRIM_type;  /* T_CONN_CON */
 long RES_length; /* длина адреса собеседника */
 long RES_offset; /* смещение адреса собеседника */
 long OPT_length; /* длина параметра */
 long OPT_offset; /* смещение параметра */
 /* далее следуют адрес протокола и параметры собеседника */
};

Мы снова вызываем функцию getmsg, но ожидаемое нами сообщение посылается как сообщение типа M_PROTO, а не как сообщение M_PCPROTO, поэтому мы обнуляем флаги. Если мы получаем сообщение T_CONN_CON, значит, соединение установлено, и мы возвращаемся, но если соединение не было установлено (по причине того, что процесс собеседника не запущен, истекло время ожидания или еще по какой-либо причине), то вместо этого вверх по потоку отправляется сообщение T_DISCON_IND:

struct T_discon_ind {
 long PRIM_type;     /* T_DISCON_IND */
 long DISCON_reason; /* причина разрыва соединения */
 long SEQ_number;    /* порядковый номер */
};

Мы можем посмотреть, какие ошибки могут быть возвращены поставщиком. Сначала мы задаем IP-адрес узла, на котором не запущен сервер времени и даты:

solaris26 % tpi_daytime 192.168.1.10
tpi_connect2: T_DISCON_IND from conn (146)

Код 146 соответствует ошибке ECONNREFUSED. Затем мы задаем IP-адрес, который не связан с Интернетом:

solaris26 % tpi_daytime 192.3.4.5
tpi_connect2: T_DISCON_IND from conn (145)

На этот раз возвращается ошибка ETIMEDOUT. Но если мы снова запустим нашу программу, задавая тот же самый IP-адрес, то получим другую ошибку:

solaris26 % tpi_daytime 192.3.4.5
tpi_connect2: T_DISCON_IND from conn (148)

На этот раз мы получаем ошибку EHOSTUNREACH. Различие в том, что в первый раз не было возвращено сообщение ICMP о недоступности узла, а во второй раз мы получили это сообщение.

Следующая функция, которую мы рассмотрим, — это tpi_read, показанная в листинге 31.5. Она считывает данные из потока.

Листинг 31.5. Функция tpi_read: считывание данных из потока

//streams/tpi_read.c
 1 #include "tpi_daytime.h"
 2 ssize_t
 3 tpi_read(int fd, void *buf, size_t len)
 4 {
 5  struct strbuf ctlbuf;
 6  struct strbuf datbuf;
 7  union T_primitives rcvbuf;
 8  int flags;
 9  ctlbuf maxlen = sizeof(union T_primitives);
10  ctlbuf.buf = (char*)&rcvbuf;
11  datbuf.maxlen = len;
12  datbuf.buf = buf;
13  datbuf.len = 0;
14  flags = 0;
15  Getmsg(fd, &ctlbuf, &datbuf, &flags);
16  if (ctlbuf.len >= (int)sizeof(long)) {
17   if (rcvbuf.type == T_DATA_IND)
18    return (datbuf.len);
19   else if (rcvbuf.type == T_ORDREL_IND)
20    return (0);
21   else
22    err_quit("tpi_read: unexpected type %d", rcvbuf.type);
23  } else if (ctlbuf.len == -1)
24   return (datbuf.len);
25  else
26   err_quit("tpi_read: bad length from getmsg");
27 }

9-26 На этот раз мы вызываем функцию getmsg для считывания как данных, так и управляющей информации. Структура strbuf, предназначенная для данных, указывает на буфер вызывающего процесса. В потоке события могут развиваться по четырем различным сценариям.

? Данные могут прибыть в виде сообщения M_DATA, и указанием на это является возвращенное значение длины управляющей информации, равное -1. Данные скопированы в буфер вызывающего процесса функцией getmsg, и функция просто возвращает длину этих данных.

? Данные могут прибыть как сообщение T_DATA_IND, в этом случае управляющая информация будет содержаться в структуре T_data_ind:

struct T_data_ind {
 long PRIM_type; /* T_DATA_IND */
 long MORE_flag; /* еще данные */
};

Если возвращено такое сообщение, мы игнорируем поле MORE_flag (оно вообще не задается для таких протоколов, как TCP) и просто возвращаем длину данных, скопированных в буфер вызывающего процесса функцией getmsg.

? Сообщение T_ORDREL_IND возвращается, если все данные получены и следующим элементом является сегмент FIN:

struct T_ordrel_ind {
 long PRIM_type; /* T_ORDREL_IND */
};

Это нормальное завершение. Мы просто возвращаем нулевое значение, указывая вызывающему процессу, что по соединению получен признак конца файла.

? Сообщение T_DISCON_IND возвращается, если произошел разрыв соединения. Наша последняя функция — это tpi_close, показанная в листинге 31.6.

Листинг 31.6. Функция tpi_close: отправка запроса о завершении собеседнику

//streams/tpi_close.c
 1 #include "tpi_daytime.h"
 2 void
 3 tpi_close(int fd)
 4 {
 5  struct T_ordrel_req ordrel_req;
 6  struct strbuf ctlbuf;
 7  ordrel_req PRIM_type = T_ORDREL_REQ;
 8  ctlbuf.len = sizeof(struct T_ordrel_req);
 9  ctlbuf.buf = (char*)&ordrel_req;
10  Putmsg(fd, &ctlbuf, NULL, 0);
11  Close(fd);
12 }

7-10 Мы формируем структуру T_ordrel_req:

struct T_ordrel_req {
 long PRIM_type; /* T_ORDREL_REQ */
};

и посылаем ее как сообщение M_PROTO с помощью функции putmsg. Это соответствует функции XTI t_sndrel.

Этот пример позволил нам почувствовать специфику TPI. Приложение посылает сообщения вниз по потоку (запросы), а поставщик посылает сообщения вверх по потоку (ответы). Некоторые обмены сообщений организованы согласно простому сценарию «запрос-ответ» (связывание локального адреса), в то время как остальные могут занять некоторое время (установление соединения), позволяя нам заняться чем-то другим в процессе ожидания ответа. Для знакомства с TPI мы выбрали этот пример (написание клиента TCP) из-за его относительной простоты. Если бы мы решили написать с использованием TPI TCP-сервер, обрабатывающий одновременно несколько соединений, это было бы гораздо сложнее.

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