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

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

Рекомендуемые сообщения

они не работают на рандомном серваке с нетвикнутым модом OC.

ты так говоришь, как будто кто-то там где-то массово играет на "рандомных" серваках с ОС, да и при том еще в роутеры и сети цинковые :giggle:  Там кроме квантух, гравиков и покемонов никому ничего не интересно в подавляющей массе  :D  

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вопрос. Правильно ли я понимаю, что любая посылка в Zn-облаке обходит абсолютно все узлы? Если так, то нужно подумать над маршрутизаторами, способными связать два и более облака.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ты так говоришь, как будто кто-то там где-то массово играет на "рандомных" серваках с ОС, да и при том еще в роутеры и сети цинковые :giggle:  Там кроме квантух, гравиков и покемонов никому ничего не интересно в подавляющей массе  :D  

 

Тут я согласен, наш проект был и остаётся уникальным в этом плане.  :)

Всё что я хотел сказать - что моды и изменения конфига - это неинтересно и не спортивно.

 

Вопрос. Правильно ли я понимаю, что любая посылка в Zn-облаке обходит абсолютно все узлы? Если так, то нужно подумать над маршрутизаторами, способными связать два и более облака.

 

Да, любой пакет обойдёт все узлы.

Что ты имеешь ввиду под облаками?

Сейчас устройство сети таково, что если существует две отдельные сети (в разных концах карты, например), то стоит появиться хотя бы тоненькуму мостику между ними (юзер с планшетом прошёл) они тут же сольются в одну большую сеть, и пакеты с западной (условно) подсети будут бегать в восточную через планшет юзера.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Это будет другая архитектура.

В сети Zn трафик передаётся всеми узлами текущего облака. И если оно слилось с другим облаком - оно будет получать весь трафик клиентов из первого облака и наоборот.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Небольшой гайд, который показывает вариант практического применения библиотеки:

Zn: строим простой ретранслятор

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

 

zn.send(address: string, message: string[, timeout: boolean/string]): boolean Отправить сообщение какому-либо узлу. Аргументы address — адрес модема конечного узла. message — сообщение для отправки. timeout — таймаут ожидания подтверждения отправки, в секундах. false отключает подтверждение совсем. Возврат true — подтверждение не запрошено или получено. false — таймаут ожидания подтверждения.   zn.broadcast(message: string): boolean Послать сообщение для всех узлов сети. Аргументы message — сообщение для отправки. Возврат true.

 

Нельзя отправить разом несколько значений, как в component.modem, так же любая программа, которая создана для component.modem, при бездумом переписывании modem на zn, перестает работать, и для ее работы надо использовать костыли через serialization. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нельзя, да; используйте сериализацию для этого. Zn позиционируется как не самая умная сетка, и вещи вроде ack, нескольких частей сообщений, длинных сообщений нужно реализовывать в специальном протоколе.

Это так и задумано, таков принцип.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

 

и для ее работы надо использовать костыли через serialization

Ну знаешь ли, сериализация не костыль) Вот попробуй написать клиент-серверное приложение на C++ или Java, как узришь передачу в байтах - поймешь о чем я)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Fingercomp, сделай, пожалуйста, в библиотеке время жизни кеша поменьше. При активном использовании вылетает на переполнении памяти(комп с 2мб)

Думаю, что 12часов все таки многовато.

 

И еще, в методе send неплохо было бы проверять аргумент message на текст и, в случае таблицы, сериализировать сообщение.

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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)

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

Это уже относится к логике твоего приложения.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Это уже относится к логике твоего приложения.

 

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

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

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

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

 

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

Изменено пользователем nailfor

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

 

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

 

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

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

 

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

 

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

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

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

lib.run("сайт")

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

да?  :D

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

 

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

Изменено пользователем Totoro

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

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

Изменено пользователем eu_tomat

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Предположим, поблизости есть 5 узлов вражеской сети...

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

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

Гость
Ответить в тему...

×   Вы вставили отформатированное содержимое.   Удалить форматирование

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.


×
×
  • Создать...