2. Что такое
видеосервер
• Камеры наблюдения (rtsp)
• Софт захвата (rtmp)
• Спутниковые грабберы (multicast)
• VLC/ffmpeg (mpegts)
• Файлы (адский набор вариантов)
3. Все это раздается на
• Десктопы (rtmp, hds)
• Приставки и айпады (hls)
• Архив для таймшифта
4. Протоколы и
форматы
• Их много
• Все реализуются по своему
• Закрытые и глючные реализации
• Надо адаптироваться под всех
• Иногда кажется что надо обобщить (rtp/
rtsp/sip)
5. Вытекающие
проблемы
• Код запутан из-за того что стройные идеи
пронизаны запилами
• Очень сложно юнит-тестировать. Лучше
вообще не рассчитывать на тесты
• Ошибки возникают и это нормально
• Нельзя из-за них ронять рантайм, который
живет долго
6. Какие еще
особенности?
• Высокие требования по скорости
• Хочется слабую связанность компонент
(конфликтует с п. 1)
• Утечки памяти - огромная проблема с
которой не справляется джава
7. Что хочется?
• Высокоэффективная платформа для сетевых
демонов
• Возможность горячей замены кода
• Автоматический контроль за ошибками
рантайма, ограничивающий их воздействие
• Слабую связность отдельных компонент
• Дешевую многоядерность
8. Erlang
• Процессы - фантастически клевая идея
• Это объекты в которых данные и поток
выполнения связаны вместе
• Больше такого нет нигде
• "Объекты обмениваются друг с другом
различными сообщениями"
9. Что из этого
следует?
• Автоматическая обработка ошибок
изолирует их в одном процессе
• Бесплатная многоядерность
• Слабая связанность через сообщения
• Немутабельность упрощает все
• Софт-риалтайм сборка мусора. Никакого stop
world
10. Процессы это
объекты
• Данные инкапсулированы в них и только в них
• Имеют ограниченное время жизни
• Есть конструкторы и деструкторы
• Имеют бизнес-логику
• Могут вызывать методы друг на друге
• Даже есть указатели на объекты (сетевые!)
11. Чем же это не C++
• Value данные немутабельны
• Вызов метода эксплицитно происходит посылкой
сообщения
• Все объекты - потоки выполнения
• Не реентерабельны и синхронизируются по mailbox
• Нет явного наследования, только руками
• Код не связан с данными
12. Неожиданные
фишки
• Возможность горячей замены кода
• Отложенный ответ на вызов метода (!)
• Отсутствие race condition внутри одного
объекта (да и вообще их мало)
• Можно сделать счетчик ссылок с
таймаутом
13. Erlang - это не о том,
как быть модным
хипстером
15. Pattern matching
• Труъ ООП
• Классификация аргументов через классы в
дереве наследования работает плохо
• Мы классифицируем объекты ad-hoc, в
каждом месте ветвления логики
• Pattern matching - это классификация объектов
по их значению, актуальному здесь и сейчас
16. Обработка ошибок
• Изолированы внутри процесса
• По умолчанию завершают текущий
объект с его ресурсами
• Можно подписаться на смерть объекта (!)
• Органичная часть рантайма
• Не надо писать код по обработке ошибок
17. Одного Erlang мало
Нужен OTP
• Эмуляция вызовов методов через
сообщения
• Слежение за деревом процессов
• Автоматическое журналирование событий
• Стандартизация стиля программ
• Код не по OTP это зло
18. Ложка дегтя
• Неудобные строки
• error_logger при известном стечении
обстоятельств может уронить систему в
oom
• Нет ORM типа ActiveRecord
• Не ценится в гей-сообществе
19. Пример Erlang в
видео
• Поток кадров осуществляется посылкой
сообщений подписчикам
• Никаких задержек источника: рантайм сам
раскидает сообщения и зашедулит
получателей
• Клиент падает и не должен явно отписываться
• В источнике счетчик подписчиков с
таймаутом
21. Опыт erlyvideo
• Несколько гигабит
• Без утечек памяти и файлов
• Работает месяцами без сбоев
• Приносит деньги
22. Структура ПО
• Java, C++ — это как марионетка с одной
веревочкой
• Erlang — раздельные компоненты
23. Либы на C
• Событийные
• Можно в отдельных тредах
• Достаточно удобно
• Нет аналога FFI
24. Резюме
• Erlang оказался прекрасной платформой
для разработки сложного, запутанного
сетевого демона
• Потребовалось гораздо меньше
ресурсов и сил чем на джаве и
результаты тоже лучше