Системная архитектура. Сетевая архитектура

Сетевая подсистема QNX Neutrino состоит из исполняемого модуля сетевого администратора (io-pkt-v4, io-pkt-v4-hc или io-pkt-v6-hc) и одного или нескольких модулей разделяемых библиотек. Эти модули могут включать в себя протоколы (например, lsm-qnet.so) и драйверы (devnp-speedo.so).

Сетевая подсистема (io-pkt*)

Компонент io-pkt* является исполняемым модулем сетевой подсистемы.

Действуя как своего рода редиректор/мультиплексор пакетов, io-pkt* отвечает за загрузку драйверов и модулей на базе настроек переданных в командной строке (или при помощи команды mount после того, как io-pkt* запущен).

Для реализации архитектуры, исключающей копирование пакетов обрабатываемых данных, исполняемый модуль io-pkt* динамически загружает несколько сетевых протоколов или драйверов (например, lsm-qnet.so) на лету. Эти модули являются разделяемыми библиотеками, которые подключаются к io-pkt*.

Стек io-pkt очень схож по архитектуре с другими подсистемами ОС QNX Neutrino. На нижнем уровне расположены драйверы, которые обеспечивают передачу данных и приём данных от оборудования. Драйвера включаются к многопоточному компоненту второго уровня (который также обеспечивает возможность мостового соединения и ретрансляции), который связывает их вместе и обеспечивает унифицированный интерфейс управления пакетами в компонентах стека, отвечающих за обработку протоколов. Сюда включается, например, обработка индивидуальных протоколов IP и протоколов более высокого уровня, таких как TCP и UDP.

В ОСРВ QNX Neutrino, менеджер ресурсов формирует уровень на вершине стека. Менеджер действует как посредник передачи сообщений между стеком и пользовательскими приложениями. Он предоставляет стандартный тип интерфейса, содержащий функции open(), read(), write() и ioctl(), которые используют поток сообщений для связи с сетевыми приложениями. Пользовательские сетевые приложения слинкованы с библиотекой socket.

Библиотека socket преобразует интерфейс передачи сообщений, предоставляемый стеком стандартный BSD API уровня сокета (BSD socket layer API), являющийся стандартом для большинства современного сетевого кода.

Рис. 12.1. Детализированное представление архитектуры io-pkt.

На уровне драйвера предоставляется интерфейс для Ethernet трафика (который используется всеми Ethernet драйверами), и интерфейс стека для управления кадрами 802.11 от драйверов беспроводных устройств. Вариант стека с суффиксом hc также включает отдельное криптографическое API, которое позволяет стеку использовать криптографическую выгружаемую подсистему, когда он шифрует или дешифрует данные для защищённых каналов. Можно загрузить драйверы (собранные как DLL для динамического связывания с префиксом devnp- для драйверов нового типа и devn- для драйверов старого типа) в стек используя опцию -d при вызове команды io-pkt.

API предоставляющее соединение в потоке данных на Ethernet или IP уровне позволяет протоколам сосуществовать в процессе стека. Протоколы (такие как Qnet) также выполнены в виде DLL. Протокол напрямую соединяется с IP или Ethernet уровнем и запускается в контекстестека. Они начинаются с префикса lsm (loadable shared module, подгружаемый разделяемый модуль) их можно загрузитьв стек используя опцию -p. Протокол tcpip (-ptcpip) специальная опция, которую стек принимает, но которая не используется для загрузки модуля (поскольку IP стек является встроенным). Однако, можно использовать опцию -ptcpip для передачи дополнительных параметров стеку, которые применяются к IP протоколу (например, -ptcpip prefix=/alt указывает IP стеку регистрировать /alt/dev/socket в качестве имени менеджера ресурсов).

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

В дополнение к драйверам и протоколам, стек также включает средства пакетной фильтрации.

Основные интерфейсы, поддерживающие фильтрацию:

Интерфейс пакетного фильтра Беркли (Berkeley Packet Filter, BPF)

Интерфейс уровня сокета, который позволяет читать и писать, но не модифицировать или блокировать пакеты. Интерфейс доступен на уровне приложений (подробнее http://en.wikipedia.org/wiki/Berkeley_Packet_Filter).

Интерфейс стоит выбирать как основу для прослушивания сырых пакетов, приёма и передачи их приложениям вне процесса стека, для предоставления доступа к сырому потоку данных.

Интерфейс пакетного фильтра (Packet Filter, PF)

Интерфейс чтения/записи/модификации/блокирования, который предоставляет полный контроль всех пакетов принимаемых от или передаваемых в верхние уровни, и он более полно соответствует API фильтра io-net.

Для получения дополнительной информации ознакомьтесь с главой «Пакетная фильтрация и сетевые экраны» (Packet Filtering and Firewalling) в электронном документе «QNX Neutrino Core Networking Stack. User’s Guide».

В обычном режиме работы менеджер io-pkt создаёт один поток на процессор. Стек io-pkt полностью многопоточный на уровне 2. Однако, только один поток может получать “контекст стека” для обработки пакетов верхнего уровня. Если множество источников прерывания требуют обслуживания в одно время, они могут быть обслужены несколькими потоками. Только один поток будет обслуживать конкретное прерывание в любой момент времени. Обычно прерывание от сетевого устройства указывает, что были получены пакеты данных. Поток, который отвечает за приём, может позже передать принятые пакеты другому интерфейсу. Примером может служить мост второго уровня.

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

• события, генерируемые стеком или модулями протоколов

Приоритет, на котором поток запускается для приёма пакетов, может быть установлен при помощи опции командной строки. Клиентские соединения запрашивают обслуживание с плавающим режимом приоритета (т.о. приоритет потока равен тому, на котором поток пользовательской программы получает доступ к стеку менеджера ресурсов).

Когда поток получает событие, он исследует тип события чтобы определить, что это – аппаратное событие, событие стека или “другое” событие:

Если происходит аппаратное событие, устройство обслуживается, а поток определяет, что требуется для приема пакетов - мостовое соединение или быстрая переадресация (fast-forwarding). В этом случае поток выполняет соответствующий поиск, чтобы определить, к какому интерфейсу пакет должен быть поставлен в очередь, затем передает его, после чего поток проверяет, не произошло ли новых аппаратных событий.

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

Как только поток завершил обслуживание оборудования, он проверяет, не требуется ли обработка событий стека, которые могли произойти в результате предыдущих действий. Если обработка не требуется, поток запускает цикл обработки событий стека. Затем он переходит в состояние "ожидание событий" в пуле потоков.

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

Модуль сетевого протокола

Модуль сетевого протокола отвечает за реализацию того или иного сетевого протокола (например, Qnet, TCP/IP и т. д.). Все компоненты протоколов исполняются как разделяемые объекты (например, npm-qnet.so) и могут работать одновременно.

Например, следующая строка из файла построения образа (buildfile) показывает, что модуль io-pkt-v4 загружает два протокола (TCP/IP и Qnet) с помощью аргумента командной строки -p протокол:

Протокол Qnet также поддерживает политики качества обслуживания QoS (Quality of Service) для обеспечения надежности передачи данных.

Более подробные сведения о протоколах Qnet и TCP/IP можно найти в главах 13 и 14.

Драйверный модуль

Модуль сетевого драйвера отвечает за управление сетевым адаптером (например, NE-2000-совместимый контроллер сети Ethernet). Каждый драйвер реализуется как разделяемый объект и устанавливается в компонент io-pkt*.

Загрузка и выгрузка драйвера

После запуска модуля io-pkt*можно динамически загружать драйверы из командной строки с помощью команды mount. Например, следующая команда запускает io-pkt-v6-hc и затем монтирует драйвер адаптеров Broadcom 57xx:

После загрузки данного разделяемого объекта модуль io-pkt* инициализирует его, при этом запущенный драйвер и модуль io-pkt* оказываются фактически скомпонованы между собой; драйвер вызывает модуль io-pkt* (например, при получении пакетов данных от интерфейса), а тот, в свою очередь, вызывает драйвер (например, при передаче пакетов данных от приложения интерфейсу).

Для выгрузки драйвера используется команда umount:

12. Сетевая архитектура