= Сообщение: 2712 из 2735 =================================== RU.FTN.DEVELOP = От : Vitaliy Aksyonov 1:104/117 14 Oct 24 23:37:18 Кому : Alexey Fayans 14 Oct 24 23:37:18 Тема : Re: Binkp handshake FGHI : area://RU.FTN.DEVELOP?msgid=1:104/117+670dffef На : area://RU.FTN.DEVELOP?msgid=2:5030/1997@fidonet+670ce104 = Кодировка сообщения определена как: CP866 ================================== ============================================================================== Привет, Alexey!
14 Oct 24 12:14, ты писал(а) Stas Mishchenkov:
AF>>> Отлично, но как я и написал, нужно тестировать binkd 1.0 в AF>>> качестве вызывающей стороны, потому что именно он, скорее всего, AF>>> будет ждать до последнего, пока вызываемая сторона не AF>>> представится. В результате либо сессия отвалится по таймауту, AF>>> либо binkd 1.0 буде думать, что соединился с каким-нибудь 0:0/0. SM>> Сори. Не внимательно прочитал. Здесь реализован binkp 1.0 таким SM>> образом, что он не ждёт, когда вызываемая сторона представится, а SM>> сразу представляется сам.
AF> Как и везде. И речь в этом треде идёт о том, что будет, если AF> вызываемая сторона представится не полностью и будет ждать адрес AF> вызывающей перед тем, как выдать свой. И я говорю о binkd 1.0, а не AF> binkp 1.0, потому что, вероятно, в какой-нибудь современной версии AF> binkd такой хендшейк и прокатит, а в старой - крайне маловероятно.
Если одна из сторон не пришлёт адрес/пароль, то сессия просто не установится и отвалится по таймауту. Но что-то мне подсказывает, что это так не работает. Ведь в самой первой версии стандарта нет никакого ожидание адресов прежде чем слать свои адреса.
