network Передача данных по EnderStorage

[RccHD 136]

Передача данных по EnderStorage-сундуку

Важно:
В статье идет речь именно о сундуках из мода EnderStorage, а не о ванилла-эндерсундуках

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

Дело в том, что есть способ 'синхронизировать' несколько сундуков(достаточно покрасить полоски этих сундуков в одинаковые цвета), и тогда эти сундуки будут иметь общее хранилище и ресурсы положенные сундук моментально окажутся во в остальных сундуках 'синхронизированных' с этим сундуком.

Используя данные о том, сколько предметов лежит в том или ином слоте сундука можно получать информацию. Например, если в первый трех слотах лежит 30, 24 и 58 камня, то компьютер сможет "прочитать" из этого сундука ровно 3 числа - 30, 24, 58
Меняя количество предметов в разных слотах, можно "отправлять" информацию.
Пример:
1) компьютер№1 положил в первые 4 слота по 10, 0, 1, 63 камня
2) через некоторое время компьютер№2 прочитал из сундука числа 10, 0, 1, 63

ИТОГ: компьютер№1 передал компьютеру№2 4 числа
Важное условие: сундуки у компьютера№1 и у компьютера№2 должны быть синхронизированы, т.е. иметь одинаковые цвета полос, чанки должны быть прогружены

Далее я буду описывать свою систему для обмена данными, построенную на связанных эндер-сундуках

Для начала нам нужно построить вот такую конструкцию:

Важное условие: транспозер ОБЯЗАТЕЛЬНО должен находиться под эндер-сундуком, а адаптер может быть подсоединен к любой из оставшихся сторон сундука


Подключаем все это дело к компьютеру:

Подобная конструкция(эндер-сундук, адаптер, транспозер) должна быть присоеденена к каждому компу, который участвует(или будет участвовать) в обмене данными

Далее открываем эндер-сундук и заполняем первые 27 слотов любыми блоками в количестве 64 штуки
ЕСЛИ ЭТО НЕ СДЕЛАТЬ ИЛИ ПОЛОЖИТЬ 26 СТАКОВ ВМЕСТО 27, ТО СИСТЕМА РАБОТАТЬ НЕ БУДЕТ



На этом настройка системы заканчивается, теперь нужно скачать исходный код моей библиотеки ender-net.lua:

pastebin get qYiQWtb0 /lib/ender-net.lua

Документация библиотеки ender-net:

sendMessage(msgCode, message, timeout): nil
msgCode - код сообщения
message - может быть либо числом от 0 до 64^23 либо таблицей из чисел
timeout - время, которое дается другим узлам сети, чтобы прочесть переданное сообщение(не рекомендуется указывать меньше 0.2)

pullMessage(): messageRecieved, messageCode, message
messageRecieved - true если пришло новое сообщение, false если новое сообщение не пришло
messageCode - код сообщения, переданный в sendMessage()
message - сообщение, переданное в sendMessage()

maxMessageSize - максимальная длина сообщения(кол-во передаваемых чисел)

Главное правило пользования этой системой: не лезть руками в сундук во время передачи/отправки сообщений, иначе все сломается нафиг
Простейший(базовый) пример использования сети

Для демонстрации возможностей этой сети я написал парочку программ
Начнем с самой простой: listen.lua ( https://pastebin.com/x6GyEynm )
Запустим эту программу на одном из компов, который является частью сети(т.е. подключен к эндер-сундуку через адаптер и транспозер):


Теперь пойдем к другому компу и попытаемся обменяться сообщениями:

И теперь вернемся туда, где мы запускали listen:

Все сообщения переданы!


Для того чтобы подробнее понять как были переданы сообщения откроем эндер-сундук:

Здесь мы увидим числа, которые были последними переданы по сети(а именно 10, 11 и 12) а также код сообщения(56):
Слоты сундука:

Отправленное сообщение:

Мы можем передавать по такой сети короткие сообщения(24 числа = 1 число на msgType и 23 числа на message)
Но что нам делать, если мы хотим передать по этой сети файл в несколько килобайт?
Для этого нужно писать сетевые драйвера с конвертацией передаваемых данных в числа от 1 до 64 (формат base64) и разбиением ваших данных на части по 24 числа в каждой.

Чтобы моя разработка не оставалась совсем-уж бесполезной( стандартные возможности сети позволяют передавать всего лишь 24 числа за сообщение ) я решил написать для нее сетевой драйвер передачи файлов

Описание драйвера для передачи файлов

Важно: Для работы драйвера необходимо установить библиотеку base64:

pastebin get 0xDgW35R /lib/ender-net-base64.lua

Драйвер состоит из двух программ
1) waitFile.lua (установить можно командой pastebin get aD20ZF4q /bin/waitFile.lua)
2) sendFile.lua (установить можно командой pastebin get wHA6QzH6 /bin/sendFile.lua)

Использование:

waitFile <fileName>

Ожидает пока кто-то начнет передавать файл по сети. После окончания передачи файл будет сохранен под именем <fileName>. fileName - абсолютный путь

sendFile <fileName>

Передает файл <fileName> другим участникам сети. fileName - абсолютный путь

Пример:

Предположим, мы хотим передать файл /home/secret.txt с компа1 на комп2 и сохранить полученный файл под именем /home/hehehe.txt на компе2

Все просто:
1) Идем к компу2 и запустив команду "waitFile /home/hehehe.txt" заставляем его ждать, пока по сети придет файл hehehe.txt

2) Идем к компу1 и отправляем файл secret.txt в нашу сеть. Для этого пишем команду "sendFile /home/secret.txt"

Как только выполнили оба шага в правильной последовательности, комп1 начнет посылать сообщения в сеть, а комп2 будет их принимать

Передача файла размером 299 байт заняла около 30 секунд:

Как мы можем видеть, файл действительно передан с одного компа на другой

Итог всей этой статьи

Используя мою библиотеку ender-net вы сможете передавать данные по сети, основанной на эндер-сундуках
Данные эти должны иметь маленький размер(помещаться в 24 числа), иначе придется ломать голову над созданием сетевого дравера
Эта сеть подойдет для обмена числами между двумя компами(пример: мониторинг температуры реакторов, которые находятся ОЧЕНЬ далеко)

Положительные стороны ender-net:
1) передача данных куда угодно, на какое угодно расстояние, даже между измерениями
2) передача данных с помощью ender-net практически не тратит энергию, в то время как связанные сетевые карты из OpenComputers тратят очень много
3) в сеть возможно подключить более чем двух участников и делать рассылку каких-нибудь сообщений

Недостатки:
1) Недостаточная для некоторых задач скорость передачи данных ( 10-12 байт в секунду )
2) Дороговизна, т.к. придется тратиться на эндер-сундук, транспозер и адаптер
3) Библиотека ender-net еще не доведена да совершенства, поэтому возможны баги

Окончательный итог: получился крутой эксперимент с эндер-сундуками, но пока трудно организовать обмен полноценными сообщениями используя библиотеку ender-net Изменено 11 июня, 2017 пользователем RccHD

[RccHD Автор темы 136]

Если запустить передачу файла и в этот момент посмотреть в эндер-сундук компа, то можно залипнуть на пару минут

 

Завораживает

[RccHD Автор темы 136]

Кто-то уже пробовал в одиночной игре в креативе тестировать эту систему?

 

Какие баги возникали?

[NEO 542]

ссылки на пикчи битые.

[Fingercomp 4 409]

ссылки на пикчи битые.

Всё работает. Через проксю какую-нибудь зайди.

[RccHD Автор темы 136]

Ой, вот зря я загрузил пикчи на сервера ВКонтакте

 

Надо было на битбакет загрузить

 

Вечером ссылки поменяю

[eu_tomat 2 155]

Кто-то уже пробовал в одиночной игре в креативе тестировать эту систему?

Эта тема интересна очень узкому кругу лиц, вряд ли кто-то будет запускать твой код. И собери все ссылки на код в одном месте, неудобно смотреть, как там всё реализовано, и какие там возможны баги. Я даже не стал искать весь код по спойлерам, поэтому и о его работе ничего говорить не буду.

 

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

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

 

Кодированию информации через содержимое инвентаря я нашел только одно применение – для передачи данных между двумя несовместимыми компьютерными модами. С ним конкурирует передача данных по редстоуну. Обе этих среды обмена данными я рассматривал, когда пытался подружить между собой OpenComputers и ComputerCraft. Но потом выяснил, что данные можно легко ретранслировать из одной сети в другую. И потребность отпала.

 

Недостаточная для некоторых задач скорость передачи данных ( 10-12 байт в секунду )

Достигнутая тобой скорость соответствует моим расчетам в 13 байт/сек для сундука такого объема и при отсутствии лагов. Скорее всего, библиотека реализована оптимально. На баги проверять не буду, уверен, что они обязательно проявятся при нехватке таймаута в случае понижения TPS сервера.

 

Предлагаю вообще отказаться от таймаута, а один из слотов задействовать для подтверждения приема. Это позволит при 20 TPS передавать сообщения со скоростью 13 байт/сек, и замедлять передачу при снижении TPS, но связь сохранит устойчивость. Скорость не должна заметно снизиться в сравнении с твоим подходом.

 

Расчеты:

Жертвуем одним слотом: получается 26 слотов на одну операцию передачи данных.

Каждый слот может иметь 64 состояния и кодировать 6 бит.

Каждая операция может передать до 156 бит.

Операция выполняется за тики (минимум):

26 тиков на обновление 26 слотов

1 тик на обновление сигнального слота передатчиком

1 тик на считывание инвентаря приемником

1 тик на обновление сигнального слота приемником.

1 тик на считывание инвентаря передатчиком

итого: 30 тиков на операцию.

Максимальная скорость передачи = 5.2 бит/тик или 13 байт/сек.

[RccHD Автор темы 136]

 

 

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

Связанные карты нельзя связать в целостную сеть без серверных стоек(или роутеров) и без написания доп. кода к ним
Представь ситуацию, когда информация о температуре реактора должна рассылаться в 15 точек одновременно.
В таком случае нам понадобится аж 30 связанных карт + придется потратить энергии на 15 запросов(а они у связанных карт недешевые в плане энергии). А ведь нам всего лишь нужно переслать одно жалкое число и ничего более

Вот чтобы не тратиться на сетевые карты и не обеспечивать к каждому компу сети большое кол-во энергии, можно использовать ender-net

Я конечно не спорю, что связанные карты удобнее, но для таких мелочных операций как пересылка чисел более чем одному получателю они не совсем подходят. В таких случаях я бы предпочел ender-net Изменено 11 июня, 2017 пользователем RccHD

[RccHD Автор темы 136]

Для тех, кому лень искать все ссылки на файлы:

Библиотека ender-net:
pastebin get qYiQWtb0 /lib/ender-net.lua

Простой 'слушатель' сообщений сети
https://pastebin.com/x6GyEynm

Драйвер передачи файлов

base64(необходимая библиотека) - pastebin get 0xDgW35R /lib/ender-net-base64.lua

Драйвер состоит из двух программ
1) waitFile.lua (установить можно командой pastebin get aD20ZF4q /bin/waitFile.lua)
2) sendFile.lua (установить можно командой pastebin get wHA6QzH6 /bin/sendFile.lua)

Изменено 11 июня, 2017 пользователем RccHD

[qwertyMAN 1 723]

 

 

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

Вот то же самое хотел посоветовать. Это позволит передавать с максимальной скоростью и даёт 100% шанс, что сообщение было получено, что очень важно. 

[SDV 784]

 

 

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

Ребят, может я слоупок или не в теме, но в чем прикол ТАКОГО вида обмена информацией? Защита информации? Или попытки создать нечто необычное? 

[Totoro 3 563]

Ребят, может я слоупок или не в теме, но в чем прикол ТАКОГО вида обмена информацией? Защита информации? Или попытки создать нечто необычное? 

 

[SDV 784]

 

 

А практическая значимость всего этого действа есть или все в ОС это FUN? 

[Asior 586]

Тем кому не видно ловите.

 

 

 

 

Кстати прикольная штука, для массовой раздачи самое то.

[RccHD Автор темы 136]

Вот то же самое хотел посоветовать. Это позволит передавать с максимальной скоростью и даёт 100% шанс, что сообщение было получено, что очень важно. 

Изначально я реализовывал обмен сообщениями по ender-net в виде broadcast-рассылки. При рассылках обычно не определяют дошло письмо или нет, так как кто-то просто рассылает, и его не волнует успел кто-то прочитать посланное сообщение или нет. 

 

Но вот как нам определить что сообщение было получено если в нашей ender-сети 15 участников? Выделить 15 слотов под это дело? Или делать инкрементный счетчик от 0 до 14? А что делать если кусок сети просто отвалился и не реагирует?

Я все это пишу к тому, что рассылать сообщения по принципу broadcast гораздо проще, и тогда не важно кто прочитал, а кто нет. Если кто-то не успевает читать сообщения, пусть увеличивает TPS в своей зоне, убирает бесполезных мобов с территории, либо договаривается об увеличении TIMEOUT'а

 

Плюс ко всему на основе ender-net можно городить свои протоколы и способы обмена информацией: можно сделать подтверждение о том, что сообщение было получено в виде ответного ender_net.sendMessage, в качестве кода сообщения указать 50(код, который означает что сообщение дошло до получателя), а в качестве самого сообщения указать ID сообщения, которое было получено

[RccHD Автор темы 136]

А практическая значимость всего этого действа есть или все в ОС это FUN? 

Практическая значимость есть...

Если нужно разослать "легкую" информацию по 15 точкам на огромном удалении друг от друга можно выбрать один из двух вариантов:

 

1) Обеспечить к каждой точке приток большого кол-ва EU + скрафтить к каждой точке по паре связанных сетевых карт(для которых как раз и была подведена EU).

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

Задача решена

 

2) Либо можно установить на каждый комп ender-net + 1 генератор на угле. Задача тоже решена.

Итог:

A) меньше заморочек с получением EU.

B) получилась нецентрализированная сеть, и если у кого-то в сети сломается комп(не важно у кого), то сеть не перестанет функционировать

Изменено 12 июня, 2017 пользователем RccHD

[Doob 2 749]

Изначальная идея здравая, но реализация хромает.

Предлагаю не занимать слоты эндерчета бессмысленной инфой.

Берем несколько сундуков, закладываем в них 255 разных ресурсов.

Для передачи информации, переносим ресурсы в эндерчест, по заранее созданной таблице соответствий (синхронизировать можно при старте).

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

[RccHD Автор темы 136]

 

Берем несколько сундуков, закладываем в них 255 разных ресурсов.

Для передачи информации, переносим ресурсы в эндерчест, по заранее созданной таблице соответствий (синхронизировать можно при старте).

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

изначально так и хотел делать, но потом понял что сложно это и решил для начала сделать вариант попроще и постабильнее

[eu_tomat 2 155]

Связанные карты нельзя связать в целостную сеть без серверных стоек(или роутеров) и без написания доп. кода к ним Представь ситуацию, когда информация о температуре реактора должна рассылаться в 15 точек одновременно. В таком случае нам понадобится аж 15 свзанных карт + придется потратить энергии на 15 запросов(а они у связанных карт недешевые в плане энергии). А ведь нам всего лишь нужно переслать одно жалкое число и ничего более

Если задача формулируется именно и только таким образом, то решение подходящее. Трудности появятся при масштабировании производства.

 

Гораздо чаще возникает ситуация, когда 15 датчиков посылают данные на один пульт. И в этом случае твоя схема увеличивается в 15 раз. Каждый новый датчик потребует для себя постройки не только передатчика с сундуком, но и приемника в каждой точке приема. В результате твоя система обмена данными будет занимать места больше, чем обслуживаемые ею механизмы. Настройка такой системы тоже отнимет много времени.

 

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

 

Я конечно не спорю, что связанные карты удобнее, но для таких мелочных операций как пересылка чисел более чем одному получателю они не совсем подходят. В таких случаях я бы предпочел ender-net

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

 

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

[eu_tomat 2 155]

А практическая значимость всего этого действа есть или все в ОС это FUN? 

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

А еще для понтов: смотрите, как я могу!

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