В erlyvideo есть одно неприятное место: в конфиге можно указать несколько виртуальных хостов и каждому из них будет соответствовать собственный сервер, хранящий ссылки на видеопотоки. Супервизор каждого сервера надо именовать, причём атомом, например для хоста default супервизор будет называться media_provider_sup_default. Генерация такого названия достаточно неприятно выглядит:
Name = binary_to_atom(<<"media_provider_sup_", (atom_to_binary(Host, latin1))/binary>>, latin1).
Технические проблемы на этом заканчиваются, но мне захотелось попробовать, как сделать автокомпилирующийся
на каждой реконфигурации модуль, в котором все vhost-ы забиты в клозы функций. Такой трюк может понадобиться например если такое преобразование происходит очень часто.
В случае со склейкой строк, на каждом вызове функции будет создаваться два бинари. Если же скомпилировать это в модуль, получится многократно быстрее, потому
что не будет никаких лишних выделений памяти. Сделать это оказалось несложно:
Различные веб-фреймворки и языки по-разному подходят к вопросу, как хранить сессию пользователя, да и просто:
как её привязать к пользователю. Особые проблемы начинаются тогда, когда надо связывать разные технологии, например
сделать единую авторизацию для рельсового приложения, phpBB форума и стриминг-сервера.
Самый простой подход — немного доработанные рельсовые сессии.
Стриминговый сервер erlyvideo вырос из своих пелёнок и научился делать достаточно важную вещь:
транслировать видеокамеру в интернет с помощью Quicktime Broadcaster или Wirecast.
Начинаем с установки erlyvideo. Теперь настраиваем вещание.
Инструкция по установке и запуску erlyvideo:
В эрланге для выставления опций сокета есть функция inet:setopts(Sock, Opts). Одной из её опций является {active, Mode}.
Я хочу немного подетальнее разобрать как ей пользоваться, потому что в документации не очень хорошо это разобрано.
Поскольку RTMP сервер на эрланге erlyvideo теперь умеет
показывать mp4 файлы как для старых флеш-плееров (до 10.0.32.18), так и для новых, я решил про него тут написать.
Демка пока очень мало чего может, но вечерами доделываю.
Стоит RabbitMQ, обслуживает порядка 5-6 источников и 4-5 потребителей,
т.е. совсем немного.
Поток сообщений небольшой: несколько штук в секунду максимум.
Иногда потребители не успевают разгрести сообщения и очередь сообщенй
растет до 5000, но позже она тоже рассасывается.
В целом, всё не страшно, но иногда RabbitMQ начинает сходить с ума.
Выражается это в отжирании 20 гигабайт памяти из которых 5 в оперативке.
Зашел на консоль сервера, нашел крысу: ей оказался процесс,
зарегистрированный как error_logger.
Его статистика по process_info(Logger, memory) показала все утерянные
20 гигабайт:
Вскоре после разворачивания AMQP сервера на выходных благополучно зависла виртуальная машина в которой жил RabbitMQ и… Было невесело и стало ясно, что пора воспользоваться кластером RabbitMQ.
Если вкратце, то кластер работает так: есть ноды, реплицирующие данные, есть memory-only ноды, на которых ничего не хранится. Клиент может подключиться к любой, но может получить редирект на другую ноду. Клиент должен уметь это отрабатывать, мне пришлось дописывать реализацию самому. При падении текущей ноды клиент должен сам переподключиться дальше. Если ему повезло, то он даже может сохранить auto_delete очереди, если успеет их законсумить. Однако я это не советую и лучше повторить процедуру подключения заново.
Итак, настройка кластера.
Мне потребовалось через RTMP рассылать данные в формате JSON по флешкам.
После прихода во флеш данные отправляются сразу в ExternalInterface.call:
ExternalInterface.call("juggernaut.receiveData", event.info.description);
В какой-то момент у меня начали валиться ошибки «в нигде» и «из
ниоткуда», которые
были видны только в Firebug-е. До receiveData дело не дошло.
Текст ошибки:
missing ) after argument list
Увидев вводный пост про AMQP решил поделиться своей практикой использования этого механизма.
Ещё задолго до начала внедрения AMQP у нас был полный зоопарк из различных обработчиков фоновых задач: delayed_job , starling + workling и т.п. Плюс к этому, ещё активно использовался HTTP ping между серверами и juggernaut для пуш-канала на браузер. Ах, ещё забыл брутальное оповещение по IP multicast.
Весь этот перечень страшных слов работает, но уж очень он разнообразен и обширен, решили урезать. Чего же общего между HTTP ping-ом и старлингом? Да то, что это всё сообщения от источника к подписчикам. AMPQ был выбран как общий транспорт для таких сообщений.