Архитектура STREAMS

Архитектура STREAMS

Подсистема STREAMS обеспечивает создание потоков — полнодуплексных каналов между прикладным процессом и драйвером устройства[57]. С другой стороны, архитектура STREAMS определяет интерфейсы и набор правил, необходимых для взаимодействия различных частей этой системы и для разработки модульных драйверов, обеспечивающих такое взаимодействие и обработку.

На рис. 5.13 показана общая архитектура коммуникационного канала между процессом и драйвером STREAMS. Сам поток полностью располагается в пространстве ядра, соответственно и все функции обработки данных выполняются в системном контексте. Типичный поток состоит из головного модуля, драйвера и, возможно, одного или более модулей. Головной модуль взаимодействует с прикладными процессами через интерфейс системных вызовов. Драйвер, замыкающий поток, взаимодействует непосредственно с физическим устройством или псевдоустройством, в качестве которого может выступать другой поток. Модули выполняют промежуточную обработку данных.

Рис. 5.13. Базовая архитектура потока

Процесс взаимодействует с потоком, используя стандартные системные вызовы open(2), close(2), read(2), write(2) и ioctl(2). Дополнительные функции работы с потоками включают poll(2), putmsg(2) и getmsg(2). Передача данных по потоку осуществляется в виде сообщений, содержащих данные, тип сообщения и управляющую информацию. Для передачи данных каждый модуль, включая головной модуль и сам драйвер, имеет две очереди — очередь чтения (read queue) и очередь записи (write queue). Каждый модуль обеспечивает необходимую обработку данных и передает их в очередь следующего модуля. При этом передача в очередь записи осуществляется вниз по потоку (downstream), а в очередь чтения — вверх по потоку (upstream). Например, на рис. 5.13 из очереди записи модуля 2 сообщение может быть передано в очередь записи модуля 1, но не наоборот. В свою очередь сообщение из очереди чтения модуля 2 передается в очередь чтения головного модуля, который далее передает данные процессу в ответ на системный вызов read(2). Когда процесс выполняет системный вызов write(2), данные передаются головному модулю и далее вниз по потоку.

Сообщения также могут передаваться в парную очередь. Другими словами, из очереди записи модуля 1 сообщение может быть направлено в очередь чтения того же модуля, а затем, при необходимости, передано вверх по потоку. При этом модулю нет необходимости знать, какой части потока принадлежит следующая очередь — головному или промежуточному модулю, или драйверу. Такой подход позволяет производить разработку модулей независимо друг от друга и использовать их затем в различных комбинациях и в различных потоках.

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

На рис. 5.14 показаны различные потоки, созданные из нескольких стандартных компонентов, для поддержки сетевых протоколов семейства TCP/IP. Причем модули IP, TCP и UDP могут поставляться одним производителем, а драйверы Ethernet или Token Ring соответствующими производителями сетевых адаптеров. В результате встраивания необходимых модулей первый поток будет обеспечивать передачу трафика TCP через адаптер Ethernet, в то время как второй — передачу трафика UDP через адаптер Token Ring.

Рис. 5.14. Использование одних и тех же модулей для создания различных потоков

Подсистема STREAMS также обеспечивает возможность мультиплексирования потоков. Мультиплексирующий драйвер может быть подключен к нескольким модулям как вверх, так и вниз по потоку. Различают три типа мультиплексоров — верхний, обеспечивающий мультиплексирование вверх по потоку, нижний, обеспечивающий мультиплексирование вниз по потоку, и гибридный, поддерживающий несколько потоков выше и ниже мультиплексора.

С помощью мультиплексирующих драйверов потоки, представленные на рис. 5.14, могут быть объединены в единый драйвер протоколов, поддерживающий несколько каналов передачи данных. Именно таким образом реализована поддержка сети во многих версиях операционной системы UNIX. Возможная организация компонентов STREAMS приведена на рис. 5.15.

Рис. 5.15. Конфигурация сетевого доступа с использованием подсистемы STREAMS

В этом случае модули TCP и UDP являются верхними мультиплексорами, а модуль IP реализован в виде гибридного мультиплексора[58]. Такая организация позволяет приложениям создавать потоки, используя различные комбинации сетевых протоколов и драйверов сетевых устройств. Задача мультиплексирующего драйвера помимо обработки данных заключается в хранении состояния всех потоков и правильной маршрутизации данных между ними, т. е. передаче данных в очередь требуемого модуля.

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг

13 Открытая архитектура

Из книги Человеческий фактор в программировании автора Константин Ларри Л

13 Открытая архитектура Многие думают, что есть только два типа людей: мы, знающие все лучше других, и остальные, отличные от нас. То же самое можно сказать о работе в организациях. Некоторые люди думают, что есть только два выбора: приказная власть или необузданная анархия.


32 Re: Архитектура

Из книги Серверные технологии хранения данных в среде Windows® 2000 Windows® Server 2003 автора Дайлип Наик

32 Re: Архитектура Что произошло с архитектурой программного обеспечения? В типичном приложении для малого бизнеса или в стандартном коммерческом пакете зачастую бывает трудно обнаружить присутствие хоть какой-то структуры. Архитектура — будь то внутренняя


1.3 Архитектура Windows NT

Из книги TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security) автора Фейт Сидни М


Глава 3 Архитектура TCP/IP

Из книги Инфраструктуры открытых ключей автора Полянская Ольга Юрьевна

Глава 3 Архитектура TCP/IP 3.1 Введение Протоколы TCP/IP разработаны для сетевого окружения, которое было мало распространено в 70-х гг., но сегодня стало нормой. Эти протоколы позволяют соединять оборудование различных производителей и способны работать через различные типы


3.6 Архитектура TCP

Из книги Полное руководство по Microsoft Windows XP автора Нортон Питер

3.6 Архитектура TCP TCP реализуется на хостах. Наличие TCP на каждом конце соединения обеспечивает для доставки данных локального приложения следующие возможности:? Точность? Сохранение последовательности? Полноту? Исключение дублированияБазовый механизм для реализации


3.7 Архитектура UDP

Из книги Операционная система UNIX автора Робачевский Андрей М.

3.7 Архитектура UDP UDP реализуется на хостах. Протокол не обеспечивает целостности доставки данных, поскольку эта функция возлагается на обменивающиеся данными приложения. Именно они проверяют целостность доставляемых данных.Приложение, которое хочет переслать данные с


18.5 Архитектура gopher

Из книги UNIX: разработка сетевых приложений автора Стивенс Уильям Ричард

18.5 Архитектура gopher Внутренняя структура gopher очень проста. На рис. 18.3, показано, как клиент соединяется с сервером gopher, извлекает меню или файл и закрывает соединение. Выбранный элемент выводится на монитор пользователя. При работе с меню или файлом пользователь уже не


19.7 Архитектура HTTP

Из книги Идеальный программист. Как стать профессионалом разработки ПО автора Мартин Роберт С.

19.7 Архитектура HTTP Как и в gopher, извлечение гипертекстового документа достаточно просто. Как показано на рис. 19.3, клиент соединяется с сервером WWW, извлекает часть документа (обычно ее называют страницей. — Прим. пер.) и закрывает соединение. Браузер выводит извлеченную


Простая архитектура PKI

Из книги автора

Простая архитектура PKI Архитектура PKI может быть очень простой, если у пользователей - простые требования. В этом разделе рассматриваются два типа простой архитектуры: одиночный УЦ и списки доверия УЦ. Простая архитектура достаточна для связывания пользователей одного и


Архитектура корпоративной PKI

Из книги автора

Архитектура корпоративной PKI В корпоративной PKI отношения доверия устанавливаются между удостоверяющими центрами одной и той же организации. Организация может быть компанией, государственным предприятием, федеральным агентством или сообществом пользователей. В


11. Архитектура Windows XP

Из книги автора

11. Архитектура Windows XP Изучение новой операционной системы обычно включает в себя последовательный анализ компонентов ее архитектуры. Но к этому вопросу можно подойти и с другой стороны. Когда речь заходит о квалифицированном автомеханике, ожидается, что он неплохо


Подсистема STREAMS

Из книги автора

Подсистема STREAMS Архитектура подсистемы потокового ввода/вывода STREAMS впервые была описана в статье Ритчи "Потоковая система ввода/вывода" (Ritchie, D.M., "A Stream Input-Output System", AT&T Bell Laboratories Technical Journal, Vol. 63, No. 8, Oct. 1984) в 1984 году. Двумя годами позднее эта система была реализована в


Архитектура TCP/IP

Из книги автора

Архитектура TCP/IP Архитектура семейства протоколов TCP/IP основана на представлении, что коммуникационная инфраструктура включает три объекта: процессы, хосты, и сети. Процессы являются основными коммуникационными объектами, поскольку между процессами, в конечном итоге,


Внутренняя архитектура

Из книги автора

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


Глава 31 Потоки (STREAMS)

Из книги автора

Глава 31 Потоки (STREAMS) 31.1. Введение В этой главе мы приводим обзор потоков STREAMS и функций, используемых приложением для доступа к потоку. Наша цель — понять, как реализованы сетевые протоколы в рамках потоковых систем. Также мы создаем простой клиент TCP с использованием TPI —


Архитектура

Из книги автора

Архитектура Если вы соблюдаете три закона и пишете тесты раньше рабочего кода, вы сталкиваетесь с дилеммой. Часто вы точно знаете, какой код нужно написать, но три закона приказывают сначала написать модульный тест, который не пройдет, потому что код еще не существует!