#google-chrome #video-streaming #webrtc #html5-video #p2p
#google-chrome #потоковое видео #webrtc #html5-видео #p2p
Вопрос:
Предположим, мы организуем конференцию WebRTC среди A, B amp; C. Тогда будут ли отдельные вызовы A <—> B, A <—> C, B <—> C?
Qn-1: Если да, то не является ли это неэффективным? Потому что каждый одноранговый узел загружает одни и те же данные дважды.
Теперь у Google другая стратегия для конференций. В их официальном документе говорится:
Использует ли classic Hangouts одноранговый вызов для общения с более чем двумя участниками?
Одноранговые соединения используются только для звонков с двумя участниками. Если присоединятся какие-либо дополнительные участники, classic Hangouts немедленно вернется к отправке и получению данных с использованием подключения к серверу Google.
Qn-2: Теперь предположим, что мы все же используем подход p2p. Теперь каким-то образом мы направляем весь трафик на один порт. Тогда есть ли какое-либо ограничение WebRTC на количество одновременных подключений к одному и тому же IP и тому же порту?
Причина вышеупомянутого вопроса в том, что, если мы сделаем это с некоторыми взломами, то после 4 исходящих подключений 5-е соединение всегда будет нестабильным и в основном завершится сбоем.
Комментарии:
1. Одноранговая конференция неустойчива.
2. @AlexCohn, не могли бы вы, пожалуйста, подробнее рассказать об этом, почему это не является устойчивым. Разве это невозможно для более чем 4-5 пользователей?
3. Да, соединения WebRTC всегда одноранговые, нет опции клиент-сервер. Я не вижу преимущества маршрутизации трафика от нескольких одноранговых узлов к одному локальному сокету. Это не изменит требуемую пропускную способность, процессор или память.
4. @sipwiz, почему большинство решений перенаправляют свой трафик для конференции через центральный сервер? Это потому, что слишком много одноранговых узлов создадут слишком много загружаемых данных повторяющегося характера?
5. Для большего количества потоков (консенсус, по-видимому,> 5) центральный сервер, который для WebRTC обычно работает как SFU или MCU, имеет некоторые большие преимущества. Это также повлечет за собой большие затраты. Доступно много информации об этом компромиссе.
Ответ №1:
Существует достаточно материалов, чтобы предположить, что «ячеистая» сеть на основе P2P подходит для стабильной конференции до 4 пользователей.
-
В этом видео говорится, что «ячеистая» сеть — самый наивный способ реализации конференции
-
Эта ссылка предполагает, что пропускная способность перегружена, а качество снижается по мере увеличения числа участников в P2P:
-
В этой ссылке указано, что «ячеистая» сеть начинает выходить из строя по мере увеличения числа участников.
