Комментарии к NNCP новости

https://www.opennet.ru/opennews/art.shtml?num=57771
Вспомнил я тут про OpenNet и что не мешало бы на нём публиковать новости
о своих релизах. Комментарии к своим статьям я давно уже не читаю, но
тут зашёл на страницу с ними. И вот почему не стоит читать комментарии в
Интернетах этих? Да потому что соотношение сигнал/шум к чему-то
полезному или шуму там крайне низкое почти во всех ИТ статьях.

Часть людей дальше заголовка явно ничего не пытается прочитать. И в
комментариях задают вопросы которые в документации явно отвечены. И речь
не про мой NNCP, а вообще про любое ПО. Блин, ведь время потраченное на
написание вопроса зачастую будет сравнимо с переходом по ссылке на
документацию и быструю навигацию по меню/TOC с нахождением ответа.

Конкретно в комментариях про NNCP: кто-то упорно пишет про scp, мол
вместо NNCP. Как-будто человек увидел что это что-то про передачу файлов
и на этом всё: scp же умеет передавать файлы, вот и заладил с ним.
Кто-то вообще задаётся вопросом "зачем шифровать, если передача между
F2F?". Ответ краток и полностью ёмок (дан кем-то): MitM. Очевидно. Но
оказывается кому-то это не очевидно. Как так?

Кто-то начал чушь про TCP и UDP писать. Да, человек понимает что TCP
может себя вести не очень на не очень хороших, колбасящихся по некоторым
характеристикам каналам связи. UDP то здесь чем поможет? Аналогично
придётся всё равно поверх UDP придумывать тему про доставку битых или
потерянных пакетов. В комментарии здраво отвечают что TCP используется
именно чтобы не заниматься этим. Может ли быть ситуация когда
самопальный транспорт поверх UDP будет эффективнее TCP? Безусловно!
Будет ли он эффективнее всегда? Очевидно что нет. Всё упирается в
алгоритм congestion control. Именно поэтому для TCP и дают возможность
его выбора и управления. В случае с UDP никто не отменяет что необходимо
всё равно управлять congestion-ом будет. Просто вместо того, чтобы это
делало ядро ОС, это перекладывается на плечи прикладного ПО. Это не есть
что-то плохое, ибо в каких-то задачах это может дать огромный profit,
как например при использовании QUIC и HTTP/3, где множество параллельных
потоков отправляются. Но когда речь про передачу единственного потока,
одного файла, то QUIC не даёт никакого профита (кроме возможно быстрого
установления, а точнее продолжения, TLS сессии). Переключение TCP CC на
какой-нибудь BBR алгоритм может дать колоссальный прирост "скорости".
Поэтому человек пишет лютый бред, игнорируя тот факт, что использование
UDP не отменяет необходимость congestion control, просто перенося его в
прикладное ПО. Если этот CC будет эффективнее на конкретных каналах
связи: будет эффективнее. Но предложения же нет о конкретике. Да и,
более того, не бывает алгоритмов CC которые работают лучше всех
остальных везде. Настройку/управление CC вместо ОС придётся делать
внутри программы. Если бы NNCP параллельно передавал зашифрованные
пакеты, то можно было бы о чём-то таком задумываться.

Кто-то пишет про то, что NNCP на плохих каналах не работает. Неправда,
ибо я на COM-порту его многократно использовал, и в Ethernet
искусственно ограничивая traffic shaper-ом его до десятков Kbps. Есть
только одна загвоздка: его online протокол оперирует 64KiB пакетами, и,
соответственно, все внутренние счётчики тикают и учитывают факты
передачи пакета. Если за 10сек он не успевает передастся, то ПО
посчитает что за 10сек (по умолчанию) timeout ничего не было передано и
значит надо делать disconnect. Тут всё как с TCP CC: не бывает алгоритма
удовлетворяющего все требования и контексты применения транспортного
протокола. TCP Reno алгоритм создавали во времена десятков Kbps каналов
связи в лучшем случае. На канале с 10-100Gbps он не может себя вести
достаточно хорошо. Но в NNCP "проблему" с 64KiB, которая требует, грубо
говоря, ~53Kbps канала как минимум, можно решить одной переменной
окружения, выставив большее время 10сек timeout-а.

И, опять же, NNCP вообще не имел средств online передачи данных
изначально. Это в первую очередь про store-and-forward и переносные
накопители.

Один человек упорно придирался к слову "простота" в описании NNCP. Мол,
настройка TCP CC это не про простоту. Меня это позабавило тем, что я
писал про простоту самой программы, про её "архитектуру", про код. Про
простоту для пользователя в этой части документации не было
предположений. Но согласен что это не очевидно. Например DJB софт
(daemontools, UCSPI) является очень простым, но имеет больший порог
входа для конечного пользователя.