= Сообщение: 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)
|
