Заливка сегмента нодлиста

Dmitriy Romanov написал(а) к Nil A в Oct 24 14:48:06 по местному времени:

Приветики, Nil!


Писал как-то Nil A к Alexey Khromov примерно 11 Окт 24 в 18:11
А я смотрю и фигею.

AK>> Как видишь, в стандарте не определено ожидание M_ADR одной из
AK>> сторон
AK>> - только синхронизация на сверке пароля, о чем явно указано в
AK>> FTS. Однако, технически возможно* и *не противоречит стандарту, если
AK>> в мейлер добавить выдачу своего адреса только после представления
AK>> вызывающей стороны, о чем я ранее и написал.

NA> Означает ли это, что если обе стороны будут, как при игре в покер, пытаться
NA> не "раскрыть свои карты" до последнего, что как бы не противоречит
NA> стандарту, то хендшейк просто будет застревать, играют в несознанку, и
NA> отваливаться по таймауту?
Так и будет. Но в такой ситуации в более других протоколах принято вызывающему представляться первым.

На сем разрешите письмо закончить. Elec (RA2FDR)
--- NoSFeRaTU's GoldED+/W32-MINGW 1.1.5-b20090603

Dmitriy Romanov написал(а) к Alexey Fayans в Oct 24 14:49:06 по местному времени:

Приветики, Alexey!


Писал как-то Alexey Fayans к Alexey Khromov примерно 11 Окт 24 в 18:28
А я смотрю и фигею.

AK>> Как видишь, в стандарте не определено ожидание M_ADR одной из
AK>> сторон
AK>> - только синхронизация на сверке пароля
AF> Возможно, ты прав. Но хотелось бы увидеть софт, который сможет успешно
AF> провести сессию с каким-нибудь binkd 1.0 в качестве вызывающей
AF> стороны, отправив ему свои адреса после того, как он предъявит свои.
Такой точно есть. У кого-то из моих линков был, когда я свой мейлер тогда писал и тестировал. Уже точно не помню у кого
и какой. Ну и наверняка с binkd он прекрасно договаривался.

На сем разрешите письмо закончить. Elec (RA2FDR)
--- NoSFeRaTU's GoldED+/W32-MINGW 1.1.5-b20090603

Dmitriy Romanov написал(а) к Nil A в Oct 24 14:51:06 по местному времени:

Приветики, Nil!


Писал как-то Nil A к Alexey Fayans примерно 11 Окт 24 в 19:43
А я смотрю и фигею.

NA>>> Означает ли это, что если обе стороны будут, как при игре в
NA>>> покер, пытаться не "раскрыть свои карты" до последнего, что как
NA>>> бы не противоречит стандарту, то хендшейк просто будет
NA>>> застревать, играют в несознанку, и отваливаться по таймауту?

AF>> Да, только вызывающей стороне нет никакого смысла это делать, т.к. она
AF>> и так знает, кого вызывает и какие адреса предъявить.

NA> Вызывающая сторона может попридержать свой левонетовский ака, пока там его
NA> не предъявят. Хотя да, кто вызывает, обычно точно знает, хочет он и с
NA> фидонетовским, и с левонетовским пообщаться.
Причем вполне может быть и такое, что реквизиты для вызова для обеих ситуаций могут совпадать. И даже две системы могут
одновременно вести две сессии, не мешая друг другу.

На сем разрешите письмо закончить. Elec (RA2FDR)
--- NoSFeRaTU's GoldED+/W32-MINGW 1.1.5-b20090603

Dmitriy Romanov написал(а) к Alexey Khromov в Oct 24 14:53:46 по местному времени:

Приветики, Alexey!


Писал как-то Alexey Khromov к Nil A примерно 11 Окт 24 в 21:35
А я смотрю и фигею.

NA>> Означает ли это, что если обе стороны будут, как при игре в покер,
NA>> пытаться не "раскрыть свои карты" до последнего, что как бы не
NA>> противоречит стандарту, то хендшейк просто будет застревать, играют в
NA>> несознанку, и отваливаться по таймауту?

AK> Да, однако я написал уже, что стандартом предполагается в первой фазе обмен
AK> всеми системными заголовками, включая адрес. Точка синхронизации - проверка
AK> пароля, а его не проверить без адреса, т.к. MD5-челендж отправляется
AK> вызываемым сервером первой же строкой.

NA>> В этом плане, какой-нибудь TLS handshake более понятен. Есть
NA>> ClientНello, есть ServerНello, и понятно кто что предъявляется, чтобы
NA>> можно было договориться.

AK> Видимо, портянки AKA с левонетами скрывать уже было незачем авторам binkp.
AK> Дополним мейлер опцией какой-нить и заставим, если он вызываемый , ждать
AK> адреса вызывающего.
А зачем их скрывать? Вызывающий сам должен разобраться, с каким адресом он будет работать. Или предъявление
"несуществующего" ака (помимо основного адреса) тянет на какое-то преступление?


На сем разрешите письмо закончить. Elec (RA2FDR)
--- NoSFeRaTU's GoldED+/W32-MINGW 1.1.5-b20090603

Dmitriy Romanov написал(а) к Nil A в Oct 24 14:57:54 по местному времени:

Приветики, Nil!


Писал как-то Nil A к Alexey Khromov примерно 12 Окт 24 в 03:20
А я смотрю и фигею.


NA> P.S. Я не знаю вашего владения технологиями, но на интервью знание про
NA> https://ru.wikipedia.org/wiki/Задача...нералов будет почти обязательна,
NA> если архитектором идёшь на какие-то такие "аля binkp" проекты. P.P.S.
NA> Правильный ответ для фидо, что всё проверяет уровень выше, со своими
NA> дуполовками. Но всё равно, можно решить многое и на уровне пересылке
NA> бандлов.
А в какой ситуации у нас может возникнуть повторная отправка бандлов? Только если в момент окончания передачи произошел
разрыв связи, и принимающий не успел послать квиток о получении. Настолько маловероятная и труднопопадаемая ситуация,
что можно исправление этой ошибки переложить и на вышестоящий уровень.

На сем разрешите письмо закончить. Elec (RA2FDR)
--- NoSFeRaTU's GoldED+/W32-MINGW 1.1.5-b20090603

Alexey Khromov написал(а) к Nil A в Oct 24 15:11:33 по местному времени:

Здраствуйте, Nil!

12 окт 24 03:20, Nil A -> Alexey Khromov:

NA> "Умные станции" выдают официоз в этом месте.
NA> Хотя мыслишка такая, что тут любой дефолтный "банер" можно показывать.

NA> А таки вот, IPv6 никак не случается, хотя уже десяток и больше лет
NA> сказали, что никаких IPv4 больших сеток не выдаём. (спойлер: есть
NA> дохериха каво можно ещё раскулачить с сетками А, и они это делают). В
NA> IPv6 сканирование примерно, как майнить койны, или ещё хуже.

В исследованиях по этому вопросу присутствовал, в том числе в МИФИ. Самый простой способ сканировать - анализ выдаваемых по MAC и типичных диапазонов для выдачи роутерами, с учетом алгоритмов "псевдослучайности". Все равно задача остается сложной, согласен.

NA> Капитан? Уже Стас прикололся недавно, и оказалось, что не все на это
NA> готовы.

Это заметил, но есть одно но - в фидо любое изменение потянет не до конца готовых, т.к. единого стандартного клиента и жестких правил подключения/обновления/синхронизации нет.

NA> Вот вопрос к тебе, и к Alexey Fayans. Если бы ты проектировал binkp
NA> протокол, то как бы решил вопрос доставку бандлов один и только один
NA> раз?

А оно надо кому сейчас? Есть два полюса - доставка как есть тем что есть на одном полюсе и полная синхронизация, допустим блокчейном, на другом полюсе. Оба полюса имеют свой предел надежности. Как есть - явно больше нуля, да и блокчейн - не 100%, хоть и lim->. Какой требуется уровень надёжности?
А если конкретней, какие уровни доступности и целостности? Про конфиденциальность не будем, мы ж в фидонете.
Мейлер должен доставить пакет(ы) ровно в том виде, в каком их положили в аутбаунд.

NA> P.S. Я не знаю вашего владения технологиями, но на интервью знание про
NA> https://ru.wikipedia.org/wiki/Задача...нералов будет почти
NA> обязательна, если архитектором идёшь на какие-то такие "аля binkp"
NA> проекты. P.P.S. Правильный ответ для фидо, что всё проверяет уровень
NA> выше, со своими дуполовками. Но всё равно, можно решить многое и на
NA> уровне пересылке бандлов.

Хорошо, что я иб-шник, а не программер)
Правильный ответ пришел "другой путёй", но соответствует.

ЗЫ.NNCP глянул. Чем UUCP|rsync им не угодили, интересно.


Alexey Khromov
--- GoldED+/LNX 1.1.5-b20240309

Alexey Fayans написал(а) к Dmitriy Romanov в Oct 24 17:12:38 по местному времени:

Нello Dmitriy!

On Sat, 12 Oct 2024 14:49 +0200, you wrote to me:

AF>> Возможно, ты прав. Но хотелось бы увидеть софт, который сможет
AF>> успешно провести сессию с каким-нибудь binkd 1.0 в качестве
AF>> вызывающей стороны, отправив ему свои адреса после того, как он
AF>> предъявит свои.
DR> Такой точно есть. У кого-то из моих линков был, когда я свой мейлер
DR> тогда писал и тестировал. Уже точно не помню у кого и какой. Ну и
DR> наверняка с binkd он прекрасно договаривался.

Я очень в этом сомневаюсь. В общем, нужно тестировать.


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707

Alexey Khromov написал(а) к Dmitriy Romanov в Oct 24 17:07:22 по местному времени:

Здраствуйте, Dmitriy!

DR> А зачем их скрывать? Вызывающий сам должен разобраться, с каким
DR> адресом он будет работать. Или предъявление "несуществующего" ака
DR> (помимо основного адреса) тянет на какое-то преступление?

Да, предъявление "несуществующего" FTN-адреса никак не преступление. Однако меня самого удивляет факт наличия в настройках bforce опций hideAka, которые работают для EMSI-сессий, но не работают для binkp.
Хорошая возможность привести все к единому знаменателю.


Alexey Khromov
--- GoldED+/LNX 1.1.5-b20240309