Что: ed2ab9886003a927d930e9509e921277d7c12ece Когда: 2021-01-08 17:01:38+03:00 ------------------------------------------------------------------------ Темы: nncp ------------------------------------------------------------------------ Релиз 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. Хотя у меня больше разнообразия в используемых фичах. Есть баги с сетевыми программами, но данные не искажаются и не пропадают -- это самое главное. ------------------------------------------------------------------------ оставить комментарий: mailto:comment@blog.stargrave.org?subject=Re:%20%D0%A0%D0%B5%D0%BB%D0%B8%D0%B7%20NNCP%20%28ed2ab9886003a927d930e9509e921277d7c12ece%29 ------------------------------------------------------------------------ комментарий 0: From: kmeaw Date: 2021-01-11 03:22:25Z У меня как раз есть вопрос относительно применимости NNCP. На работе есть система, которая позволяет внутренним пользователям через внутреннюю сеть (данная конструкция уже обеспечивает авторизацию и аутентификацию) массово и с ревью выполнять команды на удалённых узлах. Необходимость этой системы обусловленна тем, что удалённые узлы с момента ввода в эксплуатацию не всегда подключены к хорошей сети. В какие-то моменты времени связности нет совсем, в какие-то она обеспечивается мобильными операторами (может быть как плохой по bandwidth и/или latency, так и хорошей), но хотя бы один (а чаще несколько, до десятка) раз в день узлы подключены к очень хорошей сети. Если бы узлов было мало, или сеть всегда была бы хорошей, то задача бы прекрасно решалась с помощью SSH. Но так как их много, а связь не идеальна, требуется посредник для хранения списка заданий. Коллеги в соседнем отделе разрабатывают другую систему, которая работает на тех же узлах, но передаёт (уже гораздо более объёмные, чем команды) данные только при наличии подключения к хорошей сети. Сейчас же возникает потребность на некоторых узлах передавать некоторое подмножество этих данных и через сеть с характеристиками похуже, а на (пока) единичных узлах - вовсе через съёмные носители информации. Казалось бы, почти идеальный сценарий для замены этих двух систем на NNCP. Но есть особенности использования, от которых пользователи вряд ли захотят отказываться: 1) так как система предназначена для внутреннего использования, в момент ввода её узлов в эксплуатацию обеспечивается доверие к её стационарным инфраструктурным узлам с помощью PKI, что позволяет легко наращивать их мощность в случае необходимости; при использовании NNCP придётся обновлять конфигурационные файлы на всех удалённых узлах в случае масштабирования; 2) пока задание на выполнение команды не было взято в обработку (например, пользователь затребовал наличие хорошей сети или из-за отсутствия связности оно ещё не успело попасть на удалённый узел), пользователь может передумать и удалить его из очереди; в NNCP нет готового инструмента для создания "анти-пакетов" и взаимного их уничтожения вместе с соответствующими пакетами во время тоссинга; 3) когда задание выполняется, текущая реализация пытается в реальном времени доставлять результаты его выполнения, если это возможно; в случае NNCP нет возможности получить часть пакета - он либо доставлен, либо нет; 4) другая система, передающая тяжёлые данные, знает про их семантику, и может не передавать существенные (по объёму) фрагменты, если в этом нет смысла, как например в случае, когда это значение счётчика (и тогда потребителю интересно лишь последнее его значение); в случае NNCP нет возможности указать в метаинформации пакета, что он замещает собой какой-то другой, более старый пакет, поставленный в очередь на отправку. Конечно же, каждую из этих проблем можно решить снаружи соответствующей обвязкой. Мой вопрос в том, стоит ли пытаться это делать, или же лучше сразу написать свой транспорт, заточенный под наши данные? ------------------------------------------------------------------------ комментарий 1: From: Sergey Matveev Date: 2021-01-11 08:01:57Z *** kmeaw [2021-01-11 06:15]: >Конечно же, каждую из этих проблем можно решить снаружи соответствующей >обвязкой. Мой вопрос в том, стоит ли пытаться это делать, или же лучше >сразу написать свой транспорт, заточенный под наши данные? Вот из-за всех особенностей что вы перечислили, я бы не стал пытаться применять NNCP или приделывать к нему костыли/доработки. Была бы моя компания, мои задачи -- я бы всё равно лучше бы написал отдельный софт для описываемой вами задачи. Получение части пакета, "удаление из очереди" -- это плохо ложится на NNCP "архитектуру". ------------------------------------------------------------------------ Сгенерирован: SGBlog 0.34.0