Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
Когда-то копал в сторону RTMFP, даже пробовал сделать библиотеку для работы вне флеша. Но в итоге бросил бороться с ветряными мельницами и взял XMPP + Jingle
WebRTC использует Jingle.
В нём есть возможность безсервеного вещания посредством Multicast DNS, но он полностью инкапсулирует RTP стэк наследуя его недостатки.
Опять же не решается проблема с Path MTU и минимизацией задержек, нет DHT.
В нём есть возможность безсервеного вещания посредством Multicast DNS, но он полностью инкапсулирует RTP стэк наследуя его недостатки.
Опять же не решается проблема с Path MTU и минимизацией задержек, нет DHT.
Я и сам начал пилить свои велосипеды на Go.
Сейчас вот думаю как-то опубликовать наработки.
Сейчас вот думаю как-то опубликовать наработки.
Его (RTFMP) очень долго использовали ребята с одной из web версий карточной мафии. Главная проблема, которую они так и не решили — очень очень много людей друг с другом соединится не могут.
Я могу лишь предполагать что у них были проблемы с адресацией и multicast'ом.
Нужно понимать что RTMFP использует Application level multicast — клиент регистрирует поток на сервере, сервер формирует цепочку forwarder'ов и redirect'оров для вещания. Соединять клиентов по адресу в рамках сетевой группы означает рассчитывать что у них не будет проблем с multicast'ом, который обычно не очень хорошо работает ввидувездесущей возможной кривой настройки IGMP / MBGP etc на маршрутизаторах.
Нужно понимать что RTMFP использует Application level multicast — клиент регистрирует поток на сервере, сервер формирует цепочку forwarder'ов и redirect'оров для вещания. Соединять клиентов по адресу в рамках сетевой группы означает рассчитывать что у них не будет проблем с multicast'ом, который обычно не очень хорошо работает ввиду
Если кратко — дела обстоят очень плохо.
А потому что рулят RTMTP и последние расширения к HTML5 (на которые сейчас переходит, например, Netflix). Доступность протокола HTTP решает, а апдейты к HTML5 дают и шифрование, и разделение потоков аудио-видео, и динамическую подстройку под битрейт, и DRM, и метаданные. А Flash умрёт, как и планировалось.
Очень содержательный комментарий.
Я так понимаю речь идёт о WebCrypto, Encrypted Media Extensions и Media Source Extensions.
Это шифрование, DRM и адаптивный битрейт в JS.
Конечно они хотят это всё впихнуть в Webkit :3
Ведь никто у них потом контент тырить не будет, и врятли Netflix будет задумываться о качестве доставки с ихним каналом.
Прошу спустится с неба на землю и осознать то что простые смертные при жизни не будут располагать подобными ресурсами.
Как это всё решает вопрос минимизации задержек и экономии исходящего трафика?
Пропускная способность серверов чаще всего является слишком узким бутылочным горлышком, а Р2Р может кардинально уменьшить нагрузку при вещании. Собственно пост о том что RTMFP решает эти задачи очень даже хорошо и что я аналогов не видел в дикой природе, и что это всё может быть очень и очень полезно, но для начала стоит его прочитать прежде чем писать столь фанатичные высказывания.
По поводу восклицаний «Flash умрёт» советую глянуть в сторону Haxe и OpenFL.
Я так понимаю речь идёт о WebCrypto, Encrypted Media Extensions и Media Source Extensions.
Это шифрование, DRM и адаптивный битрейт в JS.
Конечно они хотят это всё впихнуть в Webkit :3
Ведь никто у них потом контент тырить не будет, и врятли Netflix будет задумываться о качестве доставки с ихним каналом.
Прошу спустится с неба на землю и осознать то что простые смертные при жизни не будут располагать подобными ресурсами.
Как это всё решает вопрос минимизации задержек и экономии исходящего трафика?
Пропускная способность серверов чаще всего является слишком узким бутылочным горлышком, а Р2Р может кардинально уменьшить нагрузку при вещании. Собственно пост о том что RTMFP решает эти задачи очень даже хорошо и что я аналогов не видел в дикой природе, и что это всё может быть очень и очень полезно, но для начала стоит его прочитать прежде чем писать столь фанатичные высказывания.
По поводу восклицаний «Flash умрёт» советую глянуть в сторону Haxe и OpenFL.
Для Netflix'a ресурсоэффективность ещё важнее, потому что там где «простые смертые» тратятся на сотню потоков — Нетфликс тратится на миллионы.
По поводу «Flash умрёт» — я имел в виду в сфере использования как плеера для воспроизведения видео. Понятно, что баннеры\игрушки ещё будут жить и жить.
P2P может кардинально уменьшить нагрузку, но только в областях, где нам по сути плевать как и когда юзер получит контент (и получит ли вообще). А вот заплатившему кровный доллар за кино покупателю нужно это кино отдать здесь и сейчас, а не когда наберётся сотня пиров.
По поводу «Flash умрёт» — я имел в виду в сфере использования как плеера для воспроизведения видео. Понятно, что баннеры\игрушки ещё будут жить и жить.
P2P может кардинально уменьшить нагрузку, но только в областях, где нам по сути плевать как и когда юзер получит контент (и получит ли вообще). А вот заплатившему кровный доллар за кино покупателю нужно это кино отдать здесь и сейчас, а не когда наберётся сотня пиров.
Умрёт как плеер для воспроизведения видео… я тоже так думаю, но пока сложно об этом судить.
Afaik нетфликс не тратится, они просто выкупают каналы пачками и потом сдают их в аренду бывшим владельцам.
2-3 лишних пира на пути к контенту это +300мс задержки, не думаю что для конечного пользователя это будет критично, а вот для самого контент-провайдера это десятки гигабит пропускной способности на один сервер. Заплатившему кровный доллар за контент «не реального времени» эта задержка не будет заметной так как она будет плавно увеличиваться в процессе буферизации. Cотня пиров не нужна — достаточно будет десятка, и даже если не наберётся — ничего не мешает качнуть с сервера. Р2Р особенно эффективен при лавинообразном наплыве народа как это было с iPhone 6.
Afaik нетфликс не тратится, они просто выкупают каналы пачками и потом сдают их в аренду бывшим владельцам.
2-3 лишних пира на пути к контенту это +300мс задержки, не думаю что для конечного пользователя это будет критично, а вот для самого контент-провайдера это десятки гигабит пропускной способности на один сервер. Заплатившему кровный доллар за контент «не реального времени» эта задержка не будет заметной так как она будет плавно увеличиваться в процессе буферизации. Cотня пиров не нужна — достаточно будет десятка, и даже если не наберётся — ничего не мешает качнуть с сервера. Р2Р особенно эффективен при лавинообразном наплыве народа как это было с iPhone 6.
У RTMFP есть и проброс через NAT
Не покажите рабочий пример?
Не покажите рабочий пример?
Нужно понимать что тут всё завязано на UDP multicast и без IGMP просто некуда…
Но если его нет, то определение маршрута должно быть реализовано в виде стороннего решения.
Сейчас определение forward'еров и redirect'оров для сессии происходит посредством Adobe Cirrus сервиса.
Также эта задача может быть решена посредством DNS Service Discovery методов.
Почитайте про peer-assisted networking что бы лучше понимать о чём идёт речь.
Но если его нет, то определение маршрута должно быть реализовано в виде стороннего решения.
Сейчас определение forward'еров и redirect'оров для сессии происходит посредством Adobe Cirrus сервиса.
Также эта задача может быть решена посредством DNS Service Discovery методов.
Почитайте про peer-assisted networking что бы лучше понимать о чём идёт речь.
Аdobe cirrius не помогает соединиться через rtmfp, когда клиенты за nat. Я весь форум адобовский перечитал, так пишут даже сами разработчики.
Цитирую по ссылке выше.
Cirrus 2: Connecting to the Rendezvous service
Before any P2P communication can take place, Flash Player 10.1 instances need to connect to the Adobe Cirrus service. The service is considered a rendezvous service, and what that means is that each Flash Player instance can connect to it and utilize Cirrus to locate other Flash Player instances. Cirrus accomplishes this by translating the peer ID of the nodes in the mesh to network address/port combinations and forwarding connection requests from one peer to another. Another benefit to using the Cirrus service is that it has the ability to assist with UDP hole punching enabling the P2P mesh to traverse many NATs and firewalls.
А можно по-подробнее про «WebRTC может отвалится при смене соты в 3G/4G. RTP стэк плохо подходит для вещания в подобной среде»?
Что помешает WebRTC перейти на использование TURN-сервера, если даже он не сможет напрямую связать два пира?
И почему такой проблемы нет в RTMFP?
Что помешает WebRTC перейти на использование TURN-сервера, если даже он не сможет напрямую связать два пира?
И почему такой проблемы нет в RTMFP?
В RTMFP любой клиент в сетевой группе может выступать forward'ером и / или redirect'ором сессии — turn-сервером для других грубо-говоря.
Сервер решает кто где и как будет пробрасывать это всё, кому хватает пропускной способности, кому нет, и как минимизировать задержки.
При инициации сессии передаётся список всех доступных forward'еров в рамках сетевой группы.
Нужно понимать что клиент при удачном подключении к сетевой группе может вещать для других клиентов.
RTP жестко привязан к сетевым адресам и при смене соты в mesh может происходить смена сетевого адреса и маршрута, соответственно multicast может просто отвалится. В RTMFP такой проблемы нет так как в нём для адресации исполользуется DHT таблица как в торрентах.
Сервер решает кто где и как будет пробрасывать это всё, кому хватает пропускной способности, кому нет, и как минимизировать задержки.
При инициации сессии передаётся список всех доступных forward'еров в рамках сетевой группы.
Нужно понимать что клиент при удачном подключении к сетевой группе может вещать для других клиентов.
RTP жестко привязан к сетевым адресам и при смене соты в mesh может происходить смена сетевого адреса и маршрута, соответственно multicast может просто отвалится. В RTMFP такой проблемы нет так как в нём для адресации исполользуется DHT таблица как в торрентах.
В теории всё хорошо, но на практике — очень серьёзные проблемы: четыре года назад мы запустили www.onwebinar.ru — там как раз использован RTMFP. Вывод — для коммерческих проектов это неподходящая технология. Примерно для 3-5% пользователей (особенно корпоративных) просто не работает в силу разных причин (NAT, заблокированные UDP-порты). Качество трансляций невозможно гарантировать и, самое главное, этим процессом никак нельзя управлять. Проблемы возникают на ровном месте: ассиметричные каналы, низкая мощность ПК пользователей (посмотрите загрузку ЦП на нетбуках).
ИМХО — тупиковая технология. Хотите проверить? Заходите на сайт, проведите тестовую трансляцию.
ИМХО — тупиковая технология. Хотите проверить? Заходите на сайт, проведите тестовую трансляцию.
RTMFP — не технология, это протокол.
Я и не говорю что у Adobe он хорошо реализован.
Но повествование в общем-то не про Adobe, а про протокол… и про его приемущества, и про то что у него нет аналогов.
rtmfp2http шлюзы реализуются также как и rtmtp, то что их нет у Adobe не означает что их нельзя реализовать.
Мощности на aes128 и hmac-sha256 не хватает?..
Ну не знаю, а SSH там нормально работает? — у него и ключик обычно толще.
Собственно с подключениями ситуация такая что пока не взять всё в свои руки — на Adobe лучше не надеяться.
Но подружить свою поделку с Flash плеером вполне реально.
Любой протокол никак не поможет гарантировать качество или бесперебойное вещание.
Серебряной пули нету.
Я и не говорю что у Adobe он хорошо реализован.
Но повествование в общем-то не про Adobe, а про протокол… и про его приемущества, и про то что у него нет аналогов.
rtmfp2http шлюзы реализуются также как и rtmtp, то что их нет у Adobe не означает что их нельзя реализовать.
Мощности на aes128 и hmac-sha256 не хватает?..
Ну не знаю, а SSH там нормально работает? — у него и ключик обычно толще.
Собственно с подключениями ситуация такая что пока не взять всё в свои руки — на Adobe лучше не надеяться.
Но подружить свою поделку с Flash плеером вполне реально.
Любой протокол никак не поможет гарантировать качество или бесперебойное вещание.
Серебряной пули нету.
Не вижу большого экономического/коммерческого смысла в использовании протокола:
— мы всё равно упираемся во Flash как единственное средство воспроизведения. В плеер на чистом JS не верю :-)
— если уж автор протокола (Adobe) за почти пять лет его существования не стала его развивать — наверное у неё были на это причины?
P.S. Низкая производительность не только из-за шифрования, но и из-за накладных расходов на декодирование видео. Если бы компьютер не служил узлом передачи в сети, то проблем бы не было, а так — падает общее качество трансляции. Деградация качества нарастает нелинейно уже при 3-5% потерь.
— мы всё равно упираемся во Flash как единственное средство воспроизведения. В плеер на чистом JS не верю :-)
— если уж автор протокола (Adobe) за почти пять лет его существования не стала его развивать — наверное у неё были на это причины?
P.S. Низкая производительность не только из-за шифрования, но и из-за накладных расходов на декодирование видео. Если бы компьютер не служил узлом передачи в сети, то проблем бы не было, а так — падает общее качество трансляции. Деградация качества нарастает нелинейно уже при 3-5% потерь.
Мне RISC гигагерца и двух ядер на телефоне хватает для aes128, sha256 и x264, вам не хватает для этого компьютера…
Ну что же, у всех свои требования, и это ваше мнение основанное на ваших потребностях и возможностях.
Для начала стоит разобраться с тем что в остальных решениях не контролируется размер окна, congestion control, и задержки при маршрутизации, а потом уже думать где это всё можно использовать, и это не обязательно должен быть flash.
Если у вас не получилось это использовать, то это не значит что у протокола нет экономического / коммерческого потенциала.
Я здесь не для того что бы развеивать ваши сомнения, или убеждать что сейчас есть нормальные реализации RTMFP. Их нет. И я рад что вы поделились своим опытом использования RTMFP, но, к сожалению, непосредственно к теме публикации это не относится.
Ну что же, у всех свои требования, и это ваше мнение основанное на ваших потребностях и возможностях.
Для начала стоит разобраться с тем что в остальных решениях не контролируется размер окна, congestion control, и задержки при маршрутизации, а потом уже думать где это всё можно использовать, и это не обязательно должен быть flash.
Если у вас не получилось это использовать, то это не значит что у протокола нет экономического / коммерческого потенциала.
Я здесь не для того что бы развеивать ваши сомнения, или убеждать что сейчас есть нормальные реализации RTMFP. Их нет. И я рад что вы поделились своим опытом использования RTMFP, но, к сожалению, непосредственно к теме публикации это не относится.
Юрий, а что вы скажете о перспективах MonaServer? Продукт выглядит многообещающим, вы уже тестировали его?
Довольно сыро и без тестов… есть костыли.
Я бы не стал использовать подобное решение в своих проектах.
Я бы не стал использовать подобное решение в своих проектах.
А какие альтернативы? Может стоит поддержать этот проект разработчиками, чтобы дело пошло быстрее?
Нет смысла поддерживать продукт с монолитной архитектурой, без внятных тестов и какого-либо профилирования/оптимизации. В противном случае тут больше половины нужно будет переписать подчистую, ну в общем «как всегда».
Если вам нужны гарантии качества и долгосрочной поддержки — в первую очередь стоит заняться оценкой рисков, вменяемой организацией работ и тестированием, в том числе и нагрузочным.
Если вам нужны гарантии качества и долгосрочной поддержки — в первую очередь стоит заняться оценкой рисков, вменяемой организацией работ и тестированием, в том числе и нагрузочным.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обзор протокола RTMFP