eu_tomat

Эта сеть - это просто длинные руки для модема. Нужно шифрование - делаешь шифрование. Нужен вайтлист - пилишь вайтлист. Всё просто.

Я почему-то решил, что это Zn предлагается в качестве общественной сети на сервере, как было с OpenNet.

Хешировалка не помешает злодею слать невалидные значения

Да тут на самом деле каждый ответ порождает новый вопрос.

 

Ну, отбросим мы сообщения с nil в хеше. Так можно тупо заспамить сеть, крашнув узлы либо переполнением памяти, либо выпадением в TLWY при переборе хешей.

 

Сделать валидацию хешей? Но спамить можно и валидными хешами.

 

Добавить кулдаун для каждого соседа или счетчик хешей? Так и сам сосед может оказаться честным репитером и вообще, узлом собственной сети. Исходного адресата тоже не найти, т. к. его адрес легко подделывается.

 

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

 

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

 

Для дополнительной защиты можно даже использовать шифрование.

 

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

 

И что делать тогда? Выдать каждому устройству сертификаты? Но тогда на каждом устройстве придется хранить открытые ключи всех устройств сети и сверяться с ними при каждом удобном случае. Ретрансляторы на EEPROM могут выпасть из этой схемы.

 

И возникает главный вопрос: выдержит ли сервер всю эту криптографию?

А если злодей отправит nil вместо хеша, это не убьет ближайшие узлы на строке hashes[hash] = computer.uptime()?

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

 

Алгоритм взял не с потолка, сжимал код автозаменой в n++, потом сделал макрос и увидел, что нужен анализ всего словаря, затем каждого слова в отдельности. А все потому-что могут попасться схожие слова, с разной эффективностью, например end - 350 слов (1400 символов), end[пробел] - 300 слов (1200 символов), LZ сначала возьмет то слово, которое больше и эффективность сжатия этого места получится на 14% ниже. Поэтому надо для каждого совпадения проводить сравнение в словаре, чтобы исключать пересекающиеся слова с меньшим коэффициентом сжатия.

1) Разве всеядность LZ77 является недостатком? Вот, урезание диапазона входных данных это скорее минус, нежели плюс. Но если настаивать на нем как на «плюсе», то с его помощью слегка модифицированный LZ77 дополнительно отожмет еще две-три сотни символов. Но сейчас даже без этого сомнительного трюка LZ77 выглядит более эффективным.

 

2) Не знаю, портит ли crunch код, но его реализация LZ77 точно не самая эффективная. Особенно учитывая, что в самораспаковывающемся коде можно сколь угодно далеко уйти от стандартного алгоритма. Главное, код восстановить. Так вот, пример crunch демонстрирует, что потенциал LZ77 еще не исчерпан. По крайней мере, реально впихнуть 8615 байт уже минизированного Lua-кода в 3300 вместе с шустрым распаковщиком. Вот эти циферки в сравнении с твоими я и предлагаю обсудить.

 

3) Недословарь, ограниченный 127 словами, будет сильно тебя сдерживать. Отказавшись от фиксированных размеров как словарей, так и ссылок, мне удалось заметно увеличить степень сжатия. Разумеется, моя версия LZ77 тоже имеет ограничения – упаковщик слишком медлителен на больших файлах, но главной задачей я поставил подготовку кода для EEPROM, где хороши все средства ради входа в заветные 4096 байт.

 

4) Нет смысла говорить об эффективности LZ, не имея в виду конкретную его разновидность и реализацию. Одних только LZ77 я встретил три разных описания, и то, я был не сильно настойчивым в поиске. Предпочтет ли LZ более или менее эффективное слово, сильно зависит от примененных эвристик и зачастую даже не требует изменений в формате файла. Поэтому сейчас я бы предпочел рассуждать не об абстрактных преимуществах алгоритма, а его числовых характеристиках. Мне интересно, улучшилась ли твоя оценка сжатия для тех файлов, что я скинул, и насколько. На раскрытии деталей можешь пока не заморачиваться, достаточно указать выходной размер вместе с распаковщиком.

Так что пора ему помолиться. Вдруг Он услышит нас, смертных, и дарует то что нам так нужно.

Молиться недостаточно. Надо еще и поститься. И слушать радио «Радонеж».

 

Кстати, OpenNet при таком подходе не появился бы на свет. Смельчаки просто взяли, да и написали кластер для своих нужд.

Я использую пропущенный через минификатор - слов меньше, получается 3951 байт. Самый примитивный декомпрессор - 152 байта, но он не эффективен, т. к. работает в несколько проходов.   P.S. извиняюсь, невнимательно скопировал, декомпрессор занимает 305 байт.

Выполнил я кое-какие расчеты на основе LZ77. Есть мнение, что файл из примера (8615 байт) после сжатия не будет превышать 3300 байт  вместе с распаковщиком.

crunch, к примеру, жмет этот файл лишь до 4581 байт.

 

Вопрос: Насколько востребован такой упаковщик? И стоит ли его доводить до работоспособного состояния?

 

Сейчас я могу примерно оценить итоговый объем сжатого файла.

Можно довести и до выдачи сжатого кода.

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

В OpenComputers не запускал, и как будет тормозить упаковщик, даже не представляю.

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

Юникод, само-собой, поддерживается.

UX-дизайн все-таки зверский. И пульты управления АЭС образца СССР – не лучший пример для подражания. Сложность хороша там, где она неизбежна.

Моя либа - один из простых механизмов хранения конфигурации и других данных, в теории по скорости работы не должна уступать либе сериализации, но в отличии от неё в моей либе структура файла в вполне читабельна и правима если открыть ещё текстовым редактом, там могут хранится пары ключ-значение, значение 2х типов - строка и число, и можно хранить множества таких же значений с еденичной вложенностью, в общем минимализм и легко редактировать вручную - для этого я ещё писал)

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

@@Barsik121

 

1) Правильно ли я понимаю, что шина из Project Red – это связка цветных проводов? Если так, то тебе может помочь тема о передаче данных по редстоуну. Правда, надо еще проверить, как передаются разные уровни сигнала по цветным проводам и связкам.

 

2) Для передачи данных между OC-CC удобнее использовать обычную сетевую карту в компьютере OC, а для компьютера CC в качестве периферии поставить коммутатор из OC. Это позволит пересылать сообщения между OC-CC привычным способом.

А мне уже давно некуда вешать медали, так бы уже две строки были бы за топ 1 по голосованию)

Пора уже вводить орденские планки.

Мы же автофермы оставляем из форестри? только напишем мол, разрешается одна ферма. Или как? или отключаем их?

А чем фермы Forestry лучше ферм на роботах?

Числа от нуля до 0xFFFFFFFFFFFF включительно. Числа повторяются но через определенные интервалы, в большинстве случаев, достаточно часто.

48 бит – это довольно много.

Можно поинтересоваться, для чего в Майне потребовались такие большие целые числа?

 

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

Бинарный режим. 4 байта на ячейку.

Во-первых, Lua позволяет оперировать целыми числами заметно длиннее четырех байт. Если я верно помню, можно свободно рассчитывать на 53 бита.

 

Во-вторых, автор вопроса не уточняет свойства хранимых в массиве чисел:

А если числа в массиве сильно ограничены, помещаясь в один байт?

А если числа в массиве часто повторяются?

 

Тогда дисковая память будет расходоваться неэффективно.

Можно сжимать, но тогда не так эффективно будет расходоваться время процессора.

 

Поэтому придется ответить на еще один вопрос: какое соотношение между занимаемым объемом и выполненными вычислениями является оптимальным?

Видимо очень долго у разработчиков pushатся их творения

Думаю уже можно закрыть топик

Вот, и врачу все твердили: мол, очень долго у твоих больных идет процесс выздоровления, можно бы уже и в морг их отправить. А тот упорным оказался – вылечил-таки больных. Не всех, правда.

можешь сделать в одиночке и карту скинуть?)

Это выше моих сил. В любом случае, у тебя где-то вставлен tank_controller, которого быть не должно.

https://yadi.sk/i/8eXshY_s39XHBy

Хм... Компонент называется tank_controller, совсем не похоже на tankvalvetile.

Ты апргейд контроллера цистерн что ли закинул в адаптер?

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

В чем проблема?)

А что выдает components?

чет не хочет работать, включаю программу и просто черный экран

Значит, адаптеры не подцепились к танкам.

у меня  вообще своя либка для конфигурационных файлов) простая как двери) чем-то похожа на ini)

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

 

Можешь рассказать, насколько твоя либа компактна и удобна? Меня в основном интересует сравнение с описанным здесь методом.

А где ссылка на пакет в репозитории?

А вот же она!

Ну да, только эта строчка ограничивает тебя в радиусе 400 блоков.

А сеть из точек доступа в режиме репитера не поможет увеличить покрытие сети?

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

@@Wanderer13, небольшое уточнение.

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

 

П.С. например, нет тормозной жидкости, а ты нажимаешь на тормоз - горит красная лампочка аварии. Не нажимай на тормоз - и авария гореть не будет. Или лампочку выкрути.

Игнорирование одних ошибок может спровоцировать ошибки впоследствии, т.к. рано или поздно тормоз все-таки потребуется.

 

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

 

Поэтому не стоит ставить вопрос таким образом:

Мне нужно именно убрать ошибку. А про модем - это пример.

Гораздо полезнее потратить силы на то, чтобы понять причину ошибки в каждом конкретном случае. При отсутствующем модеме – не задействовать его возможности, если они являются не обязательными. При отсутствующем файла на диске – создать его. При не полученном от сервера сообщении – дождаться его или повторить запрос. Нет универсального средства обхода ошибок, даже если pcall кажется таковым.

@@Fingercomp, мне одно не понятно: для чего задействованы все эти трюки с метаметодами? В чем преимущество такого кода перед более простым?

 

Можно же сначала тупо (через load/pcall) всосать файл в таблицу cfgUsr, а потом аккуратно перенести нужное в таблицу cfgWrk, изначально хранящую дефолтные значения. Заодно можно проверить и совпадение типа, и лишние поля в файле конфигурации.

function cfgUpd( cfgWrk, cfgUsr, prefix )
  local prefix = prefix or ""
  local type_v
  -- перебор значений таблицы cfgWrk,
  --    перенос (с удалением) соответсвующих значений из cfgUsr
  for k,v in pairs(cfgWrk)do
    if cfgUsr[k] then
      type_v = type(v)
      if type(cfgUsr[k]) ~= type_v then
        error("Ошибка в файле конфигурации: type("..prefix.."."..k..")~="..type_v,0)
      end
      if type_v~="table" then
        cfgWrk[k] = cfgUsr[k]
      else
        cfgUpd( cfgWrk[k], cfgUsr[k], prefix.."."..k )
      end
      cfgUsr[k]=nil
    end
  end
  -- перебор таблицы cfgUsr, все это ошибочные поля
  for k,v in pairs(cfgUsr)do
    error("Ошибка в файле конфигурации: недопустимое поле '"..prefix.."."..k.."'",0)
  end
end

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

А я популярен, меня уже начали упоминать везде

...

Я лишь предложил унифицированный метод хранения значений, тем более JSON все-таки более обширный и используется везде и всеми ЯПами.

Да тебя как ни упомянешь, а ник уже устарел. В следующий раз упомяну тебя как «Мистер – семь ников на неделе», станешь еще популярнее.

 

JSON хорош своей универсальностью и поддержкой во многих ЯП – это точно. Но о какой универсальности и других ЯП можно говорить, находясь в рамках СС и OC? К тому же, за универсальность приходится платить потреблением памяти и дискового пространства. Ты смотрел на размер этого модуля? Теперь сравни с объемами памяти, предоставляемыми OpenComputers. Есть стимул сберечь память для данных поважнее этой либы. Поэтому в контексте Майнкрафта единственным достоинством JSON остается синтаксический контроль, которого можно достичь гораздо более эффективными методами

 

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

Тянуть зависимости для исполнения Lua-кода тоже не требуется. Расплатой за контроль синтаксиса конфига является небольшое увеличение кода:

-- формирование пустого окружения и сокрытие глобального окружения
local cfg={} cfg._G=cfg
-- получение конфигурации и возможных ошибок при ее обработке
local ld,er = loadfile("./test-cfg.cfg","",cfg)
if ld then ld,er = pcall(ld) end
-- вывод ошибок, возникших как на этапе компиляции, так и исполнения кода
if not ld then
  error("Ошибка в файле конфигурации:\n\t"..er,0)
end
-- таблица конфигурации готова к использованию!
for k,v in pairs(cfg)do print(k,v)end

Парсер @Fingercomp нужен лишь для логического контроля, хотя тоже полностью его не обеспечивает. А если логический контроль важен, то он будет использован в почти в неизменном виде как в случае исполнения конфига, как десериализации, так и JSON.

 

Что касается Lua-инъекций, то с этим, похоже, нет особых проблем. Главное, не пихать load в окружение обработки конфига.

При десериализации конфига невозможно установить, в какой строке файла произошла ошибка. Это минус. При выполнении – легко.

Правда, сейчас ни мой вариант, ни вариант @@Fingercomp не способны обнаруживать любые возможные ошибки. Для полной обработки ошибок их нужно ловить как на этапе компиляции (в load), так и выполнения (в pcall) кода.