Comments 9
Звонки не пробовал, но сайт выглядит прикольно, вместе с ИИшницей делали?)
Проблему экспоненциальной нагрузки сети в p2p аудио-чатах можно решить круговым алгоритмом... повышается лаг но зато невероятно низкие требования к сети.
Каждый пользователь соединяется с условно двумя (лучше больше, но алгоритм сильно усложняется, зато повышается надежность) соседями таким образом, что бы образовалось кольцо. Каждый аудио, пакет полученный от соседа, микшируется с имеющимся в буфере, и к нему добавляется флаг - какой участник в него попал, после того как к узлу приходит пакет со всеми участниками, он уходит на прослушивание.
Алгоритм с 2 соседями и кольцом, очень простой, лаг будет равен сумме интервалов доставки и обработки пакетов на всех узлах. Недостаток, достаточно одному участнику получить проблему со связью, как у всех связь обрывается. Достоинство, итоговая нагрузка на сеть у каждого участника - константа (два пакета), и в принципе центр рекомендован только для координации процесса. Так как лаг - сумма лагов связи между нодами, можно посчитать скорость связи между всеми участниками для всех и перестраивать кольцо с наименьшим лагом.
Для двух соседей, вместо отправки пакетов в одном направлении по кольцу, делать это можно в обе стороны, т.е. два кольца, дублирование пакета (отбрасывать дублирующие пакеты с меньшим количеством участников или даже продумать алгоритм микширования, при котором повторное наложение звука ничего не портит)
И универсальное решение - вместо двух соседей, подключаться к большему их числу, вводить хранение недособранных пакетов, таймауты, повторные рассылки... если ввести специально лаг между отправки пакета со звуком от 'плохих узлов' и его озвучки у слушателей, то начиная с некоторого порядка алгоритм будет работать очень эффективно.
Очень сильно можно это оптимизировать, добавляя в круг рассылки только тех участников, кто генерирует звук (включен микрофон или автоматически определено наличие звука), пакет все еще перемещается по всему кругу участников (слушателей) но помечать флагами и ожидать законченный круг, придется меньше (шансы что одновременно говорят много людей - мало)
upd. странно, что не могу найти чего то похожего в готовом виде, библиотеки или чата... похоже со времен скайпа, p2p технологии не развиваются и даже сильно деградировали, потому что рынком правят централизованные компании, которым не выгодно 'делать правильно' для потребителя.
Спасибо, корень вы назвали верно, но при таком подходе есть несколько критических преград.
Во‑первых — лаг будет копиться по кольцу. Микшировать, не выравнивая пакеты — нельзя, а значит на каждом узле нужен джиттер‑буфер, и он (+сетевой хоп) добавляется на каждом узле. В mesh до собеседника один прямой хоп, в кольце голос до дальнего пойдет через всех, плюсом — пакет уйдет на воспроизведение, только собрав всех. Бюджет для комфортной беседы ~150-250 мс, дальше она рассыпается — и уже при 5–6 пирах сумма хопов с буферами его съедает.
Второе — хрупкость. Основная боль как раз в мобильных сетях и CG‑NAT — узлы моргают постоянно. В mesh сетевые проблемы конкретного пира бьют только по его паре, у остальных всё живет. В кольце же при любом чихе одного узла — пересборка кольца для всех. Два кольца это частично исправляют, но возвращают ту нагрузку и сложность, ради ухода от которых всё затевалось.
И еще момент: у меня громкость регулируется per‑peer, свой range на каждого. В предложенной архитектуре если смикшировать звук выше по кольцу — все получат общий микс, отдельного человека уже не убавишь. А для демонстрации экрана такая архитектура и вовсе неприменима (изображение не суммируется так же, как и звук).
P.S: про «после скайпа P2P деградировал» — тут, мне кажется, не только рынок. Централизованный SFU выигрывает на масштабе, устойчивости к CG‑NAT и надёжности; скайповский же P2P был на супернодах‑релеях, и его закопали как раз за нестабильность. Хотя коммерческий интерес тоже никто не отменял)
Вы абсолютно правы, алгоритм с кучей недостатков, что бы их решать, нужно его сильно усложнять... Например держать подключения все со всеми и даунгрейдить протокол до классмэического в проблемных случаях, или например пакет застрял на узле, координатор по тайм-аут шлет команду кому куда повторно выслать пакет (например предыдущему перескочить через сбойного), Двойные и тройные круги,.. проблема с общей громкостью (ее можно менять только на отправителе, т е для всех). Рост лага из-за количества участников можно замедлить при переходе от кольца к дереву, или даже графу (сложно с микширование AB+BC = A 2B Ç, и.е. придется запрашивать у B его пакет что бы вычесть...
Проблема в централизованных сервисов, в их стоимости, бесплатные возможнна только если клиенты - товар, и это отвратительна практика, которая стала нормой
Случайно вдохновились статьёй «Вайбкод челлендж: сгенерируй мессенджер, если «телега» больше не поедет»?
Жаль её заблочили и ссылки на проекты протухли. Интересный челендж был.
Спасибо за статью, не попадалась. Дух в самом деле схож, но развилки разные — челлендж больше про передачу текста через брокеры, в то время как Void — про голос с собственным сигналингом.
Но это очередное подтверждение того, что многое уже придумано до нас, и не раз.
Проект вырос из того самого вечера и строился на ходу, и в тот момент эта статья пригодилась бы мне куда больше, чем всё, что я тогда нагуглил)
Раз сервер звук не микширует, участники обязаны соединяться друг с другом сами. Для двоих это одно соединение, для группы «каждый с каждым» число соединений растёт как
: впятером это 10, вдесятером уже 45, и каждый шлёт свой звук всем остальным отдельным потоком.
Почему бы для обхода этого недостатка не назначить одного из пиров главным (мастер-нода) и чтобы все остальные подключались к нему? Уменьшится количество соединений, можно микшировать поток в одном месте и раздавать его всем пирам, плюс появляются возможности управления трансляцией, принудительного отключения пиров, например. Из минусов - нагрузка на мастер-ноду: должна быть хорошая сеть и достаточно ресурсов и, если мастер-нода отвалится то всё.
Вы во многом сами отвечаете на свой же вопрос :) По сути вы описываете MCU/SFU, просто размещённый не на сервере, а на устройстве одного из участников — ровно так работал Skype на супернодах‑релеях, о котором упоминали в комментариях выше.
В архитектуре звезды микширующая мастер‑нода физически получает чистый звук всех участников, сервер из разговора я убирал ровно ради этого — а тут посредник возвращается, только теперь это устройство одного из участников.
Нагрузка при таком строении не падает, а концентрируется: соединений действительно меньше (9 против 45 для комнаты на 10 человек), но платим мы не за соединения, а за потоки: мастер принимает 9 и раздаёт 9 разных миксов (каждому — без его собственного голоса), то есть ровно столько же, сколько нёс любой пир в mesh, плюс CPU на джиттер‑буферы. Они же дают и задержку: путь «я → мастер → слушатель» вместо одного прямого хопа. Общий микс вдобавок убивает per‑peer громкость. Не говоря уже о хрупкости всей комнаты, о которой вы и сами упомянули.
А если рассматривать такую архитектуру как задел для конференций на 50+ участников — то одна нода столько не вытянет, и полсотни человек будут зависеть от чьего‑то ноутбука и качества его сети. Если центральный микшер всё‑таки нужен, его место в дата‑центре, где есть аплоад, аптайм и резерв — а это и есть SFU :)
Как я случайно создал голосовой чат, который невозможно прослушать