= Сообщение: 3037 из 46911 ================================ RU.FIDONET.TODAY =
От : Serguei E. Leontiev 2:5020/400 20 Nov 15 09:53:42
Кому : Alexey Vissarionov 20 Nov 15 09:53:42
Тема : Re: Очередное осеннее об острение (Fwd: 2:5020/400)
FGHI : area://RU.FIDONET.TODAY?msgid=<1187503135@ddt.demos.su>+e236f38d
На : area://RU.FIDONET.TODAY?msgid=2:5020/545+564ea421
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.FIDONET.TODAY?msgid=2:5020/545+564ef179
==============================================================================
From: "Serguei E. Leontiev" <leo@sai.msu.ru>
Привет Алексей,
От 20 ноября 2015 г., 7:40:00 в fido7.ru.fidonet.today ты писал:
SL>>>>>> Так что надо два сервера и два
SL>>>>>> администратора.
MD>>>>> Ты имеешь в виду кластер из двух серверов?
SEL>>>> Зачем кластер? Кластера для новостей и почты не
SEL>>>> требуются
AV>>> Кластер получится с фидошной стороны, так как нужно
AV>>> будет либо использовать shared AKA на всех NNTP-гейтах,
AV>>> либо объединять их в полносвязку.
SEL>> Честно говоря, мои представления о FTN технологиях чисто
SEL>> теоретические, поэтому я не понимаю зачем им вообще знать
SEL>> друг о друге. Если несколько узлов выложат информационно
SEL>> идентичные сообщения с одинаковым MSGID это же не вызовет
SEL>> проблем и лишних пересылок, я ничего не путаю?
AV> MSGID содержит адрес узла, через который сообщение попало на
AV> FTN-сторону. Соответственно, этот адрес должен быть общим для
AV> всех гейтов (shared AKA).
Я сейчас точно не помню номер документа ФИДО, который этому посвящён. Hо
клудж MSGID получается из заголовка Message-ID и наоборот.
В моём предыдущем сообщении клудж:
@MSGID:\xE2\x80\x82<1187503132@ddt.demos.su>\xE2\x80\x82ca8169ba
Был получен из заголовка:
Message-ID: <1187503132@ddt.demos.su>
SEL>> Конечно, если механизм "автомодерации" правильно устроен.
AV> Hасчет него я уже предложил решение с кучкой MX для
AV> fido7gate.example.net
Под механизмом "автомодерации" имелось ввиду набор правила проверки
допустимости сообщения, сейчас это соответствие, так сказать, "пароля"
пользователя, его адреса и разрешения на группу.
SEL>>>> Традиционно каждая группа иерархии fido7.*
SEL>>>> модерируемая, т.е. для неё определён почтовый
SEL>>>> адрес, на который пересылается сообщение по SMTP.
SEL>>>> Обработчик этого сообщения помещает его, и в NNTP,
SEL>>>> и в FTN сети.
AV>>> Хм... А что помешает абстрактному серверу NNTP сразу
AV>>> пихнуть сообщение в конференцию - минуя почтовый адрес
AV>>> модератора?
SEL>> Это ошибка, источник ошибки найдут и поправят.
AV> Думаю, в случае незаметной текстовой группы даже искать не
AV> будут.
Будет вопрос - будут искать.
SEL>>>> Сейчас для всех групп адрес одинаковый:
SEL>>>> gateway@fido7.ru
AV>>> Так... А если для fido7gate.example.net создать пачку
AV>>> равноправных MX: ??; example.net
AV>>> fido7gate IN MX 1 somehost.somedomain1.net
AV>>> IN MX 1 somehost.somedomain2.net
AV>>> IN MX 1 somehost.somedomain3.net
AV>>> Оно ведь пойдет на "модерирование" на какой-то случайно
AV>>> выбранный сервер, а в случае его недоступности будет
AV>>> пытаться доставить на остальные. Следовательно,
AV>>> фидошный тоссер на том сервере, куда пришло сообщение,
AV>>> отправит его в эху со своим и общим (shared) адресами в
AV>>> seen-by. А как это будет выглядеть в NNTP?
SEL>> Hачну с конца, с NNTP. Мне видится, что все узлы
SEL>> закладывают информационно идентичные сообщения с
SEL>> одинаковым MSGID из FTN в NNTP сообщения с одинаковыми
SEL>> Message-ID. Другие NNTP сервера забирают сообщения с теми
SEL>> Message-ID, которых у них нет. Грубо говоря, кто первый
SEL>> сообщение выложил, того и тапки.
AV> Именно так - был MSGID: 2:5020/545.1 12345678, стал Message-ID:
AV> msgid-p1.f545.n5020.z2-12345678@fidonet.org
AV> Главное, чтобы на всех узлах это преобразование было одинаковым.
Если мне не изменяет память, то был документ ФИДО описывающий это
преобразование.
SEL>> И в сторону FTN, полагаю, может быть аналогично. Все
SEL>> выкладывают сообщения, а остальные узлы как-нибудь уж
SEL>> заберут только то, чего у них нет.
AV> Для этого точно так же нужно, чтобы преобразование Message-ID в
AV> MSGID было одинаковым на всех серверах. Для этого нужен даже не
AV> shared AKA, а отдельный служебный адрес, который используется
AV> исключительно для гейта, и с остальной FTN-сетью связан только
AV> через свой реальный узел. Пример: пусть, например, таким
AV> служебным адресом является 2:50/1000, а я хочу поднять свой
AV> гейт. Мой основной узел 2:5020/545 продолжает работать в
AV> точности так, как и работает, но у него появляется линк
AV> 2:50/1000, к которому мой узел обрачается по явно указанному
AV> адресу и порту (например, localhost:22222). Гейт может работать
AV> на том же компутере, но, например, под другим пользователем, и
AV> его задача состоит только в обмене сообщениями с двумя
AV> аплинками - по одному с каждой стороны (FTN и NNTP).
AV> Соответственно, если кто-то еще (пусть 2:5020/9999) хочет
AV> поднять свой гейт, он делает в точности такую же конструкцию.
AV> Если сообщение приходит откуда-то еще - оно совершенно
AV> одинаково гейтуется в NNTP, получая одинаковые Message-ID. Если
AV> сообщение было написано на 2:5020/9999 и приехало ко мне - в
AV> нем присутствует кладж AV> отдавать его на свой гейт. А если сообщение пришло со стороны
AV> NNTP - оно получает MSGID: 2:50/1000 12345678 на всех гейтах и,
AV> теоретически, может породить дупы на фидошной стороне, а этого
AV> можно легко избежать, объединив держателей гейтов в полносвязку. Вот,
AV> собственно, и все решение... Хорошо быть архитектором отказоустойчивых
AV> систем - подобные конструкции придумываются сами собой :-)
Всё это конечно хорошо, но клудж MSGID не обязан зависеть от FTN адреса
шлюза, но должен быть однозначно связан с заголовком Message-ID
исходного NNTP или SMTP сообщения. Пойду найду документ, который это
описывает. По-моему, здесь придумывать ничего особо не надо.
SEL>> Исходя из этого, я полагал бы, что надёжнее forward на все
SEL>> узлы, а не выбор MX. Ведь узел может быть доступным по
SEL>> SMTP, а сообщения, по тем или иным причинам, дальше
SEL>> проходить не могут.
AV> Вроде бы вышеописанный метод полностью исключает данную
AV> проблему.
При чистом шлюзовании NNTP <-> конференции FTN этой проблемы, как
очевидно, вообще нет. Каждое полученное и укладываемое в базу NNTP
сообщение гейтируется в FTN, если срок его жизни ещё не истёк (не
превысил времени хранения базы). И наоборот. Проблем отказоустойчивости
не возникает.
Проблема отказоустойчивости может возникнуть при "автомодерации", т.е. с
момента когда шлюз получил по SMTP сообщение до момента когда он отдал
его и в NNTP и в FTN, сообщение(я) могут быть задержаны на
неопределённый срок или утеряны.
Если вероятность того, что SMTP принимает, а NNTP не отправляет, мала,
то можно и не размножать сообщения.
--
Успехов, Сергей Леонтьев. E-mail: lse@CryptoPro.ru
--- ifmail v.2.15dev5.4
* Origin: ГАИШ МГУ (2:5020/400)
|
