Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.

	Введите FGHI ссылку: Присутствуют сообщения из эхоконференции RU.FTN.DEVELOP с датами от 12 Jul 13 20:52:30 до 18 Oct 24 22:48:06, всего сообщений: 2735 Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение = Сообщение: 2673 из 2735 =================================== RU.FTN.DEVELOP = От   : Nil A                            2:5015/46          11 Oct 24 18:11:30 Кому : Alexey Khromov                                      11 Oct 24 18:11:30 Тема : Binkp handshake FGHI : area://RU.FTN.DEVELOP?msgid=2:5015/46+6709418b На   : area://RU.FTN.DEVELOP?msgid=2:5030/723+67090986 = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.FTN.DEVELOP?msgid=2:5030/1997@fidonet+670952bb Ответ: area://RU.FTN.DEVELOP?msgid=2:5030/723+67097194 Ответ: area://RU.FTN.DEVELOP?msgid=2:6078/1+670a7039 ============================================================================== Hello, Alexey! 11 Oct 24 14:12, from Alexey Khromov -> Alexey Fayans: AK> Как видишь, в стандарте *не определено* ожидание M_ADR одной из сторон AK> - только синхронизация на сверке пароля, о чем явно указано в AK> FTS. Однако, технически *возможно* и *не противоречит* стандарту, если AK> в мейлер добавить выдачу своего адреса только после представления AK> вызывающей стороны, о чем я ранее и написал. Означает ли это, что если обе стороны будут, как при игре в покер, пытаться не "раскрыть свои карты" до последнего, что как бы не противоречит стандарту, то хендшейк просто будет застревать, играют в несознанку, и отваливаться по таймауту? В этом плане, какой-нибудь TLS handshake более понятен. Есть ClientHello, есть ServerHello, и понятно кто что предъявляется, чтобы можно было договориться. Best Regards, Nil --- GoldED+/LNX 1.1.5-b20240306 * Origin: FidoNet member since 1995 (2:5015/46) К главной странице гейта

Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.117031 секунды