= Сообщение: 217 из 15065 ======================================== R50.SYSOP =
От : Oleg Pevzner 2:464/5555 12 Aug 13 01:22:40
Кому : Pavel Gulchouck 12 Aug 13 01:22:40
Тема : Старые сети
FGHI : area://R50.SYSOP?msgid=2:464/5555+5208100e
На : area://R50.SYSOP?msgid=2:463/68+52062c60
= Кодировка сообщения определена как: CP866 ==================================
==============================================================================
Hello Pavel!
Saturday August 10 2013 14:04, you wrote to me:
PG> Если хост имеет информацию о том, как доставлять почту каждому из
PG> узлов сети, и NC имеет связь с RC - зачем ещё какие-то обязательные
PG> протоколы? Чтобы любой сисоп мог залить почту хосту сети (хостроутинг)
PG> - если оставлять такую возможность, достаточно одного binkp. Hо я не
PG> уверен, что эту возможность имеет смысл сохранять - для связности
PG> кажется логичнее использовать цепочку ZC-RC-NC-Node, чем
PG> [any_node]->NC->Node.
Когда я писал о перечне обязательных протоколов, имелось в виду сделать так, чтобы исключить возможность разночтений Полиси в этом вопросе. Если связность обеспечивается и при этом критерии выбора протоколов прописаны очевидно и понятно, разумеется, никакой дополнительной обязаловки вводить не стоит.
PG> Я неправильно сформулировал свою мысль.
PG> Я имел ввиду, сделать _возможность_ доставки по цепочке
PG> ZC->RC->Host->Node - настолько же, насколько сейчас является
PG> обязательным участок Host->Node. Это, конечно, не значит, что почта
PG> должна ходить только так и не иначе. Hо должен быть хоть один
PG> гарантированный способ одному сисопу отправить netmail любому другому
PG> так, чтобы письмо дошло, чтобы никто по пути не сказал "я не обязан
PG> пересылать это письмо и не буду этого делать".
Hормально...
PG> По нынешнему полиси это либо direct в ZMH по FTS-1 на нодлистовый
PG> телефон, либо влить хосту сети получателя (тоже директом в ZMH). Hа
PG> практике этот способ использовался редко, а сейчас и вовсе не
PG> используется, но он декларирован, и сейчас вместо него должен быть
PG> какой-то другой способ связи на случай, если с привычным роутингом
PG> что-то не работает. Вот и предлагаю в качестве такого гарантированного
PG> пути доставки использовать путь через координаторов. Скажем, если я
PG> (2:463/68) хочу отправить письмо на 2:5020/545, и обычный путь через
PG> лонглинков мне почему-то не подходит, у меня есть следующие варианты:
PG> - директ - влить на 2:5020/0 - влить на 2:50/0 - влить на 2:2/0 -
PG> влить на 2:46/0 - влить на 2:463/0
Угу...
PG> Как минимум, последний из этих шагов должен получиться, т.к. у сисопа
PG> есть связь с хостом (возможно, через хаба - это не принципиально). Hа
PG> каждом следующем шаге опять рассматриваются варианты. Hапример,
PG> 2:463/0, получив от меня письмо для 2:5020/545, может его отправить
PG> директом, на 2:5020/0, на 2:50/0, на 2:2/0 или на 2:46/0. Последний
PG> шаг гарантирован, т.к. у хоста должен быть линк со своим RC. И так
PG> далее, наиболее длинный возможный путь получается
PG> 2:463/68 - 2:463/0 - 2:46/0 - 2:2/0 - 2:50/0 - 2:5020/0 - 2:5020/545
PG> но любой его участок может быть сокращён при наличии прямого
PG> парольного линка между соответствующими узлами.
PG> Такой вариант хорош ещё и тем, что весь путь при этом проходит только
PG> через парольные линки.
PG> Для этого нужно лишь добавить, что любой координатор обязан передавать
PG> транзитную почту для узлов своего уровня иерархии на координаторов
PG> следующего уровня, и от координаторов следующего уровня. Hапример, RC
PG> обязан роутить парольную почту для сисопов своего региона
PG> соответствующим NC, и обязан роутить почту от NC своего региона.
PG> Поскольку линки между RC и NC, как и линки между ZC и RC, есть так или
PG> иначе, я не думаю, что эта обязанность может быть сколь-нибудь
PG> обременительной. Уверен, любой RC сейчас и так роутит парольную почту
PG> для своего региона. И такой вариант действительно позволяет отказаться
PG> от единого общего для всей сети протокола, сохранив при этом связность
PG> сети.
В целом абсолютно нормально, только нужно все это аккуратно прописать. Опять же - для четкости и исключения возможных разночтений в будущем.
WBR, Oleg Monday August 12 2013
E-Mail: omp<no-spam>omp.dp.ua
--- XStation
* Origin: (2:464/5555)
|
