From: kmeaw
Date: 2021-01-11 03:22:25Z
У меня как раз есть вопрос относительно применимости NNCP.
На работе есть система, которая позволяет внутренним пользователям через
внутреннюю сеть (данная конструкция уже обеспечивает авторизацию и
аутентификацию) массово и с ревью выполнять команды на удалённых узлах.
Необходимость этой системы обусловленна тем, что удалённые узлы с
момента ввода в эксплуатацию не всегда подключены к хорошей сети. В
какие-то моменты времени связности нет совсем, в какие-то она
обеспечивается мобильными операторами (может быть как плохой по
bandwidth и/или latency, так и хорошей), но хотя бы один (а чаще
несколько, до десятка) раз в день узлы подключены к очень хорошей сети.
Если бы узлов было мало, или сеть всегда была бы хорошей, то задача бы
прекрасно решалась с помощью SSH. Но так как их много, а связь не
идеальна, требуется посредник для хранения списка заданий.
Коллеги в соседнем отделе разрабатывают другую систему, которая работает
на тех же узлах, но передаёт (уже гораздо более объёмные, чем команды)
данные только при наличии подключения к хорошей сети. Сейчас же
возникает потребность на некоторых узлах передавать некоторое
подмножество этих данных и через сеть с характеристиками похуже, а на
(пока) единичных узлах - вовсе через съёмные носители информации.
Казалось бы, почти идеальный сценарий для замены этих двух систем на
NNCP. Но есть особенности использования, от которых пользователи вряд ли
захотят отказываться:
1) так как система предназначена для внутреннего использования, в момент
ввода её узлов в эксплуатацию обеспечивается доверие к её
стационарным инфраструктурным узлам с помощью PKI, что позволяет легко
наращивать их мощность в случае необходимости; при использовании NNCP
придётся обновлять конфигурационные файлы на всех удалённых узлах в
случае масштабирования;
2) пока задание на выполнение команды не было взято в обработку
(например, пользователь затребовал наличие хорошей сети или из-за
отсутствия связности оно ещё не успело попасть на удалённый узел),
пользователь может передумать и удалить его из очереди; в NNCP нет
готового инструмента для создания "анти-пакетов" и взаимного их
уничтожения вместе с соответствующими пакетами во время тоссинга;
3) когда задание выполняется, текущая реализация пытается в реальном
времени доставлять результаты его выполнения, если это возможно; в
случае NNCP нет возможности получить часть пакета - он либо доставлен,
либо нет;
4) другая система, передающая тяжёлые данные, знает про их семантику, и
может не передавать существенные (по объёму) фрагменты, если в этом нет
смысла, как например в случае, когда это значение счётчика (и тогда
потребителю интересно лишь последнее его значение); в случае NNCP нет
возможности указать в метаинформации пакета, что он замещает собой
какой-то другой, более старый пакет, поставленный в очередь на отправку.
Конечно же, каждую из этих проблем можно решить снаружи соответствующей
обвязкой. Мой вопрос в том, стоит ли пытаться это делать, или же лучше
сразу написать свой транспорт, заточенный под наши данные?