7.7 KiB
Архитектура проекта
Общая идея - децентрализованный модуль коммуникации, основанный на группах создаваемых самими пользователями, который включает модули раширения такие как:
- групповой чат с поддержкай медиа и голосовых сообщений (референс - телега)
- расширение чата - рация (референс - zello)
- расширение медиа - realtime CDN / трансляции
-
Модуль подключения p2p (ETCP/STCP) Позволяет подключиться двум узлам друг к другу. Весь трафик шифруется. Для подключения нужен публичный ключ удаленного узла. Позволяет использовать несколько линков до узла параллельно и динамически их переключать (агрегация/балансировка нагрузки/failover) Модуль может работать в автоматическим режиме: мониторит изменения на интерфейсах и при появлении нового сетевого интерфейса автоматически добавлять подключения через новые интерфейсы. При этом подключения работат параллельно по всем доступным интерфейсам распределяя нагрузку (какой интерфейс быстрее - тот бОльшую нагрузку берет на себя). Разуммется, бесшовная работа - если есть хотяюы один живой линк то соединение работает. В процессе могут добавляться-удаляться линки.
-
Логические группы узлов (topo_group) Один сервис может работать с несколькими группами. Группа - это изолированый от других групп список узлов, между которыми выстраивается диначическая маршрутизация и могут быть реализованы дополнительные сервисы. Для чата сейчас реализовано:
- суперузлы - узлы, обеспечивающие связь между узлами и главные хранители индексов медиафайлов
- медиа-узлы - узлы, хранящие медиафайлы (помимо клиентов у которых есть загруенные копии файлов)
-
Автоматический роутинг. При подключении узла к узлу группы активируется BGP-подобный роутинг. Тоесть узлы обмениваются информацией о соседях и каждый узел выстраивает карту связности со всеми узлами сети в этой группе через промежуточные узлы. Эта связь используется только для сигнального трафика, не для передачи медиафайлов. Если какой-то узел отвалился и в результате появились недоступные узлы то каждый узел который был связан напрямую с отвалившимся, пробует подключить отвалившийся сегмент сети через другие узлы. Таким образом, если в сети остаётся хотябы один узел с публичными адресами - связь будет восстановлена.
-
Чат, мемберы и медиахранилище При создании группы создаётся приватный-публичный ключ группы. Им подписываются действия суперадминов - можно задавать админов группы, суперузлы, медиаузлы итд. Для каждой группы есть в базе:
- список мемберов (участников группы, со своими публичными ключами и адресами-кандидатами для подклчюения), и их тип который может задавать владелец группы (все сообщения подписываются) мемберы синхронизируются между узлами используя 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 и объем у старого и нового узла. И принимаем решение - замена или отмена.
-