3. Сообщение

: «Мне хотелось бы открыть файл на чтение, пожалуйста».

4. Ответ от

: «Запросто, нет проблем».

Да-да, на этот раз

обработала запрос на чтение!

Мы опустили несколько деталей, но для восприятия базовых идей они не так важны. Очевидно, кеширующая файловая система должна предусматривать некоторый способ отправки данных по сети на «реальный» носитель. Она также должна уметь перед отправкой данных клиенту проверять, не изменился ли файл (чтобы клиент не получил устаревшие данные). К тому же, кеширующая файловая система вполне могла бы сама обработать первый запрос на чтение, загрузив данные из сетевой файловой системы в свой кэш. И так далее.

Дабы не путать понятия, сделаем небольшой экскурс в терминологию. Основное различие между объединенной файловой системой (UFS) и объединенной точкой монтирования (UMP) заключается в том, что UFS ориентирована на файлы, а UMP — на точки монтирования. В вышеупомянутой кеширующей файловой системе у нас была UFS, потому что оба администратора могли получить доступ к файлу вне зависимости от глубины его размещения файла в дереве каталогов. Давайте для примера рассмотрим другой администратор ресурса (назовем его «

»), отвечающий за путь «». В UFS-системе процесс был бы способен кэшировать файлы и оттуда тоже, присоединившись к «». В случае с UMP, что принято в QNX/Neutrino по умолчанию, поскольку там все основано на соответствии самого длинного префикса, запросы смог бы обрабатывать только администратор .

На этом с клиентом все. Перечислим ключевые моменты, которые следует запомнить:

• Клиент обычно налаживает связь с администратором ресурса с помощью вызова open (или fopen).

• После того как запрос клиента разрешился в конкретный администратор ресурса, мы его больше не меняем.

• Все дальнейшие клиентские сообщения в этом сеансе основываются на дескрипторах файлов (или

) — например, read, lseek, fgets, и т.п.

• Сеанс прекращается, когда клиент закрывает дескриптор файла или поток (или завершается по какой-либо причине).

Все вызовы, основанные на дескрипторах файлов, транслируются в сообщения.

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

Давайте кратко рассмотрим функции, реализуемые администраторами ресурсов, а затем уже углубимся в детали.

Администратор ресурса должен сообщить администратору процессов, что одно или более имя пути теперь является его доменом ответственности — иными словами, что он готов обрабатывать клиентские запросы, относящиеся к этим именам путей.

Администратор последовательного порта способен обрабатывать (допустим, так) четыре последовательных порта. В этом случае он должен зарегистрировать у администратора процесса четыре различных имени пути:

, , и . В результате этого в дереве имен путей у администратора процессов появятся еще четыре элемента, по одному на каждый из последовательных портов. Четыре элемента — это неплохо. А что если бы администратор последовательного порта обрабатывал, например, новомодную мультипортовую плату на 256 портов? Регистрация 256 отдельных префиксов (то есть от до ) привела бы к появлению в дереве имен путей администратора процессов 256 различных элементов! Администратор процессов не оптимизирован для поиска по этому дереву — он предполагает, что элементы в нем, конечно, есть, но не сотни же там этих элементов.

Как правило, не следует регистрировать больше чем несколько дюжин отдельных префиксов, потому что поиск по дереву является линейным. Число 256 портов определенно больше. В таких случаях что мультипортовый администратор ресурсов должен сделать, так это зарегистрировать каталогоподобный префикс, например,

. Это займет только один элемент в дереве имен путей. Клиент открывает последовательный порт, скажем, порт :

Администратор процессов разрешает это в четверку ND/PID/CHID/handle для мультипортового администратора; решать, насколько корректен при этом остаток имени («57») — это уже дело самого администратора ресурса. В этом примере, предположив, что часть имени пути после точки монтирования хранится в переменной path, администратор ресурса мог бы выполнить проверку очень простым способом:

Этот будет однозначно быстрее, чем поиск, выполняемый администратором процессов, — хотя бы потому что администратор процессов по сути своей намного более универсален, чем наш администратор ресурса.

Как только мы зарегистрировали один или более префиксов, мы должны быть готовы принимать сообщения от клиентов. Это делается «обычным» способом с помощью функции MsgReceive. Существуют менее 30 четко определенных типов сообщений, которые администратор ресурса должен быть способен обработать. Однако, для упрощения обсуждения и реализации их условно делят на две группы: