Следующий таймер, который мы рассмотрим, — keepalive-таймер. Этот таймер предназначен для мониторинга каналов, по которым не передаются данные, и которые возможно в действительности прекратили свое существование, например, из-за аварийного останова одной из систем. Если за определенный промежуток времени данные по каналу переданы не были, модуль TCP отправляет пробный сегмент keepalive, ожидая в ответ либо подтверждения (это означает, что задержка в передаче данных временная), либо сообщения сброса канала (
RST
RST
Последний таймер из рассматриваемых, это 2MSL-таймер (2MSL — двойное максимальное время жизни сегмента в сети). Модуль TCP запускает этот таймер, когда производится завершение связи, и уже отправлено подтверждение полученному сегменту
FIN
FIN
Поддержка сети в 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)).
Рис. 6.30. Реализация протоколов TCP/IP на основе архитектуры STREAMS
Анализ программного обеспечения сетевой поддержки показывает, что как правило сетевые и транспортные протоколы, составляющие базовый стек TCP/IP, поставляются одним производителем, в то время как поддержка уровней сетевого интерфейса и приложений может осуществляться продуктами различных разработчиков. Соответственно, можно выделить два основных интерфейса взаимодействия, стандартизация которых позволяет обеспечить совместную работу различных компонентов программного обеспечения. Первый интерфейс определяет взаимодействие транспортного уровня и уровня приложений и называется интерфейсом поставщика транспортных услуг (Transport Provider Interface, TPI). Второй интерфейс устанавливает правила и формат сообщений, передаваемых между сетевым уровнем и уровнем сетевого интерфейса, и называется интерфейсом поставщика услуг канала данных (Data Link Provider Interface, DLPI).
Вообще говоря, сетевая архитектура, основанная на архитектуре STREAMS, позволяет обеспечить поддержку любого стека протоколов, соответствующего модели OSI. Поэтому выражаясь более точно, перечисленные интерфейсы определяют взаимодействие транспортного уровня и уровня сеанса, и уровня канала и сетевого уровня, соответственно. Эти рассуждения проиллюстрированы на рис. 6.31.[93]
Рис. 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 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 T_DATA_REQ | |
T_DATA_IND | M_PROTO | Индикация получения данных. Этот примитив применим только для транспортных услуг без предварительного установления связи и информирует пользователя, что сообщение содержит пакет данных интерфейса TIDU. Сообщение состоит из одного блока M_PROTO M_DATA M_PROTO MORE_flag | |
Т_EXDATA_REQ | M_PROTO | Запрос на передачу экстренных данных. Этот примитив аналогичен T_DATA_REQ 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 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 M_PCPROTO | |
PRIM_type | Тип примитива — T_INFO_ACK | ||
TSDU_size | Определяет максимальный размер пакета данных протокола TSDU | ||
ETSDU_size | Определяет максимальный размер пакета экстренных данных протокола ETSDU | ||
CDATA_size | Определяет максимальный объем данных, передаваемых при установлении связи. Соответствует полю connect info | ||
DDATA_size | Определяет максимальный объем данных, передаваемых при разрыве связи. Соответствует полю discon info | ||
ADDR_size | Определяет максимальный объем транспортного протокола. Соответствует полю addr info | ||
OPT_size | Определяет размер опций для данного протокола. Соответствует полю options info | ||
TIDU_size | Определяет размер пакета данных интерфейса TIDU | ||
SERV_type | Определяет тип транспортных услуг, предоставляемых поставщиком. Соответствует полю servtype info | ||
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.