= Сообщение: 8124 из 15065 ======================================= R50.SYSOP =
От : Pavel Gulchouck 2:463/68 10 Nov 17 10:17:52
Кому : Alex Barinov 10 Nov 17 10:17:52
Тема : кому стандарты не писаны?
FGHI : area://R50.SYSOP?msgid=2:463/68+5a0568e2
На : area://R50.SYSOP?msgid=2:5020/715.1+5a055bc0
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://R50.SYSOP?msgid=2:5020/5480+5a05a890
Ответ: area://R50.SYSOP?msgid=2:5020/715.1+5a05bddf
Ответ: area://R50.SYSOP?msgid=2:5020/8912+5a05f356
==============================================================================
Hi Alex!
10 Nov 17, Alex Barinov ==> Pavel Gulchouck:
AB> 10 ноя 17 06:26, Pavel Gulchouck wrote to Alexey Vissarionov:
PG>> недостатки. Больше проблем было как раз от ручного управления и
PG>> делегирования поддоменов координаторам или другим доверенным лицам в
PG>> сетях:
AB> Ты не путаешь fidonet.net с fidonet.org? Первый, ЕМНИМС, вёлся централизованно.
Сети делегировались и в fidonet.net, и в fidonet.org. Причём в fidonet.net даже более активно, т.к. там распределённость была частью идеологии. При ручном внесении изменений админы fidonet.net не хотели обслуживать изменения во всём фидо.
Например, у меня жили домены n463.z2.fidonet.net и n46.z2.fidonet.net.
А когда домен fidonet.net упал, я восстанавливал информацию из поддоменов сетей, которые были доступны, чтобы перенести её в binkp.net, и чтобы узлы, сисопы которых не озаботились переездом в другой домен, были доступны через binkp.net.
PG>> Если ещё пофантазировать о том, как его можно было бы сделать лучше и
PG>> надёжнее, то мне видится система из двух-трёх доменов, принадлежащих
PG>> разным людям, с автоматической репликацией изменений (например, через
PG>> git, но это не принципиально).
AB> А смысл? Чем принципиально не устраивает существующая нодлистовая схема? Она децентрализованна by design, всю необходимую
AB> информацию для связи с узлом разместить в нодлисте возможно, скорость обновления вполне достаточна. Необходимость сисопам
AB> самостоятельно обеспечивать DNS-service? Так это, наоборот, хорошо, так как обеспечивает дополнительную децентрализацию, а
AB> стоимость данного сервиса для сисопа либо равна нулю в случае бесплатых DDNS или того же binkp.net, либо к нему стремится.
Я не говорил "принципиально не устраивает". Я сказал, наоборот, что то, что есть сейчас, тоже вполне нормально. Хотя могло быть и лучше.
Не принципиальные, но всё-таки недостатки существующей сейчас схемы, которые я вижу.
1. Необходимость ручной работы координатора при изменении адреса узла (а координатор может быть в отпуске или ещё по какой-то причине отрабатывать с задержкой). Соответственно, процедура изменения адреса для сисопа усложняется: вместо изменения параметра на сайте нужно вступать в переписку с человеком. Координатор может вообще потеряться, тогда внесение изменений в сегмент будет заблокировано, пока RC не убедится, что NC потерялся совсем, и не назначит tempNC.
2. Низкая скорость обновлений: официальным по-прежнему является еженедельный нодлист, а неделю ждать изменения адреса - очень долго. Даже при использовании ежедневного нодлиста от отправки изменения координатору до распространения нодлиста с изменениями проходит несколько дней.
3. Необходимость для сисопа, подключившегося к интернету, решать вопрос с доменом, т.е. изучать, что такое DNS, регистрировать домен, платить за него (причём, регулярно), обновлять там информацию при изменении IP. Ведь ходят слухи, что использовать binkp.net для этой цели плохо. Конечно, не факт, что при наличии системы из двух-трёх независимых доменов такие слухи не ходили бы, но такая схема могла бы быть рекомендованой координаторами, и использовать её было бы удобнее, чем заводить собственный домен каждому сисопу.
4. Прикручивание нодлиста к binkd не очень удобно (это делается через перл-хуки, и для этого нужно иметь автообновляемый нодлист), а использование какого-то чужого DDN - точка отказа. Прописать два-три рекомендованых координаторами DDN было бы удобным и надёжным решением, потому что проблемы с ними были бы быстро обнаружены и исправлены (либо упавший домен заменен на другой).
Иными словами, использование централизованого сервиса имеет не только недостатки, но и преимущества. И преимущества эти не только в более оптимальном использовании ресурсов, но и, как ни парадоксально, в надёжности: проблемы с централизованым сервисом обнаруживаются сразу, а проблемы с частями распределённой структуры могут долго оставаться незамеченными. Нужно только, чтобы проблема с централизованным сервисом не вызывала серьёзного ущерба, а это решается дублированием его "головы".
Lucky carrier,
Паша
aka gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5-b20160827
* Origin: Опыт - это то, что мы получаем вместо того, что хотели (2:463/68)
|
