Сервер Flash-вещаний (RTMP) на Python или создание высоконагруженных сетевых серверов с использованием Twisted
•
2 likes•1,877 views
![Содержание ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
What's hot
What's hot (15)
Similar to Сервер Flash-вещаний (RTMP) на Python или создание высоконагруженных сетевых серверов с использованием Twisted
Similar to Сервер Flash-вещаний (RTMP) на Python или создание высоконагруженных сетевых серверов с использованием Twisted (20)
More from Media Gorod
More from Media Gorod (20)
Сервер Flash-вещаний (RTMP) на Python или создание высоконагруженных сетевых серверов с использованием Twisted
- 1. Сервер Flash- вещаний (RTMP) на Python или создание высоконагруженных сетевых серверов с использованием Twisted Андрей Смирнов NetStream
- 8. Архитектура pyFMS Приложение 2 Приложение 1 Сервер pyFMS Комната 1 Комната 2 Разделяемый объект Поток (вещание) Клиенты:
- 9. Схема вещания API Клиент pyFMS Сайт ( API) Сбор и анализ статистики Вещание Чат Разделяемый объект Поток (вещание) Запись потока на диск с последующей обработкой Удаленные вызовы процедур ( RPC)
Editor's Notes
- Добрый день! Меня зовут Андрей Смирнов, я работаю техническим директором компании NetStream. Я расскажу о нашем опыте по созданию сервера вещаний для Flash. Сегодня этот сервер работает в качестве движка вещаний на сайте Smotri.com.
- Начнём мы с краткого рассказа о различных существующих решениях, потом уже поподробнее рассмотрим то, что у нас получилось реализовать и почему именно так, как получилось.
- Сначала несколько слов о самой технологии – о протоколе RTMP. Вещание во флеше организуется по проприетарному протоколу RTMP. Клиент, который является просто флешкой, подключается к серверу, после выполнения первоначального «рукопожатия» открывается в принципе симметричный канал, по которому передаются данные. Протокол является бинарным, соединение разделяется на независимо функционирующие каналы, по которым можно передавать пакеты, пакеты при этом разрезаются на кусочки ( chunk), которые позволяют в принципе осуществлять перемешивание ( interleaving ) данных из разных каналов. В пакетах можно передавать удаленный вызов процедур, которые кодируются с помощью AMF- кодирования (стандартного во флеше). Сам по себе протокол закрыт, основная часть работы по reverse engineering была выполнена в рамках проекта Red5. Однако документации по протоколу так и не получилось, необходимо изучать исходники Red5, других open-source серверов, где-то идти методом проб и ошибок, пока не получится результат.
- Мы рассматривали вариант реализации вещаний где-то год назад и решения принимались на тот момент. О чем можно сказать? Во-первых, коммерческие решения, ну и, конечно же, первое из них , Adobe Flash Media Server – это, собственно основной вариант реализации. Так сказать, вариант «от создателей RTMP ». Все остальные варианты – это так или иначе попытки реализовать что-то близкое. Ну если не рассуждать о плюсах и минусах таких закрытых решений, первое, что нас не устроило – это лицензирование сервера по количеству соединений, а по этому параметру как раз хотелось бы свободного масштабирования. Сегодня уже Wowza, например, предлагает лицензию просто за инсталляцию без учёта кол-ва соединений на сервер. Соответственно, следующий взгляд мы бросили в сторону свободного ПО. Тогда из более-менее готовых был только Red5. Это попытка полностью переписать Adobe FMS на Java, возможно, с некоторыми даже улучшениями по сравнению с оригиналом. Получается у них очень раздутый, сложный, но полнофункциональный сервер. Состояние по их же оценкам – честно бета. Он действительно работает, однако полностью отсутствует документация по тому, как писать приложения. Сотни способов установки, вариантов использования и т.п. Однако в результате понять что к чему бывает не так просто. Первый наш эксперимент сервера вещания был именно с Red5. Через месяц мучений и экспериментов удалось написать рабочее приложение вещания и чата, всё вполне сносно работало. Появились проблемы – утечка памяти (не уникальная проблема, судя по спискам рассылки), «утыкание» в процессор, но также возникли проблемы задержек. По непонятным причинам на не 100% загруженной машине запросы к red5 обслуживались с некоторыми довольно значительными задержками. Мы долго пытались разгадать причину, точно выяснили что проявляется она под нагрузкой, хотя процессор не нагружен. После не одной недели копания в исходниках и логах удалось обнаружить интереснейшую проблему. Мы обращались из ред5 к апи сайта при наступлении опеределенных событий во время вещания по HTTP . Red5 использует большое количество внешних библиотек (порядка 20) и в одной из них, которая реализует клиента HTTP, стояло замечательное ограничение по умолчанию на 2 коннекта к одному хосту в один момент времени. У нас же хост был всегда один. Ограничение было предназначено, видимо, для скачивателей, чтобы не перегружали хост скачивания, хотя он вообще сомнителен. Всё, чтоб было больше ограничения – вставало в очередь, забивало нити, дальнейшая деградация была уже каскадной. После обнаружения подобных проблем пропало дальнейшее желание с таким возиться. Milenia Grafter появился попозже, чем мы рассматривали первые решения, но это тоже RTMP- сервер на Java, но написан по минималистическому принципу, без использования внешних библиотек – гораздо более понятный код, однако слабый функционал, нужны существенные доработки, процесс разработки ведет один прграммист, отсутствие community. Еще существует некоторое количество проектов на разных языках программирования, но они были далеки от первой версии.
- Больше примеров? Может, разбить на несколько слайдов?
- Можно вспомнить, что Red5, например, написан на Java, который при помощи hotspot- компилятора превращается в исполняемый код, в то время как Python будет интерпертироваться. В то же время задача вещания является сильно ориентированной на центральный процессор. В RTMP формально нельзя просто копировать исходные данные из потока вещателя в потоки слушателей. Да, конечно, не стоит задача перекодирования видео или аудио потока, но формально может потребоваться достаточно большое количество преобразований, при этом поток состоит из большого количества «кусочков», на которые RTMP разрезает исходный поток, которые необходимо обрабатывать. Плюс поток состоит не только из пакетов аудио и видео, а из вызова удаленных процедур и т.п. действий.