В случае с ограничениями Си, чаще всего GCC -Wall -Wextra показывает достаточно много чего полезного, и нормальные исходники почти не генерируют предупреждений. Но вот в случае поддержки тотально устаревших архитектур 20-30ти летней давности — включаем -Wtraditional и просто «рука-лицо». Если брать во внимание ограничения С++, то тут ситуация страшнее — включаем -Weffc++ и нет предела радости.
Умрёт как плеер для воспроизведения видео… я тоже так думаю, но пока сложно об этом судить.
Afaik нетфликс не тратится, они просто выкупают каналы пачками и потом сдают их в аренду бывшим владельцам.
2-3 лишних пира на пути к контенту это +300мс задержки, не думаю что для конечного пользователя это будет критично, а вот для самого контент-провайдера это десятки гигабит пропускной способности на один сервер. Заплатившему кровный доллар за контент «не реального времени» эта задержка не будет заметной так как она будет плавно увеличиваться в процессе буферизации. Cотня пиров не нужна — достаточно будет десятка, и даже если не наберётся — ничего не мешает качнуть с сервера. Р2Р особенно эффективен при лавинообразном наплыве народа как это было с iPhone 6.
Мне RISC гигагерца и двух ядер на телефоне хватает для aes128, sha256 и x264, вам не хватает для этого компьютера…
Ну что же, у всех свои требования, и это ваше мнение основанное на ваших потребностях и возможностях.
Для начала стоит разобраться с тем что в остальных решениях не контролируется размер окна, congestion control, и задержки при маршрутизации, а потом уже думать где это всё можно использовать, и это не обязательно должен быть flash.
Если у вас не получилось это использовать, то это не значит что у протокола нет экономического / коммерческого потенциала.
Я здесь не для того что бы развеивать ваши сомнения, или убеждать что сейчас есть нормальные реализации RTMFP. Их нет. И я рад что вы поделились своим опытом использования RTMFP, но, к сожалению, непосредственно к теме публикации это не относится.
RTMFP — не технология, это протокол.
Я и не говорю что у Adobe он хорошо реализован.
Но повествование в общем-то не про Adobe, а про протокол… и про его приемущества, и про то что у него нет аналогов.
rtmfp2http шлюзы реализуются также как и rtmtp, то что их нет у Adobe не означает что их нельзя реализовать.
Мощности на aes128 и hmac-sha256 не хватает?..
Ну не знаю, а SSH там нормально работает? — у него и ключик обычно толще.
Собственно с подключениями ситуация такая что пока не взять всё в свои руки — на Adobe лучше не надеяться.
Но подружить свою поделку с Flash плеером вполне реально.
Любой протокол никак не поможет гарантировать качество или бесперебойное вещание.
Серебряной пули нету.
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.
В RTMFP любой клиент в сетевой группе может выступать forward'ером и / или redirect'ором сессии — turn-сервером для других грубо-говоря.
Сервер решает кто где и как будет пробрасывать это всё, кому хватает пропускной способности, кому нет, и как минимизировать задержки.
При инициации сессии передаётся список всех доступных forward'еров в рамках сетевой группы.
Нужно понимать что клиент при удачном подключении к сетевой группе может вещать для других клиентов.
RTP жестко привязан к сетевым адресам и при смене соты в mesh может происходить смена сетевого адреса и маршрута, соответственно multicast может просто отвалится. В RTMFP такой проблемы нет так как в нём для адресации исполользуется DHT таблица как в торрентах.
Нужно понимать что тут всё завязано на UDP multicast и без IGMP просто некуда…
Но если его нет, то определение маршрута должно быть реализовано в виде стороннего решения.
Сейчас определение forward'еров и redirect'оров для сессии происходит посредством Adobe Cirrus сервиса.
Также эта задача может быть решена посредством DNS Service Discovery методов.
Я так понимаю речь идёт о WebCrypto, Encrypted Media Extensions и Media Source Extensions.
Это шифрование, DRM и адаптивный битрейт в JS.
Конечно они хотят это всё впихнуть в Webkit :3
Ведь никто у них потом контент тырить не будет, и врятли Netflix будет задумываться о качестве доставки с ихним каналом.
Прошу спустится с неба на землю и осознать то что простые смертные при жизни не будут располагать подобными ресурсами.
Как это всё решает вопрос минимизации задержек и экономии исходящего трафика?
Пропускная способность серверов чаще всего является слишком узким бутылочным горлышком, а Р2Р может кардинально уменьшить нагрузку при вещании. Собственно пост о том что RTMFP решает эти задачи очень даже хорошо и что я аналогов не видел в дикой природе, и что это всё может быть очень и очень полезно, но для начала стоит его прочитать прежде чем писать столь фанатичные высказывания.
По поводу восклицаний «Flash умрёт» советую глянуть в сторону Haxe и OpenFL.
У меня не реализован Flash Profile и тестов маловато, будет юзабельно — обязательно опубликую и напишу обзор.
Пока вот только завлекалочка что бы интерес подогреть, да мнение народа послушать.
Хотя есть несколько DNS Service Discovery техник которые могут быть использованы для решения проблем недоступности multicast групп, но я с ними знаком очень поверхностно.
Я могу лишь предполагать что у них были проблемы с адресацией и multicast'ом.
Нужно понимать что RTMFP использует Application level multicast — клиент регистрирует поток на сервере, сервер формирует цепочку forwarder'ов и redirect'оров для вещания. Соединять клиентов по адресу в рамках сетевой группы означает рассчитывать что у них не будет проблем с multicast'ом, который обычно не очень хорошо работает ввиду вездесущей возможной кривой настройки IGMP / MBGP etc на маршрутизаторах.
WebRTC использует Jingle.
В нём есть возможность безсервеного вещания посредством Multicast DNS, но он полностью инкапсулирует RTP стэк наследуя его недостатки.
Опять же не решается проблема с Path MTU и минимизацией задержек, нет DHT.
Afaik нетфликс не тратится, они просто выкупают каналы пачками и потом сдают их в аренду бывшим владельцам.
2-3 лишних пира на пути к контенту это +300мс задержки, не думаю что для конечного пользователя это будет критично, а вот для самого контент-провайдера это десятки гигабит пропускной способности на один сервер. Заплатившему кровный доллар за контент «не реального времени» эта задержка не будет заметной так как она будет плавно увеличиваться в процессе буферизации. Cотня пиров не нужна — достаточно будет десятка, и даже если не наберётся — ничего не мешает качнуть с сервера. Р2Р особенно эффективен при лавинообразном наплыве народа как это было с iPhone 6.
Ну что же, у всех свои требования, и это ваше мнение основанное на ваших потребностях и возможностях.
Для начала стоит разобраться с тем что в остальных решениях не контролируется размер окна, congestion control, и задержки при маршрутизации, а потом уже думать где это всё можно использовать, и это не обязательно должен быть flash.
Если у вас не получилось это использовать, то это не значит что у протокола нет экономического / коммерческого потенциала.
Я здесь не для того что бы развеивать ваши сомнения, или убеждать что сейчас есть нормальные реализации RTMFP. Их нет. И я рад что вы поделились своим опытом использования RTMFP, но, к сожалению, непосредственно к теме публикации это не относится.
Я и не говорю что у Adobe он хорошо реализован.
Но повествование в общем-то не про Adobe, а про протокол… и про его приемущества, и про то что у него нет аналогов.
rtmfp2http шлюзы реализуются также как и rtmtp, то что их нет у Adobe не означает что их нельзя реализовать.
Мощности на aes128 и hmac-sha256 не хватает?..
Ну не знаю, а SSH там нормально работает? — у него и ключик обычно толще.
Собственно с подключениями ситуация такая что пока не взять всё в свои руки — на Adobe лучше не надеяться.
Но подружить свою поделку с Flash плеером вполне реально.
Любой протокол никак не поможет гарантировать качество или бесперебойное вещание.
Серебряной пули нету.
Сервер решает кто где и как будет пробрасывать это всё, кому хватает пропускной способности, кому нет, и как минимизировать задержки.
При инициации сессии передаётся список всех доступных forward'еров в рамках сетевой группы.
Нужно понимать что клиент при удачном подключении к сетевой группе может вещать для других клиентов.
RTP жестко привязан к сетевым адресам и при смене соты в mesh может происходить смена сетевого адреса и маршрута, соответственно multicast может просто отвалится. В RTMFP такой проблемы нет так как в нём для адресации исполользуется DHT таблица как в торрентах.
Но если его нет, то определение маршрута должно быть реализовано в виде стороннего решения.
Сейчас определение forward'еров и redirect'оров для сессии происходит посредством Adobe Cirrus сервиса.
Также эта задача может быть решена посредством DNS Service Discovery методов.
Почитайте про peer-assisted networking что бы лучше понимать о чём идёт речь.
Я так понимаю речь идёт о WebCrypto, Encrypted Media Extensions и Media Source Extensions.
Это шифрование, DRM и адаптивный битрейт в JS.
Конечно они хотят это всё впихнуть в Webkit :3
Ведь никто у них потом контент тырить не будет, и врятли Netflix будет задумываться о качестве доставки с ихним каналом.
Прошу спустится с неба на землю и осознать то что простые смертные при жизни не будут располагать подобными ресурсами.
Как это всё решает вопрос минимизации задержек и экономии исходящего трафика?
Пропускная способность серверов чаще всего является слишком узким бутылочным горлышком, а Р2Р может кардинально уменьшить нагрузку при вещании. Собственно пост о том что RTMFP решает эти задачи очень даже хорошо и что я аналогов не видел в дикой природе, и что это всё может быть очень и очень полезно, но для начала стоит его прочитать прежде чем писать столь фанатичные высказывания.
По поводу восклицаний «Flash умрёт» советую глянуть в сторону Haxe и OpenFL.
Пока вот только завлекалочка что бы интерес подогреть, да мнение народа послушать.
Нужно понимать что RTMFP использует Application level multicast — клиент регистрирует поток на сервере, сервер формирует цепочку forwarder'ов и redirect'оров для вещания. Соединять клиентов по адресу в рамках сетевой группы означает рассчитывать что у них не будет проблем с multicast'ом, который обычно не очень хорошо работает ввиду
вездесущейвозможной кривой настройки IGMP / MBGP etc на маршрутизаторах.В нём есть возможность безсервеного вещания посредством Multicast DNS, но он полностью инкапсулирует RTP стэк наследуя его недостатки.
Опять же не решается проблема с Path MTU и минимизацией задержек, нет DHT.
Сейчас вот думаю как-то опубликовать наработки.