Клиентская и серверная части

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

Для обеспечения требуемой гибкости, взаимодействия клиентской и пользовательской частей системы X по мере возможностей не должны были зависеть от используемых сетевой среды передачи данных и сетевых протоколов. Конечно, полная независимость - это теоретически недостижимая цель (всегда и везде), но что касается системы X, то она действительно умеет работать в большинстве распространенных сетевых сред (в том числе, естественно, в стандартных для ОС UNIX сетях, основанных на семействе протоколов TCP/IP).

Основой взаимодействия между клиентом и сервером оконной системы X является так называемый X-протокол, представляющий собой точную спецификацию допустимых запросов от клиента к серверу и допустимых ответов сервера к клиенту. Как указывается в документации оконной системы X, Х-протокол обладает следующими особо привлекательными качествами:

· При использовании этого протокола обработка взаимодействий клиента и сервера ведется единообразно, независимо от того, основана она на внутренних механизмах IPC или на реальных сетевых обменах; это позволяет добиться прозрачности сетевой среды как с точки зрения конечного пользователя, так и с точки зрения разработчика прикладных программ.

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

· X-протокол может быть реализован на основе любого надежно поддерживаемого потока байтов (обеспечиваемого внутренними механизмами IPC или внешними сетевыми механизмами); многие из пригодных механизмов являются стандартными и реализованы в большинстве архитектур.

· Для большинства (хотя и не для всех) приложений X-протокол не порождает существенных задержек при работе с графическими терминалами. Обычно задержки вызываются скорее временными потребностями самих терминалов, а не расходами на протокольные взаимодействия клиента и сервера.

Одним из клиентов оконной системы обычно является так называемый "оконный менеджер" (window manager). Это специально выделенный клиент оконной системы, обладающий полномочиями на управление расположением окон на экране терминала. Некоторые из возможностей X-протокола (связанные, например, с перемещением окон) доступны только клиентам с полномочиями оконного менеджера. Во всем остальном оконный менеджер является обычным клиентом.

Базовые библиотеки

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

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

Уровнем, который позволяет использовать ранее созданные графические образы и/или заготовки интерфейсов, является библиотека Xt (X Toolkit) Intrinsics. Эта библиотека служит для создания и использования уже существующих элементов пользовательского интерфейса, называемых виджетами (widgets). Виджет - это параметризуемая заготовка части пользовательского интерфейса (кнопка, часть меню, пиктограмма и т.д.), привязываемая к окну экрана терминала. Библиотека Xt Intrinsics выполнена в объектно-ориентированном стиле, так что каждый виджет представляет собой класс, который может использоваться для порождения новых классов, представляющих собой комбинированные виджеты и т.д.

По своим идеям Xt Intrinsics является мощным средством разработки пользовательских графических интерфейсов. Однако эта библиотека разрабатывалась в MIT и в основном являлась исследовательским прототипом. Хотя несколько компаний представили в public domain собственные наборы виджетов, их общее количество оказывается недостаточным для быстрого и качественного производства графических пользовательских интерфейсов. Это позволило занять лидирующее положение на коммерческом рынке инструментальному пакету консорциума Open Software Foundation (OSF) Motif.

В среде Linux в последнее время наиболее распространено использование графических библиотек GTK+ (Gimp ToolKit) и QT.

На основе этих графических библиотек разработаны две наиболее популярных в Linux десктоп системы: GNOME (GTK+) и KDE (QT).

В мире коммерческих UNIX систем фактическим стандартом является использование CDE на основе библиотеки Motif.

Файловая система Novell NetWare. Поддержка дополнительных пространств имен.

Сетевая файловая система

Одна из основных целей использования сетей - это обеспечение доступа всех пользователей к общим устройствам хранения информации, в основном, к жёстким дискам. Организация файловой системы во многом схожа с организацией файловой системы DOS, но и имеет важные отличия. Как и в DOS, информация хранится в файлах. Файлы размещаются в древовидной структуре каталогов и подкаталогов. Корнем такого дерева, в отличие от драйва DOS, является том. Тома располагаются на серверах. При наличии соответствующих прав пользователь может получить доступ к томам всех серверов, доступных в сети. Общая структура файловой системы приведена на рисунке 2.12.

Рассмотрим элементы этой системы.

Том. Это высший уровень файловой системы NetWare. Тома создаются в процессе инсталляции файлового сервера и в процессе его функционирования. В отличие от драйвов DOS, которые соответствуют непрерывным областям на жёстком диске, тома могут состоять из нескольких сегментов, которые могут находиться как на одном жёстком диске, так и на разных.

Каталоги. Правила работы с каталогами в NetWare и DOS практически совпадают. В отличие от DOS в NetWare ограничивается степень вложенности каталогов (SET-параметр Maximum Subdirectory Tree). По умолчанию в NetWare максимальный уровень вложенности равен 25.

Файлы. Правила использования файлов в NetWare такие же, как и в DOS. Файлы могут размещаться в каталогах и подкаталогах тома, включая и корневой.

При инсталляции файлового сервера создаётся по крайней мере том с именем SYS. Он предназначен для хранения файлов самой операционной системы NetWare, а также программ и утилит коллективного пользования. При инсталляции на этом томе создаётся несколько каталогов (таблица 2.2).

Рис. 2.12. Структура файловой системы

Войдя в сеть, можно создавать другие каталоги. Пользователи могут обмениваться файлами через эти каталоги и хранить в них свои собственные файлы. Однако прежде чем использовать созданные каталоги, необходимо, во-первых, описать пользователей в системе и, во-вторых, наделить их правами, необходимыми для доступа к каталогам.

Пользователь осуществляет доступ к файлам и каталогам NetWare с рабочей станции, на которой установлена своя операционная система, например, DOS. Связывание драйвов DOS с томами NetWare выполняется с помощью утилиты командной строки MAP. Например, после выполнения команды

том SYS файлового сервера FS4S планируется на драйв F: и становится доступным операционной системе DOS. Такие драйвы называют логическими устройствами.

Таблица 2.2. Системные каталоги ОС NetWare на томе SYS

Известно, что в DOS пути поиска указываются с помощью параметра окружения PATH. Чтобы указать операционной системе DOS пути поиска на файловом сервере, следует также использовать команду MAP, но с другими параметрами. Например, после выполнения команды

будет создан драйв Z: (выбираются буквы с конца латинского алфавита), спланированный на каталог PUBLIC тома SYS файлового сервера FS4S. При этом путь Z: будет добавлен в начало параметра PATH. Создаваемые по MAP драйвы Z:, Y: и т.д. называются поисковыми устройствами.

Поддержка рабочих станций разных платформ

NetWare поддерживает связь с рабочими станциями, на которых установлены операционные системы MS DOS, Macintosh, OS/2, UNIX, Windows NT Workstation (рисунок 2.22).

Рис. 2.22. Рабочие станции, поддерживаемые NetWare

На каждой рабочей станции должно быть установлено своё программное обеспечение (ПО) клиента. Структура этого ПО обсуждается в пункте 2.3.3.

Рис. 2.23. Организация пространств имён файлового сервера

NetWare поддерживает форматы, отличные от DOS. Файлы операционных систем Macintosh, UNIX, OS/2, которые загружаются на рабочих станциях, имеют другие наборы атрибутов, длины имён файлов и т. д. Чтобы поддержать работу таких станций, на файловом сервере должны быть загружены различные пространства имён. Пространство имён представляет собой дополнительную запись таблицы DET (рисунок 2.23).

Таким образом, на томе с активными пространствами имён Macintosh, UNIX, OS/2 будут храниться четыре записи для каждого файла: основная запись каталога и записи каталогов для Macintosh, UNIX, OS/2. Все записи ссылаются на одну и ту же цепочку элементов FAT (поток данных), т. е. физически файл записывается на диск один раз. Следует отметить, что на Macintosh файлы хранятся с использованием двух потоков данных (ветвей). Одна ветвь содержит информацию о ресурсе Macintosh для этого файла (ветвь ресурсов), а другая содержит фактические данные.

Каждое пространство имён поддерживается своим NLM-модулем с расширением NAM: MAC.NAM - для Macintosh, OS2. NAM - для OS/2 и т. д. Чтобы добавить необходимые записи в таблицы DET и FAT тома, с консоли файлового сервера необходимо для каждого пространства имён выполнить один раз команду

Здесь имя - это MAC или OS2 и т. д. Для дальнейшей работы достаточно загружать только соответствующие NLM-модули поддержки пространства имён.

7.2. ОС семейства UNIX. Общий алгоритм работы планировщика.

Рис. 2.5. Состояния процесса

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

Выполнение в режиме задачи завершается в результате системного вызова или прерывания, и процесс переходит в режим ядра, в котором выполняется код системного вызова или прерывания. После этого процесс опять может вернуться в режим задачи. Однако во время выполнения системного вызова в режиме ядра процессу может понадобиться недоступный в данный момент ресурс. Для ожидания доступа к такому ресурсу, процесс вызывает функцию ядра sleep () и переходит в состояние сна (4). При этом процесс добровольно освобождает вычислительные ресурсы, которые предоставляются следующему наиболее приоритетному процессу. Когда ресурс становится доступным, ядро "пробуждает процесс", используя функцию wakeup (), помещает его в очередь на выполнение, и процесс переходит в состояние "готов к запуску"(3).

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

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

В UNIX 4.x BSD определены дополнительные состояния процесса, в первую очередь связанные с системой управления заданиями и взаимодействием процесса с терминалом. Процесс может быть переведен в состояние "остановлен" с помощью сигналов останова SIGSTOP, SIGTTIN или SIGTTOU. В отличие от других сигналов, которые обрабатываются только для выполняющегося процесса, отправление этих сигналов приводит к немедленному изменению состояния процесса'. В этом случае, если процесс выполняется или находится в очереди на запуск, его состояние изменяется на "остановлен". Если же процесс находился в состоянии сна, его состояние изменится на состояние "остановлен в состоянии сна". Выход из этих состояний осуществляется сигналом продолжения SIGCONT, при этом из состояния "остановлен" процесс переходит в состояние "готов к запуску", а для процесса, остановленного в состоянии сна, следующим пунктом назначения является продолжение "сна". Описанные возможности полностью реализованы и в SVR4.

Наконец, процесс выполняет системный вызов exit(2) и заканчивает свое выполнение. Процесс может быть также завершен вследствие получения сигнала. В обоих случаях ядро освобождает ресурсы, принадлежавшие процессу, за исключением кода возврата и статистики его выполнения, и переводит процесс в состояние "зомби". В этом состоянии процесс находится до тех пор, пока родительский процесс не выполнит один из системных вызовов wait(2), после чего вся информация о процессе будет уничтожена, а родитель получит код возврата завершившегося процесса.

Файловая система NTFS.

NTFS эффективностее и надежнее FAT или HPFS. Она разработана для быстрого выполнения стандартных файловых операций типа чтения, записи и поиска, а также улучшенных операций типа восстановления файловой системы на очень больших жестких дисках. NTFS также включает возможности безопасности, требуемые для файловых серверов. NTFS поддерживает управление доступом к данным и привилегии владельца, что является важным для целостности корпоративных данных. NTFS - единственная файловая система в Windows NT, которая позволяет назначить разрешения для отдельных файлов.

NTFS является простой, но очень мощной разработкой. Для этой файловой системы вся информация на томе NTFS является файлом или частью файла. Каждый распределенный на томе NTFS сектор принадлежит некоторому файлу. Даже метаданные (metadata) файловой системы (информация, которая описывает непосредственно файловую систему) являются частью файла.

Эта основанная на атрибутах файловая система поддерживает объектно-ориентированные приложения, обрабатывая все файлы как объекты, которые имеют определяемые пользователем и системой атрибуты.

Главная файловая таблица

Каждый файл на томе NTFS представлен записью в специальном файле, называемом главной файловой таблицей (MFA - master file table). NTFS резервирует первые 16 записей таблицы для специальной информации. Первая запись этой таблицы описывает непосредственно главную файловую таблицу; за ней следует зеркальная запись (mirror record) MFT. Если первая запись MFT разрушена, то NTFS читает вторую запись для отыскания зеркального файла MFT, первая запись которого идентична первой записи MFT. Местоположения сегментов данных MFT и зеркального файла MFT записаны в секторе начальной загрузки. Дубликат сектора начальной загрузки находится в логическом центре диска.

Третья запись MFT - файл регистрации (log file); используется для восстановления файлов. Семнадцатая и последующие записи главной файловой таблицы используются собственно файлами и каталогами (также рассматриваются как файлы NTFS) на томе.

Главная файловая таблица отводит определенное количество пространства для каждой записи файла. Атрибуты файла записываются в распределенное пространство MFT. Небольшие файлы и каталоги (обычно до 1500 байт или меньше), могут полностью содержать. внутри записи главной файловой таблицы. В NTFS поиск файла производится только для непосредственного его использования.

Записи каталога помещены внутри главной файловой таблицы так же, как записи файла. Вместо данных каталоги содержат индексную информацию. Небольшие записи каталогов находятся полностью внутри структуры MFT. Большие каталоги организованы в B-tree, имея записи с указателями на внешние кластеры, содержащие элементы каталога, которые не могли быть записаны внутри структуры MFT.

Атрибуты файла NTFS

NTFS просматривает каждый файл (или каталог) как набор атрибутов файла. Такие элементы, как имя файла, информация зашиты и даже данные - все это атрибуты файла. Каждый атрибут идентифицирован кодом типа атрибута и, необязательно, именем атрибута.

Если атрибуты файла могут находится внутри записи файла MFT, они называются резидентными (resident) атрибутами. HanpHMqi, информация типа имени файла и отметки времени всегда включается в запись файла MFT. Если файл слишком большой, чтобы содержать все атрибуты в записи файла MFT, часть атрибутов является нерезидентной (nonresident). Нерезидентные атрибуты занимают один или несколько пробегов (run) дискового пространства в другом месте тома (пробег дискового пространства - непрерывная линейная область на диске).

Вообще, все атрибуты могут быть вызваны как поток бантов независимо от того, являются ли они резидентными или нерезидентными.

В табл. 5.1 представлен список всех атрибутов файла, в настоящее время определенных для NTFS. Этот список расширяем, т. е. другие атрибуты файла в будущем могут быть определены в случае необходимости.

Таблица 5.1. Атрибуты файла NTFS

Не нашли, что искали? Воспользуйтесь поиском по сайту: