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

Alexey Fayans написал(а) к Dmitriy Romanov в Oct 24 22:34:13 по местному времени:

Нello Dmitriy!

On Wed, 09 Oct 2024 21:07 +0200, you wrote to me:

AF>> Только в binkp хендшейк начинает отвечающая сторона, сразу
AF>> предъявляя все ака, что крайне тупо, но так уж сделали.
DR> А тут уже от реализации зависит.

В спецификации binkp написано, что вызываемая сторона должна начать хендшейк. Поэтму любой софт, реализующий протокол binkp, будет работать именно так и никак иначе. Если кто-то сделает по-другому, то ни один стандартный клиент не будет с такой реализцией работать.


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

Dmitriy Romanov написал(а) к Alexey Fayans в Oct 24 07:42:28 по местному времени:

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


Писал как-то Alexey Fayans к Dmitriy Romanov примерно 09 Окт 24 в 22:34
А я смотрю и фигею.


AF>>> Только в binkp хендшейк начинает отвечающая сторона, сразу
AF>>> предъявляя все ака, что крайне тупо, но так уж сделали.
DR>> А тут уже от реализации зависит.

AF> В спецификации binkp написано, что вызываемая сторона должна начать
AF> хендшейк. Поэтму любой софт, реализующий протокол binkp, будет работать
AF> именно так и никак иначе. Если кто-то сделает по-другому, то ни один
AF> стандартный клиент не будет с такой реализцией работать.
классический binkd не дожидается, пока вызывающий представится. Можешь проверить экспериментально, подцепившись
телнетом на соответствующий порт большинства узлов.

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

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

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


Писал как-то Alexey Fayans к Vladislav Muschinskikh примерно 09 Окт 24 в 22:09
А я смотрю и фигею.


AK>>>> аналогично сделано и в binkp - вызывающий предьявляет свои АКА и
AK>>>> параметры, вызываемый отдает свои на основании принятых.
AF>>> Только в binkp хендшейк начинает отвечающая сторона, сразу
AF>>> предъявляя все ака, что крайне тупо, но так уж сделали.
VM>> А почему тогда возникает ситуация, когда вызывающая сторона получает
VM>> от вызываемой сообщения о том что такой-то ака на удалённой системе
VM>> busy or not available? (я не настоящий сварщик, просто интересно)
AF> Это нужно в исходники смотреть, я не задавался таким вопросом.
А какая разница вызывающей стороне? Если предъявленный основной адрес busy, то сессия не состоится. Если один из AKA -
то принимающая сторона просто исключает его из обработки и ведет себя так, как будто этот ака не предъявлен.

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

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

Нello Dmitriy!

On Thu, 10 Oct 2024 07:42 +0200, you wrote to me:

AF>> В спецификации binkp написано, что вызываемая сторона должна
AF>> начать хендшейк. Поэтму любой софт, реализующий протокол binkp,
AF>> будет работать именно так и никак иначе. Если кто-то сделает
AF>> по-другому, то ни один стандартный клиент не будет с такой
AF>> реализцией работать.
DR> классический binkd не дожидается, пока вызывающий представится.

Я именно об этом и пишу. Потому что в классическом (и единственном) binkp представляется ВЫЗЫВАЕМВЫЙ, а не вызывающий. И пока вызываемый не представится (не начнёт хендшейк), сессия не начнётся.


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

Dmitriy Romanov написал(а) к Alexey Fayans в Oct 24 19:45:16 по местному времени:

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


Писал как-то Alexey Fayans к Dmitriy Romanov примерно 10 Окт 24 в 09:14
А я смотрю и фигею.


AF>>> В спецификации binkp написано, что вызываемая сторона должна
AF>>> начать хендшейк. Поэтму любой софт, реализующий протокол binkp,
AF>>> будет работать именно так и никак иначе. Если кто-то сделает
AF>>> по-другому, то ни один стандартный клиент не будет с такой
AF>>> реализцией работать.
DR>> классический binkd не дожидается, пока вызывающий представится.

AF> Я именно об этом и пишу. Потому что в классическом (и единственном) binkp
AF> представляется ВЫЗЫВАЕМВЫЙ, а не вызывающий. И пока вызываемый не
AF> представится (не начнёт хендшейк), сессия не начнётся.
Это не везде так. Мне среди линков встречались и другие мейлеры, которые вели себя по-другому. Они не представлялись
первыми на входящей сессии, а ждали, когда представится вызыывающий.

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

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

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

10 окт 24 19:45, Dmitriy Romanov -> Alexey Fayans:

AF>>>> В спецификации binkp написано, что вызываемая сторона должна
AF>>>> начать хендшейк. Поэтму любой софт, реализующий протокол binkp,
AF>>>> будет работать именно так и никак иначе. Если кто-то сделает
AF>>>> по-другому, то ни один стандартный клиент не будет с такой
AF>>>> реализцией работать.
DR>>> классический binkd не дожидается, пока вызывающий представится.

AF>> Я именно об этом и пишу. Потому что в классическом (и
AF>> единственном) binkp представляется ВЫЗЫВАЕМВЫЙ, а не вызывающий.
AF>> И пока вызываемый не представится (не начнёт хендшейк), сессия не
AF>> начнётся.

DR> Это не везде так. Мне среди линков встречались и другие мейлеры,
DR> которые вели себя по-другому. Они не представлялись первыми на
DR> входящей сессии, а ждали, когда представится вызыывающий.

Посмотрел логи bforce - фаза 0: MD5-челендж, фаза 1: обмен заголовками, заканчивается у обоих (и вызывающего, и вызываемого) посылкой своего AKA, фаза 3: проверка пароля сессии. Технически несложно дождаться АКА вызывающего, чтобы собрать свой АКА и это, как я правильно понял, вполне соответствует спецификации. Важно не кто что начинает (без MD5-челенджа не будет и обмена NUL,SYS,ZYZ и ADR).

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