Различные веб-фреймворки и языки по-разному подходят к вопросу, как хранить сессию пользователя, да и просто:
как её привязать к пользователю. Особые проблемы начинаются тогда, когда надо связывать разные технологии, например
сделать единую авторизацию для рельсового приложения, phpBB форума и стриминг-сервера.
Самый простой подход — немного доработанные рельсовые сессии.
Стриминговый сервер erlyvideo вырос из своих пелёнок и научился делать достаточно важную вещь:
транслировать видеокамеру в интернет с помощью Quicktime Broadcaster или Wirecast.
Начинаем с установки 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 был выбран как общий транспорт для таких сообщений.
Человеческие языки (насколько я это всё понимаю) бывают более или менее контекстно-зависимые. Например, русское слово «смеркается», вырванное из контекста скорее всего будет значить тоже самое, что и в самом контексте. Это удобно тем, что всегда можно его однозначно перевести просто по таблице перевода, а человеку надо меньше напрягать мозг, что бы понять что оно значит. Зато это слово писателю сложнее подогнать под свои нужды и выразить с его помощью что-то новое. Английское слово “do” наоборот: само по себе мало чего значит, зато его можно использовать в окружении других слов в разнообразнейших случаях. Минус понятен: что бы понять, что оно тут значит, надо держать кучу слов в памяти, что создает сильное когнитивное сопротивление.
Если перевести всё сказанное на программирование, то получается что:
Язык конфигурации postfix-а — первый вариант. Assembler — это чуть ли не предел контекстной зависимости. Хорошо бы держать всю память приложения в голове, когда на нем пишешь. Однако вполне понятно, что написать почтовый сервер на ассемблере безумно сложно, но теоретически возможно, а вот на языке конфигурации postfix-а — увы, никак.