Перейти к содержимому


Фотография

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

zn сети паук сервер клиент ретранслятор OpenComputers

  • Авторизуйтесь для ответа в теме
Сообщений в теме: 46

#31 Оффлайн   Totoro

Totoro
  • Хранители Кода
  • Сообщений: 1 750
  • Уровень сигнала: 0,26%
  • В игре: 2 час. 13 мин.

Награды

                                      

Отправлено 13 Май 2017 - 23:43

Так же я добавил метод

zn.listen = function(mode)
  local _, message = event.pull("zn_message")
  if mode then
    message = serialization.unserialize(message)
  end
  return message
end

Ожидает сообщение и возвращает его.

 

А нужна ли такая конструкция?

Ведь можно использовать стандартный listen:

event.listen("zn_message", function()
  ...
end)

А что касается десериализации - то не факт что пользователю нужно будет десериализовывать контент.
Это уже относится к логике твоего приложения.

Вот и выходит, что в библиотеку добавлять особенно и нечего.



#32 Оффлайн   nailfor

nailfor
  • Пользователи
  • Сообщений: 107
  • Уровень сигнала: 65,14%
  • В игре: 559 час. 38 мин.

Отправлено 14 Май 2017 - 00:03

А нужна ли такая конструкция?

Ведь можно использовать стандартный listen:

event.listen("zn_message", function()
  ...
end)

А что касается десериализации - то не факт что пользователю нужно будет десериализовывать контент.
Это уже относится к логике твоего приложения.

Вот и выходит, что в библиотеку добавлять особенно и нечего.

Данная библиотека _должна_ обеспечивать связь, приложение - только бизнес логику. Сериализировать или нет - решает пользователь передав параметр mode.

Если ожидает таблицу - true.

Почему приложение должно знать о существовании какого то "zn_message"? Почему это не задача библиотеки, ведь это она передает

 

Вполне логично что библиотека и разбирается с принимающими пакетами. Это то же самое, что сказать... эм, ты знаешь, мы тут библиотеку tcp/ip написали, но на приеме вы сами там с пакетами разбирайтесь)


Сообщение отредактировал nailfor: 14 Май 2017 - 00:04


#33 Оффлайн   Totoro

Totoro
  • Хранители Кода
  • Сообщений: 1 750
  • Уровень сигнала: 0,26%
  • В игре: 2 час. 13 мин.

Награды

                                      

Отправлено 14 Май 2017 - 00:10

Данная библиотека _должна_ обеспечивать связь, приложение - только бизнес логику. Сериализировать или нет - решает пользователь передав параметр mode.

Если ожидает таблицу - true.

Почему приложение должно знать о существовании какого то "zn_message"? Почему это не задача библиотеки, ведь это она передает

 

Вполне логично что библиотека и разбирается с принимающими пакетами. Это то же самое, что сказать... эм, ты знаешь, мы тут библиотеку tcp/ip написали, но на приеме вы сами там с пакетами разбирайтесь)

 

Ну нет я не согласен. Ты просто предлагаешь добавить библиотеке больше логики, сделать её толще.

 

Основная концепция библиотеки - это расширенный модем.

Это легковесная библиотека, которая обладает функционалом модема, но кроме передачи сообщений на соседний компьютер, обеспечивает проброс сообщений по цепочке компьютеров, таким образом связывая их в единую сеть.

Она основана на эвентах, так же как и связь через обычный модем.

 

Мы даже выбросили из библиотеки аналог TCP, когда библиотека ждёт подтверждения получения отправленного сообщений.

 

Сериализация, шифрование, подтверждение приёма, кастомные протоколы - это всё легко реализуется поверх библиотеки.


  • mrlobaker это нравится

#34 Оффлайн   nailfor

nailfor
  • Пользователи
  • Сообщений: 107
  • Уровень сигнала: 65,14%
  • В игре: 559 час. 38 мин.

Отправлено 14 Май 2017 - 00:20

Основная концепция библиотеки - это расширенный модем.

Основная концепция любой библиотеки - сделать приложение проще.

По какой причине приложение должно отлавливать эвент библиотеки?

я и без библиотеки могу отправить бродкаст и сделать слушателя на другом компе. Весь смысл как раз упросить код.



#35 Оффлайн   Totoro

Totoro
  • Хранители Кода
  • Сообщений: 1 750
  • Уровень сигнала: 0,26%
  • В игре: 2 час. 13 мин.

Награды

                                      

Отправлено 14 Май 2017 - 00:54

Основная концепция любой библиотеки - сделать приложение проще.

По какой причине приложение должно отлавливать эвент библиотеки?

я и без библиотеки могу отправить бродкаст и сделать слушателя на другом компе. Весь смысл как раз упросить код.

 

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

Эвенты - это очень удобный способ для обработки асинронных событий и действий.

 

Да, можно навешать колбеков, но зачем, когда чистые эвенты дают больше гибкости.

 

Библиотеку можно усложнять до бесконечности. В финале, это может быть монстр на 100500 Мб, который позволит сделать так:

lib.run("чатик")

И у тебя есть чат. Или:

lib.run("сайт")

И у тебя поднят сайт. Правда удобно? Никакого лишнего кода, всё очень просто, прозрачно, легко и удобно.

 

Но вот проблема. А что если на не нужен чатик или сайт, а нужена программа для обмена файлами?

Придётся дёргать автора либы, чтобы запилил нам команду lib.run("файлообменник"), да?  :D


  • eu_tomat это нравится

#36 Оффлайн   nailfor

nailfor
  • Пользователи
  • Сообщений: 107
  • Уровень сигнала: 65,14%
  • В игре: 559 час. 38 мин.

Отправлено 14 Май 2017 - 01:06

да?  :D

нет. Это передергивание.

 

Есть стандартное разделение на логику модели и логику контроллера. Никто ведь не отменяет event.pull - наоборот, zn.listener - это дополнительная гибкость, когда не нужно замарачиваться с событиями.



#37 Оффлайн   Totoro

Totoro
  • Хранители Кода
  • Сообщений: 1 750
  • Уровень сигнала: 0,26%
  • В игре: 2 час. 13 мин.

Награды

                                      

Отправлено 14 Май 2017 - 01:13

Я не говорю, что это бессмысленный код.  :)

Просто это будет алиас для обычного листенера.

 

Что писать zn.listen(function() ... end), что писать event.listen("zn_message", function() ... end) - разницы практически нет.

А поскольку библиотека стремится быть максимально легковесной, то особого смысла добавлять лишние функции, которые не несут функциональности - тоже нет.

 

Хотя первое выглядит конечно лаконичнее и красивее.


Сообщение отредактировал Totoro: 14 Май 2017 - 01:15


#38 Онлайн   eu_tomat

eu_tomat
  • Хранители Кода
  • Сообщений: 936
  • Уровень сигнала: 5,93%
  • В игре: 50 час. 55 мин.

Награды

                          

Отправлено 08 Март 2018 - 21:47

Идея подавления Zn:

Предположим, поблизости есть 5 узлов вражеской сети. Каждый тик (чаще не получится) со своего передатчика посылаем широковещательный пакет в эту сеть. Все 5 узлов дружно ретранслируют пакет на другие узлы. Теперь каждый из них вынужден обработать событие от 4 других узлов и от нашего передатчика – 5 событий каждый тик.

Даже простая проверка пустой очереди сигналов computer.pullSignal() занимает ¼ тика. Плюс тратится немного времени на обработку. Результатом атаки будет переполнение очереди событий и пропуск их части.

P.S.: И еще будет лаг в 3 секунды на каждом узле.

Сообщение отредактировал eu_tomat: 08 Март 2018 - 21:55


#39 Оффлайн   Doob

Doob
  • Пользователи
  • Сообщений: 814
  • Уровень сигнала: 17,01%
  • В игре: 146 час. 10 мин.

Награды

                                   

Отправлено 09 Март 2018 - 04:57

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

#40 Оффлайн   Alex

Alex
  • Администраторы
  • Сообщений: 3 787
  • Уровень сигнала: 46,35%
  • В игре: 398 час. 9 мин.

Награды

                 

Отправлено 09 Март 2018 - 05:29

Предположим, поблизости есть 5 узлов вражеской сети...

 

а ты оптимист :)

вот у меня есть устойчивое подозрение, что узлы Zn на наших серверах запускались лишь однажды... и то исключительно только самими разработчиками в рамках тестирования  :giggle:


  • Totoro это нравится

#41 Онлайн   eu_tomat

eu_tomat
  • Хранители Кода
  • Сообщений: 936
  • Уровень сигнала: 5,93%
  • В игре: 50 час. 55 мин.

Награды

                          

Отправлено 09 Март 2018 - 10:34

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

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

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

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

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

Решение проблемы:
* По возможности избегать использования широковещательных пакетов;
* Если же систему иным образом не построить, следует отсылать пакеты как можно реже;
* Мощность передатчиков должна быть снижена до минимума, при котором система сохраняет работоспособность;
* Система должна быть готова к переходу на другие частоты и полной отстройке от зашумленных частот.

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

SLO6JGR.jpg

#42 Оффлайн   Alex

Alex
  • Администраторы
  • Сообщений: 3 787
  • Уровень сигнала: 46,35%
  • В игре: 398 час. 9 мин.

Награды

                 

Отправлено 09 Март 2018 - 11:35

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

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

 

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

 

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



#43 Онлайн   eu_tomat

eu_tomat
  • Хранители Кода
  • Сообщений: 936
  • Уровень сигнала: 5,93%
  • В игре: 50 час. 55 мин.

Награды

                          

Отправлено 09 Март 2018 - 13:06

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

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

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

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

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

#44 Оффлайн   Totoro

Totoro
  • Хранители Кода
  • Сообщений: 1 750
  • Уровень сигнала: 0,26%
  • В игре: 2 час. 13 мин.

Награды

                                      

Отправлено 09 Март 2018 - 13:39

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

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

 

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

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

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

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

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

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

* и т.д. и т.п.

 

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

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


  • eu_tomat это нравится

#45 Оффлайн   Alex

Alex
  • Администраторы
  • Сообщений: 3 787
  • Уровень сигнала: 46,35%
  • В игре: 398 час. 9 мин.

Награды

                 

Отправлено 09 Март 2018 - 14:06

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

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



#46 Онлайн   eu_tomat

eu_tomat
  • Хранители Кода
  • Сообщений: 936
  • Уровень сигнала: 5,93%
  • В игре: 50 час. 55 мин.

Награды

                          

Отправлено 09 Март 2018 - 15:21

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

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

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

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

#47 Оффлайн   Fingercomp

Fingercomp
  • Автор темы
  • Гуру
  • Сообщений: 2 015
  • Уровень сигнала: 148,95%
  • В игре: 1279 час. 35 мин.

Награды

                                               

Отправлено 09 Март 2018 - 16:15

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

 

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







Темы с аналогичным тегами zn, сети, паук, сервер, клиент, ретранслятор, OpenComputers

Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных