AtomicScience

Хорошая вещь, попробую попользовать. Спасибо!

Но очень бы хотелось иметь возможность не только загружать последние версии файлов, но и загружать файлы последней метки релиза

3 минуты назад, ProgramCrafter сказал:

Придумывал я её, чтобы исключить коллизии для всех возможных вариантов. Да, можно сократить адреса, но не знаю, будет ли это иметь смысл.

Тогда достаточно MAC-адреса сетевой карты

15 минут назад, Zer0Galaxy сказал:

Правильно ли я понял, что корень должен знать пути абсолютно ко всем абонентам сети?

Вот это, кстати, хороший вопрос

Но его, как и многие другие, можно решить с помощью многооктетной адресации, используя адреса типа 1.2.3 - т.е. узел под номером 3 привязан к промежуточному узлу под номером 2, а тот, в свою очередь, к корню под номером 1.

Соответственно, корню достаточно знать путь под узла 2, а узлу 2 - до узла 3

А если заменить числа произвольными строками, то можно получить что-то вроде computerCraftServer.LagodromVasi.MainComputer - вот и удобочитаемые домены, считайте, подъехали

Разве такая сложная система адресации необходима?

В 12.03.2021 в 00:08, Bs0Dd сказал:

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

Я бы помог, например, но что делать - непонятно. Стоит обозначить фронт работ.

Пока попробую сделать что-то вроде WYSIWYG-редактора, может, получится чего

2 минуты назад, AlexCatze сказал:

Не хочу. По тому что:

Буду строить на библиотеке forms, ибо:

 

Упорство, конечно, похвально, но учти, что тогда тебе придется проделать очень, очень большую работу. Так и перегореть можно

Кстати, как насчет идеи использования графической библиотеки от MineOS как основы для браузера?

https://github.com/IgorTimofeev/MineOS/wiki/GUI-API

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

2 минуты назад, AlexCatze сказал:

4) Можешь, пожалуйста, объяснить как это сделать? Просто до этого я использовал гит исключительно как файлопомойку.

Самый простой способ создать тег - нажать на кнопку "Create a new release"

После заполнения описания, последний коммит в текущей ветке будет отмечен меткой

Твой код к ней можно в любой момент "перемотать" в специальном окошке:

А еще к релизу будет автоматически добавлен архив с исходниками:

---

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

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

7 часов назад, AlexCatze сказал:

pastrebin run vVrgPcf3

У тебя опечатка в команде

---

В общем, идея мне нравится - довольно стройная (как минимум в теории) архитектура с тремя уровнями устройств, связь между устройствами посредством различного оборудования благодаря унифицированному интерфейсу (что я делал-делал в своем OCNS, да не доделал), браузер, и так далее.

Поэтому я решил даже немного почитать и поревьюить твой код - а он достаточно приличный, тем более для первого проекта

Конечно, недочеты есть, и все, что я нашел, я отметил в твоем коде, который специально для этих целей форкнул: https://github.com/AtomicScience/racoon-dev

Просто поищи по коду по меткам "REV:"

Также не забудь посмотреть файлик "Общие замечания" в корне репозитория.

Надеюсь, тебе будет полезно.

P.S.:

Учти, что это все, разумеется, не квинтэссенция знаний программистского ремесла, снизошедшая на тебя, смертного, откуда-то, кажется, из-за облаков, а просто мнение о твоем коде от чувака из интернета, построенное через призму субъективных предпочтений

P.P.S.:

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

8 часов назад, IS2511 сказал:

Я думаю попросить название взять такое же (mIP, mTCP, mUDP?) и попробовать, но ничего не гарантирую.

Не думаю, что цели твоего и моего проекта совпадают. Сейчас объясню, почему

8 часов назад, IS2511 сказал:

Поскольку сеть будет скорее всего одноранговая

Вот оно!

OCNS задумывался (и даже немножко реализовывался) как портирование протоколов из реальных сетей в Minecraft.

Для "картошечки" действительно логична будет сеть одноранговая - простой и надежный, как алмазная мотыга, вариант

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

8 часов назад, IS2511 сказал:

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

Вот мое мнение - в этом вопросе нет ни "сильно неправых", ни сильно правых - есть просто две противоположные, скажем пафосно, философии - "картошечки" и "песочницы".

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

Но, боюсь, тогда с моим проектом тебе просто не по пути

В 20.07.2020 в 20:36, ProgramCrafter сказал:

Кажется, часть файлов (сама библиотека) нашлась: https://github.com/AtomicScience/OCNS

Там нет программ вроде смены IP и прочего, т.е. команда change_mIP работать не будет. Но сама библиотека вроде цела.

 

(уже фантазии)

А может быть, идёт разработка новой версии стека, который займёт место старого?

(Скорее всего, причина прозаичнее: автору могло понадобиться место на Яндекс.Диске.)

Да, я удалил архив, и маловероятно, что смогу найти его.

Поэтому вот ссылка на GitHub - https://github.com/AtomicScience/OCNS

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

Если кто-то хочет продолжить работу/сделать форк/etc., то не вижу в этом никаких проблем

На всякий случай, если кто-то захочет скачать библиотеку, выкладываю свой, исправленный и работающий на новых версиях вариант

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

Ссылка

Команда для установки (с зависимостями):

pastebin get 4XB9FdRH -f /lib/Telegram.lua; 
pastebin get 4Lh9ALEY /lib/Promise.lua;
pastebin get ji28sbxU /lib/JSON.lua;

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

Поиск по форумам не дал результатов

1 час назад, ProgramCrafter сказал:

Ocelot Online гораздо лучше соответствует таймингам Minecraft, чем OCEmu

В OCEmu есть специальная настройка, которая включает режим эмуляции задержек запросов к компонентам (fast). Она была включена?

17 часов назад, 8urton сказал:

component.proxy(component.list("gpu")())

 

А разве прокси работают без ОС?

Лично я использую Atom и встроенный в него git-клиент для разработки, а если нужно синхронизировать файлы между компами - просто клонирую один и тот же диск для его одновременного использования в нескольких компах

Элементарно, причем в две строчки:

В 07.06.2019 в 08:19, Fingercomp сказал:

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

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

Лично я планирую реализовать функцию аппаратных сокетов, то есть позволить ARP'у получать не только физические адреса машин, но и выделять на них порт (который открывается на компоненте). Если сокет перегружен - modem.close('порт'). Элегантно, просто и надежно. Правда, порты для новых клиентов таким образом никак не защитить, но по крайней мере "старожилы" смогут пользоваться сетью без каких-либо затруднений.

2 минуты назад, Totoro сказал:

Я бы поверил что это была постирония, или что угодно.

Но смущает отказ от русскоязычной документации. Он говорит вполне однозначно и без иронии - это форум не целевая аудитория. У проекта наполеоновские амбиции, и это взаправду.

Хорошо, уговорил, будет тебе русскоязычная документация, но ко второй версии, и вики на GitHub мне в этом поможет

Может, еще какие предложения есть?

@Totoro,@Fingercomp , искренне благодарю за качественной фидбек - благодаря вам я определил основные направления развития своего проекта.
Итак, к OCNSv2 я представлю:

• Расширенное API протоколов mIP и mUDP, которое позволит работать с сетью с помощью слушателей, как предлагал Тоторо, а также через "ванильную" event-систему
• Улучшенный протокол mNSP, значительно более упрощенный с точки зрения пользователя (боюсь, что в echo все-таки придется открывать второй поток )
• Протокол mTCP и потоки, реализованные через него - это позволит гарантировать сохранность данных, правда, ценой скорости
• Драйверы интерфейсов - на первое время реализую только modem и loopback

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

P.S

Учите постиронию

1 минуту назад, BrightYC сказал:

Мои интересы в практической пользе, и ферма картошки - не исключение=d 

 

Чем-то глобальным? Всякие OpenNet'ы и дзены не пользовались популярностью, так и весь майн ограничивается "картошкой".

Это майнкрафт, не нужно слишком переусложнять абстракциями. Fingercomp вообще забросил UT3 потому что начал делать Wonderful, потому что ему нужно было подключать 4 монитора с сервера =d

Зачем всё переусложнять? Почему нельзя поставить 4 сервера и подключить 4 монитора? 

P.S Я, например, никогда не понимал в чём смысл той же MineOS. Безусловно, труд проделан титанический, никто и не спорит. Просто люди занимаются тем, что им приносит удовольствие, и я не против этого.

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

Опять же, что такое "практика"? В твоем понимании, как программиста-игрока, практика это картошечка и двери, а в моем - понимании программиста-программиста - практика это еще и, например, Интернет в рамках сервера, глобальное покрытие карты сервера сетью Dronelink и прочее. Просто ты воспринимаешь Minecraft как игру, в рамках которой единственное использование OC - роботы-шахтеры и пароли на дверь, а я - как площадку, на которой можно побаловаться с протоколами и поиграть в сетевого программиста, попутно узнавая что-то новое для себя.

6 минут назад, BrightYC сказал:

ты заявляешь OCNS обязан изменить нашу жизнь

*Клик*

2 минуты назад, BrightYC сказал:

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

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

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

10 минут назад, Totoro сказал:

В первом посте были интересные примеры - передача сообщений через редстоун или любую другую хрень.

Плюс мне видится в том, что ты пишешь себе прогу для передачи сообщений, как обычно, только вместо component.modem юзаешь абстрактный network.

 

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

10 минут назад, BrightYC сказал:

Зачем это всё нужно если обычно OC ограничивается обычной простой пересылкой сообщения по модему? Кто это будет использовать? 

P.S Это не в стиле "Зачем это нужно", просто объясните, как это применить на практике.

 

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

Когда на AtomicWars (дай бог ему здоровья и стабильной работы) вы задумаетесь над чем-то более глобальным, чем пароли на двери и бурение шахт друг-другу... на участках, вы так или иначе столкнетесь с необходимостью соединить ваши компьютеры, дронов и роботов в сеть. И именно тогда вы вспомните старину Атомика, который, словно Прометей, принес вам то, что изменит вашу жизнь навсегда.
Запомните этот твит

3 минуты назад, Totoro сказал:

Эхо сервер из примера выглядит переусложненным.

От слоя абстракции над физической сетью я бы ожидал упрощения работы, а не усложнения.
То есть чего-нибудь вроде: <код>

 

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

Я тоже могу "просто" (и обрати внимание, что твое пример оперирует с пакетами, а мой - с сессией):

local mnsp = require("OCNS").mNSP

local listeningStream = mnsp.NetworkStream:newStream("l", nil, 0, 228)

function onReceive(stream, address, remotePort, data)
	local respondStream = mNSP.NetworkStream:newStream("w", address, remotePort, 228)
	respondStream:print(data)
	respondStream:flush()
	respondStream:close()
end

listeningStream:attachListener(onReceive)

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

22 минуты назад, Totoro сказал:

Какие преимущества несет именно модель стримов?

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

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

Но ты прав, API потоков весьма и весьма грубо - мне стоило добавить функцию printf, которая бы автоматом писала бы в поток и отправляла его, автоматическое чтение из потока с слушателями и прочее. Альфа все-таки