[about] [index] [prev] [2021-01-08 17:01:38+03:00] [ed2ab9886003a927d930e9509e921277d7c12ece]

Релиз NNCP

https://lists.cypherpunks.ru/pipermail/nncp-devel/2021-January/000178.html
На днях начал реализовывать деревья Меркле, чтобы можно было частями их
обновлять. В NNCP думал что это пригодится для того чтобы, не зная
точного размера передаваемого файла, в конце обновить заголовок и быстро
пересчитать дерево с результирующим хэшом. Но не доделал, ибо прежде
обнаружил что у меня есть случаи когда файл шифруется потокового сразу в
несколько "обёрток", что так сильно всё усложняет, что плюнул на идею.
Но вот вот почти почти я заиспользовал бы Меркле на практике.

В итоге в NNCP так толком ничего и не сделал, кроме простых bugfix-ов.
Но конечно же это тоже приятно. Обнаружилось что на Go 1.10 оно уже не
будет собираться, так как есть golang.org/x зависимости где используется
GOOS=aix, а 1.10 ничего про это не знает и поэтому не игнорирует файл.

А ещё тут описали свой use-case NNCP (be88dfcd96ff0a7c75ccd803b8e72ad15629e7f6):
https://lists.cypherpunks.ru/pipermail/nncp-devel/2021-January/000159.html
человек прогоняет куда бОльшие объёмы данных чем я, через NNCP. Хотя у
меня больше разнообразия в используемых фичах. Есть баги с сетевыми
программами, но данные не искажаются и не пропадают -- это самое главное.

[leave comment]
comment 0:
From: kmeaw
Date: 2021-01-11 03:22:25Z

У меня как раз есть вопрос относительно применимости NNCP.

На работе есть система, которая позволяет внутренним пользователям через
внутреннюю сеть (данная конструкция уже обеспечивает авторизацию и
аутентификацию) массово и с ревью выполнять команды на удалённых узлах.

Необходимость этой системы обусловленна тем, что удалённые узлы с
момента ввода в эксплуатацию не всегда подключены к хорошей сети. В
какие-то моменты времени связности нет совсем, в какие-то она
обеспечивается мобильными операторами (может быть как плохой по
bandwidth и/или latency, так и хорошей), но хотя бы один (а чаще
несколько, до десятка) раз в день узлы подключены к очень хорошей сети.

Если бы узлов было мало, или сеть всегда была бы хорошей, то задача бы
прекрасно решалась с помощью SSH. Но так как их много, а связь не
идеальна, требуется посредник для хранения списка заданий.

Коллеги в соседнем отделе разрабатывают другую систему, которая работает
на тех же узлах, но передаёт (уже гораздо более объёмные, чем команды)
данные только при наличии подключения к хорошей сети. Сейчас же
возникает потребность на некоторых узлах передавать некоторое
подмножество этих данных и через сеть с характеристиками похуже, а на
(пока) единичных узлах - вовсе через съёмные носители информации.

Казалось бы, почти идеальный сценарий для замены этих двух систем на
NNCP. Но есть особенности использования, от которых пользователи вряд ли
захотят отказываться:

1) так как система предназначена для внутреннего использования, в момент
ввода её узлов в эксплуатацию обеспечивается доверие к её
стационарным инфраструктурным узлам с помощью PKI, что позволяет легко
наращивать их мощность в случае необходимости; при использовании NNCP
придётся обновлять конфигурационные файлы на всех удалённых узлах в
случае масштабирования;

2) пока задание на выполнение команды не было взято в обработку
(например, пользователь затребовал наличие хорошей сети или из-за
отсутствия связности оно ещё не успело попасть на удалённый узел),
пользователь может передумать и удалить его из очереди; в NNCP нет
готового инструмента для создания "анти-пакетов" и взаимного их
уничтожения вместе с соответствующими пакетами во время тоссинга;

3) когда задание выполняется, текущая реализация пытается в реальном
времени доставлять результаты его выполнения, если это возможно; в
случае NNCP нет возможности получить часть пакета - он либо доставлен,
либо нет;

4) другая система, передающая тяжёлые данные, знает про их семантику, и
может не передавать существенные (по объёму) фрагменты, если в этом нет
смысла, как например в случае, когда это значение счётчика (и тогда
потребителю интересно лишь последнее его значение); в случае NNCP нет
возможности указать в метаинформации пакета, что он замещает собой
какой-то другой, более старый пакет, поставленный в очередь на отправку.

Конечно же, каждую из этих проблем можно решить снаружи соответствующей
обвязкой. Мой вопрос в том, стоит ли пытаться это делать, или же лучше
сразу написать свой транспорт, заточенный под наши данные?
comment 1:
From: Sergey Matveev
Date: 2021-01-11 08:01:57Z

*** kmeaw [2021-01-11 06:15]:
>Конечно же, каждую из этих проблем можно решить снаружи соответствующей
>обвязкой. Мой вопрос в том, стоит ли пытаться это делать, или же лучше
>сразу написать свой транспорт, заточенный под наши данные?

Вот из-за всех особенностей что вы перечислили, я бы не стал пытаться
применять NNCP или приделывать к нему костыли/доработки. Была бы моя
компания, мои задачи -- я бы всё равно лучше бы написал отдельный софт
для описываемой вами задачи. Получение части пакета, "удаление из
очереди" -- это плохо ложится на NNCP "архитектуру".