
- •Введение
- •1. Основные понятия в операционных системах
- •1.1. Классификация и функции операционных систем
- •1.2. Ос общего назначения и реального времени
- •1.3. Выполнение команд в вычислительной системе
- •1.4. Прерывания
- •1.5 Архитектуры операционных систем
- •1.6. Управление оперативной памятью вычислительной системы
- •1.7. Общие сведения о процессах и потоках
- •2. Операционная система windows
- •2.1. Версии операционной системы Windows
- •2.2. Архитектура операционной системы windows
- •2.3. Процессы и потоки в Windows
- •2.4. Взаимодействие процессов
- •2.5. Управление потоками в Windows
- •2.6. Файловые системы Windows
- •2.7. Установка и последовательность загрузки Windows
- •Последовательность загрузки Windows xp
- •2.8. Интерпретатор команд и пакетные файлы
- •2.9. Конфигурирование Windows
- •3. Операционная система qnx neutrino
- •3.1. Версии операционной системы qnx Neutrino
- •3.2. Архитектура операционной системы qnx Neutrino
- •3.3. Процессы в qnx6
- •Завершение процесса
- •3.4. Потоки в qnx6
- •Завершение потока
- •3.5. Управление потоками и процессами в qnx6
- •Механизмы ipc
- •Средства синхронизации в qnx
- •3.6. Файловые системы qnx
- •Типы файлов
- •3.7. Инсталляция и последовательность загрузки qnx
- •3.8. Интерпретаторы команд и пакетные файлы в qnx
- •3.9. Конфигурирование qnx
- •4. Виртуальные машины
- •4.1. Общие сведения о виртуальных машинах
- •4.2. Работа с виртуальной машиной VmWare
- •5. Защита от сбоев и несанкционированного доступа
- •5.1. Принципы построения систем безопасности
- •5.2. Безопасность операционной системы windows
- •6. Сетевые возможности операционных систем
- •6.1. Аппратаное обеспечение локальных сетей
- •6.2. Сети Windows
- •6.3. Локальная сеть на основе qnet
- •6.4. Глобальные сети
- •7. Многопроцессорные системы
- •7.1. Архитектуры многопроцессорных операционных систем
- •7.2. Принципы функционирования smp
- •7.3. Принципы функционирования кластеров
- •Список использованной литературы
- •Компилятор
6.3. Локальная сеть на основе qnet
Сетевая подсистема QNX
ОС QNX Neutrino –система изначально сетевая, однако сетевые механизмы ,как и все остальное, реализованы в виде дополнительных администраторов ресурсов. Хотя некоторая поддержка сети есть в микроядре –способ адресации QNX-сообщений обеспечивает возможность передачи их по сети.
Структура сетевой подсистемы QNX
В центре реализации сетевой подсистемы QNX Neutrino находится Администратор сетевого ввода-вывода io-net. Процесс io-net при старте регистрирует префикс каталога / dev/ io-net и загружает необходимые администраторы сетевых протоколов и аппаратные драйверы [15]. Протоколы, драйверы и другие необходимые компоненты загружаются либо в соответствии с аргументами командной строки,заданными при запуске io-net, либо в любое время командой монтирования mount.
Загрузка разделяемых библиотек:
Администратор стека TCP/IP- npm-tcpip.so
Администратор протоко Qnet- npm-qnet.so
Драйвер сетевых адаптеров AMD PCNET-devn-pcnet.so
Следующая команда запускает поддрежку сети с драйвером сетевого адаптера NE2000 и с поддержкой протоколов TCP/IP и Qnet:
io-net -dne2000 –ptcpip –pqnet
Драйверы сетевого адаптера. Администратор сетевого адаптера ввода/вывода io-net сообщает драйверу, когда он может забрать данные из какого-то буфера для передачи в физическую среду, и принимает от драйвера уведомление о поступлении данных из физической среды в какой-то буфер.
Администратор сетевого протокола. Администратор сетевого ввода/вывода io-net сообщает администратор протокола ,когда можно забрать данные из какого-то буфера для передачи в приложение, и принимает от администратора протокола уведомление о готовности данных в каком-то буфере для отправки во внешний мир.
Фильтр. Фильтр может быть восходящего и нисходящего типа. Фильтр сообщает свой тип и между какими модулями он хочет хозяйничать. Администратор io-net сообщает восходящему фильтру, когда можно забрать данные их какого-то буфера драйвера, и принимает от восходящего фильтра уведомление о готовности данных для считывания администратором протокола. Нисходящий фильтр работает с точностью донаоборот. Пример входящего фильтра-firewall, нисходящего фильтра-NAT.
Конвертор – модуль для инкапсуляции/деинкапсуляции данных при передаче их между уровнями.
Отключить поддержку какого-либо протокола, выгрузив соответствующую DLL, в QNX Neutrino 6.3.0 нельзя, но в QNX Neutrino 6.3.0 можно все-таки выгружать драйвер Ethernet:
umount /dev/io-net/en0
Для получения диагностической и статистической информации о работе сетевой карты предназначена утилита nicinfo, по умолчании. Эта утилита обращается к устройству /dev/io-net/en0.Для адаптеров nicinfo выводит наименование модели контроллера .
QNX-сеть- Qnet. Задача протокола Qnet – превратить сеть из машин под управлением QNX Neutrino в некое подобие единого распределенного компьютера. В составе дистрибутива поставляется две версии администраторов Qnet:
Npm-qnet-compact.so- полнофункциональная версия Qnet, полностью совместимая с Qnet, использовавшаяся в версии QNX Neutrino 6.2.х;
Npm-qnet-14_lite.so-‘облегченная’ версия Qnet, появившаяся в версии QNX Neutrino 6.3.0
Сетевая прозрачность QNX достигается тем, что администраторы Qnet,работающие на разных ЭВМ, организуют как бы мост между своими микроядрами. Микроядро, когда видит, что у адресата сообщения дескриптор узла не равен нулю, отдает это сообщение Администратору Qnet. Администратор Qnet засылает это сообщение администратору Qnet указанного узла. Администратору Qnet узла на стороне получателя отправляет сообщение собственно получателю (рис. 68).
Рис.68 Резервируемая Сеть QNet
В QNX Neutrino узел имеет фиксированное имя, а дескриптор ND назначается ему способом, напоминающим назначение файлового дескриптора при открытии файла. ND=0 всегда обозначает локальный узел (ядро не будет передавать администратору сети сообщение, содержащее ND=0, а сразу направит это сообщение потоку-адресату ).
Существует два способа определения ND при известном имени узла-адресата сообщения:
Первый способ заключается в использовании функции netmgr_strtond (), определяющей ND по имени узла. Недостаток этого способа очевиден – он платформозависимый. Поэтому чаще применяют второй способ.
Второй способ основан на использовании пространства путевых имен Администратора процессов. При загрузке и инициализации Администратор протокола Qnet npm-qnet.so регистрирует не только символьное устройство /dev/io-net/qnet_en ,но и префикс каталога /net, в котором размещаются папки, имена которых совпадают с именами узлов сети. Эти папки-узлы соответствуют корневым каталогам одноименных узлов. Таким образом, Qnet обеспечивает прозрачный доступ к файлам всех узлов сети с помощью обычных локальных средств - файлового менеджера, команды ls и т.п. Другими словами, просто открываем файл с путевым именем , начинающимся с /net , получаем файловый дескриптор и начинаем записывать или считывать информацию как ни в чем не бывало.
В TCP/IP используется протокол ARP, а что использует Qnet? Qnet по умолчанию использует протокол NDP, очень похожий на ARP.
Можно по аналогии с протоколом FLEET операционной системы QNX4 жестко задать пару имя_узла-МАС –адрес. Только файл будет называться не /etc/config/netmap, а /etc/qnet_hosts , и синтаксис записей в этом файле таков:
имя_узла. имя _домена МАС-адрес1[,МАС-дрес2]
как видно из синтаксиса, для одного узла можно задать два МАС – адреса.
Для того чтобы использовать эту схему, нужно задать Администратору протокола Qnet опцию resolve=file.
Поскольку в QNX Neutrino почти все построено на механизме сообщений, протокол Qnet, делающий механизм сообщений сетевым, дает нам достаточно много возможностей. Например, Qnet позволяет запускать процессы на любом узле сети.
Рассмотрим простую, но полезную утилиту on. Эта утилита является своего рода расширением командного интерпретатора по запуску приложений. Синтаксис утилиты on :
оn опции команда
При этом команда будет выполнена в соответствии с предписаниями, заданными посредством опций. Основные опции этой утилиты:
-n узел – указывает имя узла, на котором должна быть выполнена команда. При этом в качестве файловой системы будет использована файловая система узла, с которого запущен процесс;
-f узел – аналогична предыдущей опции, но в качестве файловой системы будет использована файловая система узла, на котором запущен процесс;
-t tty – указывает, с каким терминалом целевой ЭВМ должен быть ассоциирован запускаемый процесс;
-d- предписывает отсоединиться от родительского процесса. Если задана эта опция, то утилита on завершится, а запущенный процесс будет продолжать выполняться;
-p приоритет [дисциплина]- можно задать значение приоритета и , если надо, дисциплину диспетчеризации.
Например, команда, выполненная на узле host4:
оn –d –n host5 –p 30f mytest
запустит на процессоре узла с именем host5 программу mytest, находящуюся на узле host4. приоритет запущенного процесса будет иметь значение 30 с дисциплиной диспетчеризации FIFO.
После запуска программы mytest, утилита on сразу завершит свою работу, и интерпретатор выдаст приглашение для ввода очередной команды. Вывод утилиты mytest будет напечатан в текущей консоли узла host4.
Можно выполнить команду:
on -n host5 –f host3 –t con2 mytest
Она запустит на процессоре узла host5 программу mytest , находящуюся на узле host3, вывод направит на консоль /dev/con2 узла host3.
Если нужно направить поток вывода утилиты mytest на другой узел, то имя консоли нужно указать целиком. То есть команда :
on –n host5 –f host3 –t/net/node2/dev/con1 mytest
выполненная с консоли узла node4, запустит на процессоре узла host5 программу mytest, находящуюся на узле host3, а вывод направит на консоль /dev/con2 узла host2.
Платформенные файлы целесообразно хранить в «платформозависимых» каталогах например, файл PowerPCBigEndian помещают в каталог /ppcbe. Это позволяет брать на удаленном узле файлы, предназначенные для выполнения на аппаратуре конкретного узла сети.
Информацию о доступных узлах сети Qnet можно посмотреть с помощью команды sin net. В результате получим список доступных узлов Qnet –сети с информацией о каждом из них.
Для получения диагностической и статистической информации о работе Qnet можно в любом текстовом редакторе посмотреть файл статистики /proc/qnetstats.