= Сообщение: 187 из 15065 ======================================== R50.SYSOP =
От : Pavel Gulchouck 2:463/68 10 Aug 13 14:04:44
Кому : Oleg Pevzner 10 Aug 13 14:04:44
Тема : Старые сети
FGHI : area://R50.SYSOP?msgid=2:463/68+52062c60
На : area://R50.SYSOP?msgid=2:464/5555+5205fc33
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://R50.SYSOP?msgid=2:5000/111+5206663c
Ответ: area://R50.SYSOP?msgid=2:464/5555+5208100e
==============================================================================
Hi Oleg!
10 Aug 13, Oleg Pevzner ==> Pavel Gulchouck:
[...]
PG>> Так что насчёт связности - думаю, можно требования смягчить, и
PG>> оставить два условия: 1. Хост должен поддерживать на вход CM binkp и
PG>> обрабатывать unsecure netmail для узлов своей сети. 2. Сисоп узла
PG>> должен позаботиться о том, чтобы почта от хоста к нему доходила, чтобы
PG>> хост знал, как ему доставлять почту.
OP> Да, именно сисоп должен об этом позаботиться - это прямая обязанность сисопа. У меня вопрос по хосту. Думаю, следует
OP> четко перечислить протоколы, которые хост обязан поддерживать для того, чтобы иметь право так называться. Вот,
OP> например, ifcico должен или нет? А тот же PSTN? Hу и т.п. Я думаю, здесь важно, чтобы это прозвучало четко, внятно, без
OP> возможности домысливания и всевозможных манипулирований.
Если хост имеет информацию о том, как доставлять почту каждому из узлов сети, и NC имеет связь с RC - зачем ещё какие-то обязательные протоколы?
Чтобы любой сисоп мог залить почту хосту сети (хостроутинг) - если оставлять такую возможность, достаточно одного binkp. Но я не уверен, что эту возможность имеет смысл сохранять - для связности кажется логичнее использовать цепочку ZC-RC-NC-Node, чем [any_node]->NC->Node.
PG>> Как ещё один вариант: сделать доставку почты по цепочке
PG>> ZC->RC->Host->Node обязательной, и не специфицировать общий протокол
PG>> вообще. Сисоп должен договориться об общем протоколе с хостом, хост -
PG>> с RC, RC - с ZC. Сейчас стоимость междугородной доставки почты уже
PG>> неактуальна, поэтому в таком роутинге нет ничего плохого (по нынешнему
PG>> полиси RC не обязан доставлять почту на свой регион, а ZC - на свою
PG>> зону, потому что по телефону это слишком дорого). В этом случае
PG>> связность всей сети сохранится, а общий для всех протокол и директная
PG>> доставка необязательны.
OP> Я не думаю, что введение хоть малейшей обязаловки пойдет на пользу фидошке. Сам знаешь, нечасто, но возникают
OP> случаи, когда именно нестандартные пути и способы доставки почты оказываются решающими и очень нужными. Я считаю, что
OP> чем больше разрешенных официально, допустимых средств коммуникации предусмотрено, тем лучше.
Я неправильно сформулировал свою мысль.
Я имел ввиду, сделать _возможность_ доставки по цепочке ZC->RC->Host->Node - настолько же, насколько сейчас является обязательным участок Host->Node. Это, конечно, не значит, что почта должна ходить только так и не иначе.
Но должен быть хоть один гарантированный способ одному сисопу отправить netmail любому другому так, чтобы письмо дошло, чтобы никто по пути не сказал "я не обязан пересылать это письмо и не буду этого делать".
По нынешнему полиси это либо direct в ZMH по FTS-1 на нодлистовый телефон, либо влить хосту сети получателя (тоже директом в ZMH).
На практике этот способ использовался редко, а сейчас и вовсе не используется, но он декларирован, и сейчас вместо него должен быть какой-то другой способ связи на случай, если с привычным роутингом что-то не работает. Вот и предлагаю в качестве такого гарантированного пути доставки использовать путь через координаторов. Скажем, если я (2:463/68) хочу отправить письмо на 2:5020/545, и обычный путь через лонглинков мне почему-то не подходит, у меня есть следующие варианты:
- директ
- влить на 2:5020/0
- влить на 2:50/0
- влить на 2:2/0
- влить на 2:46/0
- влить на 2:463/0
Как минимум, последний из этих шагов должен получиться, т.к. у сисопа есть связь с хостом (возможно, через хаба - это не принципиально). На каждом следующем шаге опять рассматриваются варианты. Например, 2:463/0, получив от меня письмо для 2:5020/545, может его отправить директом, на 2:5020/0, на 2:50/0, на 2:2/0 или на 2:46/0. Последний шаг гарантирован, т.к. у хоста должен быть линк со своим RC. И так далее, наиболее длинный возможный путь получается
2:463/68 - 2:463/0 - 2:46/0 - 2:2/0 - 2:50/0 - 2:5020/0 - 2:5020/545
но любой его участок может быть сокращён при наличии прямого парольного линка между соответствующими узлами.
Такой вариант хорош ещё и тем, что весь путь при этом проходит только через парольные линки.
Для этого нужно лишь добавить, что любой координатор обязан передавать транзитную почту для узлов своего уровня иерархии на координаторов следующего уровня, и от координаторов следующего уровня. Например, RC обязан роутить парольную почту для сисопов своего региона соответствующим NC, и обязан роутить почту от NC своего региона. Поскольку линки между RC и NC, как и линки между ZC и RC, есть так или иначе, я не думаю, что эта обязанность может быть сколь-нибудь обременительной. Уверен, любой RC сейчас и так роутит парольную почту для своего региона.
И такой вариант действительно позволяет отказаться от единого общего для всей сети протокола, сохранив при этом связность сети.
Lucky carrier,
Паша
aka gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5
* Origin: Опыт - это то, что мы получаем вместо того, что хотели (2:463/68)
|
