= Сообщение: 3034 из 46911 ================================ RU.FIDONET.TODAY = От : Alexey Vissarionov 2:5020/545 20 Nov 15 07:40:00 Кому : Serguei E. Leontiev 20 Nov 15 07:40:00 Тема : Очередное осеннее обострение (Fwd: 2:5020/400) FGHI : area://RU.FIDONET.TODAY?msgid=2:5020/545+564ea421 На : area://RU.FIDONET.TODAY?msgid=<1187503132@ddt.demos.su>+ca8169ba = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.FIDONET.TODAY?msgid=<1187503135@ddt.demos.su>+e236f38d ============================================================================== Доброго времени суток, Serguei! 19 Nov 2015 21:04:30, ты -> мне:
MD>>>> Что такого замечательного в neva.ru? SEL>>> Да ничего особенного, просто сейчас fido7.ru всё отдаёт SEL>>> на neva.ru В принципе, всё равно, от точки подключения к SEL>>> Usenet мало чего зависит. AV>> Hу да - значение имеет наличие этого самого подключения, AV>> ибо найти сервер, готовый предоставить фид, практически AV>> нереально - фидошный линк установить намного проще. SEL> Hу да, они сейчас серьёзными делами заняты по Usenet фильмы SEL> раздают и прочее, а текстовые группы - так, их почти и не SEL> видно. Им помехи их бизнесу не желательны.
Дык я-то, к сожалению, в курсе...
SL>>>>> Так что надо два сервера и два администратора. MD>>>> Ты имеешь в виду кластер из двух серверов? SEL>>> Зачем кластер? Кластера для новостей и почты не требуются AV>> Кластер получится с фидошной стороны, так как нужно будет либо AV>> использовать shared AKA на всех NNTP-гейтах, либо объединять их AV>> в полносвязку. SEL> Честно говоря, мои представления о FTN технологиях чисто SEL> теоретические, поэтому я не понимаю зачем им вообще знать SEL> друг о друге. Если несколько узлов выложат информационно SEL> идентичные сообщения с одинаковым MSGID это же не вызовет SEL> проблем и лишних пересылок, я ничего не путаю?
MSGID содержит адрес узла, через который сообщение попало на FTN-сторону. Соответственно, этот адрес должен быть общим для всех гейтов (shared AKA).
SEL> Конечно, если механизм "автомодерации" правильно устроен.
Насчет него я уже предложил решение с кучкой MX для fido7gate.example.net
SEL>>> Традиционно каждая группа иерархии fido7.* модерируемая, SEL>>> т.е. для неё определён почтовый адрес, на который SEL>>> пересылается сообщение по SMTP. SEL>>> Обработчик этого сообщения помещает его, и в NNTP, и в FTN SEL>>> сети. AV>> Хм... А что помешает абстрактному серверу NNTP сразу пихнуть 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) адресами в seen-by. А как это будет выглядеть в AV>> NNTP? SEL> Hачну с конца, с NNTP. Мне видится, что все узлы закладывают SEL> информационно идентичные сообщения с одинаковым MSGID из FTN в SEL> NNTP сообщения с одинаковыми Message-ID. Другие NNTP сервера SEL> забирают сообщения с теми Message-ID, которых у них нет. Грубо SEL> говоря, кто первый сообщение выложил, того и тапки.
Именно так - был MSGID: 2:5020/545.1 12345678, стал Message-ID: msgid-p1.f545.n5020.z2-12345678@fidonet.org
Главное, чтобы на всех узлах это преобразование было одинаковым.
SEL> И в сторону FTN, полагаю, может быть аналогично. Все выкладывают SEL> сообщения, а остальные узлы как-нибудь уж заберут только то, SEL> чего у них нет.
Для этого точно так же нужно, чтобы преобразование Message-ID в MSGID было одинаковым на всех серверах. Для этого нужен даже не shared AKA, а отдельный служебный адрес, который используется исключительно для гейта, и с остальной FTN-сетью связан только через свой реальный узел.
Пример: пусть, например, таким служебным адресом является 2:50/1000, а я хочу поднять свой гейт. Мой основной узел 2:5020/545 продолжает работать в точности так, как и работает, но у него появляется линк 2:50/1000, к которому мой узел обрачается по явно указанному адресу и порту (например, localhost:22222). Гейт может работать на том же компутере, но, например, под другим пользователем, и его задача состоит только в обмене сообщениями с двумя аплинками - по одному с каждой стороны (FTN и NNTP).
Соответственно, если кто-то еще (пусть 2:5020/9999) хочет поднять свой гейт, он делает в точности такую же конструкцию. Если сообщение приходит откуда-то еще - оно совершенно одинаково гейтуется в NNTP, получая одинаковые Message-ID. Если сообщение было написано на 2:5020/9999 и приехало ко мне - в нем присутствует кладж Вот, собственно, и все решение... Хорошо быть архитектором отказоустойчивых систем - подобные конструкции придумываются сами собой :-)
SEL> Исходя из этого, я полагал бы, что надёжнее forward на все узлы, SEL> а не выбор MX. Ведь узел может быть доступным по SMTP, а сообщения, SEL> по тем или иным причинам, дальше проходить не могут.
Вроде бы вышеописанный метод полностью исключает данную проблему.
-- 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) |