FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.FTN.DEVELOP


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

Введите FGHI ссылку:

Присутствуют сообщения из эхоконференции RU.FTN.DEVELOP с датами от 12 Jul 13 20:52:30 до 18 Oct 24 22:48:06, всего сообщений: 2735

Ответить на сообщение

К списку сообщений

Предыдущее сообщение

Следующее сообщение

= Сообщение: 2672 из 2735 =================================== RU.FTN.DEVELOP =
От   : Alexey Khromov                   2:5030/723         11 Oct 24 14:12:07
Кому : Alexey Fayans                                       11 Oct 24 14:12:07
Тема : Binkp handshake
FGHI : area://RU.FTN.DEVELOP?msgid=2:5030/723+67090986
На   : area://RU.FTN.DEVELOP?msgid=2:5030/1997@fidonet+6708f507
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.FTN.DEVELOP?msgid=2:5015/46+6709418b
Ответ: area://RU.FTN.DEVELOP?msgid=2:5030/1997.2+2972704e
==============================================================================
Здраствуйте, Alexey!

11 окт 24 12:51, Alexey Fayans -> Alexey Khromov:

AF> выдал сразу после того, как я к нему подключился телнетом и ничего не
AF> отправил:
AF> В этой простыне в том числе и твой адрес. Были бы прописаны ака - тоже
AF> были бы предъявлены сразу.

Именно. Читаем стандарт binkp1.0 и пропозал binkp1.1 :

======================================================
http://ftsc.org/docs/fts-1026.001

Binkp uses only one synchronization point during session startup,
   that is password exchange.

Session setup stage: M_ADR (MUST be sent by both sides), M_PWD
      (MUST NOT be sent by the Answering side), M_OK (MUST NOT be sent
      by the Originating side).
      These commands MUST NOT be sent during the file transfer stage.

   +----------------------------------------------------------------+
   | Originating side               | Answering side                |
   |--------------------------------+-------------------------------|
   | M_NUL "SYS ..."                | M_NUL "SYS ..."               |
   | M_NUL "ZYZ ..."                | M_NUL "ZYZ ..."               |
   | M_NUL "LOC ..."                | M_NUL "LOC ..."               |
   | M_NUL "VER ..."                | M_NUL "VER ..."               |
   | M_NUL "OPT ..."                | M_NUL "OPT ..."               |
   | M_ADR "1:1/1.1@fidonet"        | M_ADR "2:2/2.2@fidonet"       |
   | M_PWD "password"               | (waiting for a password from  |
   |                                | remote)                       |
   |--------------------------------+-------------------------------|
   | (waiting for password          | M_OK "secure"                 |
   | acknowledgement)               |                               |
   |--------------------------------+-------------------------------|
   | (got M_OK)                     | M_FILE "file2 200 42342434 0" |
   |--------------------------------+-------------------------------|
   | M_FILE "file1 100 423424244 0" | data                          |
   |--------------------------------+-------------------------------|
   | data                           | data                          |
   |--------------------------------+-------------------------------|

http://ftsc.org/docs/fts-1027.001

1.7 Example of Frame Exchange During CRAM Authentication
   --------------------------------------------------------

     Originating :
     send M_NUL and M_ADR messages
     wait for first M_NUL and/or M_ADR message

     Answering   :
     send M_NUL "OPT xx xx CRAM-MD5-f0315b074d728d483d6887d0182fc328"
     send M_ADR message
     and other messages
     wait for M_PWD
   Note: xx means other optional extensions thay are supported.

BinkP 1.1
http://ftsc.org/docs/fsp-1024.000

   NOTE: Modify the table slightly to show one of the sides goes into
   waiting after receiving M_EOB. Not showing this is confusing.

   +-----------------------------------------------------------------+
   | Originating side               | Answering side                 |
   |--------------------------------+--------------------------------|
   | M_NUL "SYS ..."                | M_NUL "SYS ..."                |
   | M_NUL "ZYZ ..."                | M_NUL "ZYZ ..."                |
   | M_NUL "LOC ..."                | M_NUL "LOC ..."                |
   | M_NUL "VER ..."                | M_NUL "VER ..."                |
   | M_NUL "OPT ..."                | M_NUL "OPT ..."                |
   | M_ADR "1:1/1.1@fidonet"        | M_ADR "2:2/2.2@fidonet"        |
   | M_PWD "password"               | (waiting for a password from   |
   |                                | remote)                        |
   |--------------------------------+--------------------------------|
   | (waiting for password          | M_OK "" (or M_ERR "Bad         |
   | acknowledgement)               | password")                     |
   |--------------------------------+--------------------------------|

======================================================================

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

Alexey Khromov
--- GoldED+/LNX 1.1.5-b20240309
* Origin:  - Вы в опасности! Вы окружены роботами! -  (2:5030/723)

К главной странице гейта