OpenComputers Network Stack - TCP/IP-подобный сетевой стек

[AtomicScience 76]

Представляю вам плод своего долгого и упорного труда - стек протоколов для OpenComputers.
Постарался создать аналог дискетки Network Stack, но это вылилось в полностью независимый стек - OpenComputers Network Stack или же OCNS
 

Об OCNS в целом:
OpenComputers Network Stack это TCP/IP-подобный стек протоколов, цель разработки которого - попытка стандартизировать сетевое взаимодействие компьютеров в OpenComputers. Первая версия стека, описание к которой вы сейчас читаете, является альфа-версией - много чего еще недоделано, часть протоколов напоминает грубые поделки, но я все же решился предоставить эту версию на суд общественности.

Особенности стека:
В архитектуру OCNS изначально закладывались следующие качества:

• Модульность
  Для легкой расширяемости и дополняемости протокол должен поддерживать возможность представления своих составляющих в виде отдельных элементов.
  Каждый протокол в стеке реализован в виде отдельного файла, соблюдающего определенное API для протоколов своего уровня, но для достижения идеальной модульности предстоит сделать еще многое - добавить автоматическую загрузку файлов без необходимости жестко прописывать оные в init.lua, написать адекватный менеджер конфигурации и т.д.
• Абстракция
  Для пользователя протоколов верхнего уровня не должно иметь никакого значения, как именно происходят маршрутизация, установление канала, сегментирование данных и прочее, и прочее. Четкое разделение протоколов на уровни и жесткое API позволяет пользователю просто использовать интерфейс протоколов высокого уровня, а разработчику протоколов - использовать лишь один протокол нижнего уровня, делегируя реализацию всех низлежащих деталей ему.
• Эффективность
  Вместо того, чтобы слепо подражать реальным протоколам, OCNS реализует свою, OpenComputers-ориентированную систему, и имеет автора, которому приходится высасывать преимущества своего стека из пальца, поскольку список из двух преимуществ выглядит не очень солидно

 

Протоколы стека:
OCNS предоставляет протоколы, распределенные по модели OSI следующим образом:

Сеансовый:                          mNSP

Транспортный:                     mUDP, pingStub

Сетевой:                               mIP, mARP    

Канальный + Физический: Драйверы интерфейсов 

 

Начнем с самого низу:
- Интерфейсы
OpenComputers предоставляет множество сред передачи - туннельные карты, проводная сеть, беспроводная, и прочее. И чтобы унифицировать их интерфейсы, нам нужно создать одно API и объекты, которые будут соединять среды передачи с этим интерфейсом. Также ООП подход позволит создавать что-то совсем экзотическое, например, передачу пакетов через редстоун или дискеты, которые будут таскаться дронами.
К версии 1 все протоколы жестко зависят от primary сетевой карты в системе, то есть все вышеописаное является лишь мечтой планами
- mIP
Протокол маршрутизации, очень и очень близкий к реальному IP. Использует крутые 3-октетные адреса (x.x.x).
К версии 1 реализовано очень мало от запланированного - он позволяет просто передавать пакеты в одной локальной сети
- mARP
Протокол, который ищет некрутые физические адреса по крутым mIP адресам
К версии 1 приведен в божеский вид и не планируется к изменениям
- mUDP
Протокол, позволяющий открывать mUDP-сокеты и работать с ними

К версии 1 приведен в божеский вид и не планируется к изменениям
- pingStub
Старый протокол для отладки сетей, помечен к удалению, ибо теперь вместо него используется mUDP
- mNSP
Протокол, который позволяет общаться через mUDP сокеты с помощью очень удобных потоков.

 

 

Ссылка на GitHub - https://github.com/AtomicScience/OCNS

-------------------

В общем, представляю на ваш суд. Но учтите, что это очень и очень сырая альфа.
Приемлю любые замечания и предложения.

Изменено 21 июля, 2020 пользователем AtomicScience
Адекватное описание дубль два

[Totoro 3 563]

А всё таки хотелось бы адекватного описания.

И ответа на вопросы "Что это такое?", "Для чего оно нужно?" и "Какую проблему оно решает?".

После этого можно еще немного пояснить на тему "Как оно работает", если окажется что вещь стоящая.

[AtomicScience Автор темы 76]

Сразу проясню, что стек еще

В 06.06.2019 в 00:00, AtomicScience сказал:

очень и очень сырая альфа.

 

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

 

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

 

P.S.

Обновил тему

[AtomicScience Автор темы 76]

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

А всё таки хотелось бы адекватного описания.

И ответа на вопросы "Что это такое?", "Для чего оно нужно?" и "Какую проблему оно решает?".

После этого можно еще немного пояснить на тему "Как оно работает", если окажется что вещь стоящая.

 

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

[Totoro 3 563]

Так, стало чуть понятнее. Это прогресс.

 

2 часа назад, AtomicScience сказал:

постоянно мурыжить GitHub

Самый удобный способ, между прочим. Использование Git поднимет уровень разработки на одну ступеньку. А использование GitHub позволит разглядывать код онлайн, качать нужные части напрямую в OC (если надо) и не возиться с распаковкой архивов.

 

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

Выдавать IP адреса предполагается вручную? Не будет системы типа DHCP? Что будет если два узла в сети будут иметь одинаковый IP?
 

22 часа назад, AtomicScience сказал:

Каждый метод API задокументирован в коде, так что разобраться в нем не должно составить труда

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

До кода пока не добрался, так что будут еще вопросы.

[AtomicScience Автор темы 76]

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

...Использование Git поднимет уровень разработки на одну ступеньку. А использование GitHub позволит разглядывать код онлайн, качать нужные части напрямую в OC (если надо) и не возиться с распаковкой архивов

 

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

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

Этот стек решает проблему связи на больших расстояниях? То есть, строит ли он какую-то топологию сети, или работает чисто в пределах работы дефолтных сетевых карт?

 

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

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

Выдавать IP адреса предполагается вручную? Не будет системы типа DHCP? Что будет если два узла в сети будут иметь одинаковый IP?

 

DHCP (mDHCP, если быть точнее) планируется, а на первое время я реализую что-то типа виндового Zeroconf, то бишь просто выделю небольшой диапазончик адресов и позволю машинам самим выбирать себе адрес при подключении к сети - в результате сеть будет настраиваться сама. Круто!

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

Далеко не все владеют английским на нужном уровне.

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

 

Вот чего-чего, а вот профанства в английском от самого великого и легендарного Тоторки я никак не ожидал.

Но на самом деле содержать две версии кода и документации очень неудобно, но понял я это только когда сам столкнулся с необходимостью МНОГО комментировать и документировать - теперь я даже понимаю ECS'а, который нахрен снес всю русскую документацию к MineOS и оставил только английскую.

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

[Totoro 3 563]

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

Вот чего-чего, а вот профанства в английском от самого великого и легендарного Тоторки я никак не ожидал. 

Если твоя целевая аудитория - я, то нет никаких проблем.

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

7 минут назад, AtomicScience сказал:

теперь я даже понимаю ECS'а, который нахрен снес всю русскую документацию к MineOS и оставил только английскую

ECS ориентируется на "западный рынок". Он выложил свой проект на официальный английский форум.

Кроме того он может позволить себе отсечь часть пользователей - у него их дохрена.

 

8 минут назад, AtomicScience сказал:

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

Имеет смысл пересоздать тему здесь.

[AtomicScience Автор темы 76]

Только что, Totoro сказал:

Имеет смысл пересоздать тему здесь.

 

Сейчас выполним

[Totoro 3 563]

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

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

local net = require('network')

net.listen(port, function(address, port, message)
  net.send(address, port, message)
end)

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

 

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

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

[Chebuya 415]

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

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

 

[Totoro 3 563]

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

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

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

 

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

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

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

Типа единая система адресов и один и тот же виртуальный компонент network во всех случаях.

 

Но в текущем виде оно конечно малоюзабельно.

[AtomicScience Автор темы 76]

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, которая бы автоматом писала бы в поток и отправляла его, автоматическое чтение из потока с слушателями и прочее. Альфа все-таки

[AtomicScience Автор темы 76]

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

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

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

 

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

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

[Chebuya 415]

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

...

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

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

[AtomicScience Автор темы 76]

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

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

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

 

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

Изменено 6 июня, 2019 пользователем AtomicScience

[AtomicScience Автор темы 76]

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

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

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

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

[Chebuya 415]

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

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

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

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

 

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

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

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

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

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

[AtomicScience Автор темы 76]

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

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

 

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

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

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

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

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

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

 

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

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

*Клик*

[Chebuya 415]

Только что, AtomicScience сказал:

*Клик*

Сейчас крайне странно выдать какую-то ересь, а потом подкрепить её "постиронией". 

 

Практика в майне - рес, для тебя это развлечение. 

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

P.S Играй в сетевого программиста, против ничего не имею, в моём понимании майн - картошка и двери, для тебя - сетевое программирование.

[Totoro 3 563]

27 минут назад, AtomicScience сказал:

Окей, а теперь прикрути к своему примеру рукопожатие и завершение сессии

А зачем? Что дает рукопожатие и сессия? Это оверхед.

Удобно ~= сложно.

 

28 минут назад, AtomicScience сказал:

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

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

И да, ты все равно оперируешь пакетами (data) только через стрим, а не напрямую.

Сессия (что ты вообще имеешь в виду под сессией?) по-прежнему не нужна.

 

30 минут назад, AtomicScience сказал:

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

Пока чудес не наблюдается. Ждем.

 

26 минут назад, AtomicScience сказал:

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

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

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

Что касается связи компьютеров - недостатка в программах для этого нет.

Есть, например:

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

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

И это я только свои проги упоминаю. Их так-то полно.

 

13 минуты назад, AtomicScience сказал:

Интернет в рамках сервера

Делали, и не один раз. OpenNet, например. Был и браузер и сайты. Но в рамках сервера Minecraft это затея "на поглазеть один раз". Особого практического применения нет.

 

14 минуты назад, AtomicScience сказал:

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

Ну вот тут я конечно же полностью согласен и поддерживаю. Как творческий эксперимент - программа офигенна.

И объем работы проделан неплохой.

Короче жду продолжения.