Приложение N 4. Требования, предъявляемые к функционированию канала кпд 2

Приложение N 4

к Требованиям к оборудованию

и программному обеспечению операторов

почтовой связи для обеспечения доступа

к базам данных об оказанных услугах

почтовой связи и пользователях

услугами почтовой связи при проведении

оперативно-розыскных мероприятий,

утвержденным приказом Минкомсвязи России

от 23.07.2015 N 279

ТРЕБОВАНИЯ, ПРЕДЪЯВЛЯЕМЫЕ К ФУНКЦИОНИРОВАНИЮ КАНАЛА КПД 2

1.1. ТС ОРМ обеспечивают подключение ПУ и обработку поступающих запросов по каналу кпд 2 в соответствии с приведенными диаграммами состояний переходов.

Диаграмма состояний переходов ТС ОРМ по кпд 2 приведена на

1.2. Рисунок Приложения 4.

Рисунок 1. Диаграмма состояний перехода ТС ОРМ по кпд 2

(не приводится)

1.3. ТС ОРМ по ТСР-порту кпд 2 ожидают входящих соединений. После установления соединения выполняется взаимная SSL/TLS-аутентификация.

1.4. Если на ТС ОРМ была передана "запрос загрузки данных" (DataLoadRequest), ТС ОРМ посылают "ответ на запрос загрузки данных" (DataLoadResponse) по каналу кпд 1 и начинает передачу данных блоков отчетов по кпд 2 при их наличии. ПУ может получить блоки отчетов по кпд 2 до получения "ответа на запрос загрузки данных" (DataLoadResponse) по кпд 1.

1.5. Если количество переданных без получения "подтверждения" о принятии серии блоков "отчетов" по всем задачам, по которым выполняется загрузка на ПУ данных, меньше "окна канала передачи данных" (параметр data-packet-window-size в запросе создания сессии ConnectRequest), то ТС ОРМ выполняют подготовку новых блоков отчетов по загружаемым задачам и посылают их на ПУ. Количество подготовленных и переданных без получения "подтверждения" блоков не должно превышать размера окна канала передачи данных.

1.6. Максимальная задержка подтверждения приема блока данных со стороны ПУ не превышает параметр "таймаут подтверждения приема блока данных отчета" (data-packet-response-timeout), указываемый при создании сессии. Если задержка подтверждения превысила заданное значение, то оставшиеся для передачи блоки данных не отправляются и по каналу управления передается "сигнал" "Незначительная ошибка ПО, данные не потеряны, дальнейшая работа возможна" с соответствующим описанием проблемы, при этом в поле "reference-message" сообщения "сигнал" указывается идентификатор сообщения блока отчета, по которому не поступило подтверждение приема.

1.7. При получении "подтверждения" блока "отчета" ТС ОРМ должны записать информацию об ошибочно принятом ПУ блоке и ошибочных записях в блоке в специальный журнал, передача последующих блоков по задаче на ПУ не прерывается. ТС ОРМ должны предоставлять техническому персоналу оператора связи доступ к журналу с записями об ошибочно принятых на ПУ блоках отчетов и средства исправления ошибочных данных в отчетах. Подтвержденные блоки исключаются из окна канала передачи данных (в окне канала передачи данных остаются только неподтвержденные блоки).

1.8. В случае разрыва TCP/IP соединения кпд 2 при существующем соединении кпд 1 по кпд 1 передается прерывание "Незначительная ошибка ПО, данные не потеряны, дальнейшая работа возможна" с соответствующим описанием проблемы, работа в данном случае не прекращается, выполняется установление соединения по кпд 2 в соответствии с п. 1.20 Приложения 2.

1.9. Передача блоков данных может быть прервана в случае получения ТС ОРМ "запроса прерывания загрузки данных".

1.10. Если по кпд 2 не производится передача блоков отчетов в течение "максимального времени неактивности" (session-timeout при создании сессии ConnectRequest), ТС ОРМ посылают на ПУ "сигнал" Heartbeat и ожидает его подтверждения аналогично описанному в п. 1.9 Приложения 3.

1.11. Диаграмма состояний переходов ПУ по кпд 2 приведена на Рисунок Приложения N 4.

Рисунок 2. Диаграмма состояний перехода ПУ по кпд 2

(не приводится)

1.12. ПУ с задаваемым интервалом выполняет попытки установления ТСР-соединения с ТС ОРМ по заданному порту кпд 2. После установления соединения выполняется взаимная SSL/TLS-аутентификация.

1.13. При поступлении "запроса загрузки данных конкретной задачи" (DataLoadRequest) ПУ ожидает начала передачи данных в течение времени "таймаут начала передачи блоков отчетов" (data-load-timeout в ConnectRequest). Если данные не поступают в течение вышеописанного периода, то ПУ разрывает соединения по каналам кпд 1 и кпд 2 и переводит соединения в изначальное состояние (п. 1.12 Приложения 3, п. 1.12 настоящего Приложения).

1.14. При поступлении блока отчета ПУ производит декодирование полученного блока и сохранение декодированных данных.

1.15. В ответ на переданный блок данных ПУ посылает сообщение "подтверждение" получения блока отчета. Количество последовательно переданных ТС ОРМ блоков данных без подтверждения со стороны ПУ определяется параметром "размер окна канала передачи данных", который согласовывается при создании сессии. При подтверждении блока отчета ПУ может сигнализировать об ошибке декодирования блока. В этом случае в сообщении "подтверждение" приема для ошибочно декодированного блока ПУ, в случае возможности, указывает номер записи в блоке, начиная с которой декодирование не удалось.

1.16. Если при ожидании поступления в ПУ блоков отчетов ТС ОРМ не посылала "сигнал" Heartbeat в течение трех интервалов "максимального времени неактивности" (session-timeout, задается в ConnectRequest), ПУ разрывает соединения с ТС ОРМ по кпд 1 и кпд 2 и переводит их в изначальное состояние (п. 1.12 Приложения N 3, п. 1.12 настоящего Приложения).