= Сообщение: 5238 из 14902 ======================================= R50.SYSOP =
От : Alexey Vissarionov 2:5020/545 05 Sep 16 21:21:12
Кому : Alex Barinov 05 Sep 16 21:21:12
Тема : EON
FGHI : area://R50.SYSOP?msgid=2:5020/545+57cdc956
На : area://R50.SYSOP?msgid=2:5020/715.1+57cd926f
= Кодировка сообщения определена как: CP866 ==================================
==============================================================================
Доброго времени суток, Alex!
05 Sep 2016 18:02:44, ты -> мне:
AB>>> Тут мы вновь возвращаемся к религиозному спору на тему что
AB>>> такое "your coordinator was unable to contact you"
AV>> Здесь как раз все очевидно.
AV>> Или надо объяснять разницу между "you" и "your node"?
AB> Дык ответ на Arq/RRq - это как раз "your node", не? :-)
Ага. А человеческий ответ на етмыло - это уже таки "you".
AB>>> и к какому уровню OSI оно относится. :-)
AV>> Доброго сэра не затруднит назвать хотя бы один сетевой стек,
AV>> который соответствовал бы OSI? :-)
AB> С применением популярного контрацептива и глобуса - практически
AB> любой. ;-)
В твоем распоряжении есть оба предмета в натуральную величину. Натягивай :-)
И таки да: к черту перья, я должен это видеть.
AB>>> Если для протоколов, поддерживающих сессии всё понятно: нет
AB>>> сессии - нет связи, то для EON (в общем виде) всё несколько
AB>>> сложнее,
AV>> Никаких сложностей.
AV>> Что нам говорит мейлер после успешно проведенной сессии? Правильно,
AV>> что-то наподобие:
AV>> + 02 Sep 07:30:00 [1234] done (to %s, OK, S/R: 1/0 (%u/%u bytes))
AB> Угу. Это подтверждает прибытие пакета в инбаунд адресата и считается
AB> достаточным критерием живости узла (даже если тоссер при этом ушёл в
AB> себя и вернётся нескоро).
Вотъ!
AV>> Соответственно, когда в SMTP-сессии после DATA мы получаем 250 -
AV>> это точно так же означает, что отправленный .pkt успешно достиг
AV>> "той стороны".
AB> Угу. Но в этом случае для признания узла живым мы почему-то
AB> дополнительно ждём активности тоссера?
Таков протокол. В исходном значении этого слова.
Дело в том, что "директная" доставка на сабж происходит не напрямую, а опосредованно. С одной стороны, это серьезное техническое послабление, позволяющее поддерживать узлы в ситуациях, когда связь в реальном времени невозможна, а с другой - потенциальный источник почти не диагностируемой дохлятины.
Именно потому, что функции мейлера у сабжа размазаны между почтовым сервером (кстати, технически это может быть вообще любой livedrop) и собственно узлом, предъявляется дополнительное требование, обеспечивающее подтверждение живости этого самого узла.
AB>>> и даже свежий FTS-5001 (рождённый, полагаю, не без твоего участия
AB>>> ;-) ) допускает неодназначные трактовки.
AV>> В каком месте?
AB> To use the flag for any Email method providing for return receipts
AB> (currently ITX and ISE) a node *must* have them enabled and send
AB> such receipts within 24 hours of receiving a file.
AB> Эта фраза очевидно про отклик квитками компьютера сисопа, а не
AB> почтового сервера, и, соответственно, receiving относится именно к
AB> получению файла этим компьютером
Тогда уж не файла, а сообщения.
AB> (лаг в 24 часа лишь укрепляет нас в этой гипотезе).
Угу.
AB> Ты же предлагаешь считать receiving подтверждение о приёме файла
AB> почтовым сервером.
#include <FTA-1006>
Как, надеюсь, до сих пор говорят в 2:467, это таки две большие разницы.
Сабж _обязан_ (_must_) отвечать на ARq|RRq, а отправитель _может_ (_may_) считать сообщение доставленным, получив от SMTP-сервера 250 в ответ на DATA.
AB>>> Когда мы ломали копья на тему легализации EON было озвучено
AB>>> вполне логичное требование: узел должен обеспечить поддержку на
AB>>> указанном в нодлисте адресе заявленных в нодлисте протоколов
AV>> И все. А вот поддержка протокола для сабжа означает прием эмыльных
AV>> аттачей в формате .pkt и ответ тоссера (трекера) на ARq и RRq, если
AV>> таковые запрошены.
AB> В течение 24-х часов после получения _узлом_ пакета при условии
AB> поддержки им протоколов ITX и/или ISE.
А других формально не существует. И, соответственно, для существования в нодлисте сабжу нужно быть хотя бы внешне неотличимым от узла, работающего по указанным в стандарте протоколам.
AB>>> + ответ на e-mail, адресованный на тот же адрес,
AV>> Никто на него отвечать не обязан. Более того, я лично озвучивал
AV>> рекомендацию создавать для сабжей отдельные эмыльные адреса и
AV>> обрабатывать только сообщения, сожержащие валидные .pkt в аттачах,
AV>> а остальные нещадно удалять.
AB> Это равносильно запрету отвечать голосом по нодлистовому телефону,
AB> хотя это вполне себе способ связаться с сисопом, которым я в бытность
AB> NC успешно пользовался.
Та же самая ошибка: то, что по нодлистовому телефону кто-то может (_may_) позвонить голосом, вовсе не означает, что там на этот звонок кто-то должен (_must_) ответить. Равно как то, что если телефонная линия и может (_may_) использоваться для голосового звонка, не означает, что кто-то должен (_must_) туда звонить.
AB>>> Мы куда-то торопимся?
AV>> В некоторых случаях это весьма актуально.
AB> Если узер мёртв от слова совсем, то сложно представить что-то столь
AB> актуальное.
Как раз в этом случае он не напрягает никого, кроме своих линков.
AB> Если с него идёт раздражающий трафик, то его всегда можно отсечь на
AB> аплинке, после чего запустить стандартную процедуру розыска сисопа.
Пробовали. Вони было...
AB> Если сисоп пропал, а с узла льётся говнище, то его вынос из нодлиста
AB> всё равно проблему не решит. Так и сяк придётся решать проблему с
AB> аплинками.
Аплинк в такой ситуации может быть глубоким автопилотом, и это его право: ответственность за говнище с другого узла он не несет.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Любой инструмент, используемый не по назначению, превращается в грабли
--- /bin/vi
* Origin: http://openwall.com/Owl/ru (2:5020/545)
|
