illum network. Часть 1.
Simon MADFM_ _ _ _ _ (_) | |_ _ _ __ ___ _ __ ___| |___ _____ _ __| | __ | | | | | | | '_ ` _ \ | '_ \ / _ \ __\ \ /\ / / _ \| '__| |/ / | | | | |_| | | | | | | | | | | __/ |_ \ V V / (_) | | | < |_|_|_|\__,_|_| |_| |_| |_| |_|\___|\__| \_/\_/ \___/|_| |_|\_\
Предисловие:
Почти как пол года прошло с момента возникновении идеи создать собственную децентрализованную сеть. Было написано (на самом деле) 2 версии сети и сейчас уже идет 3-ая версия. Из-за чего так? Ну во первых из-за изначального концепта, который сам по себе не работал (одноранговая сеть) из-за ряда причин: NAT, мобильный интернет, динамический ip и т.д. Каждый пункт по отдельности вполне себе решается, но вот в совокупности это все дает невозможность создания чего-то действительно юзабельного. И все же...так как я люблю трудные задачи из-за ряда физиологических причин я не забросил эту идею и все-таки составил концепт и архитектуру сети. Об этом ниже.
Архитектура программных модулей:
Начнем с того, что будет 2 версии: пользовательская и серверная. Серверная часть будет служить маршрутизатором, dns-сервером, dht-сервером в одном флаконе. То есть это максимально одноранговый вариант который я только смог придумать, во всех других моих концептах это либо смотрится по васянски либо имеет ряд недостатков.
Серверная часть:
Серверная часть будет иметь 4 модуля: Модуль сети, модуль маршрутизации, модуль шифрации и модуль хранения.
- Модуль сети: создается 2 потока на базе UDP протокола. Первый поток отвечает за прием данных, второй за отправку. Поток приема может создавать дочерние потоки. Предположим нам пришел пакет, мы его приняли и создали поток конкретно для работы с этим клиентом. В этом новом потоке мы обрабатываем пакет, регистрируем подключение пользователя и отсылаем ответ обратно.
- Модуль маршрутизации: в нем функции для разбора пакета, генерации ответа, создания пакетов для других нод сети и т.д.
- Модуль хранения: в нем происходит работа с базой данных sqlite, которая в свою очередь хранит список других нод сети, работа со списками и т.д.
- Модуль шифрации: работает на базе библиотеки sodium и шифрует сообщения.
Лимит подключений: 100 пользователей (возможно будет меняться).
Лимит длины пакета: 9000 байт (тестовый вариант).
Клиентская часть:
Клиентская часть работает по аналогии с серверной, только работает 1 поток для отправки и приема сообщений. Будет доступен в виде библиотеки и в виде программы.
Стандарт входящих/исходящих пакетов:
Сообщение будет иметь такую структуру:
+------+--------------+------------------+-------------------------------------------------+
| Type | Public key | Info | Message |
+------+--------------+------------------+-------------------------------------------------+
Type - тип сообщения. Он делится на 2 категории: серверные сообщения и клиентские, занимает 1 байт, ответ на запрос строится битовым смещением влево. Примерная структура типов ответа:
- Клиентские типы сообщений:
U_RESPONSE_DOS = 0x00
U_RESPONSE_NODES = 0x02
U_RESPONSE_PING = 0x06
U_RESPONSE_ONION = 0x08
- Серверные типы сообщений:
S_RESPONSE_DOS = 0x10
S_RESPONSE_NODES = 0x12
S_RESPONSE_CLIENTS = 0x16
S_RESPONSE_FIND = 0x18
S_RESPONSE_ONION1 = 0x1a
S_RESPONSE_ONION2 = 0x1c
S_RESPONSE_ONION3 = 0x1e
Public key - публичный ключ отправителя, им служит идентификатором ноды и им будет шифроваться ответ. Занимает 32 байта.
Info - содержит дополнительную информацию для каждого типа сообщений. Занимает 500 байт (скорее всего длина изменится в меньшую сторону, но пока она такая).
Message - шифрованное сообщение. Занимает: 9000 - len(type) -len(pub_key) - len(info).
Мини размышление:
Это первая часть размышлений о будущем стандарте сети. Все очень размыто, но по мере написания он уже будет как-то устаканиваться.
Сравнивая мой концепт с концептом ТОРа все же это намного более одноранговая сеть. Тут не будет избранных 9 DNS серверов, не будет нод выхода и нод входа, все эти роли совмещены и я думаю что по концу все таки свои последователи будут (никто не запрещает мне в это верить, так что молчи урод, дай насладиться моментом).
Да, я уже переписываю сеть в 3й раз, но это можно обосновать: проект получился очень большим. Он действительно гигантский и как-то трудно прийти к общему консенсусу с самим собой когда цель не конкретизирована.
Мой GitHub (ставь звезды): https://github.com/mrrva/
Мой телеграм канал (подпишись): https://t.me/i0w2_ru