Неструктурированная децентрализованная сеть Zn

[eu_tomat 2 148]

Это работает везде, где есть опенкомповские события. Даже пиная монитор можно загадить пул и будут пропускаться ивенты, тут ничего не поделать, это вина мода и игры, а не программ.

Нет ни чьей вины. Особенности работы мода – данность, которую следует учитывать при создании систем. Или при их взломе.

 

Работает это везде, а к сбоям приводит не всегда. Если меня не подводит мой калькулятор, то для переполнения очереди сигналов на мониторе должны плясать не менее 15 человек. Интересно было бы взглянуть на программу, где это оказалось бы критичным.

 

Или возьмём, например, обработку сигналов от красного камня. Чтобы добиться пропуска сигналов, к компьютеру должны подползти не мене 4 вражеских роботов, а для полной гарантии – 5. Этим роботам еще потребуется равномерно распределиться со всех сторон компьютера или найти соответствующие адаптеры. Хотел бы я посмотреть, как эти партизаны гуськом вползают в дырявый домик и рыщут в поисках чувствительных мест компьютера.

 

Что касается Zn, так это просто хороший пример того, что не всё работает, как было задумано, и всегда есть возможность напороться на неучтённые нюансы. Проблема-то существовала и без Zn, но архитектура Zn эту проблему усугубляет. Можно же было и просто пятью передатчиками заспамить очередь событий приёмника, но всегда приятнее напакостить врагу его же собственными ресурсами.

 

Решение проблемы:

* По возможности избегать использования широковещательных пакетов;

* Если же систему иным образом не построить, следует отсылать пакеты как можно реже;

* Мощность передатчиков должна быть снижена до минимума, при котором система сохраняет работоспособность;

* Система должна быть готова к переходу на другие частоты и полной отстройке от зашумленных частот.

 

Помни: враг подслушивает! Широковещательные пакеты доступны всем приемникам, настроенных на данную частоту и находящихся в зоне действия передатчика. Обнаружив активную частоту, враг может заспамить эфир, что приведёт в лучшем случае к оглушению приёмников, а в худшем – к перехвату управления твоими системами.

 

[Alex 4 683]

Проблема-то существовала и без Zn, но архитектура Zn эту проблему усугубляет.

ну когда-то по рукам били и запрещали осовские ретрансляторы ванильные, потом их автор вроде вообще выкинул из мода. Потом Асумонтсрик додумался их функционал реализовать на микроконтроллерах и тоже весь сервак заспамил лавинообразными эхо сингалами. Сейчас опять угроза новая надвигается - это Zn.
Зря ты эту тему апнул=) опять залагают сервак этими бродкаст лагульками. Ты скорее не Zn подавишь, а проц нашего серва.

 

Помню, у нас еще как-то был модикс на антены из моарпериферал. Так Тоторо что-то в бродкаст смс-ку кинул как-то однажды. А потом через неделю ее поймал, когда зашел на сервак. Все это время она летала по серверу, зеркально отбиваясь эхом и множась лавинообразно от всех ретрансляторов сервера и время жизни ее равнялось бесконечности, судя по всему.

 

п.с. надо будет постараться не забыть драматически поднять когда-то как-то удельный коэффициент затраты энергии на излучение вай-фай сигнала и отправку пакетов. Чтобы там, например, 10 смс-ок отправил и планшет сдох

[eu_tomat 2 148]

ну когда-то по рукам били и запрещали осовские ретрансляторы ванильные, потом их автор вроде вообще выкинул из мода. Потом Асумонтсрик додумался их функционал реализовать на микроконтроллерах и тоже весь сервак заспамил лавинообразными эхо сингалами. Сейчас опять угроза новая надвигается - это Zn.

Да кто же в здравом уме будет её использовать? Но обрати внимание на эволюцию: когда-то ретрансляция выполнялась встроенными средствами мода. Потом программными. Затем система Zn решила некоторые из проблем обмена. Через несколько месяцев, может, еще какая идея появится. Тема-то как раз для ищущих развлечений программистов.

 

Зря ты эту тему апнул=) опять залагают сервак этими бродкаст лагульками. Ты скорее не Zn подавишь, а проц нашего серва.

Ну, а что ты предлагаешь? Где-то же надо было рассказать про заторможенность вызова computer.pullSignal. Про ограничения очереди сигналов где-то, кажется, уже говорили. Радиообмен сообщениями – яркий пример, где заторможенность получения сигналов из очереди может привести к потере контроля над системой. Систему Zn в этом повествовании просто необходимо было бы упомянуть. Также стоило напомнить и о вреде широковещательной передачи. Про вред для сервера говорилось много, но о вреде для собственных систем почему-то забывают. Лишь один раз, помнится, произошла увлекательная история с проникновением в дом через лаз для робота, открывавшийся по WiFi.

 

Песня партизан, сосны да туман...

[Totoro 3 563]

Вы раздуваете из мухи слона.

Все эти атаки, прослушки, переполнения и прочее легко решаются.
Система Zn сети намеренно сделана максимально простой. Она поощряет модификации.

 

В распоряжении человека, который строит систему на основе Zn сети есть множество инструментов:

* 60к уникальных портов, которые не вдруг подберёшь

* white- и black- листы модемных адресов

* кастомные модификации протокола, которые позволят легко определять чужие пакеты

* огромный простор для самописных инструментов контроля трафика и исключения из сети флудо-источников

* end-to-end шифрование любым алгоритмом

* и т.д. и т.п.

 

Жаловаться на то, что Zn не обеспечила вам 100% уровень безопасности и комфорта так же глупо,

как жаловаться на то, что библиотека OpenGL позволяет вам залагать видеокарту.

[Alex 4 683]

эвона как. будем знать=) 

Единственное есть опасение, что никто там ничего модифицировать не будет и игроки ее будут юзать, что называется из коробки. Да и смысл тогда этой системы какой, если уходить на какие-то свои частоты и порты и вайтлисты. Там и так максимум ее пара игроков запустит при лучшем раскладе, которые еще и не в зоне видимости друг друга окажутся по дальности действия сети.

[eu_tomat 2 148]

Все эти атаки, прослушки, переполнения и прочее легко решаются.

...

Жаловаться на то, что Zn не обеспечила вам 100% уровень безопасности и комфорта так же глупо...

Так мы и не жалуемся. Обсуждаем новый способ атаки, при котором сеть вроде бы отсекает и чужие узлы, и чужие пакеты, но всё равно перегружается. Проблема решается лишь отключением от рабочей частоты и переходом на новую. И меня в этой теме возбуждает неочевидность алгоритма смены частоты.

 

Я рассматриваю худший вариант, когда узел физически попал в руки врага. Теперь фиксированный список альтернативных частот раскрыт, ключи для расшифровки секретных сообщений, позволяющие согласовать динамически выбранную частоту, тоже известны. Враг всё слышит и расшифровывает, и всегда готов вмешаться. Какие имеются идеи по экстренному переходу сети на новые ключи и частоты?

 

Ещё неплохо бы рассмотреть вариант, когда мы не знаем, захвачен ли узел врагом, или просто ушёл в TLWY. Во втором случае надо как-то растолкать товарища и помочь ему перенастроиться с поправкой на то, что теоретически узел может быть и скомирометирован.

[Fingercomp Автор темы 4 398]

Опасения совершенно не напрасны. Критика объективна и по делу. Причём об этом я уже говорил Тоторе, когда мы строили эту сеточку.

 

После долгих дебатов пришлось выбросить всё нафиг и дать просто такой способ сети с flood routing. Забить сеть вайлтруду можно любую, только у нас вся сеть упадёт, а в нормальном роутинге только узел, принимающий пакеты.