Меню Рубрики

Установка и настройка udpxy

Блог Валерия Малько

Страницы

суббота, 9 февраля 2019 г.

Настройка igmpproxy, udpxy и xupnpd на прошивке Openwrt для просмотра IPTV.

Общее

3. устнановить текстовый редактор nano для более удобного редактирования конфигов:

для вставки текста из буфера обмена необходимо нажать правую кнопку мыши
CTRL+s — сохранить файл
CTRL+x — закрыть файл

1. Настройка igmpproxy

2. проверить работу IGMP snooping командой:

2. устнановить igmpproxy командой:

opkg update
opkg install igmpproxy

3. отредактировать конфиг igmpproxy:

у Вас она не будет работать т.к. работает только на сети моего провайдера!
можно разрешить igmpproxy слушать все возможные адреса, в этом случае возможна нестабильность, хотя у меня работает нормально:

сохранить и закрыть файл:
CTRL+s
CTRL+x

полный конфиг igmpproxy выглядит так:

config igmpproxy
option quickleave 1
# option verbose 1(none, minimal[default], more, maximum)

config phyint
option network wan
option zone wan
option direction upstream
list altnet 192.168.1.0/24
list altnet 0.0.0.0/0

config phyint
option network lan
option zone lan
option direction downstream

4. отредактировать конфиг файервол командой:

в данном файле ничего не удалять, только добавить строки:

config rule
option name ‘Allow-IPTV-IGMPPROXY’
option src ‘wan’
option proto ‘udp’
option dest ‘lan’
option dest_ip ‘224.0.0.0/4’
option target ‘ACCEPT’

сохранить и закрыть файл:
CTRL+s
CTRL+x

5. запустить igmpproxy командами:

/etc/init.d/firewall restart
/etc/init.d/igmpproxy enable
/etc/init.d/igmpproxy start

6. проверить работу igmpproxy командой:

2.Настройка udpxy

2. отредактировать конфиг udpxy:

необходимо изменить значение строки option disabled с «1» на «0»

сохранить и закрыть файл:
CTRL+s
CTRL+x

3. отредактировать конфиг файервол командой:

в данном файле ничего не удалять, только добавить строки:

config rule
option name ‘Allow-IPTV-UDPXY’
option src ‘wan’
option proto ‘all’
option dest_ip ‘224.0.0.0/4’
option target ‘ACCEPT’

сохранить и закрыть файл:
CTRL+s
CTRL+x

4. запустить udpxy командами:

/etc/init.d/firewall restart
/etc/init.d/udpxy enable
/etc/init.d/udpxy start

где 192.168.100.1 — ip-адрес роутера, либо использовать обычный плейлист с приложениями для просмотра IPTV, в которых можно настроить прокси, например под android есть приложение IPTV.

3. Настройка xupnpd

данный способ просмотра через DLNA можно использовать только, если остальные способы не поддержтиваются на устройстве.

1. устнановить xupnpd командой:

2. запустить xupnpd командами:

/etc/init.d/xupnpd enable
/etc/init.d/xupnpd start

3. настроить xupnpd, открыв в браузере адрес (ip подставить от своего роутера):

4. перейти в раздел «Playlists», выбрать и загрузить файл плейлиста провайдера, нажать «send», затем нажать «Reload»

источник

Настройка IPTV в TomatoUSB + udpxy

udpxy — серверное приложение (daemon) для передачи данных из сетевого потока мультикаст канала (вещаемого по UDP) в HTTP соединение запрашивающего клиента.

Многие могут возразить, мол всё итак работает если просто включить multicast в настройках, но в моём случае просмотр IPTV через Wi-Fi корректно не работал: каналы загружались долго, картинка видео застывала, изображение «рассыпалось», интернет жутко начинал тормозить или совсем пропадал. Как следует поискав в интернете, я не нашёл внятной инструкции как перенаправить UDP в TCP на прошивке Tomato, попадались некоторые инструкции, но они были краткими и описывали сам механизм работы, а не конкретную настройку. Многие наши соотечественники даже писали, что это невозможно и нужно ставить другую прошивку и настраивать её или ставить прошивку которая «из коробки» поддерживает udpxy, но больно уж я полюбил «помидорную» прошивку за её производительность, функционал, и понятный, не нагруженный, интерфейс. В общем я решил довести дело до конца и попробовать самому во всём разобраться и настроить. В итоге появилась данная инструкция.

Оборудование и параметры использованные при настройке
Инструкция по настройке
Итоги

Мы получили перенаправление UDP трафика от провайдера в TCP трафик клиента, за счёт этого разгрузили роутер, получили быструю скорость загрузки видеопотока и высокое качество видео без «замираний» и «рассыпаний» изображения при просмотре на ПК. У меня всё прекрасно работает через wi-fi соединение на ноутбуке, а так же работает на медиаплеере iconbit HDS6L, который подключен по LAN к роутеру. Способ не самый простой, но изящный. Реализация его доставила мне очень много удовольствия. Очень надеюсь что эта информация проиндексируется в поисковиках и поможет таким же, неопытным как я, пользователям.

Добавлено 24.10.2015
Я наконец нашёл время приобрести IPTV приставку и тут мне понадобилось сделать мост WAN to LAN, чтобы приставка получила ip от провайдера и начала работать.
В админке идем в «Утилиты» -> «Системные команды» (для нерусифицированной версии: Tools -> System) и набираем последовательно команды:

    Сначала проверка:

Мы должны получить ответ:

  • Если ответ совпадает, выполняем команды последовательно дальше:
  • Дожидаемся перезагрузки и проверяем повторно выполнив команду 1.

    Мы должны получить ответ:

  • Втыкаем в 4-й порт кабель, идущий к приставке и вуаля — все работает!
  • источник

    Настройка IPTV в OpenWRT

    Хотя я практически не смотрю телевизор, иногда появляется непреодолимое желание посмотреть что сейчас вещают в новостях. Часто это желание возникает когда дочка спит, и телевизор уже вне зоны доступа. Как вы понимаете выход один — IPTV.

    По счастливому стечению обстоятельств у меня подключен тарифный план с бесплатным пакетом IPTV и имеется роутер Netgear WNDR-3800. На роутере имеется прошивка OpenWrt Backfire 10.03.1.
    Так как в комментариях появились замечания по поводу того что udpxy не такая уж и нужная вещь, стоит отдельно отметить, что я смотрю IPTV исключительно по WiFi, а некоторые устройства не поддерживают 802.11n и при использовании мультикаста картинка на них рассыпается.
    На хабре было много статей об OpenWrt, о настройке сети в OpenWrt, настройке IPTV трансляций, и некоторые другие, но к сожалению в них процесс настройки собственно IPTV если и описан, то без каких либо подробностей. И хотя этот процес совсем не сложен, я надеюсь мой топик сократит время на поиск и чтение необходимых мануалов, которых в сети предостаточно. Я произвожу эти настройки не в первый раз, так как иногда в процессе экспериментов с VPN, Wi-Fi и другими плюшками роутер умирал и восстанавливался в аварийном режиме. Посему будьте внимательны и осторожны, что бы не пришлось обращаться к процедуре восстановления.

    Все настройки будем производить из консоли, т.к. я с некоторых пор не доверяю LuCI. Предпологается что вы подключены к роутеру по ssh под рутом.

    Первым делом устанавливаем udpxy:

    После успешной установки проверим что udpxy запускается:

    Эта команда выведет версию udpxy и ее основные опции. Кстати подробное описание все опций можно найти здесь.

    Перейдем собственно к настройке. В папке /etc/init.d создаем файл udpxy:

    Этот файл — стартовый скрипт udpxy. Подробнее о стартовых скриптах OpenWrt можно узнать здесь.
    Содержимое нашего файла будет примерно таким:

    Для запуска службы используется start-stop-daemon — утилита для контроля запуска и остановки системных служб. В IGMP_BIN указываем что и откуда запускать, PID_F — куда записать PID что бы в последствии за ним можно было следить, IGMP_OPTS — настройки запускаемой службы.

    Прежде чем указывать настройки, советую попробовать запустить udpxy с этими настройками, и только после этого переносить их в конфиг, это поможет вам не стать жертвой опечатки, и возможно сэкономит немного времени.

    После того как все настройки завершены, закрываем файл udpxy и запускаем сервис командой

    Проверить запустилась ли udpxy можно при помощи команды

    Если вы видите в результате только одну строку, возвращайтесь к настройкам и проверяйте что вы сделали не так. В случае если все верно, должно получиться что то вроде

    Так же можно открыть в браузере страничку http://192.168.1.1:8888/status для проверки что udpxy работает.
    Теперь можно прописать наш стартовый скрипт в автозагрузку. Для этого достаточно выполнить команду:

    после этого в папке /etc/rc.d должна появиться символическая ссылка вида S99udpxy. Проверить добавился ли скрипт в автозагрузку можно так же командой

    если все нормально вы получите в ответ «enabled».

    Дело осталось за малым — создать правила для udp трафика:

    Читайте также:  Установка пожаротушения с микрокапсулированным термоактивирующимся веществом

    Эти правила необходимо добавить в /etc/config/firewall, и после этого перезапустить службу командой:

    Так же можно перезагрузить и сам роутер, что бы убедиться что все необходимые службы запускаются, ивсе рабтает именно так как мы задумали.
    Теперь берем список каналов у провайдера, и все ссылки преобразуем так как описано в мануале к udpxy:

    то есть если у вас в списке каналов указано то на выходе должно получиться

    После этого открываем список каналов любым подходящим проигрывателем и наслаждаемся.

    источник

    OpenWrt Project

    User Tools

    Site Tools

    Table of Contents

    IPTV / UDP multicast

    Основные положения

    Когда хост хочет начать получать широковещательный UDP трафик, то он должен принадлежать к группе «UDP multicast group». Контроль для широковещательных групп базируется на протоколе IGMP. Как только хост подписан, весь трафик для этой группы посылается ей используя broadcast L2 frames. Это важно, потому как многие роутеры направляют весь широковещательный трафик на все порты. В домашних сетях вы обычно используете Linux для управления проводными и беспроводными сетями, и если вы получаете широковещательный трафик по проводному каналу, то вы будете забивать им и беспроводные каналы тоже. К счастью в версии ядра Linux 2.6.34 есть возможность «IMGP snooping», которая отслеживает подобные ситуации и по умолчанию присутствует в OpenWrt. Таким образом у вас не будет нежелательного трафика на портах, который не были вами заданы для получения.

    Ещё одним важным фактором является так же то, что из-за использования низкого уровня скорости (чтобы все клиенты могли «слушать»), а так же хитрых режимов энергосбережения – широковещание в беспроводных сетях работает не так, как этого от него ожидаешь. Зачастую широковещание бесполезно для IPTV .

    Решение

    Благодаря «IGMP snooping», утилита igmpproxy больше не должна создавать проблемы в беспроводных сетях. Теперь вы можете одновременно запускать обе утилиты igmpproxy и udpxy.

    Проверьте, что поддержка «IGMP snooping» присутствует в вашей прошивке OpenWrt и включена!

    Если команда выдаст сообщение содержащие « No such file or directory », то прошивка скомпилирована без поддержки «IGMP snooping» и просмотр IPTV затормозит вашу беспроводную сеть.

    Если файл существует, то вывод команды выдаст либо « 1 », либо « 0 ». Если выдается « 1 », то ничего делать не надо, а если « 0 », то для включения «IGMP snooping» в файл /etc/config/network , в конфигурации интерфейса «lan», необходимо добавить строку:

    Примечание: В версии OpenWrt Attitude Adjustment 12.09, «IGMP snooping» по умолчанию включен, поэтому никакие изменения в /etc/config/network для OpenWrt AA 12.09 не нужны! Однако начиная с ревизии r36463, «IGMP snooping» по умолчанию отключен и для его включения требуются вышеупомянутые действия.

    IGMP proxy

    Установка igmpproxy

    Выполните команды устанавливающие igmpproxy:

    После установки пакета, необходимо отредактировать файл конфигурации /etc/config/igmpproxy :

    Настройки Firewall

    Запуск igmpproxy

    После добавления правил, необходимо перезапустить фаервол, добавить igmpproxy в автостарт и естественно запустить сам igmpproxy. Выполните следующие команды:

    В дальнейшем igmpproxy будет сразу стартовать автоматически в процессе загрузки роутера.

    Проверка сервиса igmpproxy

    При отсутствии строки “/usr/sbin/igmpproxy /var/etc/igmpproxy.conf”, отладка сервиса из командной строки

    В случае падений сервиса, можно добавить в cron команду

    Подсети провайдера из которых идет вещание

    Если вы не уверены, что надо написать в строках list altnet файла конфигурации /etc/config/igmpproxy , то закомментируйте эти строки и посмотрите на вывод igmpproxy в логе роутера. Пытайтесь после запуска igmpproxy подписываться на какие-либо каналы с помощью VLC или каким-нибудь другим клиентом (проигрывателем). Если в файле конфигурации не будет хватать сетей, то вы увидите в логе, что-то типа: « Warn: The source address 10.254.16.66 for group 233.32.240.222, is not in any valid net for upstream VIF ». Адрес, указанный после source address необходимо прописать в list altnet файла конфигурации /etc/config/igmpproxy . В случае нескольких адресов, прописать соответсвующую маску.

    Для универсальности можно разрешить igmpproxy слушать все возможные адреса, прописав

    Однако в этом случае возможна нестабильность.

    Также следует учитывать, что значение 0.0.0.0/0 поддерживается начиная с ревизии r40729. На старых ревизиях igmpproxy откажется запускаться с данным значением, выдав ошибку: « The bits part of the address is invalid : 4286488 ».

    udpxy

    Альтернативным путем, который позволяет получить доступ к широковещательным UDP потокам, является утилита udpxy. Работает довольно хорошо, как на проводных, так и на беспроводных соединениях.

    Установка udpxy

    Выполните команды устанавливающие udpxy:

    После установки пакета, возможно вам понадобится отредактировать стартовый скрипт /etc/init.d/udpxy в соответствии с вашими требованиями. Вас должна интересовать только строка OPTIONS=“-T -S -p 4022” . Вы можете ее оставить так, как она есть, но если вас что-то будет не устраивать в работе udpxy, то вы можете изменить ключи для запуска udpxy в соответствии с руководством по использованию данной утилиты.

    Пример изменения стартового скрипта /etc/init.d/udpxy

    Настройки Firewall

    Для того, чтобы udpxy мог работать с IGMP, вы должные добавить соответствующие правила в файл /etc/config/firewall :

    Запуск udpxy

    После добавления правил, необходимо перезапустить фаервол, добавить udpxy в автостарт и естественно запустить сам udpxy. Выполните следующие команды:

    В дальнейшем udpxy будет сразу стартовать автоматически в процессе загрузки роутера.

    Теперь когда вы захотите получить доступ, скажем, к udp://@239.64.64.58:1234 , то вы должны указать своему проигрывателю соединиться с адресом http://192.168.1.1:4022/udp/239.64.64.58:1234 . В данном примере, IP -адрес 192.168.1.1 является адресом вашего роутера в локальной сети.

    Примечание по совместному использованию igmpproxy и udpxy

    Если вы планируете использовать одновременно igmpproxy и udpxy, то в файле конфигурации фаервола – /etc/config/firewall у вас в итоге должно быть два правила:

    источник

    От udpxy к GigA+: путь развития ПО доставки видеопотоков 9

    Начало udpxy

    В середине 2008 года началась разработка udpxy — утилиты для преобразования потока данных из протокола UDP в TCP. Заказчиком был человек, вступивший в «борьбу» с IP телевидением в московской квартире. Не желая прокладывать за собой провода, он положился на роутер (ASUS WL500g), обеспечивающий Wi-fi сеть. Видео смотреть было можно, но периодически вклинивались помехи. Содружество энтузиастов IPTV на интернет-форумах помогло выяснить, что суть проблемы — в потере пакетов, передающихся по протоколу UDP. Провайдер IPTV транслировал каналы в локальную сеть (здания) посредством мультикаста. Существовавшая в тот момент утилита под Windows, исправляла ситуацию, транслируя мультикаст поток в индивидуальное TCP соединение, но требовала настольный ПК. Роутер же обеспечивался, кроме фабричной, альтернативной прошивкой (известной как «прошивка от Олега»), и задача была сформулирована просто: создать аналог Windows-утилиты, работающий на прошивке роутера.

    Прошивка представляла собой набор программ поверх Linux 2.4. При наличии полноценной среды разработки, можно было воспользоваться любым поддерживаемым данной средой языком программирования. Ограничения были в мощности устройства и наличии ресурсов: 32-битный микропроцессор архитектуры MIPS и 32 Мб памяти ОЗУ. В качестве языка был выбран ANSI C — по причине крайней простоты задачи и того факта, что ни один другой язык не обеспечивал более прямолинейного доступа к сетевым протоколам. Утилита была названа udpxy («ю-ди-пикси») как соединение слов «UDP» и «proxy», и каламбуром с английским словом «pixie» (фея).

    Утилита, транслирующая единственный поток, была создана, но быстро потеряла актуальность. На вопрос, как один человек ухитряется смотреть более одного канала одновременно, последовали ссылки на семейный просмотр, наличие нескольких ноутбуков, стационарного компьютера, и многое другое. Теперь задачей было создание серверного приложения, способного транслировать несколько каналов через HTTP запросы. В какое число следует определить термин «несколько», я не был уверен, и максимальное число подписчиков было определено в шестнадцать.

    Архитектура udpxy была подчинена принципу крайней простоты. Это был простейший вариант «forked server» (по имени системного вызова fork(2)) для выполнения задач на маломощном процессоре с небольшим количеством памяти. Изначально встроенной оптимизацией было отсутствие двойного копирования: данные, прибывшие из сети (памяти ядра) в память процесса по адресу А, отбывали в сеть (память ядра) из того же адреса A.

    Читайте также:  Установка и монтаж конденсаторные батареи

    Чем обосновывался выбор «forked server» как архитектуры приложения? Прежде всего, уверенностью в простоте задачи, для которой не требуются сложные средства. Нагрузка от переключения между (максимум) 16-ю процессами не была существенной и не оправдывала усложнения.

    Новые игроки, наращивание функций

    Первым изменением была отмена ограничения на количество клиентов (те самые 16). Отменить лимит просили не домашние пользователи, раздающие IPTV каналы родным и гостям, а предприятия — IPTV провайдеры. Провайдеры «перенесли» udpxy из домена домашних роутеров на серверную аппаратуру с мощными процессорами и значительным объёмом оперативной памяти.

    Начали выявляться и ограничения самой архитектуры при обслуживании количества клиентов, намного превышающего шестнадцать. Счёт клиентов пошёл (для начала) на сотни. Каждому клиенту в udpxy соответствует свой процесс. При увеличении количества клиентов, переключения контекста между «клиентскими» процессами серьёзно загружали ОС. Процессы эти также отсылали статистику «родительскому» процессу (через pipe(2)), используя системные вызовы и, следовательно, пропуская данные через ядро.

    Кроме того, входящие каналы дублировались для каждого подписчика, потребляя ресурсы на каждый случай «подписки». Переключившись с канала А на канал Б, подписчик имел доступ лишь к «самым свежим» данным канала. Данных этих было, как правило, немного, а задержка в буферизации данных для проигрыша (на стороне плеера) приводила к осязаемой задержке при переключении каналов.

    Предприятия также заботила проблема разграничения доступа. udpxy, создававшийся для домашнего пользователя, не предусматривал возможности ограничивать доступ входящим запросам. Провайдеры выходили из положения, ставя перед udpxy дополнительный сервис (часто — NginX), выполнявший задачи аутентификации и авторизации.

    Несмотря на то, что udpxy работал стабильно, пройдя длительный период «беты», внештатные ситуации время от времени всё же случались. Анализ этих ситуаций показал, что менее стабильным (и наиболее сложным) является не код передачи данных клиенту, а код обработки входящего запроса, создания процесса-клиента и т.п. Ситуация естественная, поскольку логика обработки запросов была сложней простой схемы «перебрасывания» пакетов из одного сокета в другой. Усложнение же, в любом его виде, неизбежно вело к понижению стабильности.

    Бизнес-пользователи просили внести и множество иных изменений, продвигавших продукт в сегмент промышленного ПО. Выявленные недостатки предъявляли новые требования к архитектуре. Было ясно, что наслаивание функций на существующую архитектуру не оптимально, требовалось создание иного продукта.

    Gigapxy — переход на новые рельсы

    У нового продукта был вдохновитель, категорически отсоветовавший выпускать что-то под «старым» именем. Задумка выпустить udpxy 2.0 или udpxEE (udpxy Enterprise Edition) трансформировалась в решение оформить новый продукт под похожим, но новым именем. Этим именем стало Gigapxy.

    Продукт Gigapxy был задуман как коммерческий изначально. Целью коммерциализации не было обогащение участников, а скорее расчёт выйти на самоокупаемость, при которой работе могли бы уделяться полноразмерные рабочие часы, а не кванты времени, выкроенные от досуга. Одной из основополагающих идей было также уйти, ради повышения качества, от «гонки» по следам конкурентов. Стабильности предлагалось уделять априори больше стандартной для «валового» (корпоративного) программирования квоты времени и усилий. Идеи эти идеалистичны и не оригинальны. Это не остановило стремление воплотить их в жизнь.

    Разработка начиналась под FreeBSD, но вскоре стала параллельно идти под Linux как набирающей популярность в серверной среде. В отличие от udpxy, Gigapxy было решено сделать не «forked», а событийно-ориентированным сервером, где количество процессов не имеет пропорциональной зависимости от количества задач.

    Архитектура, взаимодействие модулей

    Приложение было разделено на два квази-независимых модуля: 1) gws — сервер, отвечающий за обработку клиентских (HTTP) запросов, интерфейс, обработку статистики и генерацию отчётов. И 2) gng — рабочий «движок», занятый приёмом-передачей данных из каналов-источников в соединения клиентов. Движков предполагалось использовать несколько, для баланса нагрузки в рамках сервера. Каждый из движков мог быть привязан к отдельному ядру процессора.

    Был отвергнут вариант многопоточной архитектуры, поскольку она не обеспечивала автономности: при крахе любого из «движков» (gng) или же gws-сервера «падало» бы всё приложение. По опыту udpxy, чаще всего работа нарушалась именно при обработке запросов. Поэтому, gws и gng были реализованы как независимые приложения (физически — единый исполняемый файл), запускаемые порознь и устанавливающие «связь» друг с другом непосредственно после запуска. Оба модуля были способны восстановить связь в случае «краха» любого из них.

    Архитектура взаимодействия модулей иерархична: изначально происходит запуск gws. gws создаёт два локальных интерфейса: 1) для административных запросов (возможность посмотреть статус программы по HTTP и статистику по каналам) и 2) интерфейс связи с «движками». Интерфейс для обработки клиентских запросов не добавляется до установления связи с «движками». Вслед за gws стартуют «движки», каждый из которых устанавливает связь с gws.

    Затем gws начинает обрабатывать запросы от пользователей. Модуль проверяет корректность запроса — синтаксически и с точки зрения прав доступа, затем формирует задачу (источник-клиент) и передаёт её для выполнения выбранному процессу gng. На стороне «движка» задача преобразуется в последовательность операций чтения источника и передачи данных клиенту.

    Каждый «движок» отвечает за множество клиентов в рамках своего процесса и работает со множеством каналов (M каналов на N клиентов, при N >= M). Изначально, каналы не дублировались на различных gng: заполучив однажды канал К, gng приобретал исключительное право на его обслуживание, все клиенты канала К направлялись на данный «движок». Однако данный подход имел серьёзный изъян. Клиенты могли в одночасье предпочесть некий канал А всем иным (как, например, во время трансляции футбольного матча) и перегрузить отведённый каналу (единственный) «движок» (читай — ядро процессора). Изъян был исправлен — в настоящее время существует опция, позволяющая равномерно распределять каналы по различным «движкам».

    Разграничение доступа

    Возможность перенести логику разграничения доступа со стороннего приложения (например, NginX) на Gigapxy была оценена высоко. В одном из клиентских сценариев, освобождённые аппаратные ресурсы позволили нарастить количество клиентских запросов до 30%.

    Разнообразие систем авторизации и аутентификации изначально повергли в замешательство: невозможно было поддержать их все. Невероятно было бы и рассчитывать на то, что все покупатели пользуются лишь двумя-тремя — выбор был широк. В этой ситуации помог пример архитектурного решения от прокси-сервера Squid, где многочисленные функции можно было делегировать «плагинам», поддерживающим связь с «родителем» через потоки стандартного ввода-вывода. Язык реализации «плагинов» был произволен. Данный механизм был применён в Gigapxy. Вопрос интерфейса с той или иной системой переносился в реализацию «плагинов». В ответственности gws оставалось общение с «плагином» (по некому протоколу) и поддержание достаточного количества сущностей «плагинов» для своевременной обработки запросов.

    Следует упомянуть, что решение переложить часть функций на сторонние компоненты поставило проблему «крахов» с их стороны. Код «плагинов» не контролируем, но в обязанности gws остаётся стабильная работа подконтрольных модулей. В результате, была реализована защита от «циклических падений»: ситуации, когда приложение в цикле пытается запустить мгновенно «падающий» компонент. Циклы подобного рода, как правило, чреваты бесконтрольным расходом ресурсов и разбухшим логом (в т.ч. и системным).

    Дополнительной трудностью была и скорость работы самих «плагинов», упиравшаяся в скорость ответа системы, с которой они контактировали. Был добавлен механизм кэширования отказов: запросы, получавшие ранее отказ на доступ, получали повторный отказ (в течение некоторого периода времени) без обращения к «плагинам», а непосредственно от gws.

    Коммуникации от gws к «плагинам» осуществлялись по несложному протоколу текстовых сообщений. С прошествием времени, к первоначальному протоколу с фиксированным количеством полей потребовалось добавить новый, с более гибкой настройкой. Протоколы поддерживаются приложением по сей день и, судя по всему, удовлетворяют запросам клиентов: заявок на улучшения не поступало несколько лет.

    Один канал — один сокет, буферные цепочки

    Создание отдельного сокета на чтение мультикаст-канала каждым клиентом в udpxy было расточительным. Прежде всего, это порождало значительное количество системных вызовов, на которых в высоконагруженных системах полагается экономить. Gigapxy кэширует данные каналов и использует для каждого канала связанный список буферов. Буфер может быть как в памяти, так и на диске, в зависимости от выбора (в конфигурации). Размер цепочки буферов автоматически корректируется в зависимости от нужд клиентов канала, и при ненадобности буфер отправляется в «резерв», откуда может быть востребован другим каналом.

    Читайте также:  Установка задней камеры prado 120

    Наличие цепочки буферов позволяет начать отправку данных клиенту сколь угодно далеко или близко от «самых свежих» данных. Клиенту практически сразу может быть послано достаточное количество материала для воспроизведения в течение нескольких секунд.

    Почему не был выбран иной механизм, например, кольцевой буфер? Система цепочек воспринималась при планировании наиболее гибкой, а схема потребления память цепочками — более разумной. Оправдался ли расчёт? Несомненно. Усилия, вложенные в не самый тривиальный код, окупились высвобождением значительных ресурсов для предприятий, переходивших на Gigapxy c крупных программных комплексов конкурентов. Для достижения этих результатов, правда, система управления буферами потребовала комплекса доработок и тестирования.

    «Ванька-встанька» — динамическое восстановление модулей

    Расчёт на то, что в процессе долговременной работы процесс gws может в какой-то момент «упасть» был оправдан. Модуль, отвечающий за обработку внешних запросов, рано или поздно сталкивается с «нестандартными» запросами, способными причинить вред из-за скрытых недостатков кода. Сталкивается этот модуль и с DDOS атаками. За несколько лет по обеим причинам было выявлено и устранено около десятка дефектов.

    Автономность модулей (каждый из которых — отдельный процесс) помогла достигнуть высокой стабильности. gws мог перестать принимать новые запросы в результате сбоя или DDOS атаки, но видеопотоки продолжали поступать клиентам. gws мог «упасть», но «движки» продолжали работу и переходили под управление заново запущенного gws. Падений же gng, благодаря простоте внутренней логики, было крайне мало.

    Работа с HTTP каналами и цепочками приложений

    Возможность запрашивать данные не только из UDP мультикаста, но и по HTTP ссылке была добавлена почти сразу же. Источником (каналом) мог стать любой передаваемый по HTTP поток. Возможность была востребована. В качестве источника Gigapxy поддерживает и HTTP, и TCP и UDP потоки в «чистом» виде. Источником может быть и файл.

    Поддерживается и конфигурация «цепочек» из gws, передающих поток от одного к другому. По сути, запрос позволяет «попросить» один gws передать дальше, по цепочке, другому gws, URL «реального» источника. Поток, таким образом, пойдёт через оба gws. Несмотря на «экзотичность» данной конфигурации, она оказалась востребована клиентами, «перебрасывающими» каналы с удалённых сетевых сегментов через «открытый» интернет.

    Клиенты и покупатели — немного истории

    Основным рынком Gigapxy (по разнообразным причинам) оказался Европейский Союз. Первой фирмой, испытывавшей позднюю альфу и последующие беты «в бою», был IPTV провайдер из Стокгольма. Опыт испытаний на «боевой» конфигурации сложно переоценить, а уровню надёжности и стабильности продукта, достигнутому за несколько лет, продукт, безусловно, обязан взаимодействию с клиентами.

    В настоящее время клиентская база охватывает большинство стран ЕС. Причины, по которым компании хотят работать с продуктом Gigapxy можно просуммировать следующим списком:

    • Высокая стабильность ПО. Стабильность, отсутствие регулярных перебоев и «крахов» ценится на рынке, по моему опыту, больше всех иных факторов. Несколько покупателей перешли с конкурентных продуктов именно из-за проблем с регулярными сбоями и «падениями» модулей прежнего ПО.
    • Сокращение расходов на «железо». Я неоднократно был свидетелем крайнего удивления (иногда переходившего в восторженное возбуждение) от количества высвобождаемых ресурсов в результате миграции на Gigapxy с иных систем. Разумеется, есть конкурентные продукты, идущие вровень, где удивления не стоит ожидать. Тем не менее, данный опыт повторялся не один раз. Эталоном остаётся пример покупателя, сумевшего «насытить» 10 гигабитную сетевую карту потоками с не самого современного сервера.
    • Оперативность в обслуживании. Без особых гарантий и громких обещаний мне, как правило, удаётся ответить на вопросы клиентов весьма оперативно. По личному опыту работы в корпорациях и фирмах разнообразных видов и размеров, могу сказать, что инертность пропорциональна размеру компании. «Гиганты индустрии» подчас не могут позволить себе быстрой обратной связи. Масштаб также часто не позволяет им отнестись с должным вниманием (и приоритетом) к запросам не крупных покупателей. В Gigapxy, множество изменений по запросам клиентов были внесены ещё на стадии испытаний.
    • Цена — существующая схема лицензирования вполне гибка и позволяет позволить себе покупку даже весьма небольшим предприятиям.

    Уроки и пожелания

    К моменту написания данной статьи, Gigapxy работает на «боевых» серверах клиентов уже почти пять лет. Как и любой продукт, за это время был накоплен опыт о том, что стоило бы сделать по-другому, где были допущены архитектурные просчёты, где была сделана лишняя работа, и суммарно — выводы на будущее. Я коснусь этих выводов вкратце.

    • Универсальность (к примеру, ввода-вывода из любого источника в любой протокол) бывает подчас излишней. Сценариев использования, как правило, не так много, а стремление к универсальности ведёт к усложнению кода и перегрузке логики.
    • Делегировать функции сторонним компонентам имеет смысл, если упрощает приложение, не уменьшая надёжности. Система выдачи отчётов, опиравшаяся на передачу данных от gws к gng, несколько усложнила логику gws. Система авторизации же напротив — упростила код gws, перенеся разумную часть нагрузки на клиента.
    • Документацию, сколь бы аккуратно и скрупулёзно она ни была написана, не берутся читать, а если берутся, то не дочитывают до конца. К сжатой документации по продукту стоит прилагать менее «сухие» по стилю руководства по установке, настройке и т.п. — их, как правило, читают.

    Камо грядеши? — GigA+

    Через год после завершения бета-тестирования Gigapxy, начали поступать запросы на добавление поддержки протокола Apple HLS. Это оказалось не столь тривиальной задачей, сколь могло бы показаться. После пары прототипов, работа над соответствующей версией началась. Сам протокол HLS весьма прост, и обсуждаться здесь не будет. В процессе разработки, задачу усложнили, добавив к HLS поддержку DVR — возможности проигрывать поток с заданной задержкой во времени; начать проигрывать, к примеру, за два часа до текущего времени.

    Первым «новоприбывшим» модулем стал модуль сегментирования потока (gxseg). Потребность генерировать различные плейлисты, в зависимости от задержки DVR, дали рождение модулю, ответственному за них. Сегментирование базировалось на библиотеке libav (от команды ffmpeg). С использованием библиотеки пришли ограничения, заставившие «обернуть» gxseg модулем управления потоком канала — vsm. Потребность в реплицировании сегментов и балансировки запросов прибавила ещё два микро-модуля. Это был уже иной продукт, и не было смысла считать его новой версией старого. Новый продукт был назван GigA+, выход его в «бету» состоялся 26 сентября 2017 года.

    Кому это выгодно?

    GigA+ заинтересует тех, кто желает привнести HLS в «репертуар», но не идёт по пути построения «хитроумного агрегата» собственными силами. Тем, кто уже работал с Gigapxy и знаком с «архитектурным стилем» данного продукта. Стиль этот будет выдержан и улучшен в GigA+.

    Что в первой бете?

    Бета — достаточно длительный период для продукта, в котором сделан упор на стабильность. Gigapxy перестал быть бетой тогда, когда стабильность его стала непререкаемым фактом (ни одного дефекта не поступило в течение полугода). Потому период беты разбивается на несколько крупных «сборок». В начальной сборке GigA+ присутствуют следующие основные функции:

    1. Линейная доставка каналов формата MPEG-TS — по сути, всё то, что включено в Gigapxy 1.0. NB: код Gigapxy 1.0 (в силу исторических причин) несколько отличен от ветки GigA+ и его стабильность (в силу внесённых изменений) официально не может быть классифицирована как равная Gigapxy 1.0, и считается также бетой.
    2. Доставка по протоколу HLS, сегментов в H.264 кодеке (видео) посредством MPEG-TS. Поддерживаются режимы LIVE и DVR. Поддерживается масштабирование на несколько серверов и балансировка запросов при помощи плагина для сервера NginX.

    Что дальше?

    Укажу лишь то, что уже внесено в план разработки и ожидает своей очереди. Итак:

    1. DRM — сперва в простейшей реализации AES- 128/256. Есть и далеко идущие планы в этой области.
    2. MPEG4 сегменты в HLS.
    3. Перевод отчётов (каналы, клиенты, статистика) на внешние сервисы.
    4. Система мониторинга состояния модулей.

    источник

    Добавить комментарий