Сервер ИРБИС64 - описание работы |
В этом разделе:
Автоматическая проверка сервера
Сервер работает |
•по внутреннему протоколу ИРБИС64 над TCP/IP.
•с базами данных исключительно формата ИРБИС64. Для доступа используется irbis64.dll.
•в режиме межпроцессорного взаимодействия набора процессов обработки server_64.exe с ядром сервера irbis_server.exe. При возрастающей нагрузке число процессов обработки увеличивается до определенного регулируемого предела.
Сервер включает в виде отдельного модуля Администратор баз данных, который работает в режиме файлового доступа к базам данных. Управление паролями и именами клиентов сервер осуществляет через файл меню и интерфейс для описания клиентов в виде таблицы.
Блок-схема работы сервера ИРБИС64 Взаимодействие Web-шлюза ИРБИС и сервера ИРБИС
|
могут быть двух типов – долгоживущими и однократными.
Долгоживущие процессы |
могут обработать последовательно N запросов от ядра сервера. N регулируется. По завершению обработки запроса от ядра сервера долгоживущий процесс дает сигнал, сообщающий ядру, что его можно использовать снова.
При старте долгоживущего процесса ядро использует два параметра командной строки – второй параметр это значение уникального сигнала управления, присвоенного ядром данному процессу
Однократные процессы |
уничтожаются по завершению обработки. Все процессы обработки можно объявить однократными.
При старте однократного процесса ядро использует один параметр командной строки – это имя файла запроса.
Уникальное значение сигнала управления |
Каждому процессу обработки ядро сервера присваивает уникальное значение сигнала управления, по которому процесс начинает обрабатывать данные по запросу.
Каждому процессу обработки ядро присваивает флаг – активный/пассивный, по которому ядро узнает - занят ли процесс.
Запрос сервера передается процессу через файл с уникальным именем
filename = !IDClient_RequestNumber,
где IDClient – идентификатор клиента, выданный ядром при регистрации. RequestNumber – порядковый номер запроса.
Пример: |
!12345_2. IDClient=12345, RequestNumber=2 |
Ответ процесса обработки передается ядру через файл с уникальным именем filename = IDClient_RequestNumber – то же что и файл запроса только без знака ‘!' по универсальному сигналу управления с уникальными параметрами WINDOWS_MESSAGE LPARAM,WPARAM.
Универсальный сигнал управления процессами |
(не путать с уникальным сигналом управления данным процессом) есть WINDOWS MESSAGE, значение которого по соглашению с WINDOWS лежит выше WM_USER. По значению параметров ядро сервера распознает идентификатор процесса, пославшего ответ, и посылает по сети ответ соответствующему клиенту. Сразу после пересылки ответа сетевое соединение закрывается сервером.
Файлы запросов и ответов |
доступны в режиме отладки для просмотра в рабочей директории сервера.
Сервер ведет лог-файл в котором отражаются запросы клиентов в виде строки описателя –
дата/время/IP/IDКлиента/Длиназапроса/Код команды/АРМ/Номер запроса
Внимание: |
Клиент обязан работать в последовательном режиме! То есть не получив ответа на N запрос, клиент обязуется не посылать N+1 запрос |
Ядро сервера irbis_server.exe осуществляет сетевой обмен информацией с клиентами, управление регистрацией клиентов, управление базами данных (администрирование), управление процессами обработки, ведением журнала.
Параметры: |
MAX_PROCESS_COUNT - максимально возможное число процессов обработки; если превышено - возвращается ошибка SERVER_OVERLOAD.
MAX_SERVERS - максимально возможное число долгоживущих процессов обработки; если превышено запускаются только однократные.
Запросы от клиентов к ядру |
делятся на четыре вида – специальные, разовые, пакетные и запрос на останов.
пакетный запрос |
Получив пакетный запрос, ядро сервера порождает только однократный процесс.
Печать, статистика и глобальная корректировка – пакетные запросы.
запрос на останов |
Получив запрос на останов, ядро посылает сигнал завершения заданному процессу обработки. Если процесс обработки не порождает в ответ сигнал завершения – ядро сервера насильно завершает процесс обработки и закрывает соединение с клиентом. В этом случае клиент не получает результата обработки. Если процесс обработки порождает сигнал завершения по требованию ядра, клиент получает ответ в том виде, в котором процесс обработки его предоставил, не давая гарантию, что запрос клиента выполнен полностью. Такой режим важен при выполнении пакетных заданий на больших базах.
Специальные запросы |
Специальные запросы обрабатывает ядро сервера без участия процессов обработки. Это регистрация, передача контекста (чтение файлов), раз-регистрация и сигнал подтверждения (NO OPERATION)
В случае работы сервера ИРБИС в режиме службы Windows добавлена возможность автоматически проверять сервер на корректность ответов и возможное “зависание” и при необходимости перезапускать его (при этом теряется регистрация клиентов). В этом случае служба ИРБИС выступает в роли клиента сервера ИРБИС и в связи с этим введены следующие параметры:
SERVICE_USER_NAME – логин для службы проверки (по умолчанию 1);.
SERVICE_USER_PASSWORD – пароль для службы (по умолчанию 1);
SERVICE_INTERVAL_SERVER_RESTART – интервал в секундах для таймера автоматической проверки сервера ИРБИС: если = 0, таймер отключается; если < 0, таймер блокируется до изменения параметра на > 0.
Исправлены ошибки сервера при работе в режиме DUPLICATE_SOCKETS=1, когда процесс обработки выполняет сетевое чтение/запись (т.е. напрямую взаимодействует с клиентом без посредничества сервера). Включение данного режима позволяет ускорить работу сервера за счет экономии времени, которое тратится на межпроцессорное взаимодействие между сервером и процессами обработки DUPLICATE_SOCKETS=0 (по умолчанию выключен)
Добавлены параметры Prefix_file_request=rqst_ и Prefix_file_response=rpns_ для оптимизации межпроцессорного взаимодействия при работе сервера.
|
См. также:
Блок-схема работы сервера ИРБИС64
Взаимодействие Web-шлюза ИРБИС и сервера ИРБИС
Режим параллельной обработки чтения-записи запросов