Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.FTN.DEVELOP
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.FTN.DEVELOP с датами от 12 Jul 13 20:52:30 до 25 Apr 24 08:46:43, всего сообщений: 2456
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 191 из 2456 ==================================== RU.FTN.DEVELOP =
От   : Pavel Gulchouck                  2:463/68           18 Jan 14 20:51:28
Кому : Ivan Agarkov                                        18 Jan 14 20:51:28
Тема : binkp unixtime
FGHI : area://RU.FTN.DEVELOP?msgid=2:463/68+52dacf7b
На   : area://RU.FTN.DEVELOP?msgid=2:5020/849.1+52daba66
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.FTN.DEVELOP?msgid=2:5020/849.1+52dad97d
==============================================================================
Hi Ivan!

18 Jan 14, Ivan Agarkov ==> Pavel Gulchouck:

PG>> В каком случае (кроме ошибки мейлера) unixtime принятого файла может
PG>> не совпадать с передаваемым?

IA> Hеполная реализация протокола/ошибка сети/ошибка процессора/памяти/64-битный unixtime/etc

64-битный unixtime не повлияет на соответствие этого самого unixtime.
Остальные ошибки затрагивают unixtime в той же степени, что размер и имя файла.
Соответственно, считаю, что на несовпадение unixtime нужно реагировать так же, как на несовпадение имени файла или его размера. То есть, как на unexpected M_GOT.
Либо игнорировать, либо дропать сессию.
А вот воспринимать некорректный M_GOT как корректный думаю, что неправильно.

PG>> Если точнее, то отправка M_GOT с другим unixtime нарушает FTS, а как
PG>> такое интерпретировать (игнорировать M_GOT или игнорировать
PG>> несовпадение или дропать сессию) - кажется, все варианты корректны.
PG>> Игнорировать несовпадение лично мне кажется не лучшим из них.

IA> Вот я и говорю, что надо бы этот момент уточнить в протоколе, поскольку там M_ERR точно указан только на несовпадение
IA> пароля.

FTS-1026:

   3. Any stage: M_NUL, M_ERR, M_BSY. These commands MAY be sent any
      time during the session.
[...]
   M_ERR 7

           This command indicates a fatal error. A party sending M_ERR
           SHOULD abort the session. Argument SHOULD contain an error
           explanation and may be logged by the remote. Mailer sends
           M_ERR in response for an incorrect password. Mailer MUST
           NOT abort a session without sending a M_ERR or a M_BSY
           frame (though state machine tables, for simplicity, may
           not include "transmit M_ERR" instructions).

           e.g. M_ERR "Incorrect password"

           The following list of M_ERR argument is recommended for
           compatibility purposes (but other messages are possible):

           * "Bad address"
             remote mailer passed bad (restricted) address;
           * "Incorrect password"
             remote side send incorrect password;
           * "<command>: cannot parse args"
             illegal argument string for binkp command;

           Implementation note: after receive M_ERR and session drops
           mailer should wait some time before next poll to that link
           to prevent continuous poll.


Никаких ограничений на возможные причины отправки M_ERR нет, и есть несколько примеров.

              Lucky carrier,
                           Паша
                           aka  gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5
* Origin: Опыт - это то, что мы получаем вместо того, что хотели (2:463/68)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.086254 секунды