А. Робачевский - Операционная система UNIX (1114671), страница 67
Текст из файла (страница 67)
По мере увеличения скоростей передачи,посимвольная обработка и передача стала неэффективной. Поэтому былразработан ряд подходов для обеспечения буферизации, например исполь!зование механизма, основанного на структурерассмотренного на!ми ранее. Однако такие схемы, по!прежнему обладая невысокой произво!дительностью, по существу возлагают буферизацию данных на драйвер,что приводит к неэффективному распределению памяти.Наконец, необходимость поддержки сетевых протоколов, большинство изкоторых имеют уровневую организацию, требует соответствующей архи!тектуры подсистемы ввода/вывода. Передача сетевых данных производитсяв виде пакетов или сообщений, при этом каждый уровень сетевого прото!кола производит определенную обработку и передает их другому уровню.Каждый уровень имеет стандартные интерфейсы взаимодействия с други!ми (верхним и нижним уровнями) и при этом может работать с различ!ными протоколами верхнего и нижнего уровней.
Например, протокол IP(уровень 3 модели OSIможет поддерживать работу нескольких протоко!лов верхнего уровня: TCP и UDP. На нижнем уровне протокол IP такжевзаимодействует с несколькими протоколами, обеспечивая передачу дан!ных через различные сетевые интерфейсы (например, Ethernet, Token RingOS1 иерархии сетевых протоколов, предложенная Международной организациейпо стандартам (ISO), включает определение функциональности для 7 уровней. Различныесемейства протоколов, например TCP/IP или SNA, имеют то или иное отображение наэту модель. Эти вопросы рассмотрены в главе 6.www.books-shop.com352Глава 5.или последовательный канал).
Такая организация сетевых протоколовпредполагает иерархическую структуру подсистемы ввода/вывода, когдадрайверы являются объединением независимых модулей.Подсистема STREAMS в большой степени призвана решить эти задачи.Она предоставляет интерфейс обмена данными, основанный на сообще!ниях, и обеспечивает стандартные механизмы буферизации, управленияпотоком данных и различную приоритетность обработки.
В STREAMSдублирование кода сводится к минимуму, поскольку однотипные функцииобработки реализованы в независимых модулях, которые могут быть ис!пользованы различными драйверами. Сам драйвер обеспечивает требуемуюфункциональность, связывая в цепочку один или несколько модулей, по!добно тому как программный канал позволяет получить новое качествообработки, связав несколько независимых утилит.Сегодня подсистема STREAMS поддерживается большинством производи!телей операционных систем UNIX и является основным способом реали!зации сетевых драйверов и модулей протоколов.
Использование STREAMSохватывает и другие устройства, например терминальные драйверы вUNIX SVR4.Архитектура STREAMSПодсистема STREAMS обеспечивает создание потоков — полнодуплекс!ных каналов между прикладным процессом и драйверомСдругой стороны, архитектура STREAMS определяет интерфейсы и наборправил, необходимых для взаимодействия различных частей этой системыи для разработки модульных драйверов, обеспечивающих такое взаимодей!ствие и обработку.На рис. 5.13 показана общая архитектура коммуникационного канала меж!ду процессом и драйвером STREAMS.
Сам поток полностью располагаетсяв пространстве ядра, соответственно и все функции обработки данных вы!полняются в системном контексте. Типичный поток состоит из головногомодуля, драйвера и, возможно, одного или более модулей. Головной мо!дуль взаимодействует с прикладными процессами через интерфейс сис!темных вызовов. Драйвер, замыкающий поток, взаимодействует непосред!ственно с физическим устройством или псевдоустройством, в качестве ко!торого может выступать другой поток. Модули выполняют промежуточнуюобработку данных.Процесс взаимодействует с потоком, используя стандартные системныевызовыи ioctl(2). Дополнительные функ!Потоковый драйвер (драйвер STREAMS) имеет архитектуру, отличную от архитектурыдрайверов символьных устройств, рассмотренных ранее.www.books-shop.comSTREAMS353ции работы с потоками включают poll(2),иПередачаданных по потоку осуществляется в виде сообщений, содержащих данные,тип сообщения и управляющую информацию. Для передачи данных каж!дый модуль, включая головной модуль и сам драйвер, имеет две очереди —очередь чтения (read queue) и очередь записи (write queue).
Каждый модульобеспечивает необходимую обработку данных и передает их в очередь сле!дующего модуля. При этом передача в очередь записи осуществляется внизпо потоку (downstream), а в очередь чтения — вверх по потоку (upstream).Например, на рис. 5.13 из очереди записи модуля 2 сообщение может бытьпередано в очередь записи модуля 1, но не наоборот. В свою очередь со!общение из очереди чтения модуля 2 передается в очередь чтения голов!ного модуля, который далее передает данные процессу в ответ на систем!ный вызовКогда процесс выполняет системный вызовданные передаются головному модулю и далее вниз по потоку.Рис. 5.13.
Базовая архитектура потокаСообщения также могут передаваться в парную очередь. Другими словами,из очереди записи модуля 1 сообщение может быть направлено в очередьwww.books-shop.com354Глава 5.чтения того же модуля, а затем, при необходимости, передано вверх попотоку. При этом модулю нет необходимости знать, какой части потокапринадлежит следующая очередь — головному или промежуточному моду!лю, или драйверу.
Такой подход позволяет производить разработку моду!лей независимо друг от друга и использовать их затем в различных комби!нациях и в различных потоках.Подсистема STREAMS обеспечивает возможность такой комбинации бла!годаря механизму динамического встраивания (push) модуля в поток.Встраивание модуля возможно непосредственно после головного модуля.При этом будут установлены связи между соответствующими очередямивстраиваемого модуля, головного модуля и модулей вниз по потоку.
Послеэтого встроенный модуль будет производить определенную обработку про!ходящих данных, тем самым изменяя изначальную функциональность по!тока. При необходимости модуль может быть извлечен (pop) из потока.На рис. 5.14 показаны различные потоки, созданные из нескольких стан!дартных компонентов, для поддержки сетевых протоколов семействаTCP/IP. Причем модули IP, TCP и UDP могут поставляться одним произ!водителем, а драйверы Ethernet или Token Ringсоответствующими про!изводителями сетевых адаптеров. В результате встраивания необходимыхмодулей первый поток будет обеспечивать передачу трафика TCP черезадаптер Ethernet, в то время как второй — передачу трафикачерезадаптер Token Ring.Рис.
5.14. Использованиеодних и тех же модулей длясоздания различных пото%ковwww.books-shop.comSTREAMS355Подсистема STREAMS также обеспечивает возможность мультиплексиро!вания потоков. Мультиплексирующий драйвер может быть подключен кнескольким модулям как вверх, так и вниз по потоку. Различают три типамультиплексоров — верхний, обеспечивающий мультиплексирование вверхпо потоку,обеспечивающий мультиплексирование вниз по пото!ку, иподдерживающий несколько потоков выше и ниже муль!типлексора.С помощью мультиплексирующих драйверов потоки, представленные нарис. 5.14, могут быть объединены в единый драйверподдержи!вающий несколько каналов передачи данных.
Именно таким образом реа!лизована поддержка сети во многих версиях операционной системы UNIX.Возможная организация компонентов STREAMS приведена на рис. 5.15.Рис.Конфигура%ция сетевого доступа сиспользованием под%системы STREAMSВ этом случае модули TCP и UDP являются верхними мультиплексорами,а модуль IP реализован в виде гибридногоТакая органи!зация позволяет приложениям создавать потоки, используя различныекомбинации сетевых протоколов и драйверов сетевых устройств. ЗадачаНа самом деле мультиплексором может являться только драйвер STREAMS. Объединениедрайверов в единый объект отлично от встраивания модулей и носит названиеподробнои различия между модулями и драйверами STREAMS мы рас!смотрим несколько позже в этой главе.www.books-shop.comГлава 5.356мультиплексирующего драйвера помимо обработки данных заключается вхранении состояния всех потоков и правильной маршрутизации данныхмежду ними, т.
е. передаче данных в очередь требуемого модуля.МодулиМодули являются основными компонентами потока. Каждый модуль со!стоит из пары очередей — очереди чтения и записи, а также набора функ!ций, осуществляющих обработку данных и их передачу вверх или вниз попотоку.
Архитектура модуля представлена на рис. 5.16.Рис. 5.16. Модуль STREAMSочередь представлена структурой данных queue. Наиболее важны!ми полями queue являются:q qinfoq first, q lastq nextУказатель на структуру qinit, описывающую функцииобработки сообщений данной очереди.Указатели на связанный список сообщений, ожидающихпередачи вверх или вниз по потоку.Указатель на очередь следующего модуля вверх или внизпо потоку.Указатель на внутренние данные модуля (очереди).www.books-shop.comПодсистема357Помимо указанных полей, структура queue содержит параметры для обес!печения управления потоком данных — верхнюю и нижнюю ватерлинииочереди.Передача данных вверх или вниз по потоку осуществляется с помощьюфункций модуля, указатели на которые хранятся в структуре qinit.
Мо!дуль должен определить четыре процедуры для обработки каждой из оче!редей: xxputи xxcloseгде хх, как и пре!жде, обозначает уникальный префикс драйвера. Эти функции адресуютсяуказателями(*qi_putp)(*qi_srvp)(*qi_qopen)Этих четырех функций достаточно для взаимодействия ссоседними модулями, обработки и передачи данных.Функцияxxopen вызывается каждый раз, когда процесс открывает поток или привстраивании модуля.
Соответственно функция(} вызывается призакрытии потока или извлечении модуля. Функция xxputосуществляетобработку сообщений, проходящих через модуль. Если xxputне можетпередать сообщение следующему модулю (например, в случае, если оче!редь следующего модуля переполнена), она помещает сообщение в собст!венную очередь.
Периодически ядро вызывает процедуру()каждого модуля для передачи отложенных сообщений.Модуль должен иметь функцию xxputдля каждой очереди. Функция(} может не существовать, в этом случае xxput () не имеетвозможности отложить передачу сообщения и должна передать его немед!ленно, даже если очередь следующего модуля переполнена. Таким образоммодули, не имеющие процедурне обладают возможностьюуправления потоком данных. Эти аспекты мы подробнее рассмотрим вследующих разделах.Оставшиеся поля структуры qinit:В этой структуре хранятся базовые значения таких парамет%ров, как ватерлинии, размер сообщений и т. д. Некоторые изэтих параметров также находятся в структуре queue.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
