= Сообщение: 3033 из 46911 ================================ RU.FIDONET.TODAY =
От : Serguei E. Leontiev 2:5020/400 19 Nov 15 21:04:30
Кому : Alexey Vissarionov 19 Nov 15 21:04:30
Тема : Re: Очередное осеннее обострение (Fwd: 2:5020/400)
FGHI : area://RU.FIDONET.TODAY?msgid=<1187503132@ddt.demos.su>+ca8169ba
На : area://RU.FIDONET.TODAY?msgid=2:5020/545+564e008c
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.FIDONET.TODAY?msgid=2:5020/545+564ea421
==============================================================================
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> Hу да - значение имеет наличие этого самого подключения, ибо
AV> найти сервер, готовый предоставить фид, практически нереально -
AV> фидошный линк установить намного проще.
Hу да, они сейчас серьёзными делами заняты по 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?
Hачну с конца, с NNTP. Мне видится, что все узлы закладывают
информационно идентичные сообщения с одинаковым MSGID из FTN в NNTP
сообщения с одинаковыми Message-ID. Другие NNTP сервера забирают
сообщения с теми Message-ID, которых у них нет. Грубо говоря, кто первый
сообщение выложил, того и тапки.
И в сторону FTN, полагаю, может быть аналогично. Все выкладывают
сообщения, а остальные узлы как-нибудь уж заберут только то, чего у них нет.
Исходя из этого, я полагал бы, что надёжнее forward на все узлы, а не
выбор MX. Ведь узел может быть доступным по SMTP, а сообщения, по тем
или иным причинам, дальше проходить не могут.
--
Успехов, Сергей Леонтьев. E-mail: lse@CryptoPro.ru
--- ifmail v.2.15dev5.4
* Origin: ГАИШ МГУ (2:5020/400)
|
