Андрей Робачевский - Операционная система UNIX

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

Многие из аспектов реализации поддержки сети в 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] Говоря еще более строго, данные интерфейсы определены самой моделью OSI. Однако в данной главе мы остановимся на практической реализации этих интерфейсов в подсистеме STREAMS.

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

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