Показать сообщение отдельно
  #22  
Старый 15.08.2016, 12:49
Alexey Vissarionov
Guest
 
Сообщений: n/a
По умолчанию Очередное осеннее обострение (Fwd: 2:5020/400)

Alexey Vissarionov написал(а) к Serguei E. Leontiev в Nov 15 07:40:00 по местному времени:

Доброго времени суток, Serguei!
19 Nov 2015 21:04:30, ты -> мне:

MD>>>> Что такого замечательного в neva.ru?
SEL>>> Да ничего особенного, просто сейчас fido7.ru всё отдаёт
SEL>>> на neva.ru В принципе, всё равно, от точки подключения к
SEL>>> Usenet мало чего зависит.
AV>> Ну да - значение имеет наличие этого самого подключения,
AV>> ибо найти сервер, готовый предоставить фид, практически
AV>> нереально - фидошный линк установить намного проще.
SEL> Ну да, они сейчас серьёзными делами заняты по 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> Начну с конца, с 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 и приехало ко мне - в нем присутствует
кладж SEEN-BY: 50/1000 и мой узел не будет отдавать его на свой гейт. А если
сообщение пришло со стороны NNTP - оно получает MSGID: 2:50/1000 12345678 на всех гейтах и, теоретически, может породить дупы на фидошной стороне, а этого можно легко избежать, объединив держателей гейтов в полносвязку.

Вот, собственно, и все решение... Хорошо быть архитектором отказоустойчивых систем - подобные конструкции придумываются сами собой :-)

SEL> Исходя из этого, я полагал бы, что надёжнее forward на все узлы,
SEL> а не выбор MX. Ведь узел может быть доступным по SMTP, а сообщения,
SEL> по тем или иным причинам, дальше проходить не могут.

Вроде бы вышеописанный метод полностью исключает данную проблему.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii

... Рожденный ползать, уйдите со взлетной полосы!
--- /bin/vi
Ответить с цитированием