Turtle >> Архитектура

Search System Transfer Protocol - SSTP/1.0

Статус этого документа
Этот документ описывает внутренний для компании Stack Technologies Ltd. стандарт взаимодействия различных компонент поисковой системы. Документ предназначен для служебного использования. Этот документ может и должен являться предметом обсуждения, с внесением изменений. Соблюдение согласованного стандарта всеми сотрудниками, занятыми в разработке поисковой системы обязательно.
Copyright Notice

Copyright © Stack Technologies Ltd. (2001). All Rights Reserved.

Содержание.

1. Введение.

1.1 Назначение.
1.2 Термины и понятия.
1.3 Общие принципы работы.

2. Коды запроса (ответа).

2.1 SSTP специфичные.

2.1.1 001 REQ_GET_URLINFO
2.1.2 002 REQ_PUT_HOST_NOTFOUND
2.1.3 003 REQ_PUT_HOST_UNRICHABLE
2.1.4 006 REQ_PUT_DATA
2.1.5 007 REQ_GET_MD5
2.1.6 008 REQ_GET_URL_BYNAME
2.1.7 010 REQ_GET_URL_BYID
2.1.8 011 REQ_GET_QUEUERESET
2.1.9 012 REQ_GET_EXCLUDE
2.1.10 013 REQ_GET_SERVICES
2.1.11 014 REQ_GET_MIME
2.1.12 015 REQ_GET_ARCHIVERS
2.1.13 016 REQ_GET_PW
2.1.14 017 REQ_GET_ALLOW
2.1.15 018 REQ_GET_DOMAINS
2.1.16 019 REQ_GET_ROBOTS
2.1.17 020 REQ_PUT_ROBOTS
2.1.18 021 REQ_RESET_ROBOTS
2.1.19 022 REQ_GET_SEARCHERS
2.1.20 023 REQ_GET_SCANERS
2.1.21 024 REQ_RELOAD_CONFIG
2.1.22 025 REQ_GET_STATS
2.1.23 026 REQ_HTTP_GETALLOW
2.1.24 027 REQ_HTTP_GETMIME
2.1.25 028 REQ_HTTP_GETARCHIVERS
2.1.26 029 REQ_HTTP_GETSCANERS
2.1.27 030 REQ_HTTP_GETUSER
2.1.28 031 REQ_HTTP_PUTALLOW
2.1.29 032 REQ_HTTP_PUTARCHIVERS
2.1.30 033 REQ_HTTP_PUTSCANERS
2.1.31 034 REQ_HTTP_PUTSEARCHERS
2.1.32 035 REQ_HTTP_PUTUSER
2.1.33 036 REQ_HTTP_PUTMIME
2.1.34 037 REQ_HTTP_GETSEARCHERS
2.1.35 038 REQ_GET_URLOBJECT
2.1.36 039 REQ_GET_URLDOCUMENT
2.1.37 040 REQ_GET_FULLDOCUMENT
2.1.38 041 REQ_GET_EXISTDOCUMENT
2.1.39 042 REQ_GET_URLVERSIONS
2.1.40 050 REQ_PUT_RECORD
2.1.41 051 REQ_PUT_MODIFIED
2.1.42 052 REQ_PUT_RANKS
2.1.43 053 REQ_END
2.1.44 054 REQ_REBUILD
2.1.45 055 REQ_TRANSFER_END
2.1.46 056 REQ_GET_WORD
2.1.47 057 REQ_GET_EXPANDWORD
2.1.48 058 REQ_GET_MORPHWORD
2.1.49 059 REQ_GET_PHRASE
2.1.50 060 REQ_GET_WORDS_OPERATION
2.1.51 061 REQ_GET_PLAN
2.1.52 062 REQ_GET_BINARYPLAТ
2.1.53 063 REQ_GET_PROGRAM
2.1.54 064 REQ_GET_BINARYPROGRAM
2.1.55 065 REQ_GET_EXPANDINFO
2.1.56 070 REQ_GET_REFERENCES
2.1.57 071 REQ_GET_REFERERS
2.1.58 072 REQ_GET_SITEREFERENCES
2.1.59 073 REQ_GET_SITEREFERERS
2.1.60 080 REQ_GRT_CACHEOBJECT
2.1.61 081 REQ_PUT_CACHEOBJECT
2.1.62 090 REQ_GET_SML
2.1.63 091 REQ_GET_SIMILAR
2.1.64 092 REQ_GET_FPS

2.2 HTTP Информационные (informational)

2.2.1 100 REQ_PUT_CONTINUE
2.2.2 101 REQ_PUT_SWITCHING_PROTOCOLS

2.3 HTTP успешные (successful).

2.3.1 200 REQ_PUT_URLFOLLOW
2.3.2 201 REQ_PUT_CREATED
2.3.3 202 REQ_PUT_ACCEPTED
2.3.4 203 REQ_PUT_NOT_AUTHORITATIVE
2.3.5 204 REQ_PUT_NO_CONTENT
2.3.6 205 REQ_PUT_RESET_CONTENT
2.3.7 206 REQ_PUT_PARTIAL_CONTENT

2.4 HTTP перенаправление (redirection).

2.4.1 300 REQ_PUT_MULTIPLE_CHOICES
2.4.2 301 REQ_PUT_PERMANENT_REDIRECT
2.4.3 302 REQ_PUT_REDIRECT
2.4.4 303 REQ_PUT_SEE_OTHER
2.4.5 304 REQ_PUT_USE_LOCAL_COPY
2.4.6 305 REQ_PUT_USE_PROXY
2.4.7 307 REQ_PUT_TEMPORARY_REDIRECT

2.5 HTTP ошибки клиента (client errors).

2.5.1 400 REQ_PUT_BAD_REQUEST
2.5.2 401 REQ_PUT_AUTH_REQUIRED
2.5.3 402 REQ_PUT_PAYMENT_REQUIRED
2.5.4 403 REQ_PUT_FORBIDDEN
2.5.5 404 REQ_PUT_NOT_FOUND
2.5.6 405 REQ_PUT_METHOD_NOT_ALLOWED
2.5.7 406 REQ_PUT_NOT_ACCEPTABLE
2.5.8 407 REQ_PUT_PROXY_AUTH
2.5.9 408 REQ_PUT_REQUEST_TIMEOUT
2.5.10 409 REQ_PUT_CONFLICT
2.5.11 410 REQ_PUT_GONE
2.5.12 411 REQ_PUT_LENGTH_REQUIRED
2.5.13 412 REQ_PUT_PRECONDITION_FAILED
2.5.14 413 REQ_PUT_ENTRY_TOO_LARGE
2.5.15 414 REQ_PUT_REQUEST_URI_TOO_LONG
2.5.16 415 REQ_PUT_UNSUPPORTED_MEDIA_TYPE
2.5.17 416 REQ_PUT_RANGE_NOT_SATISFIABLE
2.5.18 417 REQ_PUT_EXPECTATION_FAILED

2.6 HTTP ошибки сервера (server errors).

2.6.1 500 REQ_PUT_SERVER_ERROR
2.6.2 501 REQ_PUT_NOT_IMPLEMENTED
2.6.3 502 REQ_PUT_BAD_GATEWAY
2.6.4 503 REQ_PUT_SERVICE_UNAVAILABLE
2.6.5 504 REQ_PUT_GATEWAY_TIMEOUT
2.6.6 505 REQ_PUT_VERSION_NOT_SUPPORTED

3. Параметры (parameters).

3.1 HEADER_SERVER_ADDR_V4
3.2 HEADER_SERVER_ADDR_V6
3.3 HEADER_AUDIO
3.4 HEADER_AVG_NUMENTRIES
3.5 HEADER_AVG_NUMFOUND
3.6 HEADER_BASELANG
3.7 HEADER_SERVER_BPS
3.8 HEADER_CONFIG
3.9 HEADER_CHARSET
3.10 HEADER_ERROR
3.11 HEADER_ESSENCE
3.12 HEADER_EXPAND_QUERY
3.13 HEADER_EXPAND_TYPE
3.14 HEADER_EXPAND_WORDS
3.15 HEADER_FIELD
3.16 HEADER_URI_HASH
3.17 HEADER_IMAGE
3.18 HEADER_NUMLEX
3.19 HEADER_LANGUAGES
3.20 HEADER_MARKBEGIN
3.21 HEADER_MAXBACKETS
3.22 HEADER_MARKEND
3.23 HEADER_NUMCHECKED
3.24 HEADER_NUMENTRIES
3.25 HEADER_NUMFOUND
3.26 HEADER_NUMREFS
3.27 HEADER_NUMRESULTS
3.28 HEADER_THEMEFOUND
3.29 HEADER_THEMECHECKED
3.30 HEADER_URI_OLDHASH
3.31 HEADER_OLDURI_ID
3.32 HEADER_OPERATION
3.33 HEADER_PLAN
3.34 HEADER_SERVER_PROTOCOL
3.35 HEADER_REFERENCE
3.36 HEADER_SERVER_FLAGS
3.37 HEADER_SERVER_ID
3.38 HEADER_SERVER_PORT
3.39 HEADER_SERVER_ROBOTS
3.40 HEADER_SERVER_ROBOTSTIME
3.41 HEADER_SERVER_NAME
3.42 HEADER_START_RESULTS
3.43 HEADER_SEARCH_WORD
3.44 HEADER_TITLE
3.45 HEADER_URL_CHECKTIME
3.46 HEADER_URI_FLAGS
3.47 HEADER_URI_ID
3.48 HEADER_URI_LEN
3.49 HEADER_URI
3.50 HEADER_URL
3.51 HEADER_URI_STATUS
3.52 HEADER_URI_TIME
3.53 HEADER_VIDEO
3.54 HEADER_XCONTENT_LEN
3.55 HEADER_NUMWORDS
3.56 HEADER_QUERY_TIME
3.57 HEADER_CURBACKET
3.58 HEADER_NUMBACKETS
3.59 HEADER_TIME
3.60 HEADER_TEMPRES
3.61 HEADER_COMPRESSSIZE
3.62 HEADER_WORD
3.63 HEADER_COMPRESSEXTSIZE
3.64 HEADER_IDS
3.65 HEADER_WORDLEN
3.66 HEADER_DATASIZE
3.67 HEADER_EXTRA
3.68 HEADER_ESSENCE_LEN
3.69 HEADER_FINGERPRINT
3.70 HEADER_SORT_OPTIONS
3.71 HEADER_LIMIT
3.72 HEADER_HRQ
3.72 HEADER_VERSION

4. Авторизация и Система Безопасности (authorization and security).

4.1 HEADER_USER
4.2 HEADER_PASSWORD

5. Поисковые Планы и их оформление.
6. Поисковые Программы и их оформление.
7. Приложение 1. Пример запроса взаимодействия CA и DS.
8. Приложение 2. Пример запроса QP к SP, содержащего план.
9. Приложение 3. Пример запроса QP к SP, содержащего программу.

1 Введение.
Search System Transfer Protocol (SSTP) является протоколом приложений (application level) для распределенных поисковых систем. По своей природе и структуре он очень напоминает широко распространенный Hypertext Transfer Protocol (HTTP см. RFC 2616). Протокол был разработан по причине того, что задача поиска информации в рамках распределенной по нескольким поисковым серверам поисковой системы имеет некоторую специфику, отличную от уже существующих протоколов приложений. Говоря о протоколе приложений, понимаются внутренние c с точки зрения поисковой системы приложения и их взаимодействие. С внешними приложениями разрабатываемая поисковая система взаимодействует посредством HTTP. Текущая версия протокола определяется как "SSTP/1.0".
1.1 Назначение.
Основным назначением протокола является стандартизация и унификация взаимодействия компонент распределенной поисковой системы.
1.2 Термины и понятия.
Данная спецификация использует некоторые понятия и термины, требующие пояснения. В документе используются понятия на русском и английском языках.

Соединение (connection)
Виртуальная цепь транспортного уровня, установленная между двумя программами с целью обмена данными.

Сообщение (message)
Базовая единица SSTP соединения, состоящая из последовательности структурированных восьми битных данных с определенным синтаксисом, передаваемая или принимаемая через соединение.

Запрос (request)
SSTP сообщение запроса данных.

Ответ (response)
SSTP сообщение, содержащее запрошенные данные.

Заголовок (header)
Фрагмент структурированных данных SSTP сообщения, отделенных от остальной части пустой строкой (последовательностью символов CR/LF/CR/LF).

Параметр (entry)
Фрагмент заголовка, содержащий 8-битные данные и заканчивающийся последовательностью символов CR/LF (строка). Параметр состоит из 2-х частей: имя параметра (entry-name) и значение параметра (entry-value). В пределах одной строки может содержаться только один параметр. Имя параметра отделяется от значения параметра символом ':'. Для удобства чтения и контроля значению параметра предшествует символ 'пробел' (space).

Код запроса (request code)
Числовое значение, условно обозначающее код затребованной операции. Используется десятичное представление в виде строки ASCII символов. Любой запрос или ответ начинается с кода запроса.

Описание ресурса (URL info)
Часть заголовка, совокупность параметров, полностью описывающая информацию о ресурсе.

Идентификатор документа (doc ID)
Уникальный номер, присваиваемый один раз описанию ресурса и наследуемый им на время жизни описания ресурса. Идентификатор документа не изменяется. При логическом удалении описания ресурса этот номер не может быть повторно выдан новому описанию ресурса.

Клиент (client)
Программа, инициирующая соединение для посылки запроса.

Сервер (server)
Программа, ждущая установления соединения для обслуживания запросов клиента посредством пересылки затребованной информации. Любая программа, входящая в Поисковую Систему (Search System) может являться как клиентом, так и сервером в разные моменты времени, а может являться только клиентом или исключительно сервером.

Накопитель Данных Crawler Agent (CA)
Программа, ответственная за накопление данных и их первоначальную обработку. Подробнее см. документацию на Crawler Agent.

Актуализатор Robots Agent (RA)
Программа, периодически проверяющая состояние внешних разрешающих файлов robots.txt на внешних серверах ресурсов. См. Стандартные методы исключения документов из числа сканируемых http://www.robotstxt.org/wc/exclusion.html

Диспетчер Dispatcher Server (DS)
Программа, управляющая работой CA, координирующая синхронизацию конфигурационных установок для различных подсистем и пр. Подробнее см. документацию на Dispatcher Server.

Архивер Archive Server (AS)
Программа аккумуляции накопленных 'сырых' данных CA. Подробнее см. документацию на Archive Server.

Индексатор Indexer (IS)
Программа, собирающая предобработанные данные от CA, объединяющая их, формирующая индекс, приспособленный для поиска и извлечения ID документов, их ранжирования и передающая построенные части индекса на ответственные за их хранение и поиск Процессоры Поиска (Search Processors). Подробнее см. документацию Indexer.

Процессор Поиска Search Processor (SP)
Программа, принимающая порции данных своей компетенции от Индексатора, осуществляющая их хранение, перестроение и поиск по локальной порции индекса. Подробнее см. документацию Search Processor.

Оптимизатор Запросов (Query Parser)
Программа, строящая планы взаимодействия SP для нахождения искомой последовательности ID документов, удовлетворяющих условиям запроса поиска. Является также посредником между отображающей компонентой HTTP протокола и системой поиска. Подробнее см. документацию Query Parser.

Балансировщик Нагрузок Load Balancer (LB)
Программа координации работы совокупности QP для оптимального выбора свободной группы SP. Является также Кэш Сервером результатов отработанных поисковых запросов. Подробнее см. документацию Load Balancer.

Сервер похожих документов Similarity Server (SS)
Программа выделения из массива идентификаторов документов части, содержащей общие куски содержания документа. Необходима для удаления из выборки "неявных" дублей документов. Подробнее см. документацию Similarity Fingerprints Server.

/r/n
Обозначает последовательность символов CR/LF (новая строка)

1.3 Общие принципы работы.
SSTP протокол является протоколом запросов и ответов. Каждый запрос начинается с кода запроса и содержит произвольное количество параметров в заголовке запроса. Для некоторых типов запросов существует набор обязательных параметров, их количество и список зависят от кода запроса и будут описаны ниже. Заголовок запроса отделяется от остальной части запроса последовательностью символов CR/LF с новой строки. Запрос содержит заголовок и опционально расширенные данные, содержащиеся в теле запроса. Из этого следует, что последовательность символов CR/LF/CR/LF должна интерпретироваться сервером как конец описания запроса и началом расширенных данных (если таковые специфицированы). При наличии расширенных данных в запросе их длина в байтах должна быть специфицирована в одном из параметров заголовка запросов (описано ниже). Все имена параметров (entry-name) специфицированы в данном документе. Регистр символов в имени параметра не имеет значения. Значения параметров (entry-value) могут быть как строковые, так и цифровые (однако в любом случае - печатные (printable). Регистр символов значений параметров важен. Если значение поля является числом, то оно интерпретируется как десятичное, при условии, что иное не оговорено в данной документации. Все вышесказанное в полной мере соответствует и ответу сервера на запрос клиента. Последовательность запросов и ответов составляет транзакцию взаимодействия клиент/сервер. В рамках одной транзакции количество запросов и ответов не ограничено. Некоторые специальные запросы не требуют ответа либо какого-нибудь подтверждения (например, запрос остановки процесса).
В общем виде, сообщение представляет собой:
OPERATION_CODE\r\n
Mandatory_Field1: Value1\r\n
Mandatory_Field2: Value2\r\n
┘┘┘.
┘┘┘.
Optional_FieldN: ValueN\r\n
\r\n
[EXTENDED_DATA]
Текстовый (printable) характер передачи заголовка сообщения определяет простоту отладки отдельных компонент Поисковой Системы и их взаимодействия в целом. В качестве транспортной среды SSTP обычно использует TCP/IP соединения. Для установления соединения используются конфигурационно настраиваемые номера портов. Т.к. в рамках одного компьютера могут быть установлены различные компоненты поисковой системы (в пределе, все компоненты), значения по умолчанию для различных компонент разные. Это не означает, что транспортом может быть использован только TCP/IP, любой протокол более низкого уровня, чем SSTP, гарантирующий целостность соблюдения описываемых требований может быть использован.
2. Коды запроса (ответа).
Код запроса (или ответа) всегда открывает сообщение, представляет собой строку в виде десятичного представления кода запроса, оканчивающуюся комбинацией символов CR/LF. В документе использованы MACRO определения кодов и их числовые значения. Все коды запроса/ответа HTTP/1.1 включены в спецификацию SSTP, однако реакция на них специфична в зависимости от компонент взаимодействия.
2.1 SSTP специфичные коды.
Ряд кодов запроса специфичен для SSTP и предназначен исключительно для внутреннего взаимодействия отдельных компонент Поисковой Системы.
2.1.1 001 REQ_GET_URLINFO

Область применения:
Взаимодействие CA и DS.
Описание:
Накопитель Данных (CA) требует от диспетчера новой порции информации о новом объекте для сканирования. Запрос может состоять только из кода запроса без параметров. По данному запросу сервер должен вернуть клиенту описание ресурса для сканирования с перечислением всех необходимых параметров. В случае отсутствия нового объекта для накопления в очереди объектов (конец очереди или все документы отсканированы) сервер должен возвратить в качестве параметра URL ID (Uid - см. раздел Параметры) значение равное 0. Это может являться сигналом окончания работы для клиента. Если запрос клиента состоял не только из кода запроса, но и параметров описания ресурса, то сервер должен интерпретировать эти параметры как руководство к изменению объекта, описанного в параметрах. Не зависимо от того, были произведены действия с объектом параметров или нет, сервер должен сообщить параметры нового объекта сканирования. Данный запрос требует авторизации (см. 4).
Результат выполнения запроса:
сервер закрывает соединение.

2.1.2 002 REQ_PUT_HOST_NOTFOUND

Область применения:
Взаимодействие CA и DS.
Описание:
Накопитель Данных сообщает Диспетчеру о том, что попытка сканирования объекта параметров безуспешна вследствие отсутствия Domain Name System (DNS) записи для указанного в параметрах сервера. Внимание: истечение таймаута взаимодействия клиента с DNS не может и не должно являться причиной посылки подобного запроса для CA к DS. Такой причиной может являться только авторизованный ответ от DNS типа "HOST NOT FOUND" или "NO DATA ADDRESS". Сервер при получении подобного запроса обязан произвести логическое удаление всех ресурсов, связанных с IP адресом описанного в параметрах ресурса из очереди сканирования. Ответом сервера является описание нового ресурса для сканирования, как это описано в 2.1.1. Данный запрос требует авторизации (см. 4).
Результат выполнения запроса:
сервер закрывает соединение.

2.1.3 003 REQ_PUT_HOST_UNRICHABLE

Область применения:
Взаимодействие CA и DS.
Описание:
CA сообщает DS о невозможности установки HTTP соединения с указанным в параметрах ресурсом. Сервер при получении подобного запроса может временно исключить из очереди ресурс (в зависимости от его стратегии). Ответом сервера должно быть описание нового ресурса для сканирования. Данный запрос требует авторизации (см. 4).
Результат выполнения запроса:
сервер закрывает соединение.

2.1.4 006 REQ_PUT_DATA

Область применения:
зарезервировано
Описание:
в настоящий момент не применяется

2.1.5 007 REQ_GET_MD5

Область применения:
Взаимодействие CA и DS.
Описание:
Клиент запрашивает у сервера по предвычисленной комбинации MD5, характеризующей документ сканированного ресурса, существующий для данной комбинации URL ID. Запрос предназначен для удаления полных дублей документов. Сервер по данному запросу должен вернуть клиенту неизменными все параметры описания ресурса, кроме параметра ID ресурса. Если данная комбинация MD5 уже известна для какого-либо ресурса, то сервер в качестве параметра ID ресурса обязан вернуть его ID в соответствующем параметре, иначе просто оставить поле ID неизменным. Данный запрос требует авторизации (см. 4).
Результат выполнения запроса:
сервер закрывает соединение.

2.1.6 008 REQ_GET_URL_BYNAME

Область применения:
Взаимодействие CA и DS.
Описание:
Клиент требует у сервера полное описание ресурса, заданного в параметрах. Сервер должен вернуть полное описание ресурса в виде набора параметров. Данный запрос требует авторизации (см. 4).
Результат выполнения запроса: сервер закрывает соединение.

2.1.7 010 REQ_GET_URL_BYID

Область применения:
Взаимодействие CA и AS, взаимодействие QP и AS. В настоящий момент не используется, заменено на REQ_GET_URLOBJECT и REQ_GRT_URLDOCUMENT (см. 2.1.36 и 2.1.37)
Описание:
Клиент требует у сервера полное описание ресурса, заданного в параметре. Сервер должен вернуть полное описание ресурса в виде набора параметров. Данный запрос требует авторизации (см. 4).
Результат выполнения запроса:
сервер закрывает соединение.

2.1.8 011 REQ_GET_QUEUERESET

Область применения:
Взаимодействие CA и DS.
Описание:
CA требует у DS обновить очередь документов. Применяется в случае если CA получил сообщение об окончании очереди для сканирования ресурсов. Сервер должен осуществить все необходимые действия (возможно, обработать ранее временно сохраненную информацию) для обновления очереди. Логически сервер должен установить текущее состояние очереди для данного CA на ее начало и выдать первое описание ресурса, удовлетворяющее требованиям CA. Каждый CA вправе иметь собственную логическую очередь для сканирования на стороне DS. Данный запрос требует авторизации (см. 4).
Результат выполнения запроса:
сервер закрывает соединение.

2.1.9 012 REQ_GET_EXCLUDE

Область применения:
Взаимодействие CA и DS.
Описание:
Клиент требует у сервера описание шаблонов, которые определены для данного CA как шаблоны для включения в/исключения из списка возможных URL для сканирования данным CA. Авторизация CA производится соответствующими параметрами, содержащими имя сканера (username) и пароль (password). Списки параметров ведутся централизованно на DS. В случае успеха авторизации сервер возвращает клиенту список шаблонов клиента. Правила оформления шаблонов описаны в документации Dispatcher Server. Данный запрос требует авторизации (см. 4).
Результат выполнения запроса:
сервер закрывает соединение.

2.1.10 013 REQ_GET_SERVICES

Область применения:
Взаимодействие CA и DS.
Описание:
Клиент требует у сервера список разрешенных сервисов (протоколов) для сканирования внешних объектов. Такими протоколами могут являться, например, HTTP, FTP, GOPHER и пр., а также их псевдонимы, определенные для OS клиента однозначно. Конфигурация разрешенных сервисов ведется централизовано на DS. После успешной авторизации DS сообщает CA список разрешенных для него протоколов. В своей работе CA может и должен использовать только разрешенные протоколы. Правила оформления списка см. документацию Dispatcher Server. Запрос требует авторизации (см. 4).
Результат выполнения запроса:
сервер закрывает соединение.

2.1.11 014 REQ_GET_MIME

Область применения:
Взаимодействие CA и DS, взаимодействие AS и DS.
Описание:
Клиент требует у сервера список разрешенных для обработки (сканирования, сохранения и пр.) типов MIME. Тип определяется по возможному расширению имени URI. Для конкретных типов список может содержать описание внешних фильтров-преобразователей документа в пригодный для обработки формат. Правила для оформления списков MIME приведены в документации на Dispatcher Server. Сервер ведет централизованную конфигурацию для различных CA различных списков разрешенных типов MIME (в пределе, для каждого клиента свой список). Запрос требует авторизации (см. 4).
Результат выполнения запроса:
сервер закрывает соединение.

2.1.12 015 REQ_GET_ARCHIVERS

Область применения:
Взаимодействие CA и DS.
Описание:
Клиент требует у сервера список Архивных Серверов (AS), ответственных за порции хранения накопленных данных для возможного последующего взаимодействия с ними (сохранения накопленных результатов). Каждый AS отвечает за собственную порцию хранимых документов, определяемую централизовано на DS. Правила оформления списков Архивных Серверов см. документацию Dispatcher Server. Сервер возвращает клиенту полный список AS серверов. Запрос требует авторизации (см. 4).
Результат выполнения запроса:
сервер закрывает соединение.

2.1.13 016 REQ_GET_PW

Область применения:
Взаимодействие AS и DS.
Описание:
Клиент требует у сервера список данных авторизации для тех внешних клиентов, которые имеют право обращаться к клиенту данного взаимодействия с запросами. Сервер обязан выдать перечень авторизационной информации разрешенных для данного клиента соединений. Строение авторизационной информации описано в документации Dispatcher Server. Запрос требует привилегированной авторизации (см. 4).
Результат выполнения запроса:
сервер закрывает соединение.

2.1.14 017 REQ_GET_ALLOW

Область применения:
Взаимодействия AS и DS, SP и DS.
Описание:
Клиент требует у сервера конфигурационный список разрешенных для соединения внешних компьютеров (IP или доменных имен). Списки ведутся централизованно на DS. Сервер выдает клиенту набор шаблонов, разрешающих или запрещающих соединения с внешними инициаторами соединения. Правила оформления шаблонов описаны в документации Dispatcher Server. Запрос требует привилегированной авторизации (см. 4).
Результат выполнения запроса:
сервер закрывает соединение.

2.1.15 018 REQ_GET_DOMAINS

Область применения:
Взаимодействие CA и DS.
Описание:
В процессе работы клиенту требуется список существующих доменов первого уровня (например, для определения правильности написания ссылки во внешнем документе). Сервер выдает клиенту данный список, который ведется на сервере централизованно для всех клиентов. Правила оформления списка доменов первого уровня указаны в документации на Dispatcher Server. Запрос требует авторизации (см. 4).
Результат выполнения запроса:
сервер закрывает соединение.

2.1.16 019 REQ_GET_ROBOTS

Область применения:
Взаимодействие RA и DS.
Описание:
Клиент запрашивает у сервера описание ресурса для извлечения правил сканирования ресурса, определяемых в robots.txt. Сервер возвращает описание ресурса для сканирования. В пределе сервер ведет для каждого RA собственную очередь сканирования ресурсов robots.txt. Если очередь для сканирования закончена, то в качестве идентификатора ID ресурса сервер возвращает "0". Запрос требует авторизации (см. 4).
Результат выполнения запроса:
сервер закрывает соединение.

2.1.17 020 REQ_PUT_ROBOTS

Область применения:
Взаимодействие RA и DS.
Описание:
Клиент передает серверу полученное новое описание шаблонов сканирования для данного ресурса из robots.txt ресурса. Сервер должен актуализовать новые правила сканирования для данного ресурса и возможно перестроить очереди сканируемых документов, исключив из них или добавив в них разрешенные/запрещенные URL ресурсов. Ответом сервера должно быть описание нового ресурса для сканирования robots.txt. Если очередь на сканирование исчерпана, то клиенту в качестве описания возвращается ID ресурса с номером "0". Запрос требует авторизации (см. 4).
Результат выполнения запроса:
сервер закрывает соединение.

2.1.18 021 REQ_RESET_ROBOTS

Область применения:
Взаимодействие RA и DS.
Описание:
Клиент требует у сервера инициировать свою очередь для сканирования robots.txt в начальное положение. Сервер должен установить текущее положение очереди клиента на первый ресурс для сканирования robots.txt и вернуть клиенту его полное описание. Запрос требует авторизации (см. 4).
Результат выполнения запроса:
сервер закрывает соединение.

2.1.19 022 REQ_GET_SEARCHER

Область применения:
Взаимодействие IS и DS.
Описание:
Клиент требует у сервера список первичных SP для передачи им обработанного индекса. Каждый SP отвечает за свою порцию индекса, в пределах которой может производить поиск. Сервер возвращает список шаблонов и адреса серверов SP ответственных за порции. Правила оформления конфигурационного файла списка SP и сфер их ответственности описаны в документации Dispatcher Server и Search Processor. Запрос требует авторизации (см. 4).
Результат выполнения запроса:
сервер закрывает соединение.

2.1.20 023 REQ_GET_SCANERS

Область применения:
Взаимодействие IS и DS.
Описание:
Клиент требует у сервера конфигурационный список накопителей данных Поисковой Системы (список CA) для возможности забрать у них результаты их накопления. Список возможных и активных CA ведется централизовано на DS. Сервер сообщает клиенту список доступных CA. Правила оформления списка описаны в документации Dispatcher Server. Запрос требует авторизации (см. 4).
Результат выполнения запроса:
сервер закрывает соединение.

2.1.21 024 REQ_RELOAD_CONFIG

Область применения:
Взаимодействие Администратора Поисковой Системы и DS.
Описание:
Администратор требует у DS выгрузить все конфигурационные файлы и заново их перечитать. Сервер должен выполнить требование и сообщить статус выполнения обновления всех новых конфигурационных файлов. Запрос требует привилегированной авторизации (см. 4).
Результат выполнения запроса:
сервер закрывает соединение.

2.1.22 025 REQ_GET_STATS

Область применения:
Взаимодействие Администратора Поисковой Системы и DS, Администратора Поисковой Системы и AS..
Описание:i
Сервер передает клиенту статистические данные его работы. В зависимости от типа сервера данные могут быть различными. Запрос используется для отладки администрирования комплексом Поисковой Системы и Web-интерфейсом администратора. Запрос имеет HTTP аналог для обращения к DS http://dispatcher.yuor.domain/stats. Ответ сервера в стандарте HTTP/1.0. Запрос требует HTTP авторизации и привилегированной SSTP авторизации. Подробнее см. Administrator Guide.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.23 026 REQ_HTTP_GETALLOW

Область применения:
Взаимодействие Администратора Поисковой Системы с DS.
Описание:
Администратор требует текущую конфигурацию списка разрешенных удаленных компьютеров для соединения с целью их редактирования. Сервер возвращает текущие конфигурационные значения. Функция отладки Web-интерфейса администрирования серверов Поисковой Системы. Запрос имеет HTTP аналог http://dispatcher.your.domain/getallow. Ответ сервера в стандарте HTTP/1.0. Запрос требует HTTP авторизации и привилегированной SSTP авторизации (см. 4). Подробнее см. Administrator Guide.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.24 027 REQ_HTTP_GETMIME

Область применения:
Взаимодействие Администратора Поисковой Системы с DS.
Описание:
Администратор требует текущую конфигурацию списка разрешенных для сканирования типов MIME и перечень фильтров с целью их редактирования. Сервер возвращает текущие значения. Функция отладки Web-интерфейса администрирования серверов Поисковой Системы. Запрос имеет HTTP аналог http://dispatcher.your.domain/getmime. Ответ сервера в стандарте HTTP/1.0. Запрос требует HTTP авторизации и привилегированной SSTP авторизации (см. 4). Подробнее см. Administrator Guide.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.25 028 REQ_HTTP_GETARCHIVERS

Область применения:
Взаимодействие Администратора Поисковой Системы с DS.
Описание:
Администратор требует текущую конфигурацию списка ответственных за хранение Архивных Серверов (AS) с целью их редактирования. Сервер возвращает текущие значения. Функция отладки Web-интерфейса администрирования серверов Поисковой Системы. Запрос имеет HTTP аналог в виде http://dispatcher.your.domain/getarchivers. Ответ сервера в стандарте HTTP/1.0. Запрос требует HTTP авторизации и привилегированной SSTP авторизации (см. 4). Подробнее см. Administrator Guide.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.26 029 REQ_HTTP_GETSCANERS

Область применения:
Взаимодействие Администратора Поисковой Системы с DS.
Описание:
Администратор требует текущую конфигурацию списка активных накопителей данных (CA) Поисковой Системы с целью их редактирования. Сервер возвращает текущие установочные значения. Функция отладки Web-интерфейса администрирования серверов Поисковой Системы. Запрос имеет HTTP аналог http://dispatcher.your.domain/getscaners. Ответ сервера в стандарте HTTP/1.0. Запрос требует HTTP авторизации и привилегированной SSTP авторизации (см. 4). Подробнее см. Administrator Guide.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.27 030 REQ_HTTP_GETUSER

Область применения:
Взаимодействие Администратора Поисковой Системы с DS.
Описание:
Администратор требует текущую конфигурацию списка разрешенных данных SSTP авторизации Поисковой Системы с целью их редактирования. Сервер возвращает текущие установочные значения. Функция отладки Web-интерфейса администрирования серверов Поисковой Системы. Запрос имеет HTTP аналог http://dispatcher.your.domain/getuser. Ответ сервера в стандарте HTTP/1.0. Запрос требует HTTP авторизации и привилегированной SSTP авторизации (см. 4). Подробнее см. Administrator Guide.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.28 031 REQ_HTTP_PUTALLOW

Область применения:
Взаимодействие Администратора Поисковой Системы с DS.
Описание:
Администратор требует переустановить текущую конфигурацию списка разрешенных для соединения внешних инициаторов. Сервер зачитывает установочные значения, сохраняет в своем конфигурационном файле с целью дальнейшего использования новых значений. Функция отладки Web-интерфейса администрирования серверов Поисковой Системы. Запрос имеет HTTP аналог http://dispatcher.your.domain/putallow. Ответ сервера в стандарте HTTP/1.0. Запрос требует HTTP авторизации и привилегированной SSTP авторизации (см. 4). Подробнее см. Administrator Guide.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.29 032 REQ_HTTP_PUTARCHIVERS

Область применения:
Взаимодействие Администратора Поисковой Системы с DS.
Описание:
Администратор требует переустановить текущую конфигурацию списка ответственных за сохранение сканированных данных (AS). Сервер зачитывает установочные значения, сохраняет в своем конфигурационном файле с целью дальнейшего использования новых значений. Функция отладки Web-интерфейса администрирования серверов Поисковой Системы. Запрос имеет HTTP аналог http://dispatcher.your.domain/putarchivers. Ответ сервера в стандарте HTTP/1.0. Запрос требует HTTP авторизации и привилегированной SSTP авторизации (см. 4). Подробнее см. Administrator Guide.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.30 033 REQ_HTTP_PUTSCANERS

Область применения:
Взаимодействие Администратора Поисковой Системы с DS.
Описание:
Администратор требует переустановить текущую конфигурацию списка ответственных за сканирование данных (CA). Сервер зачитывает установочные значения, сохраняет в своем конфигурационном файле с целью дальнейшего использования новых значений. Функция отладки Web-интерфейса администрирования серверов Поисковой Системы. Запрос имеет HTTP аналог http://dispatcher.your.domain/putscaners. Ответ сервера в стандарте HTTP/1.0. Запрос требует HTTP авторизации и привилегированной SSTP авторизации (см. 4). Подробнее см. Administrator Guide.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.31 034 REQ_HTTP_PUTSEARCHERS

Область применения:
Взаимодействие Администратора Поисковой Системы с DS.
Описание:
Администратор требует переустановить текущую конфигурацию списка ответственных за сканирование индексов и поиск информации по ним (SP). Сервер зачитывает установочные значения, сохраняет в своем конфигурационном файле с целью дальнейшего использования новых значений. Функция отладки Web-интерфейса администрирования серверов Поисковой Системы. Запрос имеет HTTP аналог http://dispatcher.your.domain/putsearchers. Ответ сервера в стандарте HTTP/1.0. Запрос требует HTTP авторизации и привилегированной SSTP авторизации (см. 4). Подробнее см. Administrator Guide.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.32 035 REQ_HTTP_PUTUSER

Область применения:
Взаимодействие Администратора Поисковой Системы с DS.
Описание:
Администратор требует переустановить текущую конфигурацию списка данных SSTP авторизации, разрешенных в Поисковой Системе. Сервер зачитывает установочные значения, сохраняет в своем конфигурационном файле с целью дальнейшего использования новых значений. Функция отладки Web-интерфейса администрирования серверов Поисковой Системы. Запрос имеет HTTP аналог http://dispatcher.your.domain/putuser. Ответ сервера в стандарте HTTP/1.0. Запрос требует HTTP авторизации и привилегированной SSTP авторизации (см. 4). Подробнее см. Administrator Guide.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.33 036 REQ_HTTP_PUTMIME

Область применения:
Взаимодействие Администратора Поисковой Системы с DS.
Описание:
Администратор требует переустановить текущую конфигурацию списка данных разрешенных типов MIME и их фильтров в Поисковой Системе. Сервер зачитывает установочные значения, сохраняет в своем конфигурационном файле с целью дальнейшего использования новых значений. Функция отладки Web-интерфейса администрирования серверов Поисковой Системы. Запрос имеет HTTP аналог http://dispatcher.your.domain/putuser. Ответ сервера в стандарте HTTP/1.0. Запрос требует HTTP авторизации и привилегированной SSTP авторизации (см. 4). Подробнее см. Administrator Guide.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.34 037 REQ_HTTP_GETSEARCHERS

Область применения:
Взаимодействие Администратора Поисковой Системы с DS.
Описание:
Администратор требует текущую конфигурацию списка ответственных за хранение порций индексов и поиск по ним (SP) с целью их редактирования. Сервер возвращает текущие значения. Функция отладки Web-интерфейса администрирования серверов Поисковой Системы. Запрос имеет HTTP аналог в виде http://dispatcher.your.domain/getarchivers. Ответ сервера в стандарте HTTP/1.0. Запрос требует HTTP авторизации и привилегированной SSTP авторизации (см. 4). Подробнее см. Administrator Guide.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.35 038 REQ_GET_OBJECTS

Область применения:
Взаимодействие QP и AS.
Описание:
Клиент требует у сервера вернуть данные для отображения результатов поиска по указанным в параметрах ID документам. Сервер возвращает расширенную информацию по объектам, включая фрагмент начала документа в соответствующих полях. Данные о документах берутся из локальной базы данных AS. Запрос не требует авторизации, считается, что взаимодействие QP и AS должно быть организовано в рамках одного сегмента локальной сети и этот сегмент заблокирован брандмауэром для внешних соединений.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.36 039 REQ_GET_DOCUMENTS

Область применения:
Взаимодействие QP и AS.
Описание:
Клиент требует у сервера вернуть данные для отображения результатов поиска по указанным в параметрах ID документам. Сервер возвращает расширенную информацию по объектам, включая фрагмент документа, наиболее релевантный указанным в параметрах поисковым терминам, в соответствующих полях. Данные о документах берутся из хранилища накопленных CA данных. Запрос требует более длительной работы AS. При превышении загрузки сервера AS конфигурационного значения (load average) запрос может быть автоматически подменен сервером на более легкий REQ_GET_OBJECTS (см. 2.1.35). Форматы выдачи результатов REQ_GET_OBJECTS и REQ_GET_DOCUMENTS одинаковы и различия заключаются только в возвращенном фрагменте текста документа. Запрос не требует авторизации, считается, что взаимодействие QP и AS должно быть организовано в рамках одного сегмента локальной сети и этот сегмент заблокирован брандмауэром для внешних соединений.
Результат выполнения запроса: сервер закрывает соединение.

2.1.37 040 REQ_GET_FULLDOCUMENT

Область применения:
Взаимодействие отображающих программ с AS.
Описание:
Клиент требует у сервера полный текст документа, указанного в параметре URL ID. Сервер возвращает текст документа в "сыром" виде. Запрос не требует авторизации, считается, что взаимодействие отображающей программы и AS должно быть организовано в рамках одного сегмента локальной сети и этот сегмент заблокирован брандмауэром для внешних соединений. Клиент может запросить у сервера конкретную версию текста документа в поле HEADER_VERSION. Если данное поле в запросе отсутствует, то это воспринимается сервером, как инструкция для выдачи самой последней (свежей) версии текста документа.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.38 041 REQ_GET_EXISTDOCUMENT

Область применения:
взаимодействие QP и AS.
Описание:
Клиент требует у сервера информацию по существующим в базе объектам ID документов. Проверяемые идентификаторы передаются клиентов в виде неограниченной последовательности параметров HEADER_URI_ID. Сервер возвращает в этих же параметрах только те ID документов, для которых в базе найдены объекты (т.е. документ был отсканирован и его образ помещен на AS).
Результат выполнения запроса:
сервер закрывает соединение.

2.1.39 042 REQ_GET_URLVERSIONS

Область применения:
Взаимодействие QP и AS.
Описание:
Клиент требует у сервера информацию по объекту и существующим версиям текста документа объекта. Сервер возвращает клиенту описание объекта. Версии текста документа указываются сервером в поле HEADER_VERSION в виде строки DDMMYYYY.
Результат выполнения запроса:
сервер закрывает соединение.
2.1.40 050 REQ_PUT_RECORD

Область применения:
Взаимодействие IS и SP.
Описание:
Клиент требует приема порции вновь отсканированной индексной информации сервером. Сервер принимает информацию по поисковому термину и объединяет ее с уже имеющейся информацией по указанному в параметрах термину. Сервер сообщает клиенту статус принятой информации и оставляет соединение активным для приема новой порции индекса. Расширенные двоичные данные сообщения интерпретируются как один рекорд поискового термина в двоичном виде. Запрос не требует авторизации, считается, что взаимодействие IS и SP должно быть организовано в рамках одного сегмента локальной сети и этот сегмент заблокирован брандмауэром для внешних соединений.
Результат выполнения запроса:
сервер оставляет соединение активным.

2.1.41 051 REQ_PUT_MODIFIED

Область применения:
Взаимодействие IS и SP.
Описание:
Клиент требует приема данных по изменившимся в процессе последней итерации сканирования ID документам. Сервер принимает ID документов, данные индексирования для которых считаются изменившимися, и будут присутствовать во входном потоке последующих запросов REQ_PUT_RECORD. Сервер нуждается в подобных данных для дальнейшего объединения нового индекса с уже существующим на нем. Расширенные двоичные данные сообщения интерпретируются сервером как последовательность ID документов каждый размерностью u_int32_t. Запрос не требует авторизации, считается, что взаимодействие IS и SP должно быть организовано в рамках одного сегмента локальной сети и этот сегмент заблокирован брандмауэром для внешних соединений.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.42 052 REQ_PUT_RANKS

Область применения:
Взаимодействие IS и SP.
Описание:
Клиент требует приема данных по изменившимся в процессе последней итерации сканирования PageRank для ID документов. Сервер принимает PageRank ID документов. Сервер нуждается в подобных данных для дальнейшего объединения нового индекса с уже существующим на нем. Расширенные двоичные данные сообщения интерпретируются сервером как последовательность PageRank документов каждый размерностью u_int32_t, порядковый номер полученных данных соответствует ID документа. Запрос не требует авторизации, считается, что взаимодействие IS и SP должно быть организовано в рамках одного сегмента локальной сети и этот сегмент заблокирован брандмауэром для внешних соединений.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.43 053 REQ_END

Область применения:
Взаимодействие IS и SP.
Описание:
Клиент сообщает серверу об окончании всех транзакций по изменению индекса. Ответа сервера не требуется. Стратегия поведения сервера может быть определена как окончание работы сервера. Запрос не требует авторизации, считается, что взаимодействие IS и SP должно быть организовано в рамках одного сегмента локальной сети и этот сегмент заблокирован брандмауэром для внешних соединений.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.44 054 REQ_REBUILD

Область применения:
Взаимодействие Администратора Поисковой Системы с SP, взаимодействие IS и SP.
Описание:
Администратор или клиент требуют полного перестроения индекса после окончания приема данных сервером, в параметре передается время последней модификации. Все записи, имеющие время создания меньше указанного, перестраиваются с применением таблиц, полученных при последнем запросе REQ_PUT_MODIFIED и REQ_PUT_RANKS. Запрос не требует авторизации, считается, что взаимодействие IS и SP должно быть организовано в рамках одного сегмента локальной сети и этот сегмент заблокирован брандмауэром для внешних соединений.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.45 055 REQ_TRANSFER_END

Область применения:
Взаимодействие IS и SP.
Описание:
Клиент сообщает об окончании всех транзакций. Ответа сервера не требуется. Сервер немедленно закрывает все соединения и остается в ожидании нового запроса на соединение. Запрос не требует авторизации, считается, что взаимодействие IS и SP должно быть организовано в рамках одного сегмента локальной сети и этот сегмент заблокирован брандмауэром для внешних соединений.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.46 056 REQ_GET_WORD
Область применения:
Взаимодействие QP и SP.
Описание:
Запрос клиентом ID документов, в которых встречается поисковый термин, указанный в качестве параметра запроса. Сервер возвращает затребованную запросом порцию ID документов указанного размера и отранжированную в порядке убывания веса соответствия поискового термина документу. Запрос не требует авторизации, считается, что взаимодействие QP и SP должно быть организовано в рамках одного сегмента локальной сети и этот сегмент заблокирован брандмауэром для внешних соединений.
Результат выполнения запроса:
сервер закрывает соединение.
Пример:
56\r\n
swd: turtle\r\n
lgs: 1\r\n
str: 30\r\n
nrs: 15\r\n
ws: 0\r\n
\r\n
Будут найдены ID документов, содержащих поисковый термин 'turtle'. Документы должны быть на английском языке (код языка 0x01). Будет выдано 15 ID документов, начиная с тридцатого.
2.1.47 057 REQ_GET_EXPANDWORD
Область применения:
Взаимодействие QP и SP.
Описание:
Запрос клиентом ID документов, в которых встречается поисковый термин, указанный в качестве параметра запроса и имеющий произвольное окончание. Результирующее значение поисковых терминов с разными окончаниями не будет превышать значения конфигурационного параметра сервера (по умолчанию 100). Сервер возвращает затребованную запросом порцию ID документов указанного размера и отранжированную в порядке убывания веса соответствия поискового термина документу. Запрос не требует авторизации, считается, что взаимодействие QP и SP должно быть организовано в рамках одного сегмента локальной сети и этот сегмент заблокирован брандмауэром для внешних соединений.
Результат выполнения запроса:
сервер закрывает соединение.
Пример:
57\r\n
swd: паровоз\r\n
ws: 0\r\n
\r\n
Будут найдены ID документов, содержащих слова 'паровоз', 'пароход' и пр.
2.1.48 058 REQ_GET_MORPHWORD
Область применения:
Взаимодействие QP и SP.
Описание:
Запрос клиентом ID документов, в которых встречается поисковый термин, указанный в качестве параметра запроса или любые его словоформы для указанного языка. Если язык поискового термина не указан, то сервер пытается развернуть слово во все возможные словоформы всех известных ему языков. Результирующее количество развернутых словоформ не будет превышать значения конфигурационного параметра сервера (по умолчанию 100). Сервер возвращает затребованную запросом порцию ID документов указанного размера и отранжированную в порядке убывания веса соответствия поискового термина документу. Запрос не требует авторизации, считается, что взаимодействие QP и SP должно быть организовано в рамках одного сегмента локальной сети и этот сегмент заблокирован брандмауэром для внешних соединений.
Результат выполнения запроса:
сервер закрывает соединение.
Пример:
58\r\n
swd: соединение\r\n
blg: 7\r\n
ws: 0\r\n
\r\n
Будут найдены ID документов, в которых встречается любая словоформа термина 'соединение' (соединения, соединений, соединениями и пр.) на русском языке (код языка 0x07 согласно конфигурации).
2.1.49 059 REQ_GET_PHRASE
Область применения:
Взаимодействие QP и SP.
Описание:
Запрос клиентом ID документов, в которых встречается фраза, указанная в параметрах запроса. Последовательность поисковых терминов фразы полностью определяется запросом клиента в параметрах. Данный запрос может быть использован только при условии, что все поисковые термины находятся в рамках компетенции сервера соединения. В случае распределения поисковых терминов по разным SP следует использовать REQ_GET_PLAN с правильно составленным планом взаимодействия различных SP друг с другом. Сервер возвращает затребованную запросом порцию ID документов указанного размера и отранжированную в порядке убывания веса соответствия поискового термина документу. Запрос не требует авторизации, считается, что взаимодействие QP и SP должно быть организовано в рамках одного сегмента локальной сети и этот сегмент заблокирован брандмауэром для внешних соединений.
Результат выполнения запроса:
сервер закрывает соединение.
Пример:
59\r\n
Fld: 0x80000000\r\n
Swd: db\r\n
Swd reference\r\n
Swd: guide\r\n
Ws: 0\r\n
\r\n
В примере происходит поиск документов в пределах одного SP, содержащих фразу "db reference guide" в заголовке документов.
2.1.50 060 REQ_GET_WORDS_OPERATION
Область применения:
Взаимодействие QP и SP.
Описание:
Запрос клиентом ID документов, в которых встречаются все термины, указанные в параметрах запроса. Логическая операция между словами может быть указана в поле параметра. Последовательность поисковых терминов фразы игнорируется. Данный запрос может быть использован только при условии, что все поисковые термины находятся в рамках компетенции сервера соединения. В случае распределения поисковых терминов по разным SP следует использовать REQ_GET_PLAN с правильно составленным планом взаимодействия различных SP друг с другом. Сервер возвращает затребованную запросом порцию ID документов указанного размера и отранжированную в порядке убывания веса соответствия поискового термина документу. Запрос не требует авторизации, считается, что взаимодействие QP и SP должно быть организовано в рамках одного сегмента локальной сети и этот сегмент заблокирован брандмауэром для внешних соединений.
Результат выполнения запроса:
сервер закрывает соединение.
Пример:
60\r\n
Opr: or\r\n
Swd total\r\n
Swd: payment\r\n
Swd amount\r\n
Ws: 0\r\n
\r\n
Будут найдены документы, содержащие хотя бы один из терминов 'total', 'payment' или 'amount' (подразумевается, что индексы всех указанных поисковых терминов находятся в пределах одного SP).
2.1.51 061 REQ_GET_PLAN

Область применения:
Взаимодействие QP и SP.
Описание:
Запрос клиентом ID документов, в которых участвуют все термины, указанные в параметрах запроса в различных комбинациях, также указанных в параметрах запроса. Параметры запроса должны содержать правильно составленный план соединения с другими серверами SP, ответственными за свои части индекса по словам. Последовательность поисковых терминов и действий над ними должна образовывать польскую запись. Параметры плана должны предшествовать любым локальным параметрам SP (см. Приложение 2). Для передачи планов с SP на другой SP используется специальный конфигурационный параметр плана, данные которого пересылаются на определенный SP без изменения и запрос типа REQ_GET_BINARYPLAN. Пример запроса, содержащего план, приведен в Приложении 2. Сервер возвращает затребованную запросом порцию ID документов указанного размера и отранжированную в порядке убывания веса соответствия поискового термина документу. Запрос не требует авторизации, считается, что взаимодействие QP и SP должно быть организовано в рамках одного сегмента локальной сети и этот сегмент заблокирован брандмауэром для внешних соединений.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.52 62 REQ_GET_BINARYPLAN

Область применения:
Взаимодействие SP и SP.
Описание:
Запрос клиентом ID документов, в которых встречаются все термины, указанные в параметрах запроса. Параметры запроса должны содержать правильно составленный план соединения с другими серверами SP, ответственными за свои части индекса по словам. Для передачи планов с SP на другой SP используется специальный конфигурационный параметр плана, данные которого пересылаются на определенный SP без изменения и запрос типа REQ_GET_BINARYPLAN. Параметры поисковых терминов составляют польскую запись. Пример запроса, содержащего план, приведен в Приложении 2. Сервер возвращает затребованную запросом порцию ID документов указанного размера в виде расширенного сообщения в бинарном виде, пригодном для дальнейших манипуляций принимающим SP (пересечение, объединение и пр. с локальными для принимающего SP данными). Запрос не требует авторизации, считается, что взаимодействие SP и SP должно быть организовано в рамках одного сегмента локальной сети и этот сегмент заблокирован брандмауэром для внешних соединений.
Результат выполнения запроса:
сервер закрывает соединение.

2.1.53 63 REQ_GET_PROGRAM

Область применения:
Взаимодействие QP и SP.
Описание:
Клиент посылает серверу запрос выполнения Поисковой Программы. См документацию на Search System Assembly Language SSAL/1.0 и (6.)
Результат выполнения:
сервер закрывает соединение.

2.1.54 064 REQ_GET_BINARYPROGRAM

Область применения:
Взаимодействие SP и SP.
Описание:
В процессе выполнения поисковой программы SP оригинатор имеет необходимость взаимодействия с другим SP, ответственным за свою порцию индекса. Для этого используется этот код запроса, который описывается только в Поисковых Программах. Правила оформления Поисковых программ описаны в документации Search System Assembly Language SSAL/1.0 и упомянуты в (6.)
Результат выполнения:
сервер закрывает соединение.

2.1.55 065 REQ_GET_EXPANDINFO

Область применения:
Взаимодействие QP и SP.
Описание:
QP требует у SP список слов, имеющих основу слова, указанную в запросе в поле HEADER_SEARCH_WORD ("Swd"). При необходимости QP может ограничить максимальное количество расширяемых слов до величины, указанной в параметре HEADER_NUMLEX ("Lex"). SP возвращает все возможные слова из словаря, имеющие произвольное окончание относительно запроса и указывает количество терминов в поле HEADER_NUMLEX.
Результат выполнения:
сервер закрывает соединение.

2.1.56 070 REQ_GET_REFERENCES

Область применения:
Взаимодействие QP и DS.
Описание:
QP запрашивает у DS список ID документов, на которые ссылается документ ID запроса. Документ может быть определен в поле HEADER_URI_ID ("Uid") или в поле HEADER_URL ("Url"). В первом случае указывается числовое значение ID, во втором URL ресурса. Количество результатов и стартовая позиция результатов указывается при необходимости в полях HEADER_NUMRESULTS и HEADER_START_RESULTS соответственно. Сервер возвращает в поле HEADER_NUMRESULTS общее количество ID документов, соответствующих запросу.
Результат выполнения:
сервер закрывает соединение.

2.1.57 071 REQ_GET_REFERERS

Область применения:
Взаимодействие QP и SP.
Описание:
QP запрашивает у DS список ID документов, которые ссылается на документ ID запроса. Документ может быть определен в поле HEADER_URI_ID ("Uid") или в поле HEADER_URL ("Url"). В первом случае указывается числовое значение ID, во втором URL ресурса. Количество результатов и стартовая позиция результатов указывается при необходимости в полях HEADER_NUMRESULTS и HEADER_START_RESULTS соответственно. Сервер возвращает в поле HEADER_NUMRESULTS общее количество ID документов, соответствующих запросу.
Результат выполнения:
сервер закрывает соединение.

2.1.58 072 REQ_GET_SITEREFERENCES

Область применения:
Взаимодействие QP и SP.
Описание:
Аналогично 2.1.54, с той разницей, что запрос относится ко всему серверу. Номер ID сервера может быть передан в поле HEADER_SERVER_ID или сервер может быть непосредственно определен в поле HEADER_URL.
Результат выполнения:
сервер закрывает соединение.

2.1.59 073 REQ_GET_SITEREFERERS

Область применения:
Взаимодействие QP и SP.
Описание:
Аналогично 2.1.55, с той разницей, что запрос относится ко всему серверу. Номер ID сервера может быть передан в поле HEADER_SERVER_ID или сервер может быть непосредственно определен в поле HEADER_URL.
Результат выполнения:
сервер закрывает соединение.

2.1.60 080 REQ_GET_CACHEOBJECT

Область применения:
Взаимодействие QP и LB.
Описание:
Оптимизатор запроса, прежде чем строить программу запроса, должен выяснить наличие (или отсутствие) искомых результатов поиска в кэше сервера балансировки нагрузки, который также выполняет функции cache сервера. Для этих целей используется данный тип запроса. В качестве параметров QP устанавливает искомые значения HEADER_EXPAND_QUERY ("Exq"). Это поле является обязательным в запросе. QP также может определить интересующие его значения HEADER_ NUMRESULTS и HEADER_START_RESULTS. Если последние не указаны, то по умолчанию используются значения: количество результатов - все, стартовая позиция - 0. В случае успеха сервер возвращает этот же код операции и в параметрах HEADER_URI_ID идентификаторы документов и их веса соответственно. В случае, если объект не найден в кэше, сервер возвращает REQ_PUT_NOT_FOUND.
Результат выполнения:
сервер закрывает соединение.

2.1.61 081 REQ_PUT_CACHEOBJECT

Область применения:
Взаимодействие QP и LB.
Описание:
QP после выполнения операций поиска сообщает LB о результатах в случае успешного поиска с целью кэширования этих результатов. В параметре HEADER_EXPAND_QUERY оптимизатор запроса помещает уникальную строку, характеризующую данный запрос (обязательное поле) по которой впоследствии он может извлечь результаты поиска с помощью REQ_GET_CACHEOBJECT. В качестве других параметров QP определяет поля HEADER_NUMFOUND - количество результатов поиска и группу параметров HEADER_URI_ID, содержащих идентификаторы документов и их нормированные на максимальный вес весовые коэффициенты соответствующих ID. QP может также определить HEADER_AVG_NUMFOUND - примерное количество результатов, найденное по запросу, если это значение не определено, то оно устанавливается равным HEADER_NUMFOUND.
Результат выполнения:
сервер закрывает соединение.

2.1.62 090 REQ_GET_SML

Область применения:
взаимодействие QP и SS
Описание:
Этот код запроса служит для выделения из последовательности документов, определенных во входных параметрах HEADER_URI_ID только "непохожих" документов. Степень "похожести" может быть определена во входном параметре HEADER_LIMIT - десятичное целое число от 0 до 100 (уровень в процентах).
Результат выполнения:
сервер закрывает соединение.

2.1.63 091 REQ_GET_SIMILAR

Область применения:
Взаимодействие QP и SS.
Описание:
Клиент запрашивает у сервера перечень документов, похожих на документ запроса. Документ запроса определяется параметром HEADER_URI_ID. Степень "похожести" определяется параметром HEADER_LIMIT. Сервер возвращает ID документов и их степень "похожести" клиенту в виде совокупности параметров HEADER_URI_ID.
Результат выполнения:
сервер закрывает соединение.

2.1.64 092 REQ_GET_FPS

Область применения:
Взаимодействие QP и SS.
Описание:
Клиент запрашивает у сервера перечень документов, похож их на фрагмент текста, специальным образом приготовленного. Фрагмент указывается в параметре HEADER_FINGERPRINT. Способ формирования фрагмента должен совпадать со способом формирования подобного буфера агентами сканирования. Сервер возвращает найденные документы в виде полей HEADER_URI_ID. В поле HEADER_NUMFOUND сервер сообщает общее количество найденных результатов.
Результат выполнения:
сервер закрывает соединение.

2.2 HTTP Информационные (informational).
В процессе своей работы CA, взаимодействуя с внешними серверами (носителями документов сканирования), устанавливает с ними соединение и передает оригинальные HTTP запросы. Вне зависимости от того, каков был получен ответ на запрос, надо ли над данными произвести действия обработки или нет, CA обязан информировать диспетчер DS о результатах запроса. Следующие несколько разделов коротко описывают реакцию CA на стандартные HTTP ответы от внешних серверов.
При этом CA прозрачно передает полученный от внешнего сервера код ответа в числовом представлении, дополняя сообщение информационными параметрами о запросе (URL, дата, длина данных и пр.).
2.2.1 100 REQ_PUT_CONTINUE
Согласно спецификации HTTP/1.1 такой ответ внешнего сервера обозначает, что он готов к продолжению приема сообщений. В текущей реализации взаимодействия CA и DS, накопитель просто информирует диспетчер о получении кода 100 в сообщении, содержащем полное описание ресурса. В ответ от DS должен быть получено описание нового объекта для сканирования.
2.2.2 101 REQ_PUT_SWITCHING_PROTOCOL
Код ответа означает, что необходимо переключиться на указанный тип протокола для данного ресурса. Информация передается DS и ожидается новая порция описания ресурса для сканирования.
2.3 HTTP Успешные (successful).
Данная группа ответов означает, что запрос к внешнему серверу прошел успешно. CA сообщает об этом DS, указав в заголовке полное описание ресурса. Недостающие параметры описания ресурса (например, длина документа, дата последней модификации и пр.) заполняются клиентом перед посылкой сообщения DS.
2.3.1 200 REQ_PUT_URLFOLLOW
Данные от внешнего сервера получены и обработаны. CA произвел разбор полученного документа, сохранил полученный объект в локальной базе данных (если это требуется). Произвел вычисления MD5 характеристического значения и сравнил его с предыдущим состоянием. CA убедился, что с момента последнего сканирования документ изменился и сообщает об этом DS. Локальными действиями CA могут являться временное сохранение необходимых данных с целью их дальнейшей передачи другим компонентам Поисковой Системы.
2.3.2 201 REQ_PUT_CREATED
В результате запроса CA к внешнему серверу документа новый ресурс был создан. В процессе работы CA такая ситуация не должна возникать, т.к. накопитель данных не может влиять на логику работы внешних серверов, не имеющих отношения непосредственно к поисковой системе. Однако, если по каким либо причинам такая ситуация возникает, CA обязан информировать об этом DS. В настоящий момент реакция DS на такую ситуацию заключается в занесении соответствующей записи в журнал работы для того, чтобы информировать администратора системы.
2.3.3 202 REQ_PUT_ACCEPTED
Запрос CA был успешно принят внешним сервером и подготовлен им для дальнейшей обработка. Действия CA и DS аналогичны действиям на код ответа REQ_PUT_CREATED (2.3.2).
2.3.4 203 REQ_PUT_NOT_AUTHORITIVE
CA получил от внешнего сервера данные по запросу с пометкой, что сам источник данных находился не в сфере компетенции внешнего сервера. Реакция CA и DS аналогична реакции на получение REQ_PUT_URLFOLLOW (2.3.1).
2.3.5 204 REQ_PUT_NO_CONTENT
В стандарте HTTP это фактически означает, что данных по данному запросу не будет. CA передает этот код и описание ресурса, запрос которого вызвал такой ответ внешнего сервера, на DS. С точки зрения Поисковой Системы хранение информации о подобных объектах бессмысленно. DS и CA очищают на своих сторонах всю вспомогательную информацию об объекте сканирования. DS должен предотвратить повторный вызов сканирования такого документа.
2.3.7 REQ_PUT_PARTIAL_CONTENT
CA получил от внешнего сервера порцию результатов по запросу. Реакция CA и DS аналогичны реакции на код ответа REQ_PUT_URLFOLLOW от внешнего сервера (см. 2.3.1).
2.4 HTTP перенаправление (redirection).
Если в процессе работы CA при сканировании ресурса он получил код данной группы, то фактически это означает, что данных по указанному запросу нет, а их реальное нахождение сообщает внешний сервер документов. CA обязан информировать об этом DS, а DS обязан внести соответствующие изменения для помещения данных реального адреса URL и пр. в свои базы данных с целью их дальнейшего сканирования. Диспетчер сохраняет присвоенный уникальный номер ресурса за новым его местоположением.
2.4.1 300 REQ_PUT_MULTIPLY_CHOICES
CA получил от внешнего сервера несколько реальных источников данных. CA передает DS все возможные реальные значение URL в параметрах HEADER_REFERENCE. DS обязан занести новые ссылки в локальную базу и создать соответствующие объекты для них в целях дальнейшего сканирования.
2.4.2 301 REQ_PUT_PERMANENT_REDIRECT
Данные по сканированному CA адресу постоянно находятся по другому адресу. CA информирует об этом DS. DS обязан исключить ресурс из числа сканируемых и занести новый объект с тем же присвоенным ID для сканирования.
2.4.3 302 REQ_PUT_REDIRECT
Данные по сканированному адресу временно находятся по новому адресу. CA информирует об этом DS. DS заносит новые данные для сканирования, оставив неизменными старые т.к. на следующем этапе сканирования возможна ситуация, что по указанному адресу данные будут или запрос будет перенаправлен на другой ресурс, отличный от полученного в ходе данного взаимодействия CA и внешнего сервера документа.
2.4.4 303 REQ_PUT_SEE_OTHER
Действия CA и DS аналогичны описанным в 2.4.3 REQ_PUT_REDIRECT.
2.4.5 304 REQ_PUT_USE_LOCAL_COPY
CA обнаружил, что с момента последнего сканирования документ остался неизменным и не производит ни каких локальных действий с объектом. Сообщает диспетчеру о неизменности документа. DS обновляет дату последнего сканирования объекта и переходит к следующему.
2.4.6 305 REQ_PUT_USE_PROXY
Данный код ответа означает, что клиент может получить данные по запросу только с использованием указанного прокси сервера. CA сообщает об этом DS, если полученное значение прокси ресурса конфигурационно удовлетворяет DS, то новый объект создается в базе и становится пригодным для дальнейшего сканирования. Старый объект удаляется в любом случае как бесполезный.
2.4.7 307 REQ_PUT_TEMPORARY_REDIRECT
В спецификации HTTP/1.1 такой код ответа не определен, но некоторые сервера используют его как указатель на временный адрес запрашиваемых данных. Реакция CA и DS аналогична реакции на получение кода 302 REQ_PUT_REDIRECT.
2.5 HTTP Ошибки клиента (client errors).
Если в процессе своей работы CA получает от внешнего сервера документов коды ответа данной группы, то это означает, что адреса таких документов были ошибочно получены компонентами поисковой системы в процессе сканирования (типичная ситуация - ошибка в HTML коде документа или не соблюдение синтаксиса HTML). CA обязан информировать DS о подобных ошибках, а DS обязан исключать объекты, связанные с указанными адресами из локальных баз в целях предотвращения повторных попыток сканирования подобных документов вне зависимости от причин. Однако CA обязан в каждом из случаев сообщать именно тот код ошибки, какой он получил от внешнего сервера документа т.к. стратегия работы DS с объектами сканирования может быть изменена.
2.5.1 400 REQ_PUT_BAD_REQUEST
Запрос не был распознан внешним сервером документов. CA сообщает об этом DS. DS исключает этот запрос из очереди и удаляет объект, связанный с ним их баз данных. DS передает CA следующий объект для сканирования.
2.5.2 401 REQ_PUT_AUTH_REQUIRED
Для получения данных по запросу от внешнего сервера CA должен пройти авторизацию, если CA обладает данными авторизации, то пытается выполнить запрос еще раз, используя эти данные. При неудачной попытке CA сообщает об этом DS.
2.5.3 402 REQ_PUT_PAYMENT_REQUIRED
CA обнаружил, что данный ресурс является платным, пока этот код операции зарезервирован как в HTTP/1.1 так и в SSTP/1.0. CA и DS не производят ни каких действий с информацией о ресурсе и просто переходят к следующему.
2.5.4 403 REQ_PUT_FORBIDDEN
Во взаимодействии CA с внешним сервером данных отказано. CA сообщает об этом диспетчеру. Диспетчер исключает объект из очередей и удаляет его из баз данных. Подобный код может быть также получен при взаимодействии любой компоненты Поисковой Системы с другой компонентой. На практике это означает, что данный запрос требует SSTP авторизации, которая не была использована (см. 4.) или данные SSTP авторизации были неправильно указаны. Инициатор такого кода ответа компоненты Поисковой Системы обязательно заносит данные о несостоявшемся взаимодействии в журнал работ для их дальнейшего анализа администратором системы.
2.5.5 404 REQ_PUT_NOT_FOUND
Запрос CA к внешнему серверу документа был правильным, но данных по данному запросу не обнаружено. Действия CA и DS полностью описаны в (2.5). Этот код ответа может также быть использован при взаимодействии QP и SP. На практике это означает, что по указанному поисковому запросу QP не было найдено данных.
2.5.6 405 REQ_PUT_METHOD_NOT_ALLOWED
HTTP запрос, посланный CA к внешнему серверу содержит неправильный метод (например GET вместо POST). CA анализирует поле разрешенных методов внешним сервером и если разрешенные методы не имплиментированы в CA, то он сообщает об этом DS.
2.5.7 406 REQ_PUT_NOT_ACCEPTABLE
CA принял ответ от внешнего сервера, сообщающий о невозможности найти приемлемую комбинацию данных, затребованных в параметрах запроса. Реакция CA и DS описана в (2.5).
2.5.8 407 REQ_PUT_PROXY_AUTH
Запрос, посланный CA к внешнему серверу, требует прокси авторизации. Если в параметрах описания объекта есть описание авторизации, CA должен ее использовать. При неудаче результат в виде данного кода и заголовка описания ресурса сообщаются DS.
2.5.9 408 REQ_PUT_REQUEST_TIMEOUT
Неудача в приеме данных от внешнего сервера, связанная с истечением таймаута на стороне внешнего сервера. Код ответа передается CA к DS. DS может оставить запрос в очереди, а объект, привязанный к нему, в базе данных. Такие неудачи могут восприниматься Поисковой Системой как временные.
2.5.10 409 REQ_PUT_CONFLICT
Внешний сервер не смог выполнить запрос CA по причине конфликтного состояния ресурса и запроса CA. CA информирует DS об этом. Реакция аналогична (2.5).
2.5.11 410 REQ_PUT_GONE
Данный запрос более не приемлем к внешнему серверу. Реакция аналогична описанной в (2.5).
2.5.12 411 REQ_PUT_LENGTH_REQUIRED
Внешний сервер не воспринимает запрос CA по причине отсутствия HTTP заголовка Content-Length. Если CA в описании объекта получил длину документа от DS, то он должен повторить запрос, указав это значение. В случае неудачи CA сообщает об этом DS. Реакция описана в (2.5).
2.5.13 412 REQ_PUT_PRECONDITION_FAILED

2.5.14 413 REQ_PUT_ENTRY_TOO_LARGE

2.5.15 414 REQ_PUT_REQUEST_URI_TOO_LONG

2.5.16 415 REQ_PUT_UNSUPPORTED_MEDIA_TYPE

2.5.17 416 REQ_PUT_RANGE_NOT_SATISFIABLE

2.5.18 417 REQ_PUT_EXPECTATION_FAILED
По разным причинам HTTP запрос CA к внешнему серверу не может быть выполнен (см. Спецификацию HTTP/1.1 RFC 2616). CA сообщает об этом DS. DS исключает объекты из очереди и удаляет объекты (или помечает для удаления) из базы данных. CA получает от DS описание следующего объекта сканирования.
2.6 HTTP Ошибки сервера (server errors).
В процессе взаимодействия CA с внешним сервером, накопитель (сканер) может получить от внешнего сервера один из кодов ответа, характеризующий ошибку исполнения запроса на серверной стороне. CA сообщает об этом своему DS. DS в зависимости от кода ответа либо оставляет запрос в очереди для последующего повторного исполнения, считая что ошибка носит временный характер, либо удаляет объект из очереди и из базы, полагая, что ошибка фатальная. В любом случае, результатом транзакции CA и DS будет то, что DS выдаст описание нового объекта для сканирования.
2.6.1 500 REQ_PUT_SERVER_ERROR
Ошибка не фатальная с точки зрения комплекса Поисковой Системы. Объект оставляется DS в очереди и базе.
2.6.2 501 REQ_PUT_NOT_IMPLIMENTED
Ошибка фатальная с точки зрения комплекса Поисковой Системы. Объект удаляется из очереди и базы данных DS.
2.6.3 502 REQ_PUT_BAD_GATAWAY
Ошибка фатальная с точки зрения комплекса Поисковой Системы. Объект удаляется из очереди и базы данных DS.
2.6.4 503 REQ_PUT_SERVICE_UNAVAILABLE
Ошибка фатальная с точки зрения комплекса Поисковой Системы. Объект удаляется из очереди и базы данных DS.
2.6.5 504 REQ_PUT_GATEWAY_TIMEOUT
Ошибка не фатальная с точки зрения комплекса Поисковой Системы. Объект сохраняется в очереди и базе данных DS для последующего сканирования.
2.6.6 505 REQ_PUT_VERSION_NOT_SUPPORTED
Ошибка фатальная с точки зрения комплекса Поисковой Системы. Объект удаляется из очереди и базы данных DS.
3. Параметры.
При взаимодействии отдельных компонент Поисковой Системы SSTP протокол подразумевает передачу описания содержащейся в сообщении информации с помощью параметров. Для некоторых типов сообщений наличие некоторых параметров обязательно, для других - опционально. Если переданный параметр не имеет принципиального значения для клиента или сервера, то он может быть опущен или проигнорирован. В некоторых случаях сами параметры и являются полным описанием информации, в других требуются расширенные данные (extended data). Интерпретация расширенных данных регламентируется данной спецификацией SSTP/1.0.
3.1 HEADER_SERVER_ADDR_V4

Название:
HEADER_SERVER_ADDR_V4
Имя:
Ad4
Значение:
ASCII строка, представляющая IP адрес v4 в представлении '.' (dot notation).
Пример:
Ad4: 192.168.1.1

3.2 HEADER_SERVER_ADDR_V6

Название:
HEADER_SERVER_ADDR_V6
Имя:
Ad6
Значение:
ASCII строка, представляющая IP адрес v6 в представлении ':'.
Пример:
Ad6: 1080:0:0:0:8:800:200C:417A

3.3 HEADER_AUDIO

Имя:
Aud
Значение:
ASCII строка, содержащая информацию о данных, распознанных как аудио (например CA обнаружил аудио ссылки). В настоящий момент не используется, для обозначения типа данных используются побитные флаги. Однако в будущих разработках может оказаться необходимым использование отдельного поля.
Пример:
Aud: /path/myfile.au

3.4 HEADER_AVG_NUMENTRIES

Имя:
Ave
Значение:
Цифровое значение, представляющее приблизительное количество вхождений слов в документы, найденные в результате работы группы SP. Наличие этого поля в ответе обозначает усредненный алгоритм определения соответствия ID документов запросу или, иначе говоря, что не все данные были просмотрены на полное соответствие запросу, а только часть, из которых была составлена результирующая выборка.
Пример:
Ave: 16000000

3.5 HEADER_AVG_NUMFOUND

Имя:
Avf
Значение:
Цифровое значение, представляющее приблизительное количество ID документов, найденных в результате работы группы SP. Наличие этого поля в ответе обозначает усредненный алгоритм определения соответствия ID документов запросу или, иначе говоря, что не все данные были просмотрены на полное соответствие запросу, а только часть, из которых была составлена результирующая выборка.
Пример:
Avf: 2000000

3.6 HEADER_BASELANG

Имя:
Blg
Значение:
Десятичное цифровое представление кода базового языка документа (согласно конфигурации поисковой системы) определенного накопителем. При поисковых запросах это поле обозначает, что найденные документы строго должны соответствовать языку, указанному в поле (фильтр). Значение параметра может быть представлено и в шестнадцатеричном виде с префиксом 0x┘
Пример:
Blg: 0x07

3.7 HEADER_SERVER_BPS

Имя:
Bps
Значение:
Десятичное значение последней зарегистрированной скорости обмена с сервером байт/сек. Параметр имеет информационный характер.
Пример:
Bps: 24200

3.8 HEADER_CONFIG

Имя:
Cfg
Значение: Печатная строка, содержащая структурированные данные конфигурационных параметров. Структура данных определяется типом запроса и согласовывается интерфейсами различных компонент. Например, этот параметр может использоваться для выдачи текущей конфигурации кластера SP и пр.
Пример:
Cfg: 0-1000000 archiver-001.my.domain

3.9 HEADER_CHARSET

Имя:
Chs
Значение:
Каноническое имя charset документа (например, windows-1251, ibm-866, koi8-r и пр.)
Пример:
Chs: iso-8859-1

3.10 HEADER_ERROR

Имя:
Err
Значение:
Текст описания ошибки, передаваемый в соединении при наличии ошибки в обработке на произвольном этапе цепочки взаимодействия компонент системы. Имеет отладочное назначение.
Пример:
Err: searcher-001 Memory allocation error

3.11 HEADER_ESSENCE

Имя:
Ess
Значение:
Текст фрагмента документа, наиболее релевантный заданному запросу (см. HEADER_SEARCH_WORD). Размер текста в символах конфигурационно определяется на серверной стороне.
Пример:
Ess: Этот документ посвящен проблемам┘

3.12 HEADER_EXPAND_QUERY

Имя:
Exq
Значение:
Расширенный (преобразованный) поисковый запрос, сформированный серверной стороной на основании правил, описанных в запросе клиента (например, морфологические формы поискового термина).
Пример:
Ехq: ночь | ночью | ночами | ночи | ночах & темна | темно

3.13 HEADER_EXPAND_TYPE

Имя:
Ext
Значение:
Фиксированные значения 'single' (использовать термин так как он задан), 'morph' (расширить термин до его морфологических форм, язык расширения может быть определен параметром HEADER_BASE_LANG), 'expand' (расширить слово до произвольного окончания).
Пример:
Ext: morph

3.14 HEADER_EXPAND_WORDS

Имя:
Exw
Значение:
Числовое значение количества развернутых форм слова, если подразумевалось в запросе использование расширенного запроса. Количество словоформ или слов с произвольным окончанием не может превышать определенного предела, заданного конфигурационно на сервере (по умолчанию 100).
Пример:
Exw: 56

3.15 HEADER_FIELD
Имя:
Fld
Значение:
Десятичное или шестнадцатеричное беззнаковое комплексное 32-разрядное число, определяющее фильтр для поиска термина. Младшие 8 разрядов определяют базовый язык документов выборки, старшие 8 разрядов определяют принадлежность поискового термина к определенной группе HTML тэгов (например, 0x80000000 определяет принадлежность к <TITLE>) см. описание CA. Средние 16 разрядов определяют принадлежность документов к определенной теме.
Пример:
Fld: 0x80000001
Macro определения:
#define LEX_IN_TITLE 	0x80000000 /* <TITLE> */
#define LEX_IN_HEADER	0x40000000 /* <H1>-<H6> */
#define LEX_IN_MARKED	0x20000000 /* <B>,<STRONG>,<I>,<U> etc. */
#define LEX_IN_ESSENCE	0x10000000 /* First 512 bytes of document */
#define LEX_IN_REF	0x08000000 /* in <a href="┘" */
#define LEX_IN_IMAGE	0x04000000 /* in <img src="┘" */
#define LEX_IN_VIDEO	0x02000000 /* in <a href="┘" - video reference */
#define LEX_IN_AUDIO	0x01000000 /* in <a href="┘" - audio reference */
3.16 HEADER_URI_HASH

Имя:
Hsh
Значение:
Строка, состоящая из шестнадцати чисел представляющая побайтно вычисленное для документа значение MD5. Каждый байт записывается в десятичном беззнаковом виде. Разделителем между представлением байт является 'пробел' ('space').
Пример:
Hsh: 124 0 18 4 187 14 48 255 221 0 0 1 224 221 18 7

3.17 HEADER_IMAGE

Имя:
Img
Значение:
ASCII строка, содержащая информацию о данных, распознанных как image (например, CA обнаружил ссылки на картинки). В настоящий момент не используется, для обозначения типа данных используются побитные флаги. Однако в будущих разработках может оказаться необходимым использование отдельного поля.
Пример:
Img: /place/turtle.gif

3.18 HEADER_NUMLEX

Имя:
Lex
Значение:
Количество лексем (слов), найденных обнаруженных в сканируемом документе.
Пример:
Lex: 4261

3.19 HEADER_LANGUAGES

Имя:
Lgs
Значение:
Строка, содержащая коды языков слов, найденных в сканируемом документе через символ 'пробел' ('space'). Таблица соответствия кодов языков определяется конфигурационно на DS.
Пример:
Lgs: 6 7

3.20 HEADER_MARKBEGIN

Имя:
Mbg
Значение:
Строка, содержащая префикс для выделения терминов, определенных в полях "Swd". Обычно это 'открывающий' HTML тэг.
Пример:
Mbg: <b><>u

3.21 HEADER_MAXBACKETS

Имя:
Mxb
Значение:
Максимальное количество порций ('корзин') индекса, считываемых с диска для поискового термина, указанного в поле "Swd". Каждая порция содержит в себе не более чем N значений ID документов для данного слова (N определяется конфигурационно на SP, по умолчанию 200000).
Пример:
Mxb: 3

3.22 HEADER_MARKEND

Имя:
Men
Значение:
Строка, содержащая суффикс для выделения терминов, определенных в полях "Swd". Обычно это 'закрывающий' HTML тэг.
Пример:
Men: </u></b>

3.23 HEADER_NUMCHECKED

Имя:
Nck
Значение:
Количество лексем, проверенных на словарность в документе.
Пример:
Nck: 234

3.24 HEADER_NUMENTRIES

Имя:
Nen
Значение:
Цифровое значение, представляющее точное количество вхождений слов в документы, найденные в результате работы группы SP.
Пример:
Nen: 86734

3.25 HEADER_NUMFOUND

Имя:
Nfd
Значение:
Точное количество ID документов, найденных в результате обработки поискового запроса группой SP.
Пример:
Nfd: 132

3.26 HEADER_NUMREFS

Имя:
Nrf
Значение:
Количество ссылок на другие документы, найденных в документе сканирования CA.
Пример:
Nrf: 14

3.27 HEADER_NUMRESULTS

Имя:
Nrs
Значение:
Количество ID документов, которые должен выдать SP в результате обработки поискового запроса (Значение по умолчанию 15). Максимальное значение этого поля не может превышать конфигурационно установленного параметра на SP. При превышении максимального значения, SP будет подразумевать максимально допустимое конфигурационное значение (значение по умолчанию 100).
Пример:
Nrs: 30

3.28 HEADER_THEMEFOUND

Имя:
Ntf
Значение:
Количество документов, исследуемых CA на предмет определения базовой темы документа за время своей активности и распознанных. Статистический параметр.
Пример:
Ntf: 486550

3.29 HEADER_THEMECHECKED

Имя:
Ntm
Значение:
Общее количество документов, исследуемых CA на предмет определения темы документа за время активности CA. Статистический параметр.
Пример:
Ntm: 499864

3.30 HEADER_URI_OLDHASH

Имя:
Ohs
Значение:
MD5 комбинация, вычисленная для документа в момент последнего сканирования (см. HEADER_URI_HASH). Предается от DS к CA для выяснения, не дубликат ли получил CA.
Пример:
Ohs: 0 247 221 0 1 23 45 67 124 21 78 4 76 77 2 112

3.31 HEADER_OLDURI_ID

Имя:
Oid
Значение:
ID документа, который был получен при последнем сканировании CA или присвоен DS при обнаружении ссылки. После очередного сканирования может возникнуть ситуация, что документ является точной копией какого-нибудь другого документа, ранее сканированного. Это поле позволяет отслеживать подобные ситуации на серверной стороне.
Пример:
Oid: 17

3.32 HEADER_OPERATION

Имя:
Opr
Значение:
Условное обозначение логической операции между поисковыми терминами в поисковом запросе. Возможные значения: 'and' (логическое 'И' для ID документов); 'cand' (координатное логическое 'И" - нахождение точной фразы запроса); 'or' (логическое 'ИЛИ' для ID документов); 'not' (исключение документов из списка); 'push' - занести ID документов в стек аккумулятора.
Пример:
Opr: and

3.33 HEADER_PLAN

Имя:
Pln
Значение:
Поле предназначено для занесения плана операции для внешнего SP. В процессе обработки поискового запроса возникает необходимость построения планов взаимодействия различных SP. Значения совокупности этих полей будут переданы от оригинального SP к вспомогательному SP по цепочке, как инструкции для удаленного выполнения. См 5. Планы и их оформление.
Пример:
Pln: Opr: push

3.34 HEADER_SERVER_PROTOCOL

Имя:
Prt
Значение:
Наименование протокола взаимодействия CA с внешним сервером документов для сканирования. Перечень разрешенных протоколов определяется конфигурационно на DS и един для всех CA. Значениями могут являться официальные названия протоколов, принятых в ОС или их псевдонимы (http, www, ftp и т.д.). CA должен уметь работать конфигурационно разрешенными протоколами с внешними источниками документов с целью их сканирования.
Пример:
Prt: http

3.35 HEADER_REFERENCE

Имя:
Ref
Значение:
URL (полностью канонизированный) ссылки, обнаруженной CA после сканирования в полученном документе.
Пример:
Ref: /some_place/

3.36 HEADER_SERVER_FLAGS

Имя:
Sfl
Значение:
Беззнаковое 32-х разрядное число, передающее любую необходимую вспомогательную информацию между CA и DS (например, номер сканирования). Клиент и сервер обязаны однозначно понимать информацию одинаково.
Пример:
Sfl: 38

3.37 HEADER_SERVER_ID

Имя:
Sid
Значение:
ID сервера, присвоенное DS в момент обнаружения первой ссылки на документ сервера. Каждый сервер имеет свой уникальный и неизменный идентификатор.
Пример:
Sid: 24807

3.38 HEADER_SERVER_PORT

Имя:
Spt
Значение:
Номер TCP порта внешнего сервера. Некоторые протоколы (например, HTTP) могут функционировать по различным портам. Это поле описывает подобную ситуацию, указав CA номер порта, по которому следует запросить сканируемый документ у внешнего источника. Значение по умолчанию: 80
Пример:
Spt: 8080

3.39 HEADER_SERVER_ROBOTS

Имя:
Srb
Значение:
Строка шаблона, полученная в результате сканирования robots.txt и разрешающая или запрещающая какие либо действия. Должна быть приведена CA в вид шаблона, пригодного для использования функцией fnmatch()
Пример:
Srb: */cgi-bin/*

3.40 HEADER_SERVER_ROBOTSTIME

Имя:
Srt
Значение:
Дата последнего сканирования robots.txt с описываемого ресурса в секундах.
Пример:
Srt: 998872823

3.41 HEADER_SERVER_NAME

Имя:
Srv
Значение:
Каноническое имя сервера для сканироумого ресурса, передается CA во время взаимодействия его с внешним сервером документа сканирования как адрес установления соединения и значение HTTP заголовка 'Host:'.
Пример:
Srv: turtle.rambler.ru

3.42 HEADER_START_RESULTS

Имя:
Str
Значение:
Порядковый номер в выборке поиска, начиная с которого SP должен выдать результаты QP. Значение по умолчанию - 0.
Пример:
Str: 20

3.43 HEADER_SEARCH_WORD

Имя:
Swd
Значение:
Термин для поиска SP (поисковое слово).
Пример:
Swd: security

3.44 HEADER_TITLE

Имя:
Tit
Значение:
Заголовок документа (заключенный в HTML тэге . Длина заголовка обрезается до конфигурационного значения на CA.
Пример:
Tit: Berkeley DB Reference Guide

3.45 HEADER_URL_CHECKTIME

Имя:
Uct
Значение:
Дата последнего сканирования URL в секундах.
Пример:
Uct: 998899926

3.46 HEADER_URI_FLAGS

Имя:
Ufl
Значение:
Беззнаковое 32-разрядное число, характеризующее вспомогательную информацию о ресурсе сканирования (например, номер сканирования). Однозначно одинаково интерпретируется на клиенте и сервере по договоренности.
Пример:
Ufl: 38

3.47 HEADER_URI_ID

Имя:
Uid
Значение:
Уникальный идентификатор документа, присвоенный ему во время создания объекта баз данных поисковой системы. При взаимодействии QP и SP, SP вправе поместить в это поле дополнительно вес данного документа, вычисленный на SP и нормированный на 1 относительно наибольшего веса в документах выборки. Разделителем в таком случае является символ '/'.
Пример:
Uid: 38776/0.974

3.48 HEADER_URI_LEN

Имя:
Uln
Значение:
Длина сканированного и при необходимости конвертированного документа в байтах.
Пример:
Uln: 24211

3.49 HEADER_URI

Имя:
Uri
Значение:
URI документа на внешнем сервере.
Пример:
Uri: /some/dir/file.html

3.50 HEADER_URL

Имя:
Url
Значение:
Каноническое имя ресурса URL
Пример:
/some/path/file.html

3.51 HEADER_URI_STATUS

Имя:
Ust
Значение:
Беззнаковое 32-х разрядное число, биты 0-3: код протокола, биты 4-7: код charset (согласно конфигурации), биты 8-15: код базового языка документа (согласно конфигурации), биты 16-31 - код темы документа (согласно конфигурации).
Пример:
Ust: 0

3.52 HEADER_URI_TIME

Имя:
Utm
Значение:
Дата создания документа в секундах. Если внешний сервер не сообщает ее (HTTP заголовок Last-Modified: ), то присваивается значение даты сканирования.
Пример:
Utm: 999981892

3.53 HEADER_VIDEO

Имя:
Vid
Значение:
Информация, интерпретируемая CA как относящаяся к видео материалам. В настоящий момент не используется.
Пример:
Vid: http://host.domain/file.mp3

3.54 HEADER_XCONTENT_LEN

Имя:
Xcl
Значение:
Длина расширенных данных в компрессированном виде, передаваемая CA к AS. (Длина компрессированного документа).
Пример:
Xcl: 24221

3.55 HEADER_NUMWORDS

Имя:
Wrd
Значение:
Количество видимых на экране лексем документа, обнаруженных в нем после сканирования.
Пример:
Wrd: 48

3.56 HEADER_QUERY_TIME

Имя:
X-time
Значение:
Время в секундах, затраченное сервером на выполнение запроса клиента без учета передачи данных по сети.
Пример:
X-time: 0.0045

3.57 HEADER_CURBACKET

Имя:
Cb
Значение:
Текущее значение обработанных "корзин" запроса. Используется при взаимодействии SP друг с другом, чтобы последнее звено цепочки SP могло определить количество обработанных данных и приблизительно оценить размер реальной результирующей выборки.
Пример:
Cb: 8

3.58 HEADER_NUMBACKETS

Имя:
Nb
Значение:
Общее количество "корзин", составляющих данные терминов поискового запроса. Используется при взаимодействии SP друг с другом, чтобы последнее звено цепочки SP могло определить количество обработанных данных и приблизительно оценить размер реальной результирующей выборки.
Пример:
Nb: 16

3.59 HEADER_TIME

Имя:
Tm
Значение:
Время начала "заливки" новой порции индекса IS на группу SP в секундах. Используется как timestamp для нахождения записей индекса, которые были изменены за последнюю итерацию обновления индекса.
Пример:
Tm: 994976654

3.60 HEADER_TEMPRES

Имя:
Tr
Значение:
Промежуточные результаты выполнения операций по цепочке взаимодействующих SP. Имеют отладочное значение и могут быть использованы визуализатором для выведения дополнительной информации о ходе выполнения запроса (например, сколько данных было найдено для каждого отдельного термина запроса). Формируются SP для QP.
Пример:
Tr: discovery/1256

3.61 HEADER_COMPRESSSIZE

Имя:
Wc
Значение:
Размер компрессированных данных индекса по одному слову, передаваемых от IS к SP. В настоящий момент не используется, при загрузке новой порции индекса принято целесообразным проводить компрессирование данных на стороне QP это позволяет сократить время передачи индекса от IS на несколько SP.
Пример:
Wc: 338766

3.62 HEADER_WORD

Имя:
Wd
Значение:
Поисковый термин, для которого данные передаются от IS к SP.
Пример:
Wd: references

3.63 HEADER_COMPRESSEXTSIZE
Имя:
We
Значение:
Размер дополнительных данных поискового термина, передаваемых от IS к SP. В настоящий момент не используется по причине, описанной в 3.61.
Пример:
We: 87315
3.64 HEADER_IDS

Имя:
Wi
Значение:
Количество ID документов в передаваемой порции индекса от IS к SP. Это значение необходимо SP для правильной интерпретации элементов структуры принимаемых от IS индексных данных.
Пример:
Wi: 479083

3.65 HEADER_WORDLEN

Имя:
Wl
Значение:
Длина поискового термина в символах, для которого данные от IS будут переданы на SP.
Пример:
Wl: 7

3.66 HEADER_DATASIZE

Имя:
Ws
Значение:
Общий размер не компрессированных данных для поискового термина, передаваемых от IS к SP при индексировании или при передаче от одного SP к другому при выполнении поискового запроса. При взаимодействии QP и SP это поле должно быть обязательно установлено в 0.
Пример:
Ws: 0

3.67 HEADER_EXTRA

Имя:
Exr
Значение:
Текстовая строка произвольного содержания, сохраняемая сервером и никак не интерпретируемая, в дальнейшем может быть возвращена клиенту при новом запросе. Используется, например, при взаимодействии QP с LB для сохранения промежуточных результатов поиска.

3.68 HEADER_ESSENCE_LEN

Имя:
Esl
Значение:
Длина фрагмента документа, предназначенного для визуализации QP. Используется при взаимодействии QP и AS. Определяет размер искомого, релевантного запросу, фрагмента текста.
Пример:
Esl: 256

3.69 HEADER_FINGERPRINT

Имя:
Fpt
Значение:
последовательность шестнадцатиричных чисел, разделенных пробелами (space), характеризующая данный документ методом fingerprints (см. libsml.a описание).
Пример:
Fpt: 34b5 27a8c 3285 97

3.70 HEADER_SORT_OPTIONS

Имя:
Sop
Значение:
Может содержать следующие термины: 'time' - отсортировать выборку по времени создания документов, 'hosts' - сгруппировать выборку по серверам, 'title' - исключить из выборки документы с одинаковым заголовком, 'dup' - исключить из выборки документы.
Пример:
Sop: hosts

3.71 HEADER_LIMIT

Имя:
Lim
Значение:
Десятичное целое число в интервале от 0 до 100. Обозначает порог срабатывания при определении похожих документов по технологии fingerprints в процентах.
Пример:
Lim: 94

3.72 HEADER_HRQ

Имя:
Hrq
Значение:
Строка запроса клиента пригодная для повторного выполнения поиска.

3.72 HEADER_VERSION

Имя:
Vrs
Значение:
Строка вида DDMMYYYY, указывающая дату создания документа (или дату последнего сканирования, если дата создания не известна.

4. Авторизация и система безопасности (authorization and security).
Система безопасности Поисковой Системы имеет несколько уровней защиты. Один из них реализуется на уровне SSTP протокола путем авторизации инициатора соединения на сервере. Каждому субъекту взаимодействия в рамках Поисковой Системы присваивается уникальное имя и выдается пароль. Базу данных таких идентификаторов ведет администратор системы на DS. Авторизация также имеет своей целью проследить последовательность действий отдельной компоненты в условиях сложной распределенной системы, протоколировать статистические характеристики элемента взаимодействия и пр. Для некоторых взаимодействий такая авторизация является необходимым условием (Например, CA и DS), для других (например, QP и SP) такой необходимости нет.
4.1 HEADER_USER

Имя:
X-user
Значение:
Присвоенное администратором имя пользователя системы.
Пример:
X-user: searcher-001

4.2 HEADER_PASSWORD

Имя:
X-pass
Значение:
Присвоенный администратором пароль для проверки.
Пример:
X-pass: %34#567k

5. Поисковые Планы и их оформление.
Планом называется запрос QP к SP, который в силу распределенности поискового индекса по нескольким SP может быть выполнен только путем внутреннего взаимодействия SP оригинатора с другими SP, отвечающими каждый за свою порцию индекса. Взаимодействие различных SP для удовлетворения запроса QP происходит с помощью SSTP и полностью в рамках его спецификации. Планы строятся на QP. Логика построения плана должна быть подчинена минимизации срока выполнения задания, учитывая скорости чтения, обработки и пересылки промежуточных данных для получения окончательного результата запроса.
Пояснения: Элементом действия над поисковым запросом является совокупность пяти заголовков, которая характеризует поисковый термин и операцию с ним. Поля должны следовать в строго указанной ниже последовательности. Отсутствие какого-либо поля из указанной пятерки вызывает диагностику ошибки в разборщике запроса и такой запрос с момента выявления ошибки не обрабатывается. Последовательность операция описывается польской записью. Перечислим эти пять полей:

Поле:
Opr
Значения:
"Push" (поместить в аккумулятор, не обязательное использование), "And" (сделать логическое пересечение ID документов термина с аккумулятором), "Or" (сделать логическое объединение с аккумулятором), "Not" (исключить из аккумулятора ID документов, соответствующих термину), "ExclOr" (оставить в аккумуляторе ID документов с любым из слов, которые не встречаются в комбинации друг с другом), "Cand" (координатное "И" или полное соответствие искомой фразе)

Поле:
Swd
Значение:
Поисковое слово

Поле:
Ext
Значения:
"single"( использовать термин как он дан), "morph" (расширить термин до морфологических форм, "expand" (расширить термин с произвольным окончанием)

Поле:
Blg
Значение:
Код языка (см. languages.conf) используется при морфологическом расширении слова до всех его форм. Если указан 0 и указан способ морфологического расширения, то термин будет расширен до всех возможных форм во всех языках

Поле:
Mxb
Значение:
Число максимального кол-во "корзин" данных, которые будут прочитаны из базы. Данные по каждому слову хранятся в виде сортированной совокупности корзин, в каждой из которых хранится информация о фиксированном количестве ID документов, в которых данное слово встретилось (размер корзины определяется конфигурационно и может быть перестроен). В данном поле указывается число корзин для чтения.

Не обязательные поля.

Поле:
Pln
Значение:
Совокупность данных, которые должны быть переданы на внешний SP для выполнения им элементарных операций, включая код запроса. Все данные передаются без изменения на выбранный SP, выбор производится по первому значению поискового термина согласно конфигурации кластера поисковых процессоров. В приведенном в Приложении2 примере планы запросов пересылаются по цепочке на SP ответственные за поисковые термины "reference" и "db". При этом сам план ничего не знает о конкретных IP адресах ответственных за индекс этих слов.
Замечание: если план содержит внешние планы, то они должны предшествовать локальным логическим операциям. Это означает, что в процессе работы SP сначала пересылает план внешнему обработчику, потом принимает от него двоичные данные результатов и только после этого осуществляет логические операции с терминами, за которые данный SP отвечает локально.

Поле:
Nrs
Значение:
Количество результатов (ID документов), которое следует вернуть после выполнения всего запроса. Значение по умолчанию - 15.

Поле:
Str
Значение:
Порядковый номер первого документа после отбора и ранжирования. Значение по умолчанию - 0. Значения больше 0 означают, что надо выдать результаты, начиная с этого значения (первая, вторая, третья двадцатка и.т.д.)

Поле:
Lgs
Значение:
код языка документов, если 0 - то документ на любом языке, в противном случае для логических операций отбираются только те документы, для которых ранее распознанный основной язык документа соответствует указанному значению. Это фильтр.

Поле:
Ntf
Значение:
номер темы документа, если 0 - документы любой темы. Пока не используется. Планируется, что если накопители данных будут уметь автоматически определять принадлежность документа к какой либо теме, либо если оператор (администратор поисковой системы) в явном виде укажет, что данный документ принадлежит к указанной теме, то данное поле можно использовать в качестве фильтра поиска.

Поле:
Fld
Значение:
комплексное 32-х разрядное беззнаковое число, старшие 8 бит содержат информацию о необходимой принадлежности поискового термина к конкретной группе HTML тэгов. Младшие 8 бит - код языка документов (см. выше). Средние 16 бит - код темы. Это поле используется как начальный фильтр.
Обязательное поле.

Поле:
Ws
Значение:
Всегда 0 (применительно к работе SP). Для образования - это поле характеризует размер двоичных данных, которые будут переданы после окончания заголовка. В процессе взаимодействия Поисковых Процессоров друг с другом они сами заполняют эти поля.

6. Поисковые Программы и их оформление.
Ограничения, накладываемые определением планов и правилами их оформления (например, невозможность использовать в одном плане двух подпланов для разных серверов или невозможность сохранить результаты логической операции для их дальнейшего использования после проведения других логических операций над массивами данных поисковых терминов) обходятся при использовании программ поиска. Программа поиска это дальнейшее идеологическое развитие планов. Сами планы являются подмножеством программ и сохранены в качестве интерфейса для полной совместимости.
Программы позволяют создавать несколько соединений с различными SP системы и передавать в каждое соединение свою программу действий, с результатами которых можно провести ряд логических операций. В отличие от планов, в программах можно указывать индивидуальные фильтры (язык документов, тема документов, поле принадлежности HTML тэгу) для каждого поискового термина в отдельности. В планах эти фильтры могут быть использованы только на запрос в целом. В программах также нет жесткой необходимости указывать все поля для поискового термина (в пределе, достаточно только HEADER_SEARCH_WORD).
Полное описание программ приведено в документации Search System Assembly Language.
7. Приложение 1. Пример запроса CA к DS.
scaonner-011: send (посылка CA запроса к DS):
1\r\n
X-User: scanner-011\r\n
X-Pass: qwerty123\r\n
\r\n
scanner-011: red (прием ответа от DS):
1\r\n
Prt: http\r\n
Srv: maze.stack.net\r\n
Spt: 80\r\n
Sid: 1\r\n
Sfl: 0\r\n
Ad4: 212.192.243.40\r\n
Uri: /\r\n
Url: http://maze.stack.net/\r\n
\r\n
8. Приложение 2. Пример запроса QP к SP, содержащего план.
61\r\n
pln: reference\r\n
pln: 62\r\n
pln: pln: db\r\n
pln: pln: 62\r\n
pln: pln: fld: 0x80000000\r\n
pln: pln: opr: push\r\n
pln: pln: swd: db\r\n
pln: pln: ext: single\r\n
pln: pln: blg: 0\r\n
pln: pln: mxb: 1\r\n
pln: pln: ws: 0\r\n
pln: fld: 0x80000000\r\n
pln: opr: and\r\n
pln: swd: reference\r\n
pln: ext: single\r\n
pln: blg: 0\r\n
pln: mxb: 1\r\n
pln: ws: 0\r\n
fld: 0x80000000
opr: and\r\n
swd: guide\r\n
ext: single\r\n
blg: 0\r\n
mxb: 1\r\n
ws: 0\r\n
\r\n
9. Приложение 3. Пример запроса QP к SP, содержащего программу
Для понимания синтаксиса поисковых программ необходимо ознакомиться с Search System Assembly Language SSAL/1.0
63\r\n
Opr: LOA reg1,berkeley\r\n
Fld: 0x20000000\r\n
Bid: 0 1\r\n
Opr: CPY reg1,tmp\r\n
Opr: RLD reg1,searcher-002.turtle.ru\r\n
Pln: 64\r\n
Pln: Opr: LOA reg1,db\r\n
Pln: Opr: AND reg1,reference\r\n
Pln: Ws: 0\r\n
Opr: AND reg1,tmp\r\n
Ws: 0
\r\n
Данный пример иллюстрирует операцию поиска документов, содержащих все слова "berkeley", "db", "reference". При этом подразумевается, что индексные данные слов "db" и "reference" находятся на внешнем SP (searcher-002.turtle.ru). Слово "berkeley" должно содержаться выделенным типом в найденных документах.
Того же результата можно достигнуть с помощью:
63\r\n
Opr: LOA tmp,Berkeley\r\n
Fld: 0x20000000\r\n
Opr: RLD tmp2,searcher-002.turtle.ru\r\n
Pln: 64\r\n
Pln: Opr: LOA reg1,db\r\n
Pln: Ws: 0\r\n
Opr: RLD tmp3,searcher-002.turtle.ru\r\n
Pln: 64\r\n
Pln: Opr: LOA reg1,reference\r\n
Pln: Ws: 0\r\n
Opr: CPY tmp,reg1\r\n
Opr: AND reg1,tmp2\r\n
Opr: AND reg1,tmp3\r\n
Ws: 0\r\n
\r\n
Приведенные примеры не являются оптимальными, а лишь иллюстрируют возможные варианты.

Черепаший Ранк. Реклама на Turtle Логотипы Правовая информация Конфиденциальность Контакты