Комментарии 10
Как именно выбирается "самый быстрый" клиент для соединения? Например, если в графе сотни клиентов, и появляется новый клиент К, как ему подключиться к самому близкому для него (по rtt) клиенту в этом графе?
Самый быстрый это не обязательно минимальный TTL на последней миле - у разных источников разная накопленная задержка.
Хорошим решением был бы выбор активного соединения из списка имеющихся основываясь на сумме "зарержка источника" + round trip time между источником и получателем. Т.е.
* новый пир получает список из 10 источников с минимальной собственной задержкой
* к каждому из них клиент устанавливает пассивное соединение и смотрит roundTripTime
* лучшая комбинация выбирается активной.
Смотреть TTL до всех-всех источников я бы не стал - для этого нужно установить соединение (хотя бы DataChannel) ко всем источникам, на больших сетках это будет знатно грузить и источники и сигнальный.
лет 10 уже наблюдаю попытки сделать p2p видео а оно все никак не взлетает, оставаясь уделом энтузиаcтов. смотрят несколько десятков пользователей, отдавать могут единицы, чего бы тогда замарачиваться
Вопрос цены вопроса, естественно. Пилить такое ради галочки "смотри чего мы умеем" или просто впрок - сомнительное решение. А когда на кону экономия весьма ощутимых денег и экономия эта даже в краткосрочной перспективе отобьет стоимость разработки и сопровождения - совсем другое пальто.
Насчет "отдавать единицы" не соглашусь - исходя из моих экспериментов, бюджетный ноут вполне способен отдавать 3-5 видео потоков без боли и страданий. С аудио все еще вкуснее, естетсвенно.
Идея эта давно витает в воздухе, но из-за узости ниши и высокого порога входа не сильно отсвечивает. И пока opensource-решение не появится - так и останется уделом фанатов и крупняка.
бюджетный ноут вполне способен отдавать 3-5 видео
как раз часть всей этой моей истории что один друг решил помочь ноутом в ретрансляции и удивился лютой загрузке (это было давно и ноут был реально слабый) :) а вообще "открытием" было что люди действительно смотрели со слабых ПК и ноутов, да еще подключенным фиговым wiFi через всю квартиру, с соседями, или на смартфонах, в общем даже воспроизведение 720p у них не тянуло, в т.ч. из-за канала
а вот к примеру коллега @nikhotmsk в аналогичном случае таки пробовал peertube, но потом перешел на youtube
у WebRTC P2P mesh меньше overhead, чем у сегментов HLS?
Не думаю, что разница оверхеда транспорта будет сколь либо значима / определяющя. Гораздо большая разница будет из-за того что в HLS гвоздями прибиты h264/mp3, а в WebRTC можно использовать VP8/VP9(если допустимо)/Opus. Например, чтобы предоставить несколько уровней качества, HLS требует отдельно кодировать каждый поток, а в VP можно использовать Simulcast.
Посмотрите проект https://webtorrent.io, это ведь почти оно?
Идеи по перебалансировке внедрить на уровне обвязки и хорошо будет, в свете актуальных событий.
Странно даже было узнать, что peertube не про это.
Не совсем. Webtorrent, насколько я вижу, допилили фичу, которая уже есть в некоторых торрент-клиентах - запрашивать пакеты в порядке воспроизведения и проигрывать их сразу. Технически это как раз ближе к HLS и работает для существующих видео, не для трансляций реального времени. Фильм так посмотреть можно, живую трансляцию хоккейного матча - увы. Но штука, безусловно, полезная для своих задач.
Строим CDN для медиа-трафика или экономим трафик при помощи WebRTC P2P mesh