ТЗ на файловый сервер
h2. Решаемые проблемы

• При интенсивной работе с файлами по сети возникают задержки при открытии файлов. Они вызваны проверками прав доступа, антивирусами итд. На данный момент не видно другого решения проблемы.
• Права доступа к файловому хранилищу. Если мы обращаемся к файлам только через свой сервис, уходит проблема с тем, что у пользователя есть права на запись в файловом хранилище, что небезопасно.
• Резервирование. Возможность перенаправить все обращения на другой сервер.

Используемые модули¶

TCP_MANAGER - поддержка TCP
BASE_SERVICE - windows service
DBG_LOG - Модуль записи отладочных логов, настройка, какие логи писать
PARAM_FILE - Хранение настроек. Редактирование настроек.
NC_CONTAINER - дерево параметров аналогично XML

Новые модули¶

Пишем два модуля: серверный и клиентский. Связь между модулями осуществляется по TCP. Запрос и ответ передается в виде NC_CONTAINER. Возможно также использование XML запросов благо конвертация в обе стороны не проблема. Сервер обрабатывает запросы клиента на предмет работы с файлами. В дальнейшем появятся и другие запросы.

Резервирование¶

Серверные модули могут работать в паре (активный и резервный).Каждый на своем сервере. При нормальной работе активный модуль обрабатывает запросы клиентов, а резервный резервирует на свой сервер содержимое хранилища.

Серверный модуль¶

• TCP server
• Windows service
• Допускает одновременное подключение значительного количества клиентов (несколько тысяч).
• По запросу клиента выполняет любую файловую операцию (!CreateFile, ReadFile, WriteFile, CloseHandle, LockFile etc)
• Нотификация клиентов об изменениях файлов в каталогах
• Для одного клиента допускается передача нового запроса до окончания обработки предыдущего. Это не касается случаев запросов к одному файлу по одному хэндлу.
• Ответ на более поздний запрос может быть отправлен раньше.
• Запросы выполняются параллельно. То есть, есть некоторое кол-во потоков. Каждый новый запрос передается свободному потоку (если таковой есть).
• Режим кеширования. В этом режиме доступ к хранилищу осуществляется только через серверный модуль. в этом случае допускается кэширование файлов на чтение и запись (настраивается)
• Резервирование. Серверные модули могут работать в паре (активный и резервный). Каждый на своем сервере. Соединяются по TCP. При нормальной работе активный модуль обрабатывает запросы клиентов, а резервный резервирует на свой сервер содержимое хранилища. После восстановления рухнувшей половинки, она становится резервной. В общем, система во многом похожа на кластер.
• Логи. Настраиваемые. Пишет все операции, длительные операции, ошибки. Для записи логов используем модуль DBG_LOG.
• Допускается подключение через инет. То есть одно медленное соединение не влияет на другие.
• Для хранения и редактирования настроек (в том числе системы записи логов) используем модуль PARAM_FILE. Пример использования модуля записи логов совместно с редактором настроек можно посмотреть в VIDEO_SERVICE’е

Клиентский модуль¶

• TCP client
• Используется в джине. Вся работа с файлами в хранилище осуществляется через этот модуль.
• Режим, в котором модуль вместо обращения к серверному модулю выполняет все операции сам.
• Резервирование. Клиент соединяется с активным и резервным серверными модулями. В случае проблем запросы перенаправляются.
• Логи. Настраиваемые. Пишет все операции, длительные операции, ошибки.

Протокол клиент-сервер¶

* В качестве запроса или ответа всегда используется NC_CONTAINER

* В нем есть обязательные поля.

* ID запроса - уникальный идентификатор запроса-ответа генерируется клиентом для запроса. Для ответа берется из запроса.

* Код операции (строчный, осмысленный) - генерируется клиентом. Копируется в ответ сервером.

• И необязательный - параметры, зависящие от кода операции.
• При использовании XML протокола, сразу по получении сервером XML запроса он конвертируется в NC_CONTAINER. Ответ конвертируется в XML непосредственно перед отправкой

Примечания¶

• Клиентский модуль должен работать совместно с системой резервирования файлов. Если есть резервная копия на локальном диске работает с ней. Алгоритм взаимодействия с системой резервирования указывается при запросе на открытие файла. Учесть при внедрении клиентского модуля в джин.

Поддерживаемые файловые операции¶

Вместо HANDLE используем некоторый собственный класс. У класса клиента должны быть методы полностью аналогичные по параметрам функциям API.
К сожалению выяснилось, что поддержка overlapped операций тоже нужна, потому что она используется.

    FILER_FILE_HANDLE FILER_FILE_HANDLE CreateFile();
    bool    CloseHandle(FILER_FILE_HANDLE handle);

    bool    ReadFile();
    bool    WriteFile();
    !+int64 SetFilePointer();
    bool    LockFileEx();
    bool    UnlockFileEx();

    FindFirstFile()
    FindNextFile()
    FindClose()

    GetFileAttributesEx()
    CreateDirectory();
    DeleteFile();
    MoveFile();
    MoveFileEx();
    GetFileSize();
    SetEndOfFile();
    FlushFileBuffers();
    FindFirstChangeNotification();
    ReadDirectoryChangesW();

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