58 lines
7.7 KiB
Markdown
58 lines
7.7 KiB
Markdown
Архитектура проекта
|
|
|
|
Общая идея - децентрализованный модуль коммуникации, основанный на группах создаваемых самими пользователями, который включает модули раширения такие как:
|
|
- групповой чат с поддержкай медиа и голосовых сообщений (референс - телега)
|
|
- расширение чата - рация (референс - zello)
|
|
- расширение медиа - realtime CDN / трансляции
|
|
|
|
|
|
1. Модуль подключения p2p (ETCP/STCP)
|
|
Позволяет подключиться двум узлам друг к другу. Весь трафик шифруется. Для подключения нужен публичный ключ удаленного узла.
|
|
Позволяет использовать несколько линков до узла параллельно и динамически их переключать (агрегация/балансировка нагрузки/failover)
|
|
Модуль может работать в автоматическим режиме: мониторит изменения на интерфейсах и при появлении нового сетевого интерфейса автоматически добавлять подключения через новые интерфейсы.
|
|
При этом подключения работат параллельно по всем доступным интерфейсам распределяя нагрузку (какой интерфейс быстрее - тот бОльшую нагрузку берет на себя).
|
|
Разуммется, бесшовная работа - если есть хотяюы один живой линк то соединение работает. В процессе могут добавляться-удаляться линки.
|
|
|
|
|
|
2. Логические группы узлов (topo_group)
|
|
Один сервис может работать с несколькими группами.
|
|
Группа - это изолированый от других групп список узлов, между которыми выстраивается диначическая маршрутизация и могут быть реализованы дополнительные сервисы.
|
|
Для чата сейчас реализовано:
|
|
- суперузлы - узлы, обеспечивающие связь между узлами и главные хранители индексов медиафайлов
|
|
- медиа-узлы - узлы, хранящие медиафайлы (помимо клиентов у которых есть загруенные копии файлов)
|
|
|
|
3. Автоматический роутинг.
|
|
При подключении узла к узлу группы активируется BGP-подобный роутинг.
|
|
Тоесть узлы обмениваются информацией о соседях и каждый узел выстраивает карту связности со всеми узлами сети в этой группе через промежуточные узлы.
|
|
Эта связь используется только для сигнального трафика, не для передачи медиафайлов.
|
|
Если какой-то узел отвалился и в результате появились недоступные узлы то каждый узел который был связан напрямую с отвалившимся, пробует подключить отвалившийся сегмент сети через другие узлы.
|
|
Таким образом, если в сети остаётся хотябы один узел с публичными адресами - связь будет восстановлена.
|
|
|
|
4. Чат, мемберы и медиахранилище
|
|
При создании группы создаётся приватный-публичный ключ группы. Им подписываются действия суперадминов - можно задавать админов группы, суперузлы, медиаузлы итд.
|
|
Для каждой группы есть в базе:
|
|
- список мемберов (участников группы, со своими публичными ключами и адресами-кандидатами для подклчюения), и их тип который может задавать владелец группы (все сообщения подписываются)
|
|
мемберы синхронизируются между узлами используя merkle-tree сравнение таблиц.
|
|
- список сообщений чата. append-only таблица. синхронизируется только хвост - находим первое расхождение и добавляем отсутствующие записи соседей.
|
|
- список медиаблоков.
|
|
Таблица в которой указано какие узлы хранят какие медиафрагменты.
|
|
И какие мадиафрагменты скачивают.
|
|
Позволяет вытраивать цеочку раздачи контента. например:
|
|
- владелец опубликовал медиафайл порезанный на 10 кусков.
|
|
Далее 100 человек в чате увидели сообщение и захотели скачать.
|
|
Обратились к суперузлам с вопросом - где есть блоки.
|
|
Медиаузел отвечает:
|
|
- список узлов у кого есть нужный блок или кто уже качает нужный блок.
|
|
Далее узел который хочет скачать устанавливает оптимальную связь с узлом (напрямую или через оптимального посредника), после - скачивает нужный блок
|
|
Владелец блока имеет лимит количества подклчений. Если лимит исчерпан - он возвращает список ущлв которые скачивают у него контент (Я загружен - качай у следующих по цепочке).
|
|
Таким образом узел желающий скачать контент, дойдёт до незагруженного узла через дерево загрузок и начнёт у него скачивать. Точнее, выберет лучшего по RTT и скачает.
|
|
Подобным образом можно выстраивать раздачу Live контента, оптимизируя связность узлов по RTT.
|
|
|
|
todo: оптимизация цепочки раздачи.
|
|
Допустим есть картина:
|
|
A (стример) -> B (посредник) -> C (потребитель)
|
|
[msk] 50ms [мухосранск] 50ms [msk]
|
|
Есть узел D(msk). у которого пинги: A-D: 5ms, B-D 50ms, C-D 5ms.
|
|
Тоесть узел заменив B может время цепочки A-C снизить с 100ms до 10ms.
|
|
Он предлагает после замеров RTT свою кандидатуру. наступает фаза probe - сравниваем несколько секунд RTT и объем у старого и нового узла. И принимаем решение - замена или отмена.
|