НАЧАЛО >> TCP/IP сервер ИРБИС 64/128 >> Конфигурирование и настройка сервера >> Несколько замечаний для администраторов
Сервер работает по внутреннему протоколу ИРБИС64 над TCP/IP.
Сервер работает с базами данных исключительно формата ИРБИС64. Для доступа используется irbis64.dll.
Сервер работает в режиме межпроцессорного взаимодействия набора процессов обработки server_64.exe с ядром сервера irbis_server.exe. При возрастающей нагрузке число процессов обработки увеличивается до определенного регулируемого предела.
Процессы обработки независимы друг от друга, связаны с сервером через условный уникальный сигнал управления (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 запрос
Ядро сервера осуществляет сетевой обмен информацией с клиентами, управление регистрацией клиентов, управление базами данных (администрирование), управление процессами обработки, ведением журнала.
Процессы обработки могут быть двух типов – долгоживущими и однократными. Долгоживущие процессы могут обработать последовательно N запросов от ядра сервера. N регулируется. По завершению обработки запроса от ядра сервера долгоживущий процесс дает сигнал, сообщающий ядру, что его можно использовать снова. Однократные процессы уничтожаются по завершению обработки. Все процессы обработки можно объявить однократными.
При старте однократного процесса ядро использует один параметр командной строки – это имя файла запроса.
При старте долгоживущего процесса ядро использует два параметра командной строки – второй параметр это значение уникального сигнала управления, присвоенного ядром данному процессу
Параметр MAX_PROCESS_COUNT - максимально возможное число процессов обработки; если превышено - возвращается ошибка SERVER_OVERLOAD. Есть параметр MAX_SERVERS - максимально возможное число долгоживущих процессов обработки; если превышено запускаются только однократные.
Запросы от клиентов к ядру делятся на четыре вида – специальные, разовые, пакетные и запрос на останов. Получив пакетный запрос, ядро сервера порождает только однократный процесс. Получив запрос на останов, ядро посылает сигнал завершения заданному процессу обработки. Если процесс обработки не порождает в ответ сигнал завершения – ядро сервера насильно завершает процесс обработки и закрывает соединение с клиентом. В этом случае клиент не получает результата обработки. Если процесс обработки порождает сигнал завершения по требованию ядра, клиент получает ответ в том виде, в котором процесс обработки его предоставил, не давая гарантию, что запрос клиента выполнен полностью. Такой режим важен при выполнении пакетных заданий на больших базах.
Специальные запросы обрабатывает ядро сервера без участия процессов обработки. Это регистрация, передача контекста (чтение файлов), раз-регистрация и сигнал подтверждения (NO OPERATION)
Печать, статистика и глобальная корректировка – пакетные запросы.
Сервер включает в виде отдельного модуля Администратор баз данных, который работает в режиме файлового доступа к базам данных.
Управление паролями и именами клиентов сервер осуществляет через файл меню и интерфейс для описания клиентов в виде таблицы.
Сервер может работать в режиме параллельной обработки чтения-записи запросов клиентов в многопотоковом режиме. Режим управляется следующими параметрами
THREADS_AVAILABLE=1 – включение режима.
THREADS_LOCKING=0 – блокировка всех параллельных
потоков, кроме текущего, на время чтения-записи.
MIN_THREADS_COUNT=1 – минимальное количество потоков
в очереди. Если превышено – поток после завершения операции записи завершается.
MAX_THREADS_COUNT=10 – максимально возможное количество потоков, если превышено - сервер переходит в режим последовательного чтения-записи.
Многопотоковый режим следует использовать при медленной работе сети. То есть при работе в глобальной сети, когда доступ затруднен. В локальной сети данный режим выигрыша не даст, за исключением большей надежности при операциях чтения-записи. Если будет зависание системных функций чтения-записи, беспотоковый сервер не сможет продолжать обработку запросов.