Текст книги "Операционная система UNIX"

Автор книги: Андрей Робачевский

сообщить о нарушении

Текущая страница: 34 (всего у книги 39 страниц)

Программный интерфейс TLI

При обсуждении реализации сетевой поддержки в BSD UNIX был рассмотрен программный интерфейс доступа к сетевым ресурсам, основанный на сокетах. В данном разделе описан интерфейс транспортного уровня (Transport Layer Interface, TLI), который обеспечивает взаимодействие прикладных программ с транспортными протоколами.

TLI был впервые представлен в UNIX System V Release 3.0 в 1986 году. Этот программный интерфейс тесно связан с сетевой подсистемой UNIX, основанной на архитектуре STREAMS, изолируя от прикладной программы особенности сетевой архитектуры. Вместо того чтобы непосредственно пользоваться общими функциями STREAMS, рассмотренными в предыдущей главе, TLI позволяет использовать специальный набор вызовов, специально предназначенных для сетевых приложений. Для преобразования вызовов TLI в функции интерфейса STREAMS используется библиотека TLI, которая в большинстве систем UNIX имеет название libnsl.a или libnsl.so.

Схема использования функций TLI во многом сходна с рассмотренным интерфейсом сокетов и зависит от типа используемого протокола – с предварительным установлением соединения (например, TCP) или без него (например, UDP).

На рис. 6.18 и 6.19 представлены схемы использования функций TLI для транспортных протоколов с предварительным установлением соединения и без установления соединения. Можно отметить, что эти схемы очень похожи на те, с которыми мы уже встречались в разделе "Межпроцессное взаимодействие в BSD UNIX. Сокеты" главы 3 при обсуждении сокетов. Некоторые различия отмечены ниже при описании функций TLI.

Рис. 6.18. Схема вызова функций TLI для протокола с предварительным установлением соединения

Рис. 6.19. Схема вызова функций TLI для протокола без предварительного установления соединения

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

Для определения адреса TLI предоставляет общую структуру данных netbuf, имеющую вид:

struct netbuf {

 unsigned int maxlen;

 unsigned int len;

 char *buf;

}

Поле buf указывает на буфер, в котором может передаваться адрес узла, maxlen определяет его размер, a len – количество данных в буфере, т.е. размер адреса. Эта структура по своему назначению похожа на структуру sockaddr, которая является общим определением адреса коммуникационного узла для сокетов. Далее рассматривается пример сетевого приложения, основанного на TLI, где показано, как netbuf используется при передаче адреса для протоколов TCP/IP.

Структура netbuf используется в TLI для хранения не только адреса, но и другой информации – опций протокола и прикладных данных. Эта структура является составной частью более сложных структур данных, используемых при передаче параметров в функциях TLI. Для упрощения динамического размещения этих структур библиотека TLI предоставляет две функции: t_alloc(3N) для размещения структуры и t_free(3N) для освобождения памяти. Эти функции имеют следующий вид:

#include

char *t_alloc(int fd, int struct_type, int fields);

int t_free(char *ptr, int struct_type);

Аргумент struct_type определяет, для какой структуры данных выделяется память. Он может принимать следующие значения:

T_BIND	struct t_bind
T_CALL	struct t_call
T_DIS	struct t_discon
T_INFO	struct t_info
T_OPTMGMT	struct t_optmgmt
T_UNITDATA	struct t_unitdata
T_UDERROR	struct t_uderr

Co структурами, приведенными в таблице, мы познакомимся при обсуждении функций TLI. Большинство из них включают несколько элементов netbuf. Поскольку в некоторых случаях может отсутствовать необходимость размещения всех элементов netfuf, поле fields позволяет указать, какие конкретно буферы необходимо разместить для данной структуры:

T_ALL	Все необходимые поля
T_ADDR	Поле addr в структурах t_bind, t_call, t_unitdata, t_uderr
T_OPT	Поле opt в структурах t_call, t_unitdata, t_uderr, t_optmgmt
T_UDATA	Поле udata в структурах t_call, t_unitdata, t_discon

Отметим одну особенность. Фактический размер буфера и, соответственно, структуры netbuf зависят от значения поля maxlen этой структуры. В свою очередь, этот параметр зависит от конкретного поставщика транспортных услуг – именно он определяет максимальный размер адреса, опций и прикладных данных. Чуть позже мы увидим, что эта информация ассоциирована с транспортным узлом и может быть получена после его создания с помощью функции t_open(3N). Поэтому для определения фактического размера размещаемых структур в функции t_аlloc(3N) необходим аргумент fd, являющийся дескриптором транспортного узла, который возвращается процессу функцией t_open(3N).

Перейдем к основным функциям TLI.

Как видно из рис. 6.18 и 6.19, в качестве первого этапа создания коммуникационного узла используется функция t_open(3N). Как и системный вызов open(2), она возвращает дескриптор, который в дальнейшем адресует узел в функциях TLI. Функция имеет вид:

#include

#include

int t_open(const char *path, int oflags, struct t_info *info);

Аргумент path является именем специального файла устройства, являющегося поставщиком транспортных услуг, например, /dev/tcp или /dev/udp. Аргумент oflags определяет флаги открытия файла и соответствует аналогичному аргументу системного вызова open(2). Приложение может получить информацию о поставщике транспортных услуг в структуре info, имеющей следующие поля:

addr	Определяет максимальный размер адреса транспортного протокола. Значение -1 говорит, что размер не ограничен, -2 означает, что прикладная программа не имеет доступа к адресам протокола. Протокол TCP устанавливает размер этого адреса (адрес порта) равным 16.
options	Определяет размер опций для данного протокола. Значение -1 свидетельствует, что размер не ограничен, -2 означает, что прикладная программа не имеет возможности устанавливать опции протокола.
tsdu	Определяет максимальный размер пакета данных протокола (Transport Service Data Unit, TSDU). Нулевое значение означает, что протокол не поддерживает пакетную передачу (т.е. не сохраняет границы записей). Значение -1 свидетельствует, что размер не ограничен, -2 означает, что передача обычных данных не поддерживается. Поскольку протокол TCP обеспечивает передачу неструктурированного потока данных, значение tsdu для него равно 0. Напротив, UDP поддерживает пакетную передачу.
etsdu	Определяет максимальный размер пакета экстренных данных протокола (Expedited Transport Service Data Unit, ETSDU). Нулевое значение означает, что протокол не поддерживает пакетную передачу (т.е. не сохраняет границы записей). Значение -1 свидетельствует, что размер не ограничен, -2 означает, что передача экстренных данных не поддерживается. TCP обеспечивает такую поддержку, а UDP – нет.
connect	Некоторые протоколы допускают передачу прикладных данных вместе с запросом на соединение. Поле connect определяет максимальный размер таких данных. Значение -1 свидетельствует, что размер не ограничен, -2 означает, что данная возможность не поддерживается. И TCP и UDP не поддерживают этой возможности.
discon	Определяет то же, что и connect, но при запросе на прекращение соединения. И TCP и UDP не поддерживают этой возможности.
servtype	Определяет тип транспортных услуг, предоставляемых протоколом. Значение T_COTS означает передачу с предварительным установлением соединения, T_COTS_ORD – упорядоченную передачу с предварительным установлением соединения, T_CLTS – передачу без предварительного установления соединения. Протокол TCP обеспечивает услугу T_COTS_ORD, a UDP – T_CLTS.

Прежде чем передача данных будет возможна, транспортному узлу должен быть присвоен адрес. Эта фаза называется операцией связывания и мы уже сталкивались с ней при разговоре о сокетах в главе 3 и при обсуждении сетевой поддержки в BSD UNIX ранее в этой главе. В рассмотренных случаях связывание выполнял вызов bind(2). В TLI для этого служит функция t_bind(3N), имеющая вид:

#include

int t_bind(int fd, const struct t_bind *req,

 struct t_bind *ret);

Аргумент fd адресует коммуникационный узел. Аргумент req позволяет программе явно указать требуемый адрес, а через аргумент ret возвращается значение, установленное протоколом.

Два последних аргумента описываются структурой t_bind, имеющей следующие поля:

struct netbuf addr	Адрес
unsigned qlen	Максимальное число запросов на установление связи, которые могут ожидать обработки. Имеет смысл только для протоколов с предварительным установлением соединения

Рассмотрим три возможных формата аргумента req:

req == NULL	Позволяет поставщику транспортных услуг самому выбрать подходящий адрес
req != NULL req->addr.len == 0	Позволяет поставщику транспортных услуг самому брать подходящий адрес, но определяет максимальное число запросов на установление связи, которые могут ожидать обработки
req != NULL req->addr.len > 0	Явно указывает требуемый адрес и максимальное число запросов на установление связи, которые могут ожидать обработки

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

Для протоколов с предварительным установлением соединения программе-клиенту необходимо использовать функцию t_connect(3N), отправляющую запрос на создание соединения с удаленным транспортным узлом. Функция t_connect(3N) имеет вид:

#include

int t_connect(int fd, const struct t_call* sndcall,

 struct t_call *rcvcall);

Аргумент sndcall содержит информацию, необходимую поставщику транспортных услуг для создания виртуального канала. Формат этой информации описывается структурой t_call, имеющей следующие поля:

struct netbuf addr	Адрес удаленного транспортного узла
struct netbuf opt	Требуемые опции протокола
struct netbuf udata	Прикладные данные, отправляемые вместе с управляющей информацией (запрос на установление соединения или подтверждение)
int sequence	В данном случае не имеет смысла

Через аргумент revcall программе возвращается информация о виртуальном канале после его создания: адрес удаленного узла, опции и прикладные данные, переданные удаленным узлом. Как уже отмечалось, ни TCP, ни UDP не позволяют передавать данные вместе с управляющей информацией. Программа может установить значение rcvcall равным NULL, если информация о канале ее не интересует.

Обычно возврат из функции t_connect(3N) происходит после окончательного установления соединения, когда виртуальный канал готов к передаче данных (конечно, в случае успешного завершения).

Для протоколов с предварительным установлением соединения программа-сервер вызывает функцию t_listen(3N), блокируя свое выполнение до получения запроса на создание виртуального канала.

#include

int t_listen(int fd, struct t_call *call);

Информация, возвращаемая транспортным протоколом в аргументе call, содержит параметры, переданные удаленным узлом с помощью соответствующего вызова t_connect(3N): его адрес, установленные опции протокола, а также, в ряде случаев, прикладные данные, переданные вместе с запросом. Поле sequence аргумента call содержит уникальный идентификатор данного запроса.

Хотя t_listen(3N), несмотря на название, напоминает функцию accept(2), используемую для сокетов, сервер должен выполнить вызов другой функции – t_accept(3N) для того, чтобы фактически принять запрос и установить соединение. Функция t_accept(3N) имеет вид:

#include

int t_accept(int fd, int connfd, struct t_call *call);

Аргумент fd адресует транспортный узел, принявший запрос (тот же, что и для функции t_listen(3N)). Аргумент connfd адресует транспортный узел, для которого будет установлено соединение с удаленным узлом. За создание нового транспортного узла отвечает сама программа (т.е. необходим явный вызов функции t_open(3N)), при этом fd может по-прежнему использоваться для обслуживания поступающих запросов.

Как и в случае t_listen(3N), через аргумент call передается информация об удаленном транспортном узле.

После возврата из функции t_accept(3N) между двумя узлами (connfd и удаленным узлом-клиентом) образован виртуальный канал, готовый к передаче прикладных данных.

Для обмена прикладными данными после установления соединения используются две функции: t_rcv(3N) для получения и t_snd(3N) для передачи. Они имеют следующий вид:

#include

int t_rcv(int fildes, char *buf, unsigned nbytes, int* flags);

int t_snd(int fildes, char *buf, unsigned nbytes, int flags);

Первые три аргумента соответствуют аналогичным аргументам системных вызовов read(2) и write(2). Аргумент flags функции t_snd(3N) может содержать следующие флаги:

T_EXPEDITED	Указывает на отправление экстренных данных
T_MORE	Указывает, что данные составляют логическую запись, продолжение которой будет передано последующими вызовами t_snd(3N). Напомним, что TCP обеспечивает неструктурированный поток и, следовательно, не поддерживает данной возможности

Эту информацию принимающий узел получает с помощью t_rcv(3N) также через аргумент flags.

Для протоколов без предварительного установления соединения используются функции t_rcvdata(3N) и t_snddata(3N) для получения и передачи датаграмм соответственно. Функции имеют следующий вид:

#include

int t_rcvudata(int fildes, struct t_unitdata *unitdata,

 int* flags);

int t_sndudata(int fildes, struct t_unitdata *unitdata);

Для передачи данных используется структура unitdata, имеющая следующие поля:

struct netbuf addr	Адрес удаленного транспортного узла
struct netbuf opt	Опции протокола
struct netbuf udata	Прикладные данные

Созданный транспортный узел может быть закрыт с помощью функции t_close(3N). Заметим, что при этом соединение, или виртуальный канал, с которым ассоциирован данный узел, в ряде случаев не будет закрыт. Функция t_close(3N) имеет вид:

#include

int t_close(int fd);

где fd определяет транспортный узел. Вызов этой функции приведет к освобождению ресурсов, связанных с транспортным узлом, а последующий системный вызов close(2) освободит и файловый дескриптор. Судьба виртуального канала (если таковой существует) зависит от того, является ли транспортный узел, адресующий данный канал, единственным. Если это так, соединение немедленно разрывается. В противном случае, например, когда несколько файловых дескрипторов адресуют один и тот же транспортный узел, виртуальный канал продолжает существовать.

Завершая разговор о программном интерфейсе TLI, необходимо упомянуть об обработке ошибок. Для большинства функций TLI свидетельством ошибки является получение -1 в качестве возвращаемого значения. Напротив, в случае нормального завершения эти функции возвращают 0. Как правило, при неудачном завершении функции TLI код ошибки сохраняется в переменной t_errno, подобно тому, как переменная errno хранит код ошибки системного вызова. Для вывода сообщения, расшифровывающего причину ошибки, используется функция t_error(3N):

#include

void t_error(const char *errmsg);

При вызове t_error(3N) после неудачного завершения какой-либо функции TLI будет выведено сообщение errmsg, определенное разработчиком программы, за которым последует расшифровка ошибки, связанной с кодом t_errno. Если значение t_errno равно TSYSERR, то расшифровка представляет собой стандартное сообщение о системной ошибке, связанной с переменной errno.

В заключение в качестве иллюстрации программного интерфейса TLI приведем пример приложения клиент-сервер. Как и в предыдущих примерах, сервер принимает сообщения от клиента и отправляет их обратно. Клиент, в свою очередь, выводит полученное сообщение на экран. В качестве сообщения, как и прежде, выступает жизнерадостное приветствие "Здравствуй, мир!".

Сервер

#include

#include

#include

#include

#include

#include

#include

#include

/* Номер порта, известный клиентам */

#define PORTNUM 1500

main(argc, argv)

int argc;

char *argv[];

{

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

 int tn, ntn;

 int pid, flags;

 int nport;

 /* Адреса транспортных узлов сервера и клиента */

 struct sockaddr_in serv_addr, *clnt_addr;

 struct hostent *hp;

 char buf[80], hname[80];

 struct t_bind req;

 struct t_call *call;

 /* Создадим транспортный узел. В качестве поставщика

    транспортных услуг выберем модуль TCP */

 if ((tn = t_open(«/dev/tcp», O_RDWR, NULL)) == -1) {

  t_error(«Ошибка вызова t_open()»);

  exit(1);

 }

 /* Зададим адрес транспортного узла – он должен быть

    известен клиенту */

 nport = PORTNUM;

 /* Приведем в соответствие порядок следования байтов для хоста

    и сети */

 nport = htons((u_short)nport);

 bzero(&serv_addr, sizeof(serv_addr));

 serv_addr.sin_family = AF_INET;

 serv_addr.sin_addr.s_addr = INADDR_ANY;

 serv_addr.sin_port = nport;

 req.addr.maxlen = sizeof(serv_addr);

 req.addr.len = sizeof(serv_addr);

 req.addr.buf = (char*)&serv_addr;

 /* Максимальное число запросов, ожидающих обработки,

    установим равным 5 */

 req.qlen = 5;

 /* Свяжем узел с запросом */

 if (t_bind(tn, &req, (struct t_bind*)0) < 0) {

  t_error("Ошибка вызова t_bind();

  exit(1);

 }

 fprintf(stderr, «Адрес сервера: %sn»,

  inet_ntoa(serv_addr.sin_addr));

 /* Поскольку в структуре t_call нам понадобится только буфер

    для хранения адреса клиента, разместим ее динамически */

 if ((call =

  (struct t_call*)t_alloc(tn, T_CALL, T_ADDR)) == NULL) {

  t_error(«Ошибка вызова t_alloc()»);

  exit(2);

 }

 call->addr.maxlen = sizeof(serv_addr);

 call->addr.len = sizeof(srv_addr);

 call->opt.len = 0;

 call->update.len = 0;

 /* Бесконечный цикл получения и обработки запросов */

 while (1) {

  /* Ждем поступления запроса на установление соединения */

  if (t_listen(s, call) < 0) {

   t_error(«Ошибка вызова t_listen()»);

   exit(1);

  }

  /* Выведем информацию о клиенте, сделавшем запрос */

  clnt_addr = (struct sockaddr_in*)call->addr.buf;

  printf(«Клиент: %sn», inet_ntoa(clnt_addr->sin_addr));

  /* Создадим транспортный узел для обслуживания запроса */

  if (ntn = t_open(«/dev/tcp», O_RDWR, (struct t_info*)0)) < 0) {

   t_error(«Ошибка вызова t_open()»);

   exit(1);

  }

  /* Пусть система сама свяжет его с подходящим адресом */

  if (t_bind(ntn, (struct t_bind*)0), (struct t_bind*)0) < 0) {

   t_error(«Ошибка вызова t_accept()»);

   exit(1);

  }

  /* Примем запрос и переведем его обслуживание на новый

     транспортный узел */

  if (t_accept(tn, ntn, call) < 0) {

   t_error(«Ошибка вызова t_accept()»);

   exit(1);

  }

  /* Создадим новый процесс для обслуживания запроса.

     При этом родительский процесс продолжает принимать

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

  if ((pid = fork()) == -1) {

   t_error(«Ошибка вызова fork()»);

   exit(1);

  }

  if (pid == 0) {

   int nbytes;

   /* Дочерний процесс: этот транспортный узел уже не нужен,

      он используется родителем */

   close(tn);

   while ((nbytes = t_rcv(ntn, buf,

    sizeof(buf), &flags)) != 0) {

    t_snd(ntn, buf, sizeof(buf), 0);

   }

   t_close(ntn);

   exit(0);

  }

  /* Родительский процесс: этот транспортный узел не нужен,

     он используется дочерним процессом для обмена данными

     с клиентом */

  t_close(ntn);

 }

 t_close(ntn);

}

Клиент

#include

#include

#include

#include

#include

#include

#include

#include

#define PORTNUM 1500

main(argc, argv)

char *argv[];

int argc;

{

 int tn;

 int flags;

 struct sockaddr_in serv_addr;

 struct hostent *hp;

 char buf[80]="Здравствуй, мир!";

 struct t_call* call;

 /* В качестве аргумента клиенту передается доменное имя хоста,

    на котором запущен сервер. Произведем трансляцию доменного

    имени в адрес */

 if ((hp = gethostbyname(argv[1])) == 0) {

  perror(«Ошибка вызова gethostbyname()»);

  exit(1);

 }

 /* Создадим транспортный узел. В качестве поставщика

    транспортных услуг выберем модуль TCP */

 printf(«Сервер готовn»);

 if ((tn = t_open(«/dev/tcp», O_RDWR, NULL)) == -1) {

  t_error(«Ошибка вызова t_open()»);

  exit(1);

 }

 /* Предоставим системе самостоятельно связать узел с

    подходящим адресом */

 if (t_bind(tn, (struct t_bind*)0,

  (struct t_bind *)0) < 0} {

  t_error(«Ошибка вызова t_bind()»);

  exit(1);

 }

 fprintf(stderr, «Адрес клиента: %sn»,

  inet_ntoa(serv_addr.sin_addr));

 /* Укажем адрес сервера, с которым мы будем работать */

 bzero(&serv_addr, sizeof(serv_addr));

 bcopy(hp->h_addr, &serv_addr.sin_addr, hp->h_length);

 serv_addr.sin_family = hp->h_addrtype;

 /* Приведем в соответствие порядок следования байтов

    для хоста и сети */

 serv_addr.sin_port = htons(PORTNUM);

 /* Поскольку в структуре t_call нам понадобится только буфер

    для хранения адреса сервера, разместим ее динамически */

 if ((call =

  (struct t_call*)t_alloc(tn, T_CALL, T_ADDR)) == NULL) {

  t_error(«Ошибка вызова t_alloc()»);

  exit(2);

 }

 call->addr.maxlen = sizeof(serv_addr);

 call->addr.len = sizeof(serv_addr);

 call->addr.buf = (char*)&serv_addr;

 call->opt.len = 0;

 call->udata.len = 0;

 /* Установи соединение с сервером */

 if (t_connect(tn, call, (struct t_call*)0) == -1) {

  t_error(«Ошибка вызова t_rcv()»);

  exit(1);

 }

 /* Передадим сообщение и получим ответ */

 t_snd(tn, buf, sizeof(buf), 0);

 if (t_rcv(tn, buf, sizeof(buf), &flags) < 0) {

  t_error(«Ошибка вызова t_rcv()»);

  exit(1);

 }

 /* Выведем полученное сообщение на экран */

 printf(«Получено от сервера: %sn», buf);

 printf(«Клиент завершил работу!nn»);

}

В рассмотренном примере большая часть исходного текста посвящена созданию транспортных узлов и установлению соединения, в то время как завершение сеанса связи представлено скупыми вызовами t_close(3N). На самом деле, вызов t_close(3N) приводит к немедленному разрыву соединения, запрещая дальнейшую передачу или прием данных. Однако виртуальный канал, обслуживаемый протоколом TCP, является полнодуплексным и, как было показано, TCP предусматривает односторонний разрыв связи, позволяя другой стороне продолжать передачу данных. Действиям, предписываемым TCP, больше соответствуют две функции t_sndrel(3N) и t_rcvrel(3N), которые обеспечивают "корректное "прекращение связи (orderly release). Разумеется, эти рассуждения справедливы лишь для транспортного протокола, обеспечивающего передачу данных с предварительным установлением связи, каковым, в частности, является протокол TCP.

Функции t_sndrel(3N) и t_rcvrel(3N) имеют вид:

#include

int t_sndrel(int fd);

int t_rcvrel(int fd);

Вызывая функцию t_sndrel(3N), процесс отправляет другой стороне уведомление об одностороннем прекращении связи, это означает, что процесс не намерен больше передавать данные. В то же время процесс может принимать данные – файловый дескриптор fd доступен для чтения.

Другая сторона подтверждает получение уведомления вызовом функции t_rcvrel(3N). Однако поскольку получение такого уведомления носит асинхронный характер, процесс должен каким-то образом узнать, что запрос поступил. Такой индикацией является завершение с ошибкой попытки получения данных от удаленного узла, например, с помощью функции t_rcv(3N). В этом случае вызов функции t_rcv(3N) завершится с ошибкой TLOOK.

Эта ошибка свидетельствует, что произошло событие, связанное с коммуникационным узлом, анализ которого позволяет получить дополнительную информацию о причине неудачи. Текущее событие может быть получено с помощью функции t_look(3N):

#include

int t_look(int fildes);

Функция возвращает идентификатор, соответствующий одному из событий, перечисленных в табл. 6.6.

Таблица 6.6. События, связанные с коммуникационным узлом

T_CONNECT	Узлом получено подтверждение создания соединения
T_DISCONNECT	Узлом получен запрос на разрыв соединения
T_DATA	Узлом получены данные
T_EXDATA	Узлом получены экстренные данные
T_LISTEN	Узлом получен запрос на установление соединения
T_ORDREL	Узлом получен запрос на корректное прекращение связи
T_ERROR	Свидетельствует о фатальной ошибке
T_UDERR	Свидетельствует об ошибке датаграммы

Если в рассматриваемом случае событием, связанным с ошибкой t_rcv(3N), является T_ORDREL, это означает, что удаленный узел завершил передачу данных и более не нуждается в соединении. Если узел, получивший запрос на прекращение связи, не возражает против полного прекращения сеанса, он вызывает функцию t_sndrel(3N). Впрочем, при необходимости, коммуникационный узел может продолжить передачу данных. Единственное, отчего ему следует воздержаться, это от попытки получения данных, или, другими словами, от вызова t_rcv(3N), поскольку в этом случае выполнение процесса будет навсегда заблокировано, т.к. данные от удаленного узла поступать не будут.

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

while (t_rcv(fd) != -1) {

 /* Выполняем обработку принятых данных */

 ...

}

if (t_errno == T_LOOK && t_look(fd) == T_ORDREL) {

 /* Значит, получен запрос на корректное прекращение связи.

    Мы согласны на завершение сеанса, поэтому также корректно

    завершаем связь */

 t_rcvrel(fd);

 t_sndrel(fd);

 exit(0);

} else {

 t_error(«Ошибка получения данных (t_rcv)»);

 exit(1);

}