От 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 и наоборот.
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