TCP/IP Сервер БД ИРБИС64 > Сервер ИРБИС64

В этом разделе:

Сервер работает

•по внутреннему протоколу ИРБИС64 над TCP/IP.

•с базами данных исключительно формата ИРБИС64. Для доступа используется irbis64.dll.

•в режиме межпроцессорного взаимодействия набора процессов обработки server_64.exe с ядром сервера irbis_server.exe. При возрастающей нагрузке число процессов обработки увеличивается до определенного регулируемого предела.

Сервер включает в виде отдельного модуля Администратор баз данных, который работает в режиме файлового доступа к базам данных.

Управление паролями и именами клиентов сервер осуществляет через файл меню и интерфейс для описания клиентов в виде таблицы.

Блок-схема работы сервера ИРБИС64

Взаимодействие Web-шлюза ИРБИС и сервера ИРБИС

Процессы обработки

могут быть двух типов – долгоживущими и однократными.

Долгоживущие процессы

могут обработать последовательно N запросов от ядра сервера. N регулируется. По завершению обработки запроса от ядра сервера долгоживущий процесс дает сигнал, сообщающий ядру, что его можно использовать снова.

При старте долгоживущего процесса ядро использует два параметра командной строки – второй параметр это значение уникального сигнала управления, присвоенного ядром данному процессу

Однократные процессы

уничтожаются по завершению обработки. Все процессы обработки можно объявить однократными.

При старте однократного процесса ядро использует один параметр командной строки – это имя файла запроса.

Процессы обработки независимы друг от друга, связаны с сервером через условный уникальный сигнал управления (WINDOWS MESSAGE).

Уникальное значение сигнала управления

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

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

Запрос сервера передается процессу через файл с уникальным именем

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)

Автоматическая проверка сервера сервер ИРБИС64

В случае работы сервера ИРБИС в режиме службы 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_ для оптимизации межпроцессорного взаимодействия при работе сервера.

См. также: