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

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