@Dusk Многие говорят, что сеть P2P сама по себе станет быстрее, если узлов будет достаточно, но я этой фразе долго не слишком верил — пока не прочитал $DUSK про Core Components и не обратил внимание, что Kadcast использует не случайный gossip, а structured overlay. Его цель — уменьшить расход пропускной способности и сделать задержку более предсказуемой. Этот выбор заставил меня пересмотреть суждения: эффективность сети зависит не только от количества узлов, но и от того, какие связи образуются между ними, чтобы сообщения могли достигать цели.
Для операторов узлов это не абстрактное понятие. Когда маршруты более структурированы, узел сильнее полагается на корректность обнаружения соседей и качество сетевой связности. И если эксплуатационная среда блокирует UDP-канал или адреса Kadcast, то теоретически предсказуемая задержка не превращается автоматически в реально полезную сетевую производительность. Оператор может увидеть лишь то, что сообщения не доходят или блоки отстают, при этом ему самому приходится решать, проблема в версии, в сетевой стратегии или в некорректной конфигурации.
Сценарии под нагрузкой тоже очень конкретны. Когда маркетинговые активности усиливаются, приложения хотят, чтобы транзакции подтверждались быстрее, но при этом какой-то критически важный узел оказывается заблокирован фаерволом. Эта система — не так просто, что «чем больше узлов, тем безопаснее». Доступность узлов также может определять, сможет ли сообщение распространяться так, как задумано, а итоговые затраты на диагностику ложатся на тех, кто непосредственно запускает и обслуживает узлы. Поэтому, оценивая сетевую производительность DUSK, я уже не смотрю только на время блоков или количество узлов — мне важнее сверить отношения соседей в Kadcast, коммуникационные порты и есть ли у отстающих узлов понятные сигналы мониторинга, на которые можно опереться. @Dusk выбрал структурированное распространение, но то, сможет ли оно действительно передать предсказуемость в руки операторов — вот что должна доказать сеть #dusk .
Для операторов узлов это не абстрактное понятие. Когда маршруты более структурированы, узел сильнее полагается на корректность обнаружения соседей и качество сетевой связности. И если эксплуатационная среда блокирует UDP-канал или адреса Kadcast, то теоретически предсказуемая задержка не превращается автоматически в реально полезную сетевую производительность. Оператор может увидеть лишь то, что сообщения не доходят или блоки отстают, при этом ему самому приходится решать, проблема в версии, в сетевой стратегии или в некорректной конфигурации.
Сценарии под нагрузкой тоже очень конкретны. Когда маркетинговые активности усиливаются, приложения хотят, чтобы транзакции подтверждались быстрее, но при этом какой-то критически важный узел оказывается заблокирован фаерволом. Эта система — не так просто, что «чем больше узлов, тем безопаснее». Доступность узлов также может определять, сможет ли сообщение распространяться так, как задумано, а итоговые затраты на диагностику ложатся на тех, кто непосредственно запускает и обслуживает узлы. Поэтому, оценивая сетевую производительность DUSK, я уже не смотрю только на время блоков или количество узлов — мне важнее сверить отношения соседей в Kadcast, коммуникационные порты и есть ли у отстающих узлов понятные сигналы мониторинга, на которые можно опереться. @Dusk выбрал структурированное распространение, но то, сможет ли оно действительно передать предсказуемость в руки операторов — вот что должна доказать сеть #dusk .
