Изменить стиль страницы

Следующий таймер, который мы рассмотрим, — keepalive-таймер. Этот таймер предназначен для мониторинга каналов, по которым не передаются данные, и которые возможно в действительности прекратили свое существование, например, из-за аварийного останова одной из систем. Если за определенный промежуток времени данные по каналу переданы не были, модуль TCP отправляет пробный сегмент keepalive, ожидая в ответ либо подтверждения (это означает, что задержка в передаче данных временная), либо сообщения сброса канала (

RST
). Если получен сегмент
RST
, канал будет закрыт. Если после нескольких попыток, не будет получен отклик, канал будет уничтожен.

Последний таймер из рассматриваемых, это 2MSL-таймер (2MSL — двойное максимальное время жизни сегмента в сети). Модуль TCP запускает этот таймер, когда производится завершение связи, и уже отправлено подтверждение полученному сегменту

FIN
. При этом отправитель не знает, получено ли его подтверждение. Поэтому он некоторое время ждет возможного повторного получения сегмента
FIN
, чтобы в свою очередь повторить подтверждение. Таймер запускается при переходе коммуникационного узла канала в состояние TIME-WAIT, и после его срабатывания соответствующий управляющий блок удаляется. Заметим, что это ожидание не блокирует процесс, выполнивший системный вызов close(2) сокета, отвечающего за данный канал. Другими словами, управляющий блок может существовать еще некоторое время после закрытия дескриптора сокета.

Поддержка сети в UNIX System V

Многие из аспектов реализации поддержки сети в BSD UNIX справедливы и для архитектуры сетевых протоколов UNIX System V. Однако сам механизм обеспечения взаимодействия модулей существенно отличается. Для поддержки сети в UNIX System V используется подсистема STREAMS, рассмотренная в главе 5.

Подсистема ввода/вывода, основанная на архитектуре STREAMS, позволяет в полной мере отразить уровневую структуру коммуникационных протоколов, когда каждый уровень имеет стандартные интерфейсы взаимодействия с другими (верхним и нижним) уровнями, и может работать независимо от конкретной реализации протоколов на соседних уровнях. Архитектура STREAMS полностью соответствует этой модели, позволяя создавать драйверы, которые являются объединениями независимых модулей.

Обмен данными между модулями STREAMS также соответствует характеру взаимодействия отдельных протоколов: данные передаются в виде сообщений, а каждый модуль выполняет требуемую их обработку. На рис. 6.30 приведена схема реализации протоколов TCP/IP в UNIX System V. Используя терминологию предыдущей главы, можно отметить, что модуль IP является гибридным мультиплексором, позволяя обслуживать несколько потоков, приходящих от драйверов сетевых адаптеров (в данном случае Ethernet и FDDI), и несколько потоков к модулям транспортных протоколов (TCP и UDP), а модули TCP и UDP — верхними мультиплексорами, обслуживающими прикладные программы, такие как сервер маршрутизации routed(1M), сервер удаленного терминального доступа telnetd(1M), сервер FTP ftpd(1M), а также программы-клиенты пользователей (например talk(1)).

Операционная система UNIX img_119.jpeg

Рис. 6.30. Реализация протоколов TCP/IP на основе архитектуры STREAMS

Анализ программного обеспечения сетевой поддержки показывает, что как правило сетевые и транспортные протоколы, составляющие базовый стек TCP/IP, поставляются одним производителем, в то время как поддержка уровней сетевого интерфейса и приложений может осуществляться продуктами различных разработчиков. Соответственно, можно выделить два основных интерфейса взаимодействия, стандартизация которых позволяет обеспечить совместную работу различных компонентов программного обеспечения. Первый интерфейс определяет взаимодействие транспортного уровня и уровня приложений и называется интерфейсом поставщика транспортных услуг (Transport Provider Interface, TPI). Второй интерфейс устанавливает правила и формат сообщений, передаваемых между сетевым уровнем и уровнем сетевого интерфейса, и называется интерфейсом поставщика услуг канала данных (Data Link Provider Interface, DLPI).

Вообще говоря, сетевая архитектура, основанная на архитектуре STREAMS, позволяет обеспечить поддержку любого стека протоколов, соответствующего модели OSI. Поэтому выражаясь более точно, перечисленные интерфейсы определяют взаимодействие транспортного уровня и уровня сеанса, и уровня канала и сетевого уровня, соответственно. Эти рассуждения проиллюстрированы на рис. 6.31.[93]

Операционная система UNIX img_120.jpeg

Рис. 6.31. Интерфейсы взаимодействия модулей протоколов

Интерфейс TPI

TPI представляет собой интерфейс предоставления услуг транспортного уровня OSI модели как с предварительным установлением соединения (connection mode), так и без установления соединения (connectionless mode). Стандартизация этого интерфейса позволяет изолировать особенности реализации транспортного уровня от потребителя этих услуг и, тем самым, предоставить возможность разработки программного обеспечения, независимо от конкретного протокола и услуг им предоставляемых.

TPI определяет набор и формат сообщений, с помощью которых протоколы верхнего уровня взаимодействуют с модулем транспортного протокола. Таким образом, TPI является интерфейсом между поставщиком транспортных услуг (transport provider) и пользователем этих услуг (transport user). Эти сообщения определяют транспортные примитивы (transport primitive), или команды, и могут иметь следующий формат:

□ Сообщение состоит из блока типа

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

□ Сообщение состоит из одного блока

M_PCPROTO
, который содержит управляющую информацию, включая тип команды и ее аргументы.

□ Сообщение состоит из одного или более блоков

M_DATA
, в которых передаются данные прикладной программы.

Таблица 6.10. Основные управляющие сообщения TPI

Транспортный примитив Тип сообщения Значение
T_BIND_REQ
M_PROTO
Запрос на связывание. Этот примитив инициируется пользователем транспортных услуг и запрашивает связывание потока с адресом протокола. Сообщение состоит из одного блока
M_PROTO
, который содержит значение адреса и заказанное максимальное число запросов, ожидающих обслуживания со стороны пользователя. Последний параметр игнорируется для транспортных услуг без предварительного установления связи. Блок
M_PROTO
содержит следующие поля:
PRIM type
Тип примитива —
T_BIND_REQ
ADDR_length
Размер адреса протокола
ADDR_offset
Смещение адреса в блоке
M_PROTO
CONIND_number
Максимальное число запросов, ожидающих обслуживания
T_BIND_ACK
M_PCPROTO
Подтверждение получения запроса на связывание. Этот примитив отправляется пользователю транспортных услуг и означает, что поток был связан с адресом протокола, заказанное максимальное число ожидающих запросов допустимо и поток был активизирован. Сообщение состоит из одного блока
M_PCPROTO
, содержащего значения указанных параметров. Заметим, что возвращаемый адрес может не совпадать с адресом, указанным в запросе
T_BIND_REQ
. Блок
M_PROTO
содержит следующие поля:
PRIM_type
Тип примитива —
T_BIND_ACK
ADDR_length
Размер адреса протокола
ADDR_offset
Смещение адреса в блоке
M_PROTO
CONIND_number
Максимальное число запросов, ожидающих обслуживания
T_UNBIND_REQ
M_PROTO
Запрос на уничтожение связывания. Этот примитив инициируется пользователем транспортных услуг и запрашивает у поставщика уничтожение ранее созданного связывания потока с адресом протокола и деактивизацию потока.
T_CONN_REQ
M_PROTO
Запрос на установление связи. Этот примитив применим только для транспортных услуг с предварительным установлением связи. Он инициируется пользователем транспортных услуг и запрашивает установление связи с указанным адресатом. Сообщение состоит из одного блока
M_PROTO
, за которым может следовать один или несколько блоков типа
M_DATA
, содержащих прикладные данные, определенные пользователем. Заметим, что протокол TCP не позволяет передавать прикладные данные вместе с запросом. Блок
M_PROTO
содержит значение адреса получателя и опции, связанные с этим примитивом. Блок
M_PROTO
содержит следующие поля:
PRIM_type
Тип примитива —
T_CONN_REQ
DEST_length
Размер адреса протокола
DEST_offset
Смещение адреса получателя в блоке
M_PROTO
ОРТ_length
Размер опций
ОРТ_offset
Смещение опций в блоке
M_PROTO
T_CONN_IND
M_PROTO
Индикация установления связи. Этот примитив применим только для транспортных услуг с предварительным установлением связи и свидетельствует о том, что удаленным пользователем с указанным адресом был сделан запрос на установление связи. Сообщение состоит из одного блока
M_PROTO
, за которым может следовать один или несколько блоков типа
M_DATA
, содержащих прикладные данные, определенные пользователем. Блок
M_PROTO
содержит значение адреса удаленного пользователя, отправившего запрос на установление связи, а также опции, связанные с этим примитивом. Блок
M_PROTO
содержит следующие поля:
PRIM_type
Тип примитива —
T_CONN_IND
SRC_length
Размер адреса протокола
SRC_offset
Смещение адреса отправителя в блоке
M_PROTO
OPT_length
Размер опций
OPT_offset
Смещение опций в блоке
M_PROTO
SEQ_number
Идентификатор соединения
T_CONN_RES
M_PROTO
Ответ на запрос на установление связи. Этот примитив применим только для транспортных услуг с предварительным установлением связи и свидетельствует о том, что поставщик транспортных услуг принимает предшествующий запрос на установление связи. Сообщение состоит из одного блока
M_PROTO
, за которым может следовать один или несколько блоков типа
M_DATA
, содержащих прикладные данные, определенные пользователем. Блок
M_PROTO
содержит указатель на очередь чтения потока, который будет обрабатывать запрос. Блок
M_PROTO
содержит следующие поля:
PRIM_type
Тип примитива —
T_CONN_RES
QUEUE_ptr
Указатель на очередь потока, который должен быть использован в качестве узла созданного соединения
OPT_length
Размер опций
OPT_offset
Смещение опций в блоке
M_PROTO
SEQ_number
Идентификатор соединения
T_CONN_CON
M_PROTO
Подтверждение установления связи. Этот примитив применим только для транспортных услуг с предварительным установлением связи. Он отправляется пользователю транспортных услуг в качестве подтверждения установления связи с удаленным пользователем. Сообщение состоит из одного блока
M_PROTO
, за которым может следовать один или несколько блоков типа
M_DATA
, содержащих прикладные данные, определенные пользователем. Блок
M_PROTO
содержит значение размера адреса, сам адрес удаленного пользователя, обслуживающего соединение, а также опции, связанные с этим примитивом. Блок
M_PROTO
содержит следующие поля:
PRIM_type
Тип примитива —
T_CONN_CON
RES_length
Размер адреса протокола
RES_ offset
Смещение адреса удаленного узла в блоке
M_PROTO
OPT_length
Размер опций
ОРТ_offset
Смещение опций в блоке
M_PROTO
Т_DISCON_REQ
M_PROTO
Запрос на разрыв связи. Этот примитив применим только для транспортных услуг с предварительным установлением связи. Он инициируется пользователем транспортных услуг и свидетельствует либо об отказе пользователем в установлении связи, либо о желании пользователя разорвать уже существующее соединение для данного потока. Сообщение состоит из одного блока
M_PROTO
, за которым может следовать один или несколько блоков типа
M_DATA
, содержащих прикладные данные, определенные пользователем. Блок
M_PROTO
содержит следующие поля:
PRIM_type
Тип примитива —
T_DISCON_REQ
SEQ_number
Идентификатор соединения
Т_DISCON_IND
M_PROTO
Индикация разрыва связи. Этот примитив применим только для транспортных услуг с предварительным установлением связи и свидетельствует о том, что удаленный пользователь либо отказывает в установлении связи, либо желает разорвать существующее соединение. Сообщение состоит из одного блока
M_PROTO
, за которым может следовать один или несколько блоков типа
M_DATA
, содержащих прикладные данные, определенные пользователем. Блок
M_PROTO
содержит следующие поля:
PRIM_type
Тип примитива —
T_DISCON_IND
DISCON_reason
Причина разрыва связи
SEQ_number
Идентификатор соединения
Т_ORDREL_REQ
M_PROTO
Запрос на "аккуратное" прекращение связи. Этот примитив применим только для транспортных услуг с предварительным установлением связи и указывает поставщику транспортных услуг, что пользователь завершил передачу данных. При этом соединение переходит в симплексный режим, позволяя пользователю принимать данные от удаленного узла. Сообщение состоит из одного блока
M_PROTO
.
Т_ORDREL_IND
M_PROTO
Индикация "аккуратного" прекращения связи. Этот примитив применим только для транспортных услуг с предварительным установлением связи и отправляется пользователю транспортных услуг, свидетельствуя о том, что удаленный пользователь соединения завершил передачу данных. При этом соединение переходит в симплексный режим, позволяя пользователю передавать данные удаленному узлу. Сообщение состоит из одного блока
M_PROTO
.
T_UNIDATA_REQ
M_PROTO
Запрос на передачу данных. Этот примитив применим только для транспортных услуг без предварительного установления связи и отправляется пользователем транспортных услуг в качестве запроса на передачу дата- граммы. Сообщение состоит из одного блока
M_PROTO
, за которым может следовать один или несколько блоков типа
M_DATA
, содержащих прикладные данные пользователя. Блок
M_PROTO
содержит значение размера адреса и сам адрес получателя датаграммы, а также опции, связанные с этим примитивом. Блок
M_PROTO
содержит следующие поля:
PRIM_type
Тип примитива —
T_UNIDATA_REQ
DEST_length
Размер адреса протокола
DEST_offset
Смещение адреса получателя в блоке
M_PROTO
OPT_length
Размер опций
ОРТ_offset
Смещение опций в блоке
M_PROTO
Т_UNITDATA_IND
M_PROTO
Индикация получения данных. Этот примитив применим только для транспортных услуг без предварительного установления связи и указывает пользователю, что поставщиком транспортных услуг получена датаграмма от удаленного узла. Сообщение состоит из одного блока
M_PROTO
, за которым может следовать один или несколько блоков типа
M_DATA
, содержащих прикладные данные пользователя. Блок
M_PROTO
содержит значение адреса отправителя датаграммы, а также опции, связанные с этим примитивом. Блок
M_PROTO
содержит следующие поля:
PRIM_type
Тип примитива —
T_UNIDATA_IND
SRC length
Размер адреса протокола
SRC_offset
Смещение адреса отправителя в блоке
M_PROTO
OPT_length
Размер опций
ОРТ_offset
Смещение опций в блоке
M_PROTO
T_UDERROR_IND
M_PROTO
Сообщение об ошибке датаграммы. Этот примитив применим только для транспортных услуг без предварительного установления связи и указывает пользователю, что датаграмма с указанным адресом получателя и опциями вызвала ошибку. Сообщение состоит из одного блока
M_PROTO
, содержащего размер адреса и сам адрес получателя, опции, а также код ошибки, зависящий от конкретного транспортного протокола. Блок
M_PROTO
содержит следующие поля:
PRIM_type
Тип примитива —
T_UDERROR_IND
DEST_length
Размер адреса протокола
DEST_offset
Смещение адреса отправителя в блоке
M_PROTO
OPT_length
Размер опций
OPT_offset
Смещение опций в блоке
M_PROTO
ERROR_type
Код ошибки
T_DATA_REQ
M_PROTO
Запрос на передачу данных. Этот примитив применим только для транспортных услуг без предварительного установления связи и информирует поставщика транспортных услуг, что сообщение содержит пакет данных интерфейса (Transport Interface Data Unit, TIDU). Одно или более таких сообщений формируют пакет данных протокола TSDU. Сообщение состоит из одного блока
M_PROTO
, за которым может следовать один или несколько блоков типа
M_DATA
, содержащих прикладные данные пользователя. Блок
M_PROTO
содержит флаг
MORE_flag
, указывающий, является ли следующее сообщение
T_DATA_REQ
частью того же TSDU. На основании этого флага поставщик транспортных услуг компонует транспортные пакеты TSDU. Передача данных с помощью запросов
T_DATA_REQ
позволяет сохранить границы записи при передаче. Заметим, что протоколом TCP данная возможность не поддерживается.
T_DATA_IND
M_PROTO
Индикация получения данных. Этот примитив применим только для транспортных услуг без предварительного установления связи и информирует пользователя, что сообщение содержит пакет данных интерфейса TIDU. Сообщение состоит из одного блока
M_PROTO
, за которым может следовать один или несколько блоков типа
M_DATA
, содержащих прикладные данные удаленного пользователя. Блок
M_PROTO
содержит флаг
MORE_flag
, позволяющий пользователю определить границы TSDU.
Т_EXDATA_REQ
M_PROTO
Запрос на передачу экстренных данных. Этот примитив аналогичен
T_DATA_REQ
, но служит для передачи экстренных данных. Протокол TCP поддерживает передачу экстренных данных с помощью функции t_snd(3N) с аргументом
flags
, содержащим флаг
T_EXPEDITED
и, возможно,
T_MORE
.
T_EXDATA_IND
M_PROTO
Индикация получения экстренных данных. Этот примитив аналогичен
T_DATA_IND
, но служит для передачи пользователю экстренных данных.
T_OK_ACK
M_PCPROTO
Положительное подтверждение. Этот примитив сообщает пользователю транспортных услуг, что предшествующий примитив, инициированный им, был успешно принят поставщиком транспортных услуг. В то же время, получение подтверждения не означает, что поставщиком были совершены какие-либо действия, связанные с предыдущим примитивом. Сообщение состоит из одного блока
M_PCPROTO
в котором хранится тип подтвержденного примитива
CORRECT_prim
.
T_ERROR_ACK
M_PCPROTO
Сообщение об ошибке. Этот примитив сообщает пользователю услуг, последний примитив, инициированный им, вызвал ошибку. Получение этого примитива может рассматриваться как отрицательное подтверждение, свидетельствующее, что никаких действий, связанных с ошибочным примитивом, не было предпринято. Сообщение состоит из одного блока
M_PCPROTO
, содержащего тип примитива, вызвавшего ошибку, код TLI и код системной ошибки UNIX. Блок
M_PCPROTO
содержит следующие поля:
PRIM_type
Тип примитива —
T_ERROR_ACK
ERROR_prim
Тип ошибочного примитива
TLI_error
Код ошибки TLI
UNIX_error
Код системной ошибки UNIX
T_INFO_REQ
M_PCPROTO
Запрос на получение параметров транспортного протокола. Этот примитив служит для запроса пользователем значений размеров различных параметров протокола, а также информации о текущим состоянии поставщика транспортных услуг. Сообщение состоит из одного блока
M_PCPROTO
.
T_INFO_ACK
M_PCPROTO
Параметры транспортного протокола. Этот примитив служит для передачи пользователю ранее запрошенных с помощью
T_INFO_REQ
параметров транспортного протокола. Сообщение состоит из одного блока
M_PCPROTO
, содержащего информацию, часть из которой возвращается функцией t_open(3N), рассмотренной в разделе "Программный интерфейс сокетов" ранее в этой главе. Блок
M_PCPROTO
состоит из следующих полей:
PRIM_type
Тип примитива —
T_INFO_ACK
TSDU_size
Определяет максимальный размер пакета данных протокола TSDU
ETSDU_size
Определяет максимальный размер пакета экстренных данных протокола ETSDU
CDATA_size
Определяет максимальный объем данных, передаваемых при установлении связи. Соответствует полю
connect
структуры
info
функции t_open(3N)
DDATA_size
Определяет максимальный объем данных, передаваемых при разрыве связи. Соответствует полю
discon
структуры
info
функции t_open(3N)
ADDR_size
Определяет максимальный объем транспортного протокола. Соответствует полю
addr
структуры
info
функции t_open(3N)
OPT_size
Определяет размер опций для данного протокола. Соответствует полю
options
структуры
info
функции t_open(3N)
TIDU_size
Определяет размер пакета данных интерфейса TIDU
SERV_type
Определяет тип транспортных услуг, предоставляемых поставщиком. Соответствует полю
servtype
структуры
info
функции t_open(3N)
CURRENT_state
Определяет текущее состояние поставщика транспортных услуг
PROVIDER_flag
Определяет дополнительные характеристики поставщика транспортных услуг
T_OPTMGMT_REQ
M_PROTO
Управление опциями протокола. Этот примитив позволяет пользователю получить или установить опции протокола. Сообщение состоит из одного блока
M_PROTO
, включающего следующие поля:
PRIM_type
Тип примитива —
T_OPTMGMT_REQ
OPT_length
Размер опций
ОРТ_offset
Смещение опций в блоке
M_PROTO
MGMT_flags
Флаги, определяющие характер запроса пользователя:
T_NEGOTIATE
 — установить опции, указанные пользователем. В результате опции, установленные поставщиком, могут отличаться от заказанных;
T_CHECK
 — проверить, поддерживаются ли опции, указанные пользователем, поставщиком;
T_DEFAULT
 — возвратить значения опций протокола.
T_OPTMGMT_ACK
M_PCPROTO
Положительное подтверждение. Этот примитив подтверждает завершение операции с опциями протокола, заказанными пользователем. Сообщение состоит из одного блока
M_PROTO
, включающего те же поля, что и
T_OPTMGMT_REQ
.
вернуться

93

Говоря еще более строго, данные интерфейсы определены самой моделью OSI. Однако в данной главе мы остановимся на практической реализации этих интерфейсов в подсистеме STREAMS.