Операционная система UNIX
Шрифт:
Второй таймер — это persist-таймер (таймер сохранения). Этот таймер обеспечивает защиту от потери управляющих сообщений, содержащих значения окна. В случае, если отправитель готов передать данные, но анонсированное получателем окно слишком мало (равно нулю или меньше определенного значения), и отсутствуют неподтвержденные данные (т. е. таймер повторной передачи не включен), включается таймер сохранения. Если таймер срабатывает (его значение становится равным нулю), а обновленное значение так и не получено, отправитель передает максимально допустимый объем данных, определяемый текущим окном. Если же в этом случае значение текущего окна равно нулю (нулевое окно), то передается пробный сегмент (window probe), содержащий один октет данных, и таймер запускается снова. Если сообщение с обновленным значением окна было утеряно, или получатель по-прежнему отказывается изменить его размер, будет получено подтверждение, содержащее текущее значение окна. Такая ситуация, когда получатель не может принимать дополнительные данные, может продлиться достаточно долго. Например, пользователь может приостановить терминальный вывод и уйти на обед. В этом случае отправитель будет периодически посылать пробные сегменты, а его окно будет по-прежнему закрыто.
Следующий таймер, который мы рассмотрим, — keepalive-таймер. Этот таймер предназначен для мониторинга каналов, по которым не передаются данные, и которые возможно в действительности прекратили свое существование, например, из-за аварийного останова одной из систем. Если за определенный промежуток времени данные по каналу переданы не были, модуль TCP отправляет пробный сегмент keepalive, ожидая в ответ либо подтверждения (это означает, что задержка в передаче данных временная), либо сообщения сброса канала (
Последний таймер из рассматриваемых, это 2MSL-таймер (2MSL — двойное максимальное время жизни сегмента в сети). Модуль TCP запускает этот таймер, когда производится завершение связи, и уже отправлено подтверждение полученному сегменту
Поддержка сети в UNIX System V
Многие из аспектов реализации поддержки сети в BSD UNIX справедливы и для архитектуры сетевых протоколов UNIX System V. Однако сам механизм обеспечения взаимодействия модулей существенно отличается. Для поддержки сети в UNIX System V используется подсистема STREAMS, рассмотренная в главе 5.
Подсистема ввода/вывода, основанная на архитектуре 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. Интерфейсы взаимодействия модулей протоколов
93
Говоря еще более строго, данные интерфейсы определены самой моделью OSI. Однако в данной главе мы остановимся на практической реализации этих интерфейсов в подсистеме STREAMS.
Интерфейс TPI
TPI представляет собой интерфейс предоставления услуг транспортного уровня OSI модели как с предварительным установлением соединения (connection mode), так и без установления соединения (connectionless mode). Стандартизация этого интерфейса позволяет изолировать особенности реализации транспортного уровня от потребителя этих услуг и, тем самым, предоставить возможность разработки программного обеспечения, независимо от конкретного протокола и услуг им предоставляемых.
TPI определяет набор и формат сообщений, с помощью которых протоколы верхнего уровня взаимодействуют с модулем транспортного протокола. Таким образом, TPI является интерфейсом между поставщиком транспортных услуг (transport provider) и пользователем этих услуг (transport user). Эти сообщения определяют транспортные примитивы (transport primitive), или команды, и могут иметь следующий формат:
Сообщение состоит из блока типа
Сообщение состоит из одного блока
Сообщение состоит из одного или более блоков
Таблица 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 . |
Взаимодействие с прикладными процессами
Рассмотренный ранее программный интерфейс TLI полностью реализует функциональность TPI. Легко заметить соответствие между отдельными функциями TLI и примитивами TPI, приведенными в табл. 6.10. Схема вызова функций TPI и обмена соответствующими примитивами TPI между клиентом и сервером для типичного TCP-сеанса приведена на рис. 6.32.
Рис. 6.32. Функции TLI и примитивы TPI