1.1. Исследовательская часть

В специальном разделе пояснительной записки к дипломному проекту я опишу основные стадии разработки программного модуля «VFS»: постановка задачи, предварительные НИР и техническое задание. На этапе эскизного проектирования будут определены требования к входным и выходным данным, составлен общий алгоритм работы модуля. При техническом проектировании будет определена архитектура модуля, детализированы функциональные требования, разработаны основные алгоритмы работы, описана конфигурация технических средств.

1.1.1. Постановка задачи

Общая проблематика файловых хранилищ была освещена во введении. Поясню основные принципы работы с файловыми ресурсами в игровых проектах, так сказать, «изнутри».

Большинство модулей, так или иначе нуждающихся в файловом вводе, принимают информацию в виде потока, реализованного силами CRT или STL. В силу широкого использования в индустрии средств STL, решения на базе CRT используются всё реже, поэтому закладываться на их использование я не стал – таким образом, стандартным форматом ввода-вывода де-факто в модуле стали std::basic_istream и std::basic_ostream.

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

Второй задачей модуля является представление в стандартном виде (как потока STL) файловых данных, полученных из различных по внутренней структуре файловых хранилищ. Как правило, приходится сталкиваться с заархивированными, зашифрованными данными, сетевыми устройствами, платформенно-зависимыми хранилищами (например, данные, «зашитые» в исполняемые файлы Win32 как ресурсы). В данном контексте сложность составляют ограничения, налагаемые структурой хранилищ.

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

1.1.2. Предварительные нир

Из постановки задачи следует, что требуемый модуль является самостоятельной подключаемой библиотекой, поэтому в предварительных НИР следует изучить имеющиеся примеры ПО аналогичного назначения. В силу специфики задачи подобные системы как отдельные программные модули, как правило, реализуются только в стенах софтверных компаний, имеющих в таких модулях необходимость – потенциальный рынок таких систем невелик. Подобные системы были разработаны для внутреннего использования конкурентами MiSTland, а так же самой MiSTland для её ранних проектов. Необходимость в повторной разработке была вызвана недостаточной гибкостью и переносимостью ранее разработанного модуля, а так же трудностью его поддержки. Таким образом, доступными для изучения оказались только свободно распространяемые средства и общеизвестные концепции родом из мира open-source.

BOOST filesystem

Библиотека boost::filesystem является свободно распространяемой в рамках пакета BOOST, продвигаемого комитетом по стандартизации C++. Эта библиотека призвана облегчить «сборку» пути до файла и некоторые операции с путем. Также она делает небольшую обертку (паттерн Wrapper) над стандартными потоками C++, позволяя удобнее указывать путь. Есть возможность обхода файлов внутри директорий при помощи механизма, совместимого с итераторами стандартной библиотеки С++. Работа с различными форматами представления пути успешно инкапсулирована внутри.

Эта библиотека реализует часть требуемого в ТЗ функционала, конкретно – единообразное представление клиентскому коду данных файлов и возможность итерирования файлов. Она никоим образом не решает проблемы распределенных хранилищ, но её код открыт (в соответствии с условиями распространения библиотеки BOOST), поэтому она может служить замечательным образцом внешнего программного интерфейса. Крайне полезны детали её реализации, касающиеся универсального представления пути и конвертирования различных его форматов, а также механизма итерирования веток файловой системы.

UNIX VFS

Задача абстракции от конкретного типа хранилища наиболее полно решена на данный момент в системе Linux (и в большинстве используемых ныне *nix-систем) комплексом под названием VFS (Virtual File System). Аналогичные операции в других доступных для изучения операционных системах - рассматривались системы семейства Windows – производятся не с той гибкостью, которой бы хотелось достичь в проектах MiSTland. Использовать систему VFS непосредственно не представляется возможным, поскольку VFS является неотъемлемой частью ядер операционных систем *nix, однако интерфейс и логика работы VFS, несомненно, являются удачными и проверенными долговременным использованием.

Кратко о VFS в реализации *nix - систем:

Существует виртуальное дерево, каждый «лист» которого является ячейкой, с которой может быть ассоциирован список неких файловых хранилищ – разделов или директорий на диске, съемных носителей, сетевых дисков и т.д. Структура каталогов ассоциированного (в терминологии VFS - замонтированного) хранилища становится для VFS естественным продолжением имен ветки виртуального дерева. Работа с каждым хранилищем на физическом уровне инкапсулирована кодом VFS и может быть изменена или дополнена путем модификации кода, компиляции модуля VFS и интеграции системой патчей в ядро ОС.

Каждому файлу в VFS соответствует идентификатор (в терминологии VFS – «dentry»), по которому VFS определяет, к какому физическому хранилищу принадлежит файл и из которого, соответственно, можно запросить атрибуты, содержимое файла, права доступа, число активных копий и т.п. VFS ведет учет идентификаторов файлов, организуя их в хэш-очереди. Файлом, кстати, в зависимости от реализации хранилища, может быть представлен специальный файл устройства, канал («pipe»), сетевой сокет.

Все файловые операции – чтение, запись, удаление – реализованы на уровне VFS, которая «спускает» вызовы реализациям, предназначенным для работы с конкретными типами хранилищ.