| From | Pavel Gulchouck | 2:463/68.0 | Date Write | 2017-11-11 16:28:28 |
|---|---|---|---|---|
| To | Alex Barinov | 0:0/0.0 | Date Arrived | 2017-11-11 17:50:09 |
| Subj | кому стандарты не писаны? | |||
| Attr | ||||
|
Hi Alex! 10 Nov 17, Alex Barinov ==> Pavel Gulchouck: PG>> Не принципиальные, но всё-таки недостатки существующей сейчас схемы, которые я вижу. AB> Проблемы по пп 1 и 2 вполне решаются силами сисопа: AB> - регистрируется FQDN, заносится в нодлист, и все последующие изменения IP ведутся в соответствующем DNS AB> - для страховки от падения DNS регистрируются несколько FQDN, все заносятся в нодлист, далее см. п. 1. Конечно, они решаются. Но сложнее. AB> Проблемы по п.3 аналогичны проблемам с PSTN / интернет каналом: таки их нужно получать, протягивать в квартиру и регулярно AB> за них платить. :-) Разумеется, всё можно решить. Но можно было бы решить проще и сэкономить ресурсы. AB> П.4 - вообще не проблема: не нравится perl - пиши свой скрипт обработки нодлиста под binkd или бери готовый из R50ROUTE AB> (или, более того, готовый регуляно обновляемый include-файл для binkd оттуда же). С автообновлением нодлиста тоже никаких AB> проблем: хочешь - бери в фэхах, хочешь - wget прямо у Деда. :-) Это всё нужно делать, причём каждому сисопу отдельно. Сделать один раз так, чтобы другие могли использовать и не тратить своё время - по-моему, естественное побуждение. Btw, вспомнился ещё один недостаток имеющейся схемы с нодлистом. Если у аплинка внезапно изменился адрес, то даунлинк (при одностороннем линке) не сможет узнать новый адрес из нового нодлиста, потому что новый нодлист ему нужно получить по файлэхе у аплинка, а его адрес неизвестен. Значит, нужно иметь разные пути получения нодлиста, а это усложняет всю схему. Lucky carrier, Паша aka gul@gul.kiev.ua --- GoldED+/LNX 1.1.5-b20160827 * Origin: Опыт - это то, что мы получаем вместо того, что хотели (2:463/68) | ||||