Очередное осеннее обострение (Fwd: 2:5020/400)

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

From: "Serguei E. Leontiev" <leo@sai.msu.ru>

Привет Алексей,

От 19 ноября 2015 г., 20:02:00 в fido7.ru.fidonet.today ты писал:
SEL>>>>>> Когда-то я высказывал вопрос о создании
SEL>>>>>> параллельного шлюза связанного с neva.ru,
SEL>>>>>> технически это возможно, но ясное дело,
SEL>>>>>> энтузиазма это не вызывает, да и не должно
SEL>>>>>> вызывать.
MD>>> Что такого замечательного в neva.ru?
SEL>> Да ничего особенного, просто сейчас fido7.ru всё отдаёт на
SEL>> neva.ru В принципе, всё равно, от точки подключения к
SEL>> Usenet мало чего зависит.
AV> Ну да - значение имеет наличие этого самого подключения, ибо
AV> найти сервер, готовый предоставить фид, практически нереально -
AV> фидошный линк установить намного проще.

Ну да, они сейчас серьёзными делами заняты по Usenet фильмы раздают и
прочее, а текстовые группы - так, их почти и не видно. Им помехи их
бизнесу не желательны.

SL>>>> Так что надо два сервера и два администратора.
MD>>> Ты имеешь в виду кластер из двух серверов? Типа
MD>>> pacemaker?
SEL>> Зачем кластер? Кластера для новостей и почты не требуются,
SEL>> однако. NNTP так же как и FTN обеспечивает многосвязанное
SEL>> и многопутевое распространение сообщений без дубликатов и
SEL>> потерь, конечно при условии взаимно однозначного
SEL>> соответствия Message-ID и информационного тела сообщения.
AV> Кластер получится с фидошной стороны, так как нужно будет либо
AV> использовать shared AKA на всех NNTP-гейтах, либо объединять их
AV> в полносвязку.

Честно говоря, мои представления о FTN технологиях чисто теоретические,
поэтому я не понимаю зачем им вообще знать друг о друге. Если несколько
узлов выложат информационно идентичные сообщения с одинаковым MSGID это
же не вызовет проблем и лишних пересылок, я ничего не путаю?

Конечно, если механизм "автомодерации" правильно устроен.

SEL>> Традиционно каждая группа иерархии fido7.* модерируемая,
SEL>> т.е. для неё определён почтовый адрес, на который
SEL>> пересылается сообщение по SMTP.
SEL>> Обработчик этого сообщения помещает его, и в NNTP, и в FTN
SEL>> сети.
AV> Хм... А что помешает абстрактному серверу NNTP сразу пихнуть
AV> сообщение в конференцию - минуя почтовый адрес модератора?

Это ошибка, источник ошибки найдут и поправят.

SEL>> Сейчас для всех групп адрес одинаковый: gateway@fido7.ru
SEL>> Если делать дополнительный шлюз, то можно, либо изменить MX
SEL>> для fido7.ru, но тогда на новом MX надо будет сразу
SEL>> правильно обрабатывать все сообщения, хотя бы пересылать
SEL>> их на старый MX, либо постепенно для каждой группы
SEL>> изменять адрес модератора на новый, скажем,
SEL>> fido7gate@mail.ru, который будет обеспечивать forward на
SEL>> все шлюзы.
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?

Начну с конца, с NNTP. Мне видится, что все узлы закладывают
информационно идентичные сообщения с одинаковым MSGID из FTN в NNTP
сообщения с одинаковыми Message-ID. Другие NNTP сервера забирают
сообщения с теми Message-ID, которых у них нет. Грубо говоря, кто первый
сообщение выложил, того и тапки.

И в сторону FTN, полагаю, может быть аналогично. Все выкладывают
сообщения, а остальные узлы как-нибудь уж заберут только то, чего у них нет.

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

--
Успехов, Сергей Леонтьев. E-mail: lse@CryptoPro.ru


--- ifmail v.2.15dev5.4

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