gigaplus(1) gigaplus - Краткое руководство gigaplus(1) ИИММЯЯ GGiiggAA++ - Программный комплекс доставки IPTV потоков. ООППИИССААННИИЕЕ GGiiggAA++ ((ггииггаа--ппллююсс)) - это программный комплекс (ПК) доставки видеопотоков от поставщиков IPTV каналов к клиентам (на видеоприставки, "умные" ТВ, видео-плееры и.т.п.). GigA+ обеспечивает доставку как в виде непрерывных потоков (посредством _H_T_T_P), так и в виде сегментов (посредством _H_L_S). В случае HHLLSS, в комплексе может быть задействован сторонний веб-сервер (например, NNggiinnXX) или же ggxxnngg(1) - "движок" передачи данных. GGiiggAA++ - продолжение GGiiggaappxxyy, целиком сфокусированному на доставке непрерывных ("линейных") потоков. В Gigapxy доставка осуществлялась с помощью модулей ggwwss и ggnngg. GGiiggaa++ включает в себя подобные модули, названные соответственно ggxxwwss и ggxxnngg. ТТееррммииннооллооггиияя ии ссццееннааррииии ииссппооллььззоовваанниияя GigA+ использует термин _к_а_н_а_л для обозначения источника данных и _к_л_и_е_н_т для обозначения точки назначения данных. GGiiggAA++ доставляет данные _M мультикаст-каналов _N клиентам. Клиентом может быть любое приложение, способное выдать запрос HTTP в соответствующем формате. GGiiggAA++ спроектирован для эфективной и экономичной доставки данных как можно большему числу клиентов. В случае линейной доставки, встроенный кэш-механизм позволяет новым клиентам сразу же начать чтение данных из кэша и значительно сократить задержку при переключении каналов. Для конечного пользователя это означает, что переключать IPTV-каналы можно значительно быстрей. В случае доставки посредством HHLLSS, GigA+ позволяет распределить нагрузку между несколькими серверами и предоставляет свой собственный балансировочный модуль. Для отложенного проигрывания видео каналов можно настроить режим DDVVRR. ППРРООГГРРААММММННЫЫЕЕ ММООДДУУЛЛИИ GGiiggAA++ условно подразделяет модули на три категории: ппооддггооттооввккаа, ддооссттааввккаа и рраассппррееддееллееннииее. При линейной доставке задействуются только модули ддооссттааввккии. При доставке посредством HHLLSS, линейный поток должен пройти процесс подогтовки: сегментирование, генерацию плейлистов и т.д. Модули распределения отвечают за то, чтобы сегменты реплицировались на несколько серверов, и запросы перенаправлялись должным образом. ggxxwwss ((ВВеебб--ссееррввиисс)) обрабатывает пользовательские запросы, устанавливает входящие и исходящие соединения для соответствующих потоков, а затем передаёт задачу соответствующему процессу ggxxnngg. В случае HHLLSS, запрос может быть либо на плейлист, либо на сегмент данных. Если запрос на _п_л_е_й_л_и_с_т, ggxxwwss обращается к модулю _у_п_р_а_в_л_е_н_и_я _п_л_е_й_л_и_с_т_а_м_и и передаёт полученные данные клиенту. Для получения сегмента данных, запрос передаётся модулю ggxxnngg, который и обеспечивает доставку. ggxxwwss управляет _N процессами ggxxnngg, где _N <= _к_о_л_и_ч_е_с_т_в_а _я_д_е_р на ЦП данного сервера. Это позволяет равномерно распределять нагрузку на процессор(ы). ggxxnngg ((ММооддуулльь ддооссттааввккии)) обрабатывает запросы от ggxxwwss и обеспечивает доставку данных клиентам. Каждый ggxxnngg стыкуется с контролирующим ggxxwwss через UNIX-сокет. Большинство нагрузки на (ядра) ЦП идёт от работы ggxxnngg, поэтому обычно запускается несколько процессов этого модуля на различных ЦП (или ядрах). ggxxnngg отдаёт статистику по клиентам ggxxwwss, что позволяет тому балансировать нагрузку между несколькими процессами. ggxxnngg также поставляет статистику по параметрам потоков (отчёты TPS) для ggxxwwss. vvssmm ((ММееннеедджжеерр HHLLSS--ппооттооккоовв)) модуль _п_о_д_г_о_т_о_в_к_и потоков для HLS. Данный модуль обеспечивает разбивку входного (линейного) потока на сегменты и координирует действия с прочими модулями. Каждый процесс vvssmm отвечает за определённый канал, считывая нужные параметры из текстового файла - _с_п_е_ц_и_ф_и_к_а_ц_и_и _к_а_н_а_л_а. vvssmm, однако, всего лишь надстройка, задействующая другие модули для выполнения задач. vvssmm обеспечивает перезапуск нужных модулей и обеспечивает обработку всевозможных сбоев и ошибок при подготовке данных канала. ggxxsseegg ((ССееггммееннттииррооввааннииее HHLLSS ппооттооккоовв)) разбивает входной поток на сегменты. Модуль оповещает ggxxppmm(1) - _м_е_н_е_д_ж_е_р _п_л_е_й_л_и_с_т_о_в - о каждом сегменте. Данный модуль не должен вызываться напрямую. wwuuxx ((ППррооккссии ссллуужжееббнныыхх ссооооббщщеенниийй)) обеспечивает передачу сообщений между ggxxsseegg(1) и _м_е_н_е_д_ж_е_р_о_м _п_л_е_й_л_и_с_т_о_в. wwuuxx(1) ведёт _м_а_н_и_ф_е_с_т _с_е_г_м_е_н_т_о_в для предотвращения потери метаданных при крахе одного из задействованных модулей. Данный модуль не должен вызываться напрямую. ggxxppmm ((ММееннеедджжеерр HHLLSS--ппллееййллииссттоовв)) отвечает за генерацию плейлистов. vvssmm поставляет мета-данные для ggxxppmm в виде элементов плейлистов. ggxxwwss получает плейлисты от ggxxppmm и обеспечивает их доставку клиентам. ggxxppmm шлёт оповещение о _г_о_т_о_в_н_о_с_т_и для каждого сегмента ddwwgg(1) - _а_г_е_н_т_а_м _з_а_г_р_у_з_к_и. ddwwgg ((ААггееннтт ззааггррууззккии)) получает оповещения о _г_о_т_о_в_н_о_с_т_и _с_е_г_м_е_н_т_о_в и обеспечивает загрузку соответствующих файлов с удалённых серверов. ffllbb ((FFaassttCCGGII ббааллааннссииррооввщщиикк)) предстваляет из себя загружаемый FastCGI модуль для веб-сервера (NginX), распределяющий запросы на HLS-сегменты по множеству серверов. Алгоритм распределения может быть просто "перебором" (_r_o_u_n_d_-_r_o_b_i_n) или по принципу _м_и_н_и_-_м_а_к_с_а в зависимости от значения ппооллььззооввааттееллььссккооггоо ссееннссоорраа. ffllbb перенаправляет запрос (посредством HTTP 302) на сервер, выбранный соответствующим алгоритмом. РРЕЕЖЖИИММЫЫ ДДООССТТААВВККИИ ((ссттррииммииннггаа)) GGiiggAA++ поддерживает два режима доставки: линейный (поток подаётся непрерывно) и посредством _H_L_S (поток подаётся как последовательность сегментов данных, совместимых по формату с протоколом Apple _H_L_S). ЛЛииннееййннааяя ддооссттааввккаа ((ссттррииммииннгг)) ggxxwwss и ggxxnngg - два взамодействующих модуля при выполнения линейной доставки потока. Запрос изначально прихожит к ggxxwwss, который (после аутентификации) устанавливает соединение с источником, а затем поручает дальнейшую работу одному из пристыкованных процессов ggxxnngg. Запрос на линейную доставку может выглядеть следующим образом: _h_t_t_p_:_/_/_a_c_m_e_._c_o_m_:_8_0_8_0_/_s_r_c_/_u_d_p_:_/_/_2_2_4_._0_._2_._2_6_:_5_9_5_9_/_d_s_t_/_?_k_e_y_=_4_9_3_f_0_6_4_5_6_7 Для детального разбора _ф_о_р_м_а_т_а _з_а_п_р_о_с_о_в обращайтесь к странице ggxxwwss(1) документации. В данном сценарии, ggxxwwss разбирает вышеуказанный запрос и подписывается (если подписка уже не оформлена для иного запроса) на данные мультикаст-канала 224.0.2.26:5959. Затем оба соединения (источник AA == 222244..00..22..2266::55995599, назначение BB == ссооккеетт ззааппррооссаа) передаются одному из состыкованных процессов ggxxnngg. Тот, в свою очередь, осуществляет передачу данных из А в В до тех пор, пока одно из соединений не будет закрыто. ООддннооссееррввееррннааяя HHLLSS ддооссттааввккаа ((ссттррииммииннгг)) В данном режиме доставка потока происходит по протоколу HHLLSS, при этом все данные генерируются и хранятся на _о_д_н_о_м _и _т_о_м _ж_е _с_е_р_в_е_р_е. Изначально, запрос на _H_L_S_-_п_л_е_й_л_и_с_т поступает в ggxxwwss. Подобный запрос может выгладеть следующим образом: _h_t_t_p_:_/_/_d_a_t_a_-_h_o_s_t_1_:_4_0_4_6_/_h_l_s_-_m_3_u_/_s_h_o_w_t_i_m_e_/_p_l_a_y_l_i_s_t_._m_3_u_8 Для детального разбора _ф_о_р_м_а_т_а _з_а_п_р_о_с_о_в обращайтесь к странице ggxxwwss(1) документации. В данном случае ggxxwwss определяет, что это запрос на LLIIVVEE--ппллееййллиисстт и запрашивает плейлист у ggxxppmm, используя sshhoowwttiimmee как _и_д_е_н_т_и_ф_и_к_а_т_о_р _к_а_н_а_л_а. Чтобы ggxxppmm мог выполнить данный запрос (выдать LIVE плейлист для канала sshhoowwttiimmee), процесс vvssmm для данного канала должен быть в рабочем состоянии, обеспечивая ggxxppmm метаданными о сгенерированных сегментах. ggxxppmm отвечает на запрос ggxxwwss, передав плейлист, содержащий ссылки (URL) на сегменты данных (из текущего LIVE "окна"). URL в плейлисте может выглядеть следующим образом: _h_t_t_p_:_/_/_d_a_t_a_-_h_o_s_t_1_:_4_0_4_6_/_h_l_s_-_f_r_a_/_s_h_o_w_t_i_m_e_/_2_3_1_9_2_7_6_7_._t_s Данный URL ссылается на ggxxwwss (если судить по порту и префиксу _h_l_s_-_f_r_a), что означает, что файл сегмента (23192767.ts) должен быть отправлен клиенту посредством ggxxnngg. Получив данный запрос, ggxxwwss передаёт его процессу ggxxnngg для отправки файла клиенту. При ином сценарии, URL сегмента мог бы выглядеть так: _h_t_t_p_:_/_/_d_a_t_a_-_h_o_s_t_1_:_8_0_8_6_/_g_p_x_-_s_e_g_/_s_h_o_w_t_i_m_e_/_2_3_1_9_2_7_6_7_._t_s В этом случае мы полагаем, что сторонний веб-сервер был установлен и сконфигурирован на _п_о_р_т_у _8_0_8_6, выполняя файловые запросы из корня _g_p_x_-_s_e_g. Сторонний веб-сервер в нашем случае - независимый компонент, ответственный за доставку сегментов. При наличии стороннего веб-сервера можно обойтись без ggxxnngg, если обслуживаются только HLS-запросы. HHLLSS--ссттррииммииннгг ссоо ммнноожжеессттвваа ссббааллааннссиирроовваанннныыхх ссееррввеерроовв В данном режиме сегменты данных реплицируются, а запросы распределяются на множество серверов. Сегмент должен быть скопирован/реплицирован на каждый из участвующих серверов. ggxxppmm рассылает (через мультикаст-канал) сообщения о готовности сегментов, а ddwwgg (агенты загрузки) считывают сообщения и загружают данные на соответствующие серверы. ggxxppmm генерирует URL для балансировки нагрузки посредством модуля ffllbb(1) , сопряжённого со сторонним веб-сервером. ffllbb распределяет запросы, выбирая один из (множества) серверов и перенаправляя запрос посредством HTTP 302. URL может выглядеть, к примеру, так: _h_t_t_p_:_/_/_l_b_-_h_o_s_t_:_5_0_8_9_/_g_p_x_-_s_e_g_/_s_h_o_w_t_i_m_e_/_2_3_1_9_2_7_6_7_._t_s ffllbb, обслуживающий lb-host:5089 и распоряжающийся серверами начиная с _d_a_t_a_-_h_o_s_t_1 до _d_a_t_a_-_h_o_s_t_8 (количество не ограничено), может, к примеру, выбрать _d_a_t_a_-_h_o_s_t_4 и перенаправить запрос по ссылке: _h_t_t_p_:_/_/_d_a_t_a_-_h_o_s_t_4_:_8_0_8_6_/_g_p_x_-_s_e_g_/_s_h_o_w_t_i_m_e_/_2_3_1_9_2_7_6_7_._t_s где запрос будет обработан сторонним веб-сервером (или же ggxxwwss). Заметим, что ffllbb - не самостоятельное приложение, а FastCGI модуль веб-сервера. (В настоящее время ffllbb был испытан и гарантированно работает под управлением сервера _N_g_i_n_X 1.4+). Для усложнённых методов балансировки (т.е. кроме простого перебора), на одном из серверов понадобится установить и сконфигурировать _R_e_d_i_s NoSQL БД. База данных объединяет в себе различные метрики, позволяющие ffllbb задействовать критерии _m_i_n_i_-_m_a_x. Дополнительные детали установки БД и конфигурации _m_i_n_i_-_m_a_x следует искать на странице ggxxaa--llbb--sseettuupp(5) документации. ААВВТТООРРЫЫ Pavel V. Cherenkov ССММООТТРРИИТТЕЕ ТТААККЖЖЕЕ ggxxwwss(1),ggxxnngg(1),ggxxppmm(1),wwuuxx(1),ggxxsseegg(1),ddwwgg(1),ffllbb(1),ggxxaa--llbb--sseettuupp(5) gxws(1) gxws - Краткое руководство gxws(1) ИИММЯЯ ggxxwwss - сервер обработки HTTP запросов к GigA+. ППААРРААММЕЕТТРРЫЫ ggxxwwss [-h?TvVqkU] [-C _c_o_n_f_i_g___f_i_l_e] [-l _l_o_g_f_i_l_e_}_] _[_-_p _p_i_d_f_i_l_e_] ООППИИССААННИИЕЕ ggxxwwss - модуль обработки пользовательских и административных запросов к GigA+. Запросы приходят по протоколу HTTP. Формат различных запросов описан в разделах ППООЛЛЬЬЗЗООВВААТТЕЕЛЛЬЬССККИИЕЕ ЗЗААППРРООССЫЫ и ААДДММИИННИИССТТРРААТТИИВВННЫЫЕЕ ЗЗААППРРООССЫЫ данной страницы. ggxxwwss направляет (определённые) пользовательские запросы "движкам" ggxxnngg(1) GigA+. Для принятия пользовательских запросов требуется, по крайней мере, один "движок" ggxxnngg. Для запросов к сегментам ggxxnngg может не требоваться, если сегменты отдаёт сторонний веб-сервер. ggxxwwss может контролировать до 64-x ggxxnngg. ggxxwwss считывает параметры из файла конфигурации: по умолчанию либо _g_x_w_s_._c_o_n_f, либо _g_i_g_a_p_l_u_s_._c_o_n_f. Файл конфигурации может содержать секции для любых модулей GigA+. ggxxwwss ищет файл конфигурации в а) текущей директории, б) _/_e_t_c, в) _/_u_s_r_/_l_o_c_a_l_/_e_t_c. Путь к файлу конфигурации также может быть указан в командной строке (см. раздел ООППЦЦИИИИ). Параметры конфигурации подробно описаны в разделе ККООННФФИИГГУУРРААЦЦИИЯЯ данной страницы. ggxxwwss пересчитывает файл конфигурации после получения SIGHUP. ggxxwwss делает ротацию лога при получении SIGUSR1. ООППЦЦИИИИ ggxxwwss обрабатывает следующие (необязательные) параметры: --CC,, ----ccoonnffiigg _p_a_t_h путь к файлу конфигурации. --ll,, ----llooggffiillee _p_a_t_h путь к логу приложения. Не забывайте о правах доступа к директории для логов для пользователя, установленного параметром --runas (см. ниже). --pp,, ----ppiiddffiillee _p_a_t_h путь к pid-файлу. --uu,, ----rruunnaass _u_s_e_r_n_a_m_e пользователь, под которым будет работать процесс, будучи запущен как "демон". По умолчанию, в режиме "демона" процесс работает как _r_o_o_t. NNBB: рекомендуется ииззббееггааттьь работы модулей под _r_o_o_t. --TT,, ----tteerrmm запуск в рамках терминала (т.е. ннее "демона"). Данный режим подразумевается по умолчанию, когда приложение запускается из-под непривилегированного пользователя. Опция -T может быть задействована, когда приложение нужно запустить из-под _r_o_o_t_P_, ННЕЕ _п_е_р_е_в_о_д_я _е_г_о _в _р_е_ж_и_м _"_д_е_м_о_н_а_"_; _н_а_п_р_и_м_е_р_, _в _ц_е_л_я_х _о_т_л_а_д_к_и_. --VV,, ----vveerrssiioonn вывести версию приложения и закончить работу. --vv,, ----vveerrbboossee установить уровень детализации логов. Данная опция может быть повторена многократно. Каждое дополнительное использование повышает уровень (с изначального 0 = normal) на единицу. --qq,,----qquuiieett не выводить сообщения на терминал. Данная опция запрещает вывод сообщений на STDOUT, STDERR. Если она не указана, то при запуске приложения из-под непривилегированного режима, модуль ппррооддууббллииррууеетт диагностические сообщения, посылаемые в лог приложения, в поток стандартного вывода. --kk,,----oollddmmccaasstt использовать старый API для мультикаста. По умолчанию, ggxxwwss использует новый, протоколо-независимый API, однако на старых ОС может быть оправдано применение старого API, как более стабильного. --UU,,----uunnaauutthh Отменить авторизацию (если включена в конфигурации). Данная опция позволяет оперативно отменить авторизацию, не внося изменений в конфигурацию. --hh,, ----hheellpp,, --??,, ----ooppttiioonnss вывести краткое руководство по вызову из командной строки. --KK,, ----ssyysskkeeyy сгенерировать системный ключ (для использования в лицензии) и закончить работу. ППООЛЛЬЬЗЗООВВААТТЕЕЛЛЬЬССККИИЕЕ ЗЗААППРРООССЫЫ ggxxwwss(1) поддерживает два способа передачи потоков: линейный (HTTP) и сегментированный (HLS), и определяет форматы запросов для каждой из этих категорий. ЛЛииннееййнныыее ппооттооккии Форматы запроса линейных потоков таковы: a) _h_t_t_p_:_/_/_{_a_d_d_r_}_:_{_g_x_w_s___p_o_r_t_}_/_{_c_m_d_}_/_{_m_c_a_s_t_-_a_d_d_r_}_:_{_m_c_a_s_t_-_p_o_r_t_} _W_H_E_R_E {addr}:{gxws_port} ::= IPv4/6 адрес порт, слушающий запросы; {cmd} ::= udp; {mcast-addr}:{mcast-port} ::= IPv4/6 адрес мультикаст-группы; NNBB:: IPv6 адреса всегда обозначаются в формате [{addr}]:port, например: [ff18::1]:5056. В данном запросе (формата, принятого в uuddppxxyy) источником обозначается мультикаст-группа, а получателем - HTTP соединение, по которому пришёл запрос. b) _h_t_t_p_:_/_/_{_a_d_d_r_}_:_{_g_x_w_s___p_o_r_t_}_/_s_r_c_/_{_c_h_a_n_n_e_l_-_u_r_i_}_/_d_s_t_/_{_c_l_i_e_n_t_-_u_r_i_} _W_H_E_R_E {addr}:{gxws_port} ::= IPv4/6 адрес порт, слушающий запросы; {channel-uri} ::= URI канала (см. формат ниже); {client-uri} ::= URI for the client (см. формат ниже); URI формат: {protocol}://{path}?{query} c) _h_t_t_p_:_/_/_{_a_d_d_r_}_:_{_g_x_w_s___p_o_r_t_}_/_$_{_a_l_i_a_s_} Данный тип запроса использует _п_с_е_в_д_о_н_и_м _к_а_н_а_л_а: имя, начинающееся со знака доллара. Внутри модуля псевдоним транслирующееся в URI канала. Страница cchhaannnneellss..ccoonnff(5) содержит подробную информацию о работе с псевдонимами. Поддерживаются протоколы: _F_I_L_E, _T_C_P, _U_D_P, _H_T_T_P. Ниже приведено несколько примеров использования различных протоколов и форматов: a) _h_t_t_p_:_/_/_a_c_m_e_._c_o_m_:_8_0_8_0_/_s_r_c_/_f_i_l_e_:_/_/_/_o_p_t_/_d_a_t_a_/_s_o_m_e_‐ _f_i_l_e_._d_a_t_/_d_s_t_/_?_a_=_b_b_&_c_=_d_d ggxxwwss(1) слушает на порту 8080 по адресу acme.com. Каналом является файл _/_o_p_t_/_d_a_t_a_/_s_o_m_e_f_i_l_e_._d_a_t. В запросе есть дополнительные параметры ´a=bb&c=dd', не рассматриваемые логикой модуля. Клиент (dst) не указан, что по умолчанию означает, что им является соединение данного HTTP запроса. Содержимое файла _/_o_p_t_/_d_a_t_a_/_s_o_m_e_f_i_l_e_._d_a_t будет отправлено клиенту; дойдя до конца файла, приложение "подождёт" (в неблокирующем режиме) прибавления размера файла и, если файл увеличится в размере, пошлёт недостающую часть клиенту. Если же файл не увеличится в течение определённого (конфигурацией) времени, канал будет считаться закрытым. b) _h_t_t_p_:_/_/_a_c_m_e_._c_o_m_:_8_0_8_0_/_s_r_c_/_u_d_p_:_/_/_[_f_f_1_8_:_:_1_]_:_5_0_5_6_/_d_s_t_/_f_i_l_e_:_/_/_/_o_p_t_/_d_a_t_a_/_s_o_m_e_‐ _f_i_l_e_._d_a_t Каналом являктся мультикаст-группа по (IPv6) адресу ff18::1, порт 5056. Клиентом является файл _/_o_p_t_/_d_a_t_a_/_s_o_m_e_f_i_l_e_._d_a_t. "Движок" будет последовательно писать данные, поступающие из канала (мультикаст-группы) в поименованный файл. Канал может выйти в тайм-аут, если новые данные не появятся в канале за определённое время; в этом случае сессия будет закрыта. В случае ошибки при записи в файл, сессия так же будет прекращена. c) _h_t_t_p_:_/_/_a_c_m_e_._c_o_m_:_8_0_8_0_/_s_r_c_/_u_d_p_:_/_/_[_f_f_1_8_:_:_1_]_:_5_0_5_6_/_d_s_t_/ d) _h_t_t_p_:_/_/_a_c_m_e_._c_o_m_:_8_0_8_0_/_u_d_p_/_[_f_f_1_8_:_1_]_:_5_0_5_6 Два вышеуказанных запроса эквивалентны по действию (но указаны в различных форматах). Оба указывают мультикаст-группу [ff18::1]:5056 в качестве источника и (запрашивающее) HTTP соединение в качестве клиента. Тайм-аут или же разрыв может случиться на любом из этих двух сетевых соединений, что повлечёт за собой прекращение сессии. e) _h_t_t_p_:_/_/_a_c_m_e_._c_o_m_:_8_0_8_0_/_s_r_c_/_h_t_t_p_:_/_/_1_0_._0_._1_._1_2_:_4_0_5_6_/_u_d_p_/_2_2_4_._0_._2_._2_6_:_4_0_3_3_?_k_k_=_y_y_/_d_s_t_/_t_c_p_:_/_/_1_9_2_._1_6_8_._1_2_._1_0_:_5_0_5_1_?_m_m_=_f_f подразумевыет, что данные канала идут в ответ на HTTP запрос GET /udp/224.0.2.26:4033?kk=yy, посланный по адресу http://10.0.1.12:4056. Какое бы приложение на находилось по данному адресу, ожидается, что на данный запрос оно ответит потоком данных, направляемым, в свою очередь, согласно запросу, в TCP сокет соединения с адресом 192.168.12.10:5051. У сессии также есть ассоциированный подзапрос: ´mm=ff´, способный нести дополнительную информацию в контексте данной сессии. Данный запрос подчёркивает способность GigA+ работать со "вложенными" запросами и, следовательно, составлять "цепочки" приложений, работающих с одним из двух форматов запроса ('udp-channel' и пара 'src-dst'). Таким образом, к примеру, может быть построена цепочка: udpxy -> GigA+ -> udpxy -> media player. f) _h_t_t_p_:_/_/_a_c_m_e_._c_o_m_:_8_0_8_0_/_$_T_V_9 запрашивает канал _T_V_9 по псевдониму в качестве источника, клиентом является запрашивающее соединение. g) _h_t_t_p_:_/_/_a_c_m_e_._c_o_m_:_8_0_8_0_/_s_r_c_/_$_T_V_9_?_k_e_y_=_B_F_0_9_4_7_4_4_c_5_/_d_s_t запрашивает канал по тому же псевдониму в формате src-dst и передаёт дополнительный параметр _k_e_y в URL псевдонима. Более подробная информация о каналах по псевдонимам содержится на странице cchhaannnneellss..ccoonnff(5) документации. ЗЗааппррооссыы ннаа HHLLSS--ппооттооккии Подразделяются на два типа (по типу возвращаемых данных): a) _П_л_е_й_л_и_с_т_ы - запрос возвращает клиентам мета-данные по сегментам и способам их проигрывания. Формат запросов на (M3U8) плейлисты приведён ниже: _h_t_t_p_:_/_/_{_a_d_d_r_}_:_{_p_o_r_t_}_/_h_l_s_-_m_3_u_/_$_{_c_h_a_n_‐ _n_e_l_-_t_a_g_}_/_p_l_a_y_l_i_s_t_._m_3_u_8_[_?_u_t_i_m_e_=_{_u_n_i_x_-_t_i_m_e_}_] _Г_Д_Е: hhllss--mm33uu - символьный идентификатор типа запроса; _c_h_a_n_n_e_l_-_t_a_g - символьный идентификатор канала (ннее ппууттааййттее с псевдонимом из _c_h_a_n_n_e_l_s_._c_o_n_f); _u_n_i_x_-_t_i_m_e (необязательный) временной маркер (UNIX timestamp) начала передачи (в режиме DDVVRR). Пример (LIVE): http://acme.tv:5046/hls-m3u/tv5monde/playlist.m3u8 Пример (DVR): http://acme.tv:5046/hls- m3u/tv5monde/playlist.m3u8?utime=1499069128 В режиме _D_V_R требуется временной маркер (UNIX time). Если данные за обозначенный маркером период времени присутствуют в хранилище, передача начнётся с указанного момента (с некоторым приближением). b) Запросы _с_е_г_м_е_н_т_о_в возвращают клиентам сами сегменты данных. Для того, чтобы запросы сегментов были обработаны ggxxwwss, модуль ggxxppmm((11)) должен быть настроен так, чтобы URL сегментов включали соответствующий адрес (ggxxwwss). Формат URL запросов: _h_t_t_p_:_/_/_{_a_d_d_r_}_:_{_p_o_r_t_}_/_h_l_s_-_f_r_a_/_$_{_c_h_a_n_n_e_l_-_p_a_t_h_}_/_{_a_n_y_n_a_m_e_}_._t_s _Г_Д_Е: hhllss--ffrraa - символьный идентификатор типа запроса; _c_h_a_n_n_e_l_-_p_a_t_h - относительный путь к директории канала от _h_l_s_._d_a_t_a___r_o_o_t (см. раздел ККООННФФИИГГУУРРААЦЦИИЯЯ); _a_n_y_n_a_m_e - имя файла (без обязательного расширения .ts), которое может быть произвольным именем, совместимым с правилами наиманования файлов в данной ОС. Пример: http://acme.tv:5046/hls-fra/vol3/2017-07-03/60706956.ts Просьба учесть, что структура пути _c_h_a_n_n_e_l_-_p_a_t_h сильно зависит от установок _с_п_е_ц_и_ф_и_к_а_ц_и_и _к_а_н_а_л_а модуля vvssmm(1) и установок для модуля ggxxppmm(1) Получив _з_а_п_р_о_с _с_е_г_м_е_н_т_а, ggxxwwss разбирает его, производит некоторые проверки (существует ли, к примеру, запрашиваемый файл), а затем передаёт запрос одному из подконтрольных процессов _g_x_n_g, используя для выбора процесса тот же метод балансировки, что был бы задействован для иных запросов. ggxxnngg передаёт содержимое файла клиенту по изначальному сетевому соединению (переданному от ggxxwwss). NNBB: заметьте, что канал может быть также сконфигурирован для доставки сегментов сторонним веб-сервером. В этом случае, ggxxwwss не получает запросы сегментов для данного канала (запросы идут сразу на сторонний веб-сервер). ППееррееннааппррааввллееннииее HHTTTTPP ззааппррооссоовв Клиент может быть перенаправлен на иной источник, если запрашиваемый канал в данное время недоступен. ggxxwwss ответит в таком случае кодом HHTTTTPP 330022 (Moved Temporarily), предполагая, что ПО клиента распознает код и перенаправит запрос по указанному адресу. ggxxwwss производит _п_р_о_с_т_е_й_ш_и_е проверки с целью убедиться, что перенаправление не образует замкнутый цикл, но в целом ответственность за предотвращение появления подобных циклов лежит на клиенте. ППооддддеерржжккаа HHTTTTPP HHEEAADD Запросы HTTP HEAD могут быть использованы для проверки доступа к каналам. ggxxwwss обрабатывает HTTP HEAD таким же образом, как и GET, за исключением того, что запрос не возвращает никаких данных; также не будет запрос передан и процессу ggxxnngg. Перенаправление, тем не менее, будет применено в соответствующем сценарии. ААДДММИИННИИССТТРРААТТИИВВННЫЫЕЕ ЗЗААППРРООССЫЫ ggxxwwss(1) принимает административные запросы на выделенных TCP портах. Типы запросов приведены ниже. TTPPSS rreeppoorrttss TPS (traffic, tps) - пропускная статистика по активным каналам и клиентам. Формат запросов следующий: _h_t_t_p_:_/_/_{_a_d_d_r_}_:_{_p_o_r_t_}_/_r_e_p_o_r_t_?_t_y_p_e_=_{_t_y_p_e_}_&_f_o_r_m_a_t_=_{_f_o_r_m_a_t_}_&_c_a_c_h_e_d_=_{_0_|_1_} _Г_Д_Е_: {type} ::= traffic|tps {format} ::= html|web|xml Форматы вывода: HTML (html, web) - HTML/web страница. XML (xml) - XML страница. По умолчанию принимается формат _h_t_m_l. ВВннииммааннииее:: сбор пропускной статистики должен быть включен в конфигурации (ggxxwwss и ggxxnngg)).. Пример: http://acme.tv:4047/report?type=tps ККеешшииррооввааннииее ооттччёёттоовв ggxxwwss(1) может сохранять в кеше отчёты в течение определённого времени, определяемого в конфигурации как wwss..rreeppoorrtt..ccaacchhee__ttiimmeeoouutt__mmss. Запрос может игнорировать сохранённые данные, указав параметр _c_a_c_h_e_d_=_0 в URL. ВВннииммааннииее:: использование данного параметра целесообразно, лишь если непременно требуется доставка самых актуальных данных. В остальных случаях использование кеша имеет больший смысл, поскольку способно снизить нагрузку на ЦП при серии запросов одного рода в течение небольшого промежутка времени. Пример: http://acme.tv:4047/report?type=tps&format=xml&cached=1 ССббрроосс ккааннааллаа//ккллииееннттаа ((ddrroopp)) осуществляется по запросу следующего формата: _h_t_t_p_:_/_/_{_a_d_d_r_}_:_{_p_o_r_t_}_/_d_r_o_p_?_c_h_a_n_n_e_l_=_{_c_h_a_n_n_e_l___t_a_g_}_&_c_l_i_e_n_t_=_{_c_l_i_e_n_t___t_a_g_} _Г_Д_Е_: {channel_tag} - уникальный идентификатор (тэг) канала; {client_tag} - уникальный идентификатор (тэг) клиента (данного канала). ВВннииммааннииее: если параметр cclliieenntt отсутствует, то ккааннаалл={channel_tag} со ввссееммии ккллииееннттааммии будет отключен. И канал, и клиент должны быть указаны в том же формате, что и в TPS отчёте. Например, для мультикаст-канала, обозначенного как UDP://224.0.12.15:7010 (заметьте, что дополнительные параметры URL, такие как ключи авторизации, ннее входят в идентификатор) и клиента, обозначенного как TCP://192.168.10.15:50905, запрос к ggxxwwss (слушающем на 127.0.0.1:4047) будет выглядеть так: _h_t_t_p_:_/_/_1_2_7_._0_._0_._1_:_4_0_4_7_/_d_r_o_p_?_c_h_a_n_‐ _n_e_l_=_U_D_P_:_/_/_2_2_4_._0_._2_._1_5_:_7_0_1_0_&_c_l_i_e_n_t_=_T_C_P_:_/_/_1_9_2_._1_6_8_._1_0_._1_5_:_5_0_9_0_5. Данный запрос отключит ("сбросит") ттооллььккоо ккллииееннттаа, оставив канал в рабочем состоянии. В то же время, запрос _h_t_t_p_:_/_/_1_2_7_._0_._0_._1_:_4_0_4_7_/_d_r_o_p_?_c_h_a_n_n_e_l_=_U_D_P_:_/_/_2_2_4_._0_._2_._1_5_:_7_0_1_0 "сбросит" (отсоединит) ввссеехх ккллииееннттоовв канала и отключит входной поток самого канала. При получении запроса "сбросить" клиента, ggxxwwss прежде всего отыскивает информацию о канале (а не клиенте) и переправляет запрос на соответствующий процесс ggxxnngg. В обязанности ggxxwwss НЕ входит выполнение запроса (поскольку "сброс" выполняет ggxxnngg)),, ппооээттооммуу ggxxwwss ооттввееччааеетт ккооддоомм ууссппееххаа ((HHTTTTPP 220000)),, ккаакк ттооллььккоо ооттппррааввлляяеетт ддаанннныыйй ззааппрроосс ggxxnngg.. ЕЕссллии ggxxnngg ннее ннааййддёётт ннуужжннооггоо ккллииееннттаа,, оошшииббккаа ннее ссттааннеетт уужжее ииззввеессттннаа ддррууггоойй ссттооррооннее.. ЕЕссллии ззааппрроосс ббууддеетт ууссппеешшнноо ввыыппооллннеенн,, ттоо ggxxnngg ооттррааппооррттууеетт оо ""ссббррооссее"" ккллииееннттаа ggxxwwss,, ччттоо ннааййддёётт ооттрраажжееннииее вв _л_о_г_е _д_о_с_т_у_п_а ((aacccceessss lloogg)).. ССмм.. ссееккццииюю ККООННФФИИГГУУРРААЦЦИИЯЯ для дополнительной информации по логам ggxxwwss. PPiinngg//ssttaattuuss данный запрос устанавливает, находится ли получивший его процесс ggxxwwss в рабочем состоянии. Формат: _h_t_t_p_:_/_/_{_a_d_d_r_}_:_{_p_o_r_t_}_/_p_i_n_g или _h_t_t_p_:_/_/_{_a_d_d_r_}_:_{_p_o_r_t_}_/_s_t_a_t_u_s; Ключевое слово ssttaattuuss поддерживается лишь для (условной) совместимости с командой _s_t_a_t_u_s от uuddppxxyy, НЕ эквивалентной (для udpxy) команде _p_i_n_g. Тем не менее, поскольку пользователи uuddppxxyy использовали команду _s_t_a_t_u_s для проверки рабочего состояния сервиса, команда поддерживается (именно в данном качестве) в рамках ggxxwwss, который отправляет в ответ HTTP 200. ООттссооееддииннииттьь ввссеехх ((rreesseett)) отсоединяет все каналы и их клиентов. Формат: _h_t_t_p_:_/_/_{_a_d_d_r_}_:_{_p_o_r_t_}_/_r_e_s_e_t. При получении данной команды ggxxwwss посылает всем контролируемым процессам ggxxnngg сигнал SIGUSR2. Сигнал воспринимается ggxxnngg как требование отсоединить всех клиентов и закрыть все каналы. ААВВТТООРРИИЗЗААЦЦИИЯЯ GigA+ использует _п_р_и_л_о_ж_е_н_и_я_-_п_о_м_о_щ_н_и_к_и авторизации (сторонние компоненты, предоставленные пользователем или интегратором ПО). "Помощники" состыкованы с ggxxwwss(1) как дочерние процессы, через SSTTDDIINN и SSTTDDOOUUTT. При включенной (в конфигурации) авторизации, каждый пользовательский запрос (к ggxxwwss) порождает запрос на авторизацию, посылаемый одному из процессов-помощников. Пример (простейшего) скрипта для помощникa авторизации находится в //uussrr//sshhaarree//ggiiggaapplluuss//ssccrriippttss//ggaauutthh..sshh Запрос на авторизацию имеет вид текстовой строки, завершённой последовательностью _C_R_L_F. Пример (для протокола A): AA33440044 110044..1122..3333..6677::1122330011 uuddpp::////222244..00..22..1122::55001111??aauutthh==eeff003311220044bbaa00cc -- Поскольку нет гарантии, что процесс-помощник не "зависнет" в процессе выполнения запроса, все запросы подвержены тайм-ауту (согласно параметрам конфигурации, см. секцию ниже). Если запрос выходит в тай-аут на авторизации, процессу-помощнику отправляется сигнал прекратить работу. Уделите внимание выбору сбалансированного значения для тайм-аута пользовательских запросов, с тем, чтобы запросы могли быть завершены естественным образом, не выходя в тайм-аут. Также, убедитесь, что ggxxwwss запускает достаточное количество помощников для обслуживания текущего объёма запросов. ggxxwwss предупреждает о наличии "медленных" помощников при каждом тайм-ауте, последовательность подобных предупреждений может сигнализировать о неадекватности параметров конфигурации. Более подробно протокол авторизации и расширенная информация по данной теме представлены на странице ggxxwwss..aauutthh(5) документации. ККООННФФИИГГУУРРААЦЦИИЯЯ ggxxwwss(1) считывает конфигурацию из файла, по умолчанию, gxws.conf или gigaplus.conf. После прочтения и проверки конфигурации, модуль применяет к ней параметры, переданные из командной строки. После того, как все параметры считаны ggxxwwss, модуль использует данную конфигурацию до тех пор, пока не перезагрузит конфигурационный файл в ответ на сигнал SSIIGGHHUUPP. У всех параметров конфигурации данного приложения есть префикс: 'wwss..'. Так, к примеру, параметр _A должен полностью именоваться как _w_s_._A. Параметры конфигурации перечислены ниже. Значение параметра по умолчанию даётся в квадратных скобках. Параметры без значения по умолчанию являются обязательными. lloogg..** Установки для лог-файлов: level_default = err| crit| warn| norm| info| debug [info] устанавливает детализацию лога ввссееггоо приложения. ffiillee полный путь к лог-файлу. lleevveell уровень детализации лога: _c_r_i_t_|_e_r_r_|_n_o_r_m_|_w_a_r_n_|_i_n_f_o_|_d_e_b_u_g mmaaxx__ssiizzee__mmbb == _N максимальный размер лог-файла в MB (1MB = 1048576). Каждый раз, когда размер лога превышает данную величину, файл переименовывается в архив, а приложение начинает новый лог. mmaaxx__ffiilleess == _n максимальное количество файлов перед ротацией. Каждый раз, когда количество архивных логов превышает данное значение, самый старый архив стирается. ttiimmee__ffoorrmmaatt == llooccaall|| ggmmtt|| rraaww|| rraaww__mmoonnoo|| nnoo__ttiimmee|| [[llooccaall]] устанавливает формат таймстэмпа в записях лога, _Г_Д_Е: _l_o_c_a_l = местное время в формате YYYY-MM-DD HH24:MI TZ; _g_m_t = GMT время в том же формате, что и local; _r_a_w = UNIX время в формате: seconds.nanoseconds; _f_B_r_a_w___m_o_n_o = raw для таймера monotonic (не соотносится с часовым временем); _n_o___t_i_m_e = не показывать время в логе. sshhooww__ppiidd == _t_r_u_e_|_f_a_l_s_e [[ttrruuee]] показывать PID в каждой строчке лога. eennaabbllee__ssyysslloogg == _t_r_u_e_|_f_a_l_s_e [[ttrruuee]] писать ошибки, предупреждения и критические сообщения в sys‐ log(2). eeoodd__rroottaattee == ttrruuee||ffaallssee [[ffaallssee]] Осуществлять ротацию лога в конце (кажлого) дня. Т.е. начинать новый лог в начале каждого нового дня. nngg..** данная секция определяет параметры обмена данными между ggxxwwss(1) и ggxxnngg(1) nngg..ssoocckkeett__ppaatthh == _p_a_t_h [[//vvaarr//rruunn//ggppxx--nnggccoommmm..ssoocckkeett]] путь к доменному (UNIX) сокету для коммуникаций между ggxxwwss и _п_р_и_п_и_с_а_н_н_ы_м_и к нему процессами ggxxnngg. nngg..ffoorrccee__sshhuuttddoowwnn == ttrruuee || ffaallssee [[ttrruuee]] если установлен в ttrruuee, ggxxwwss по окончании работы попытается закрыть (kill -SIGTERM) все приписанные процессы ggxxnngg. nngg..ppiicckk__mmeetthhoodd == _m_e_t_h_o_d [[rroouunndd--rroobbiinn]] метод выбора ggxxnngg, один из перечисленных ниже: rroouunndd--rroobbiinn - (метод перебора) следующий движок (gxng) по списку; mmiinn--cchhaannnneellss - выбрать движок с наименьшим количеством каналов; mmiinn--cclliieennttss - выбрать движок с наименьшим количеством клиентов. nngg..aacccceepptt__mmiinn__aattttaacchheedd == _n_u_m [[11]] количество движков, которые должны быть приписаны к данному ggxxwwss прежде, чем он начнёт принимать пользовательские запросы. sspplliitt__cchhaannnneellss == ttrruuee || ffaallssee [[ffaallssee]] если установлен в true, ggxxwwss выбирает ggxxnngg для каждого нового клиента, используя _n_g_._p_i_c_k___m_e_t_h_o_d. Это позволяет распределять клиентов канала по нескольким движкам (и соответственно, ЦП или ядрам). По умолчанию же (false), если первый клиент канала определяет, на какой движок пойдёт данный канал и все последующие его клиенты. aacccceessss__lloogg..** последующие установки применяются к логу доступа (access log) ggxxwwss, цель которого - фиксировать основные события работы с каналами и клиентами. Лог доступа дополняется каждый раз, когда открывается или закрывается новый поток. Записи имеют следующий формат: OOPPEENN__CCHHAANNNNEELL _c_h_a_n_n_e_l___a_d_d_r_e_s_s открыто соединение к данному каналу. Данные начинают идти из канала (указанного адресом) во внутреннее хранилище (кеш) и затем клиентам данного канала CCLLOOSSEE__CCHHAANNNNEELL _c_h_a_n_n_e_l___a_d_d_r_e_s_s _n_u_m___u_s_e_r_s ggxxwwss фиксирует закрытие канала (_c_h_a_n_n_e_l___a_d_d_r_e_s_s_, _в _м_о_м_е_н_т _з_а_к_р_ы_т_и_я _у _к_о_т_о_р_о_г_о _о_с_т_а_в_а_л_о_с_ь _n_u_m___u_s_e_r_s _п_о_д_п_и_с_ч_и_к_о_в_. OOPPEENN__CCLLIIEENNTT _c_l_i_e_n_t___a_d_d_r_e_s_s _c_h_a_n_n_e_l___a_d_d_r_e_s_s клиент по адресу _c_l_i_e_n_t___a_d_d_r_e_s_s успешно подписался на канал _c_h_a_n_‐ _n_e_l___a_d_d_r_e_s_s. Данная запись вносится в лог ещё ДО начала поступления данных канала клиенту посредством ggxxnngg. CCLLOOSSEE__CCLLIIEENNTT _c_l_i_e_n_t___a_d_d_r_e_s_s _c_h_a_n_n_e_l___a_d_d_r_e_s_s _n_u_m___u_s_e_r_s _u_p_t_i_m_e _n_b_y_t_e_s _n_p_k_t_s окончание клиентской сессии; параметры статистики: _n_u_m___u_s_e_r_s = оставшееся количество подписчиков на канал; _u_p_t_i_m_e = время работы в формате sseeccoonnddss..nnaannoosseeccoonnddss; _n_b_y_t_e_s = переданное количество байт; _n_p_k_t_s = количество переданных фрагментов данных. NNGG__AATTTTAACCHH//DDEETTAACCHH//QQUUIITT _p_i_d _i_n_d_e_x _f_d присоединение или отсоединение движка ggxxnngg(1) к ggxxwwss(1). В параметрах: pid процесса _g_x_n_g, _i_n_d_e_x = внутренний индекс движка и _f_d = дескриптор соединения ggxxwwss с движком. NNGG__QQUUIITT означает, что ggxxnngg ввооззммоожжнноо,, ннее ооппооввеессттиилл ggxxwwss ообб ооттссооееддииннееннииии ссооооббщщееннииеемм CCLLOOSSEE__xxxx ддоо ооккооннччаанниияя ррааббооттыы.. AAUUTTHH__SSTTAARRTT//EEXXIITT _p_i_d процесс-помощник авторизации стартовал/закончил работу. _p_i_d для процесса-помощника. aacccceessss__lloogg..ffiillee == _p_a_t_h полный путь к логу доступа. aacccceessss__lloogg..mmaaxx__ssiizzee__mmbb == _n_u_m [[1166]] максимальный размер лога в мегабайтах. При превышении размера осуществляется ротация лога. aacccceessss__lloogg..mmaaxx__ffiilleess == _n_u_m [[1166]] максимальное количество логов в ротации. При превышении лимита, после очередной ротации стирается самый старый из логов. aacccceessss__lloogg..ttiimmee__ffoorrmmaatt == llooccaall|| ggmmtt|| rraaww|| rraaww__mmoonnoo|| nnoo__ttiimmee|| [[llooccaall]] формат для тайм-стэмпа в записях лога. См. _l_o_g_._t_i_m_e___f_o_r_m_a_t. aacccceessss__lloogg..sshhooww__ppiidd == _t_r_u_e_|_f_a_l_s_e [[ttrruuee]] добавлять поле с PID в каждую запись. cchhaannnneell__ggrroouuppss == _p_a_t_h [[]] полный путь к файлу конфигурации псевдонимных каналов (если указан). Если путь не указан, не определять псевдонимы каналов. Подробности на странице cchhaannnneellss..ccoonnff(5) документации. cchhaannnneell__ggrroouupp__rreeffrreesshh == uumm [[00]] проверять каждые N секунд, изменился ли файл конфигурации псевдонимов. Если изменился, то считать заново и переопределить соответствующие параметры. lliisstteenneerr..** Установки данной секции применяются к слушающим портам [вплоть до 16] на каждом из двух типов запросов (пользовательские, административные), обрабатываемых данным приложением. Пример конфигурации со многими портами можно найти в файле _g_i_g_a_p_l_u_s_-_c_o_m_m_e_n_t_e_d_._c_o_n_f. lliisstteenneerr..**..aalliiaass == _u_n_i_q_u_e_-_a_l_i_a_s [[{{iiffcc}}::{{ppoorrtt}}]] уникальный строковый идентификатор данного слушающего порта. По умолчанию заполняется именем сетевого интерфейса и номером порта, разделёнными двоеточием. Напирмер, слушающий порт 3030 на интерфейсе eth0 будет обозначен по умолчанию как eth0:3030. lliisstteenneerr..**..iiffcc == _i_n_t_e_r_f_a_c_e [[aannyy]] aannyy или aallll, то интерфейсы (или один интерфейс) будут выбраны ОС. lliisstteenneerr..**..ppoorrtt == _n_u_m_b_e_r номер слушающего порта. lliisstteenneerr..**..ddeeffaauulltt__aaff == iinneett || iinneett66 [[iinneett]] протокол (семейство) интерфейса, выбираемый по умолчанию в том случае, когда семейство не может быть определено однозначным образом. Например, если сетевой интерфейс eth0 определён и для IPv4, и для IPv6, то данный параметр разъясняет, какой из адресов интерфейса должен быть использован. lliisstteenneerr..**..iiss__ssaaffee == _t_r_u_e_|_f_a_l_s_e [[ffaallssee]] пропускать авторизацию запросов, поступивших с данного интерфейса. ppiiddffiillee..ddiirreeccttoorryy == _d_i_r_n_a_m_e [[//vvaarr//rruunn//ggiiggaapplluuss]] директория для pid-файла (куда должна быть разрешена запись _r_u_n___a_s___u_s_e_r). ppiiddffiillee..nnaammee == _f_i_l_e_n_a_m_e [[ggxxwwss--_{_u_s_e_r___p_o_r_t_}..ppiidd]] имя pid-файла (без директорий), по умолчанию устанавливается в комбинацию имени интерфейса и порта. iiddllee__ccllkk__mmss == _m_i_l_l_i_s_e_c_o_n_d_s [[--11]] время (в милисекундах), через которое приложение прерывается на выполнение промежуточных (idle-time) задач. Этот параметр, по сути, определяет время максимальной паузы в режиме ожодания ввода-вывода. По умолчанию же, приложение будет прерывать ожидание только на поступающие извне события (новое соединение, сигнал, данные в сокете и т.п.). mmaaxx__ssoocckkeettss__ttoo__aacccceepptt == _n_u_m [[112277]] максимальное количество сокетов для вызова aacccceepptt(2) в рамках одной итерации. Модуль попытается принять максимальное количетсво соединений, ограниченное данным пределом. mmuullttiiccaasstt__iiffcc == _n_a_m_e [[aannyy]] мультикаст-интерфейс по умолчанию. rrccvv__llooww__wwaatteerrmmaarrkk == _n_u_m [[1166]] нижний порог данных: сокет не показывает данные, пока в нём не накопится _N байт. rruunn__aass__uusseerr _u_s_e_r_n_a_m_e [[]] пользователь, под которым приложение будет работать, если запущено в режиме "демона". По умолчанию, как root. rruunn__aass__uuiidd == _u_i_d [[--11]] То же, что и _r_u_n___a_s___u_s_e_r, но пользователь обозначается не по имени, а по численному идентификатору (uid). (Имеет приоритет выше, чем _r_u_n___a_s___u_s_e_r). rruunn__aass__ggiidd == _g_i_d [[--11]] переключиться на данную группу (gid), если >=0. nnoonn__ddaaeemmoonn == ttrruuee || ffaallssee [[ffaallssee]] если true, запуск в рамках терминала (т.е. ннее "демона"). Данный режим подразумевается по умолчанию, когда приложение запускается из-под непривилегированного пользователя. ttccpp__nnoo__ddeellaayy == ttrruuee || ffaallssee [[ttrruuee]] устанавливать опцию TCP_NODELAY для каждого принятого соединения. uussee__hhttttpp1100__ggeett == ttrruuee || ffaallssee [[ffaallssee]] использовать протокол HTTP/1.0, отвечая на запросы данных. Это позволяет избежать передачи данных от источника в режиме _c_h_u_n_k_e_d _e_n_c_o_d_‐ _i_n_g. Используемый часто в качестве прокси веб-сервер _n_g_i_n_x, устанавливает режим _c_h_u_n_k_e_d _e_n_c_o_d_i_n_g по умолчанию и может, следовательно, посылать видеопоток в виде HTTP chunks. В настоящее время GGiiggAA++ не поддерживает разбор HTTP chunks в потоках. uusseerr__ppiinngg == ttrruuee || ffaallssee [[ffaallssee]] разрешать использование запросов _p_i_n_g и _s_t_a_t_u_s со стороны пользователя (на соотв. слушающих портах). ВВННИИММААННИИЕЕ: данный параметр обеспечивает частичную совместимость с запросами в uuddppxxyy, где не предусмотрены выделенные порты для административных запросов. ННЕЕ ВВККЛЛЮЮЧЧААЙЙТТЕЕ данный параметр, если на то нет абсолютной потребности. Гораздо безопасней использовать административный интерфейс для подобных запросов. lleeggaaccyy__mmuullttiiccaasstt__aappii == ttrruuee || ffaallssee [[ffaallssee]] использовать старый (протоколо-зависимый) API для мультикаст-подписки. eennffoorrccee__ccoorree__dduummppss == ttrruuee || ffaallssee [[ffaallssee]] при установке в _t_r_u_e, приложение разрешает себе core dumps и устанавливает предельный размер в _u_n_l_i_m_i_t_e_d. При значении _f_a_l_s_e, данные параметры регулируются установками оболочки. ВВННИИММААННИИЕЕ: на отдельных версиях Linux, демоны, переключающиеся на другого пользователя, теряют способность оставлять после себя core dumps (см. //pprroocc//ssyyss//ffss//ssuuiidd__dduummppaabbllee и страницу pprrccttll(2) документации). qquuiieett == ttrruuee || ffaallssee [[ffaallssee]] не выводить ничего в STDOUT/STDERR, если установлено в _t_r_u_e. pprroocceessss__lliimmiittss..** параметры данной секции позволяют установить ограничения на рабочий процесс при помощи системного вызова sseettrrlliimmiitt(2) меры исчисления, таким как _K_b, _M_b или _G_b. Числа могут быть и дробными, т.е. 1.5Kb = 1024 + 512 = 1536 байт. Указанное значение "0" означает, что лимит не будет установлен вовсе и, стало быть, в силе останется установленное pprroocceessss__lliimmiittss..rrssss == {{NN}}{{ssuuffffiixx}} [[""00""]] ограничение по физической памяти процесса: процесс не может привысить данный показатель зарезервированной физической памяти. ВВННИИММААННИИЕЕ: данный лимит не вполне выполняется под ОС Linux, где для него используется RRLLIIMMIITT__AASS (лимит виртуальной памяти). Под ОС FFrreeeeBBSSDD лимит полностью поддерживается. pprroocceessss__lliimmiittss..vvmmeemm == {{NN}}{{ssuuffffiixx}} [[""00""]] ограничение по виртуальной памяти = RRLLIIMMIITT__AASS. Используется вместо лимита по физической памяти (RSS) под ОС Linux. Полностью поддерживается и Linux, и FreeBSD. hhttttpp__rreeaadd__ttiimmeeoouutt__mmss == _m_i_l_l_i_s_e_c_o_n_d_s [[220000]] тайм-аут (в милисекундах) на чтение части HTTP запроса. uusseerr__rreeqquueesstt__ttiimmeeoouutt__mmss == _m_i_l_l_i_s_e_c_o_n_d_s [[550000]] тайм-аут (в милисекундах) на обработку пользовательского запроса. aaddmmiinn__rreeqquueesstt__ttiimmeeoouutt__mmss == _m_i_l_l_i_s_e_c_o_n_d_s [[330000]] тайм-аут (в милисекундах) на обработку административного запроса. mmoodduullee__rreeqquueesstt__ttiimmeeoouutt__mmss == _m_i_l_l_i_s_e_c_o_n_d_s [[110000]] тайм-аут (в милисекундах) на обработку модульного запроса. Модульные запросы - суть запросы между модулями GGiiggAA++, т.е., в данном контексте, между _g_x_w_s и _g_x_n_g. hhttttpp__ddaattaa__ccoonntteenntt__ttyyppee == _t_y_p_e___s_p_e_c_i_f_i_e_r [[aapppplliiccaattiioonn//oocctteett--ssttrreeaamm]] содержимое HTTP заголовка Content-Type для передачи данных (непрерывного потока). cchhaannnneell__ssaammppllee__ttiimmeeoouutt__mmss == _m_i_l_l_i_s_e_c_o_n_d_s [[--11]] если >0, то ggxxwwss будет пытаться считать хоть какое-то количество данных из только что открытого источника, прежде, чем передать запрос одному из движков. ВВННИИММААННИИЕЕ: данное (блокирующее) _о_ж_и_д_а_н_и_е может замедлить работу ggxxwwss из-за задержек ввода-вывода на канале. ИСПОЛЬЗУЙТЕ ОСМОТРИТЕЛЬНО. ttppuutt__ssttaattss..** данная секция содержит параметры, используемые для передачи движками данных по пропускной статистике. Данные эти запрашиваются с помощью административного запроса rreeppoorrtt (см. секцию по админ. запросам). ttppuutt__ssttaattss..eennaabblleedd == ttrruuee || ffaallssee [[ttrruuee]] если не установлен в _t_r_u_e, то статистика не будет приниматься. Просьба заметить, что движки будут расходовать дополнительные ресурсы на сбор и передачу статистики. ttppuutt__ssttaattss..cchhaannnneell__ppaatthh == _p_o_s_i_x___s_h_m_e_m___p_a_t_h [[//ggxxyy--cchhaa..sshhmm]] путь для сегмента разделяемой памяти (POSIX shared memory), используемого при обменом статистикой по каналам (менее 32 символов). ttppuutt__ssttaattss..cclliieenntt__ppaatthh == _p_o_s_i_x___s_h_m_e_m___p_a_t_h [[//ggxxyy--ccllii..sshhmm]] путь для сегмента разделяемой памяти (POSIX shared memory), используемого при обменом статистикой по клиентам (менее 32 символов). ttppuutt__ssttaattss..mmaaxx__cchhaannnneell__rreeccoorrddss == _n_u_m [[225500]] максимальное количество записей, выделенных на статистику по каналам. Должно быть НЕ МЕНЬШЕ, чем максимальное количество одновременно задействованных каналов (на всех движках). ttppuutt__ssttaattss..mmaaxx__cclliieenntt__rreeccoorrddss == _n_u_m [[11000000]] максимальное количество записей, выделенных на статистику по клиентам. Должно быть НЕ МЕНЬШЕ, чем максимальное количество одновременно задействованных клиентов (на всех движках). ttppuutt__ssttaattss..mmaaxx__ssppeeeedd__ddeellttaa == _n_u_m [[88]] максимальная разница (в Кб) между скоростью канала и его клиента. Данный показатель виден в TPS отчётах и будет выделен, если дельта окажется превышенной. rreeppoorrtt..** данная секция определяет параметры, требующиеся для генерации разлмчного вида отчётов. rreeppoorrtt..ddeeffaauulltt..ttyyppee == _n_a_m_e [[ttrraaffffiicc]] тип отчёта по умолчанию (применяется, когда URL не указывает тип). rreeppoorrtt..ddeeffaauulltt..ffoorrmmaatt == _n_a_m_e [[hhttmmll]] формат отчёта по умолчанию (если не указан в URL). rreeppoorrtt..mmeemmoorryy..mmiinn == _b_y_t_e_s [[552244228888]] изначальный размер памяти под размещение отчёта (полный текст отчёта хранится в памяти). rreeppoorrtt..mmeemmoorryy..mmaaxx == _b_y_t_e_s [[1166777777221166]] максимальный размер буфера памяти, выделенного под отчёт. rreeppoorrtt..mmaaxx__sseenndd__aatttteemmppttss == _n_u_m [[1166]] максимальное количество попыток переслать отчёт заказчику, если нельзя переслать весь сразу. rreeppoorrtt..ccaacchhee__ttiimmeeoouutt__mmss == _n_u_m [[550000]] отчёты сохраняются в кеш и выдаются оттуда в течение данного периода времени (в милисекундах) или же НЕ кешируются вовсе, если _n_u_m <= 0 (создаются заново в ответ на каждый запрос). rreeppoorrtt..bbaacckkuupp__ffiillee == _f_i_l_e_p_a_t_h [[]] отчёт дублируется в файл при каждом запросе (файл переписывается заново). ssyynncc..rreegguullaarr__ttiimmeeoouutt__mmss == _m_s [[550000]] через _N ms после "прикрепления" ggxxnngg, синхронизировать (затребовать) статистику по каналам/клиентам данного процесса из TPS кеша (хранилища). Доступно только при включенной статистике TPS (_t_p_u_t___s_t_a_t_s_._e_n_a_b_l_e_d = ttrruuee). ssyynncc..ffoorrcceedd__ttiimmeeoouutt__mmss == _m_s [[1100000000]] пока "присоединён" хотя бы один движок, синхронизировать (брать) статистику по каналам/клиентам каждые N ms. Доступно только при включенной статистике TPS (_t_p_u_t___s_t_a_t_s_._e_n_a_b_l_e_d = ttrruuee). rreeddiirreecctt..eerrrr__cchhaannnneell == _c_h_a_n_n_e_l___U_R_L [[]] перенаправлять клиента на данный URL, если канал оказывается недоступен (по любой причине, кроме внутренней ошибки компонента GigA+). URL должен быть дан полностью, в том виде, в каком он будет передан в составе ответа HTTP 302. rreeddiirreecctt..nnoo__aacccceessss == _c_h_a_n_n_e_l___U_R_L [[]] перенаправлять клиента на данный URL, если канал оказывается недоступен по причине отказа в доступе (процессом-помощником авторизации). URL должен быть дан полностью, в том виде, в каком он будет передан в составе ответа HTTP 302. ppsseennssoorrss..** сенсоры производительности позволяют делать замеры расхода ресурсов процесса между двумя моментами времени, используя метрики системного вызова uuttiimmee(2) нагрузку на отдельных участках программы. Включая какой-либо из сенсоров, следует отдавать себе отчёт, что это повлечёт за собой системный вызов uuttiimmee(2) при каждом замере. Результаты замеров выводятся приложением по окончании работы, в формате, сходном с выводом системной утилиты ttiimmee(1) Сенсоры производительности - инструмент отладки и профилирования. Их использование неизбежно создаёт дополнительную нагрузку приложению и системе в целом. ИСПОЛЬЗУЙТЕ ОСМОТРИТЕЛЬНО. ССппииссоокк ссееннссоорроовв:: aapppp = общая нагрузка; eevv__lloooopp = обработка событий (всех); eevv__rreeaadd = обработка входных данных; eevv__wwrriittee = обработка исходящих данных; eevv__eerrrr = обработка ошибок; eevv__pppp = post-обработка событий; wwss__uusseerrqq = обработка пользовательских запросов; wwss__aaddmmrrqq = обработка административных запросов (отчётов, и т.д.). ppsseennssoorrss..eennaabbllee__aallll == _t_r_u_e_|_f_a_l_s_e [[ffaallssee]] включает все сенсоры сразу, если true, или же выключает, если false. Удобно инициализировать множество сенсоров таким образом в одно из двух положений (ВКЛ/ВЫКЛ). Параметр предназначен для использования в комбинации с ppsseennssoorrss..eexxcceepptt. ppsseennssoorrss..eexxcceepptt == _s_e_n_s_o_r___l_i_s_t [[]] включает перечисленные сенсоры, если _p_s_e_n_s_o_r_s_._e_n_a_b_l_e___a_l_l установлен в ffaallssee, и выключает, если в ttrruuee. Таким образом, данный параметр добавляет или вычитает сенсоры из инициализированного множества. _П_Р_И_М_Е_Р _A_: psensors.enable_all = true; # Включить все сенсоры. psensors.except = ["ev_read", "ev_write"]; # Выключить перечисленные. Включает все сенсоры, кроме _e_v___r_e_a_d and _e_v___w_r_i_t_e. _П_Р_И_М_Е_Р _B_: psensors.enable_all = false; # Выключит все сенсоры. psensors.except = ["ev_read", "ev_write"]; # Включить перечисленные. Включить _e_v___r_e_a_d and _e_v___w_r_i_t_e, остальные выключить. aauutthh..** данная секция содержит параметры, используемые механизмом авторизации запросов, описанном выше, в разделе ААВВТТООРРИИЗЗААЦЦИИЯЯ. aauutthh..eennaabblleedd == _t_r_u_e_|_f_a_l_s_e [[ffaallssee]] авторизовать пользовательские запросы, если true. Пропускать все, если false. aauutthh..hheellppeerr__pprroottooccooll == _"_A_1_P_"_|_"_B_2_P_" [[""AA11PP""]] определяет протокол, по которому сообщаются ggxxwwss и процессы-помощники. Подробности протоколов описаны на странице ggxxwwss..aauutthh(5) документации. aauutthh..bb__ffiieellddss == _f_i_e_l_d_s [[""UUSSDDPP""]] этот параметр специфичен протоколу B2P и определяет, какие поля и в каком порядке будут посылаться помощникам для обработки. "USDP" означает в данном контексте _U_R_L, _S_o_u_r_c_e, _D_e_s_t_i_n_a_t_i_o_n и _P_e_e_r - эти поля будут посылаться (именно в этом порядке) процессам-помощникам. Полный список поддерживаемых полей доступен на странице ggxxaauutthh(5) документации. aauutthh..eexxeecc == _e_x_e_c___p_a_t_h___w_i_t_h___p_a_r_a_m_s [[]] полный путь к исполняемому файлу модуля-помощника авторизации, со всеми параметрами командной строки. ВВННИИММААННИИЕЕ: модуль-помощник запускается под тем же пользователем (и группой), на которую переключился ggxxwwss в начале работы (см. параметры _r_u_n___a_s_*). aauutthh..mmiinn__hheellppeerrss == _c_o_u_n_t [[11]] количество изначально запускаемых (и поддерживаемых в работе) процессов-помощников. aauutthh..mmaaxx__hheellppeerrss == _c_o_u_n_t [[11]] максимально возможное количество запущенных процессов-помощников. aauutthh..ddeennyy__nnoo__aauutthh == _t_r_u_e_|_f_a_l_s_e [[ffaallssee]] если true, то отказывать в авторизации во всех случаях, когда авторизация невозможна (по причине внутренней ошибки или сбоя системы). Значение по умолчанию разрешает доступ в подобной ситуации, чтобы сбой не повлёк за собой массовый отказ в доступе к ресурсам. aauutthh..nnoo__ssppaawwnn__ttmmoouutt == _m_s [[55000000]] длительность паузы, когда запуск помощников запрещён в целях избежать каскадных (циклических) крушений. Если помощник "рушится" практически сразу после запуска, то ggxxwwss вводит своеобразный "мораторий" на дальнейшие попытки запусков в течение означенного периода времени. aauutthh..aauuxx__ppaarraammss == _l_i_s_t___o_f___p_a_r_a_m_s [[]] дополнительные параметры (для AA11PP протокола), передаваемые помощникам. Параметрами могут быть: lliisstteenneerr--aalliiaass = alias for the originating listener aauutthh..ccaann__rreewwrriittee__eennddppooiinnttss == _t_r_u_e_|_f_a_l_s_e [[ffaallssee]] указывает на то, что ggxxwwss, использующий протокол BB22PP, должен быть готов переписать значения полей _S_o_u_r_c_e или _D_e_s_t_i_n_a_t_i_o_n, если это запрашивает процесс-помощник. aauutthh..aallllooww__ccuussttoomm__uurrllss == _t_r_u_e_|_f_a_l_s_e [[ffaallssee]] разрешает использование протоколом BB22PP нестандартных (т.е. несовместимых по формату c шаблонами типа _u_d_p_/_a_d_d_r_e_s_s_:_p_o_r_t и _s_r_c_/_s___u_r_i_/_d_s_t_/_d_s_t___u_r_i_/_f_P_) _U_R_L_. _Д_а_н_н_ы_й _п_а_р_а_м_е_т_р _с_л_е_л_у_е_т _у_с_т_а_н_о_в_и_т_ь _в ttrruuee_, _е_с_л_и _п_о_м_о_щ_н_и_к_и _м_о_г_у_т _п_о_д_м_е_н_я_т_ь _и_з_н_а_ч_а_л_ь_н_ы_е _U_R_L _д_л_я SSoouurrccee//DDeessttii‐‐ nnaattiioonn _н_а _н_е_с_т_а_н_д_а_р_т_н_ы_е_. aauutthh..ccaacchhee..** кеш негативной авторизации хранит запросы с негативным результатом проверки. Подобный кеш позволяет сократить время авторизации при повторных запросах, что позволяет сэкономит ресурсы в такой критической ситуации, как, например атака DDOS. Кеш использует механизм LRU, каждый занесённый URL может храниться там ограниченное время. aauutthh..ccaacchhee..eennaabblleedd == _t_r_u_e_|_f_a_l_s_e [[ffaallssee]] включить кеширование. aauutthh..ccaacchhee..mmaaxx__rreeccoorrddss == _n_u_m [[55000000]] установить максимальное количество элементов кеша. При превышении данного лимита, лишние элементы удаляются по правилам LRU. aauutthh..ccaacchhee..eexxppiirryy__sseecc == _n_u_m [[330000]] максимальное время пребывания элемента в кеше (в секундах). hhllss..** данная секция отвечает за параметры работы с протоколом _H_L_S. hhllss..eennaabblleedd == ttrruuee||ffaallssee [[ffaallssee]] разрешает запросы по HLS, в противном случае все дальнейшие установки секции игнорируются. hhllss..ddaattaa__rroooott == _p_a_t_h [[]] абсолютный путь к корневой директории файлов сегментов данных. ggxxwwss(1) использует этот путь в сочетании с _c_h_a_n_n_e_l_-_p_a_t_h частью запроса на сегменты (т.е. hhllss--ffrraa запросы) чтобы составить полный путь к запрашиваемому файлу сегмента. Например, при запросе http://acme.tv:5046/hls-fra/vol3/2017-07-03/60706956.ts и _h_l_s_._d_a_t_a___r_o_o_t = /opt/data, полный путь к файлу 60706956.ts будет: /opt/data/vol3/2017-07-03/60706956.ts. ggxxwwss затем проверяет наличие доступа к файлу. hhllss..rreeqquueesstt__ttiimmeeoouutt__mmss == _n_u_m [[11000000]] максимальное время обработки HLS запроса. Если на операции ввода-вывода затрачивается больше времени, запрос прерывается. HLS запросы могут потребовать своего тайм-аута, поскольку программная логика для данного типа запросов несколько иная. Проставленное по умолчанию значение считается достаточным, но может быть скорректировано по обстоятельствам (медленная авторизация, и т.п.). Если установить данный параметр в 0, то тайм-аут для HLS не будет отличаться от тайм-аута для запросов линейной доставки (HTTP) и будет равен user_request_timeout_ms. hhllss..mm33uu88__ttmmoouutt__sseecc == _n_u_m [[3300]] время (в секундах), которое ggxxwwss держит в памяти ккааннаалл (мета-данные) HLS плейлиста (M3U8), в отсутствие повторных запросов на данный плейлист. Когда LIVE плейлист запрашивается впервые, логика диктует, что данный плейлист будет запрошен снова, когда будут проиграны все входящие в него сегменты. По этой причине ggxxwwss кеширует мета-данные плейлиста, созданные изначально, _n_u_m секунд, после чего данные стираются (см. комментарии к _h_l_s_._g_p_m___s_o_c_k_e_t.) Если нормальная длительность плейлиста больше, чем проставленное значение, то параметр следует скорректировать (увеличить). hhllss..ffaasstt__uurrqq__lleenn == _N_-_b_y_t_e_s [[00]] количество байт в пользовательском запросе, после которых ggxxwwss должен попытаться обработать полученные данные, даже если запрос не был получен до конца. Некоторые HLS-клиенты (vvllcc - один из них) посылают запросы на HLS-плейлисты (M3U8) небольшими построчными фрагментами, перемежаемыми значительными (>100 ms) паузами (почему они так делают, не вполне ясно, но факт остаётся фактом). Часто самая значимая часть запроса, содержащая затребованный URL, бывает получена изначально, остальные же (не столь важные) части запроса идут вслед. Если дать ggxxwwss дожидаться прохождения запроса целиком (вплоть до завершающей последовательности CRLF,CRLF), обработка займёт слишком много времени. Необходимая же часть запроса доступна практически с самого начала. Данный параметр даёт возможность логике "рискнуть" обработать данные, как только получено как минимум _N байт. В случае работы с vvllcc, по моему опыту, это может сильно ускорить процесс. Тнм не менее, ППООЛЛЬЬЗЗУУЙЙТТЕЕССЬЬ ООССММООТТРРИИТТЕЕЛЛЬЬННОО.. hhllss..ggppmm__ssoocckkeett == _p_a_t_h [[]] полный путь к сокету для обработки пользовательских запросов модуля ggxxppmm(1) Пример: hls.gpm_socket = "/tmp/gpm-Y.sock" ВВННИИММААННИИЕЕ: ggxxwwss(1) запрашивает плейлист у модуля ggxxppmm(1) каждый раз, когда создаёт новый _к_а_н_а_л HLS. Программой создаётся запись о канале, в которой хранится (среди иных данных) полный путь к плейлисту. Данный путь используется в ответах на дальнейшие запросы (на плейлист) по данному каналу. (За содержание плейлиста отвечает модуль ggxxppmm.) ggxxwwss также вносит изменения в _ф_а_й_л _б_л_о_к_и_р_о_в_к_и (см. секцию lid.* в конфигурации ggxxppmm). Изменения в файле блокировки позволяют ggxxppmm распознать, что данный плейлист задействован. hhllss..ssnnoooozzee__hhttttpp1111 == ttrruuee||ffaallssee [[ffaallssee]] оставляет в ожидании клиентское HLS-соединение после успешного выполнения запроса, вместо того, чтобы закрыть. Если параметр установлен в ttrruuee, HTTP/1.1 keep-alive соединения не закрываются со стороны ggxxwwss по окончании запроса, a "засыпают"; приложение в этом случае будет (N секунд) ожидать следующего запроса или же обрыва соединения со стороны клиента. hhllss..ccoonnnn__rreeuussee__sseecc == _N_-_s_e_c [[2200]] максимальное количество секунд ожидания прихода нового запроса на "заснувшее" соединение. hhllss..ffoorrccee__cclloossee == ttrruuee||ffaallssee [[ffaallssee]] закрывать ввссее HTTP/1.1 соединения по окончании запроса, вне зависимости от значения параметра _k_e_e_p_-_a_l_i_v_e. hhllss..ppllaayylliissttss == _с_п_и_с_о_к_-_с_о_о_т_в_е_т_с_т_в_и_й определяет соответствие между именами плей-листов (без расширения .m3u или .m3u8) и временным сдвигом назад для возвращаемого потока. (Внимание: тот же эффект достигается, если указать отрицательный параметр _u_t_i_m_e в URL HLS-запроса на плей-лист.) Каждый элемент списка имеет ровно два поля: ppll__aalliiaass = alias; просто имя файла (без расширения), как указано в URL, ИЛИ _c_h_a_n_n_e_l_:_p_l_a_y_l_i_s_t - т.е. имя канала и имя плей-листа, разделённые двоеточием. В первом случае, соответствие определено для любого канала, во втором - только для указанного. uuttiimmee = seconds; в случае _п_о_л_о_ж_и_т_е_л_ь_н_о_г_о значения - точное время (эпохи UNIX) начала потока указанного канала, в случае, если значение _о_т_р_и_ц_а_т_е_л_ь_н_о_е - смещение во времени назад на указанное количество секунд. Пример: playlists = ( { pl_alias = "g200"; utime = -200; }, { pl_alias = "cable1:c250"; utime = -250; } ); Выше определены два соответствия. Первое, по плей-листу gg220000, применяется ко всем каналам. Таким образом, запрос _h_t_t_p_:_/_/_a_c_m_e_._t_v_:_4_1_4_6_/_h_l_s_-_m_3_u_/_c_i_n_e_m_a_x_/_g_2_0_0_._m_3_u_8 будет интерпретирован ggxxwwss как требование потока канала _c_i_n_e_m_a_x, смещённого во времени на 200 секунд назад. То же правило работает для прочих каналов, указавшик в качестве плей-листа _g_2_0_0_._m_3_u_8. Второе соответствие определяет смещение в 250 секунд, но только для канала _c_a_b_l_e_1. Для других каналов, поток будет отдаваться без смещения. ААВВТТООРРЫЫ Pavel V. Cherenkov ССММООТТРРИИТТЕЕ ТТААККЖЖЕЕ ggiiggaapplluuss(1),ggxxnngg(1),ggxxppmm(1),vvssmm(1),ggxxwwss..aauutthh(5) channels.conf(5) Обзор конфигурации именованных каналов channels.conf(5) ИИММЯЯ channels.conf - файл конфигурации поименованных каналов в GigA+. ООППИИССААННИИЕЕ ggxxwwss(1) использует данную конфигурация для определения каналов, доступ к которым может быть осуществлён не по абсолютному адресу, а по ппссееввддооннииммуу. Псевдоним (alias) представляет из себя имя, начинающееся с символа "доллар" ($). ggxxwwss распознаёт псевдонимы в процессе обработки URL запросов и транслирует их в абсолютные адреса соответствующих каналов. Псевдоним создаёт однозначное соответствие между именем и адресом канала при обработке пользовательских запросов. Пример файла конфигурации псевдонимов поставляется вместе с пакетом и находится в директории _/_u_s_r_/_s_h_a_r_e_/_d_o_c_/_g_i_g_a_p_l_u_s (//uussrr//llooccaall//.... под Free‐ BSD). Секция верхнего уровня конфигурации - cchhaannnneellss, в её рамках определяются каналы. Параметры для определения канала обозначены ниже: aalliiaass псевдоним (начинающийся с символа "доллар") для использования в URL. Данный псевдоним будет транслирован в адрес канала в процессе обработки запроса. uurrllss URL, в который будет транслирован адрес (параметр использует множ. число - urls - по историческим причинам). URL может содержатся в себе другой псевдоним, но он не будет транслирован (может быть транслирован). ППррииммеерр Ниже дан пример конфигурации каналов (также поставляемый в виде файла в пакете инсталляции): channels = ( { alias = "TV5"; urls = ["file:///opt/prog/tv5/channel-down.ts"]; }, { alias = "NightLife"; urls = ["udp://10.0.24.16:5054"]; } ); ААВВТТООРРЫЫ Pavel V. Cherenkov ССММООТТРРИИТТЕЕ ТТААККЖЖЕЕ ggxxwwss(1) gxws.auth(5) gxws.auth (GigA+ authentication) manual page gxws.auth(5) ИИММЯЯ gxws.auth - GigA+ authentication manual. ВВННИИММААННИИЕЕ В настоящее время данная страница ещё не была завершена (переведена). Пожалуйста, примите наши извинения и обратитесь к ааннггллоояяззыыччнноойй версии данной страницы (ниже). ООППИИССААННИИЕЕ ggxxwwss employs _h_e_l_p_e_r_s - custom scripts - to authenticate and authorize incoming user requests. Any application reading from SSTTDDIINN and responding via SSTTDDOOUUTT could serve as a _h_e_l_p_e_r as long as it 'speaks' one of the two communication protocols: AA11PP or BB22PP. This page is dedi‐ cated to giving the insight into _a_u_t_h _h_e_l_p_e_r_s, employed protocols and associated capabilities. CCoommmmoonn ffeeaattuurreess:: Both protocols have things in common. Firstly, they are textual and line-oriented: a message is a text string ending with CCRRLLFF ASCII sequence (single LLFF symbol under Linux and FreeBSD). ggxxwwss writes mes‐ sages/lines to _h_e_l_p_e_r_s via unnamed pipes connecting to the helpers' SSTTDDIINN. Message example: BB1100 PP 113344..1122..1122..5500::55005500 Messages contain _f_i_e_l_d_s, separated by whitespace. An empty (blank) value is always specified as - (dash). Some fields are common for both protocols, the first field is always the same: _S_e_s_s_i_o_n _I_D. SSeessssiioonn--IIDD == AA||BB{{11 .... 22114477448833664477}} [[eexxaammpplleess:: AA110000,, AA11,, BB115500443333]] Identifies the request. The first symbol is _p_r_o_t_o_c_o_l___i_d: 'A' for AA11PP and 'B' for BB22PP. The rest of the field is sseessssiioonn__nnuummbbeerr - non-zero 32-bit unsigned decimal integer; _s_e_s_s_i_o_n _I_D in the incoming message should match the one in the response. RReessuulltt--CCooddee == {{00 .... 22114477448833664477}} [[eexxaammpplleess:: 00,, 11,, 111111]] 32-bit unsigned decimal integer, specifies the result of the evalua‐ tion. Only 00 ((zzeerroo)) code is treated as AAPPPPRROOVVEE response, all others currently signify authorization failure. AA11PP rreeqquueesstt:: A1P uses pre-defined sequence of mandatory and optional fields in each request/response message. The request fields are: _S_e_s_s_i_o_n_-_I_D _P_e_e_r _S_o_u_r_c_e _D_e_s_t_i_n_a_t_i_o_n [_L_i_s_t_e_n_e_r] (the last field is optional and is added only if wwss..aauutthh..aauuxx__ppaarraammss value contains lliisstteenneerr--aalliiaass). A1P request example: AA110022 1100..00..11..1155::3300440033 uuddpp::////222244..00..22..2255::33003300 -- bbbb11 PPeeeerr == aaddddrreessss::ppoorrtt Address/port of the client (that sent the original request to ggxxwwss) SSoouurrccee == cchhaannnneell UURRLL URL of the requested channel, as specified either in uuddpp or ssrrcc section of the request URL. DDeessttiinnaattiioonn == cclliieenntt UURRLL URL for the destination. For most requests, destination is the socket/connection that started the request (i.e. peer), empty value (dash) is used to specify it. LLiisstteenneerr == aalliiaass Alias of the listener that accepted the request. Do mind that when using this option, aalliiaass must be specified for each listener in ggxxwwss..ccoonnff. AA11PP rreessppoonnssee:: A1P response example: AA110022 00 BB22PP pprroottooccooll B2P is an extension of A1P protocol that mainly addresses the iinnfflleexxii‐‐ bbiilliittyy of A1P (fixed number of fields come in and come out). The core features that drove towards creating a new protocol were: a) _c_u_s_t_o_m _U_R_L_s and b) endpoint (source/destination) _r_e_-_w_r_i_t_e _c_a_p_a_b_i_l_i_t_y. B2P accommodates both of these features and provides future expansion of functionality. B2P adds one mmaannddaattoorryy field to _S_e_s_s_i_o_n_-_I_D, the _F_i_e_l_d_- _M_a_s_k. FFiieelldd--MMaasskk == [[aa--zz]][[AA--ZZ]]{{1166}} [[eexxaammppllee:: UUSSDDPP]] Specifies the fields (up to 16) that will follow (in the order they will appear). A single symbol is designated to each of the recognized fields, the mask is, in effect, a sequence of field identifiers. FFiieelldd iiddeennttiiffiieerrss:: UU = Request-URL - the B2P field that holds URL for the HTTP request, the way it was in the header. Example: /udp/224.0.4.56:4504 SS = Source DD = Destination PP = Peer AA = User-Agent LL = Listener rr = Result-Code Field-Mask 'USDP' means that the message, besides the mandatory two fields, must have four fields of the corresponding types. ggxxwwss..ccoonnff provides _w_s_._a_u_t_h_._b___f_i_e_l_d_s setting to specify what information gxws will send to auth helpers with every B2P message. BB22PP rreeqquueesstt:: Example B2P request: BB110022 UUPPLL //uuddpp//222244..00..22..2266::55003344??aauutthh==00xx9933ffbb00aadd 1100..00..33..1144::4400998877 bbbb11 Some fields (rr) don't make much sense in the request and will be rejected by ggxxwwss if specified. BB22PP rreessppoonnssee:: It's up to the helper implementation what set of fields would be returned, but at least one field should be. Absense of RReessuulltt--CCooddee is assumed as AAPPPPRROOVVEE as long as other fields are present in the response. With all the flexibility, only certain fields will be accepted in by ggxxwwss in the response message. RReessppoonnssee--aapppprroovveedd ffiieellddss:: SS = source will be re-written to the returned value DD = destination will be re-written to the returned value rr = APPROVE if 0, DENY otherwise. A typical B2P ddeenniiaall response would be: BB110022 rr 111111 (Don't you worry about 111, any non-zero number would do). CCuussttoomm UURRLLss aanndd ssoouurrccee rree--wwrriittee B2P (and appropriate settings in wwss..aauutthh config section) allows com‐ pletely opaque URLs to be converted to gigapxy-compliant source/desti‐ nation pairs. RReeqquueesstt--UURRLL field matched to helper-specific endpoints allows to reply with the appropriate SSoouurrccee (and DDeessttiinnaattiioonn is needed) and let ggxxwwss know what the endpoints are. Here's an example scenario: GGEETT //ddcc0033dd0033333322ff0099aa is the original HTTP request as read by ggxxwwss. The auth config specifies: auth: { enabled = true; helper_protocol = "B2P"; b_fields = "USP"; exec = "/usr/local/bin/b2p-auth.sh /var/log/gigapxy/auth.log"; deny_no_auth = true; can_rewrite_endpoints = true; allow_custom_urls = true; }; aallllooww__ccuussttoomm__uurrllss lets ggxxwwss ignore that the URL could not be parsed into gigapxy endpoints, so both _S_o_u_r_c_e and _D_e_s_t_i_n_a_t_i_o_n remain empty after request has been parsed. ggxxwwss sends a B2P request: BB11 UUSSPP //ddcc0033dd0033333322ff0099aa -- 1100..00..1144..2266::4400998877 Please note that SSoouurrccee is empty in the request and could be omitted if we know it's never needed by the helper. The helper translates the data (using its own logic) into the following response: BB11 SS uuddpp::////222266..00..33..1144::66006600 ggxxwwss reads the response and assumes the request is APPROVED (no rr field but another field present). It then takes uuddpp::////222266..00..33..1144::66006600 as the source endpoint, directing to read from the given multicast channel. WWhheerree ddoo II bbeeggiinn?? Having decided which features you'd need and thus which protocol to select, make a copy of the corresponding _e_x_a_m_p_l_e _h_e_l_p_e_r in //uussrr//sshhaarree//ggiiggaappxxyy//ssccrrppttss under Linux (//uussrr//llooccaall//sshhaarree//.... under Free‐ BSD). If you understand the logic, but dislike /bin/sh, use any other language. Once your helper (kind of) works, make a text file (requests.txt) with sample requests (the kind you'd be most likely pro‐ cessing) and run: ccaatt rreeqquueessttss..ttxxtt || aauutthh--hheellppeerr //vvaarr//lloogg//hheellppeerr..lloogg The output will be the response messages. If somethig does not quite work, the log (where yyoouurr script writes) should help. ААВВТТООРРЫЫ Pavel V. Cherenkov ССММООТТРРИИТТЕЕ ТТААККЖЖЕЕ ggiiggaapplluuss(1),ggxxwwss(1),ggxxnngg(1) gxng(1) Документация gxng (GigA+ streaming engine) gxng(1) ИИММЯЯ gxng - Сервер доставки потоков GigA+. ППААРРААММЕЕТТРРЫЫ ggxxnngg [-h?TvVq] OPTIONS ООППИИССААННИИЕЕ ggxxnngg - "движок" GigA+, выполняющий операции ввода-вывода по запросам на данные, полученные модулем ggxxwwss. Формат запросов к ggxxwwss описан на странице ggxxwwss(1) документации. ggxxnngg _п_р_и_с_о_е_д_и_н_я_е_т_с_я к означенному (в конфигурации) ggxxwwss после запуска; вплоть до 64 движков могут присоединиться к одному ggxxwwss (данный лимит - искусственный). Контролирующий ggxxwwss направляет (обработанные) запросы одному из присоединённых движков для дальнейшего выполнения. ggxxnngg считывает параметры из файла конфигурации: по умолчанию либо _g_x_n_g_._c_o_n_f, либо _g_i_g_a_p_l_u_s_._c_o_n_f. Файл конфигурации может содержать секции для любых модулей GigA+. ggxxnngg ищет файл конфигурации в а) текущей директории, б) _/_e_t_c, в) _/_u_s_r_/_l_o_c_a_l_/_e_t_c. Путь к файлу конфигурации также может быть указан в командной строке (см. раздел ООППЦЦИИИИ). Параметры конфигурации подробно описаны в разделе ККООННФФИИГГУУРРААЦЦИИЯЯ данной страницы. ggxxnngg пересчитывает заданный файл конфигурации после получения SIGHUP. ggxxnngg делает ротацию лога при получении SIGUSR1. ООППЦЦИИИИ Компонент принимает следующие необязательные параметры: --CC,, ----ccoonnffiigg _p_a_t_h путь к файлу конфигурации. --ll,, ----llooggffiillee _p_a_t_h путь к логу приложения. Не забывайте о правах доступа к директории в соотношении с параметром --runas (см. ниже). --pp,, ----ppiiddffiillee _p_a_t_h путь к pid-файлу. --uu,, ----rruunnaass _u_s_e_r_n_a_m_e пользователь, под которым приложение будет работать, если запущено в режиме "демона". По умолчанию, приложение остаётся под пользователем _r_o_o_t (в режиме "демона"). NNBB: рекомендуется ииззббееггааттьь работы модулей под _r_o_o_t. --TT,, ----tteerrmm запуск в рамках терминала (т.е. ннее "демона"). Данный режим подразумевается по умолчанию, когда приложение запускается из-под непривилегированного пользователя. Опция -T может быть задействована, когда приложение нужно запустить из-под _r_o_o_t_P_, ННЕЕ _п_е_р_е_в_о_д_я _е_г_о _в _р_е_ж_и_м _"_д_е_м_о_н_а_"_; _н_а_п_р_и_м_е_р_, _в _ц_е_л_я_х _о_т_л_а_д_к_и_. --VV,, ----vveerrssiioonn вывести версию приложения и закончить работу. --vv,, ----vveerrbboossee установить уровень детализации логов. Данная опция может быть повторена многократно. Каждое дополнительное использование повышает уровень (с изначального 0 = normal) на единицу. NNBB: данная опция ууссттааррееллаа, пользуйтесь вместо неё --ll,, ----llooggffiillee _p_a_t_h в далешейшем. --qq,,----qquuiieett не выводить сообщения на терминал. Данная опция запрещает вывод сообщений на STDOUT, STDERR. Если она не указана, то при запуске приложения из-под непривилегированного режима, модуль ппррооддууббллииррууеетт диагностические сообщения, посылаемые в лог приложения, в поток стандартного вывода. --ww,, ----ggxxwwss _p_a_t_h указать путь к (доменному сокету) контролирующего ggxxwwss. --hh,, ----hheellpp,, --??,, ----ooppttiioonnss вывести краткое руководство по вызову из командной строки. То же будет сделано при запуске модуля без параметров. --KK,, ----ssyysskkeeyy сгенерировать системный ключ (для использования в лицензии) и закончить работу. ККООННФФИИГГУУРРААЦЦИИЯЯ ggxxnngg(1) считывает конфигурацию из файла, по умолчанию, gxws.conf или gigaplus.conf. После прочтения и проверки конфигурации, модуль применяет к ней параметры, переданные из командной строки. После того, как все параметры считаны ggxxnngg, модуль использует данную конфигурацию до тех пор, пока не перезагрузит конфигурационный файл в ответ на сигнал SSIIGGHHUUPP. У всех параметров конфигурации данного приложения есть префикс: 'nngg..'. Так, к примеру, параметр _A должен полностью именоваться как _n_g_._A. Параметры конфигурации перечислены ниже. Значение параметра по умолчанию даётся в квадратных скобках. Параметры без значения по умолчанию являются обязательными. nngg..ssoocckkeett__ppaatthh == _p_a_t_h [[//vvaarr//rruunn//ggppxx--nnggccoommmm..ssoocckkeett]] путь к доменному (UNIX) сокету для коммуникаций между ggxxwwss и _п_р_и_п_и_с_а_н_н_ы_м_и к нему процессами ggxxnngg. lloogg..** Установки для лог-файлов: level_default = err| crit| warn| norm| info| debug [info] устанавливает детализацию лога ввссееггоо приложения. ffiillee полный путь к лог-файлу. lleevveell уровень детализации лога: _c_r_i_t_|_e_r_r_|_n_o_r_m_|_w_a_r_n_|_i_n_f_o_|_d_e_b_u_g mmaaxx__ssiizzee__mmbb == _N максимальный размер лог-файла в MB (1MB = 1048576). Каждый раз, когда размер лога превышает данную величину, файл переименовывается в архив, а приложение начинает новый лог. mmaaxx__ffiilleess == _n максимальное количество файлов перед ротацией. Каждый раз, когда количество архивных логов превышает данное значение, самый старый архив стирается. ttiimmee__ffoorrmmaatt == llooccaall|| ggmmtt|| rraaww|| rraaww__mmoonnoo|| nnoo__ttiimmee|| [[llooccaall]] устанавливает формат таймстэмпа в записях лога, _Г_Д_Е: _l_o_c_a_l = местное время в формате YYYY-MM-DD HH24:MI TZ; _g_m_t = GMT время в том же формате, что и local; _r_a_w = UNIX время в формате: seconds.nanoseconds; _f_B_r_a_w___m_o_n_o = raw для таймера monotonic (не соотносится с часовым временем); _n_o___t_i_m_e = не показывать время в логе. sshhooww__ppiidd == _t_r_u_e_|_f_a_l_s_e [[ttrruuee]] показывать PID в каждой строчке лога. eennaabbllee__ssyysslloogg == _t_r_u_e_|_f_a_l_s_e [[ttrruuee]] писать ошибки, предупреждения и критические сообщения в sys‐ log(2). eeoodd__rroottaattee == ttrruuee||ffaallssee [[ffaallssee]] Осуществлять ротацию лога в конце (кажлого) дня. Т.е. начинать новый лог в начале каждого нового дня. rruunn__aass__uusseerr _u_s_e_r_n_a_m_e [[]] пользователь, под которым приложение будет работать, если запущено в режиме "демона". По умолчанию, как root. rruunn__aass__uuiidd == _u_i_d [[--11]] То же, что и _r_u_n___a_s___u_s_e_r, но пользователь обозначается не по имени, а по численному идентификатору (uid). (Имеет приоритет выше, чем _r_u_n___a_s___u_s_e_r). rruunn__aass__ggiidd == _g_i_d [[--11]] переключиться на данную группу (gid), если >=0. nnoonn__ddaaeemmoonn == ttrruuee || ffaallssee [[ffaallssee]] если true, запуск в рамках терминала (т.е. ннее "демона"). Данный режим подразумевается по умолчанию, когда приложение запускается из-под непривилегированного пользователя. eennffoorrccee__ccoorree__dduummppss == ttrruuee || ffaallssee [[ffaallssee]] при установке в _t_r_u_e, приложение разрешает себе core dumps и устанавливает предельный размер в _u_n_l_i_m_i_t_e_d. При значении _f_a_l_s_e, данные параметры регулируются установками оболочки. ВВННИИММААННИИЕЕ: на отдельных версиях Linux, демоны, переключающиеся на другого пользователя, теряют способность оставлять после себя core dumps (см. //pprroocc//ssyyss//ffss//ssuuiidd__dduummppaabbllee и страницу pprrccttll(2) документации). nnoo__rrttpp__ssttrriipp == ttrruuee || ffaallssee [[ffaallssee]] если установлен в true, движок ннее ббууддеетт пытаться удалять RTP заголовки TS-пакетов, чтобы сконвертировать их в TS (по умолчанию будет). В этом случае пакеты RTP будут передаваться "как есть". uussee__sseennddffiillee == ttrruuee || ffaallssee [[ttrruuee ппоодд FFrreeeeBBSSDD,, ииннааччее -- ffaallssee]] использовать, когда возможно, sseennddffiillee(2) для передачи данных. Имеет серьёзный эффект под ОС FreeBSD, где посредством данного системного вызова реализована передача с нулевым копированием. Под Linux, производительность не обязательно улучшится (потому и false по умолчанию). qquuiieett == ttrruuee || ffaallssee [[ffaallssee]] не выводить ничего в STDOUT/STDERR, если установлено в _t_r_u_e. ccppuunnuumm == --11 || 00 .... NN [[--11]] установить привязку к ЦП (нумерация с нуля), если не -1 (или <0). pprroocceessss__lliimmiittss..** параметры данной секции позволяют установить ограничения на рабочий процесс при помощи системного вызова sseettrrlliimmiitt(2) меры исчисления, таким как _K_b, _M_b или _G_b. Числа могут быть и дробными, т.е. 1.5Kb = 1024 + 512 = 1536 байт. Указанное значение "0" означает, что лимит не будет установлен вовсе и, стало быть, в силе останется установленное pprroocceessss__lliimmiittss..rrssss == {{NN}}{{ssuuffffiixx}} [[""00""]] ограничение по физической памяти процесса: процесс не может привысить данный показатель зарезервированной физической памяти. ВВННИИММААННИИЕЕ: данный лимит не вполне выполняется под ОС Linux, где для него используется RRLLIIMMIITT__AASS (лимит виртуальной памяти). Под ОС FFrreeeeBBSSDD лимит полностью поддерживается. pprroocceessss__lliimmiittss..vvmmeemm == {{NN}}{{ssuuffffiixx}} [[""00""]] ограничение по виртуальной памяти = RRLLIIMMIITT__AASS. Используется вместо лимита по физической памяти (RSS) под ОС Linux. Полностью поддерживается и Linux, и FreeBSD. mmaaxx__cchhaannnneellss == _n_u_m [[220000]] максимальное количество каналов (на движок). mmaaxx__cchhaannnneell__cclliieennttss == _n_u_m [[550000]] максимальное количество клиентов на один канал. cchhaannnneell__iioo__ttiimmeeoouutt__sseecc == _s_e_c_o_n_d_s [[55]] максимальное время ожидания (в секундах) ввода-вывода на сокете канала. cclliieenntt__iioo__ttiimmeeoouutt__sseecc == _s_e_c_o_n_d_s [[55]] максимальное время ожидания (в секундах) ввода-вывода на клиентском сокете. cclliieenntt__bbuussyy__ttiimmeeoouutt__sseecc == _s_e_c_o_n_d_s [[8866440000 == 2244 ччаассаа]] максимальное время клиентской сессии (в секундах). ccaann__eexxtteenndd__cclliieennttss == _t_r_u_e_|_f_a_l_s_e [[ffaallssee]] в случае тайм-аута клиента (на запись), проверить, есть ли данные (канала) для записи и возможна ли ссееййччаасс запись в сокет клиента. Если да, то продлить период ожидания (лишь единожды) на величину _c_l_i_e_n_t___i_o___t_i_m_e_o_u_t___s_e_c. cclliieenntt__ssoocckkeett__ssnnddbbuuff__ssiizzee == _b_y_t_e_s [[ssyysstteemm ddeeffaauulltt]] размер (в байтах) буфера на запись клиентских сокетов. cchhaannnneell__ssoocckkeett__rrccvvbbuuff__ssiizzee == _b_y_t_e_s [[ssyysstteemm ddeeffaauulltt]] размер (в байтах) буфера на приём сокетов канала. cchhaannnneell__lloo__wwmmaarrkk == _b_y_t_e_s,, 00 == nnoonnee [[00]] нижний порог (ватерлинии) для сокетов каналов. cclliieenntt__ttccpp__ccoorrkk == _t_r_u_e_|_f_a_l_s_e [[ffaallssee]] использовать (Linux) опцию сокетов TCP_CORK для агрегации клиентских пакетов (только под Linux). cclliieenntt__ttccpp__nnooppuusshh == _t_r_u_e_|_f_a_l_s_e [[ffaallssee]] использовать (BSD) опцию сокетов TCP_NOPUSH для агрегации клиентских пакетов (только под FreeBSD). mmuullttiiccaasstt__ttttll == _h_o_p_s [[22]] установить значение TTL для посылаемых мультикаст-пакетов. ttppuutt__ssttaattss..** данная секция содержит параметры, используемые для передачи движками данных по пропускной статистике. Данные эти запрашиваются с помощью административного запроса rreeppoorrtt (см. секцию по админ. запросам). ttppuutt__ssttaattss..eennaabblleedd == ttrruuee || ffaallssee [[ttrruuee]] если не установлен в _t_r_u_e, то статистика не будет приниматься. Просьба заметить, что движки будут расходовать дополнительные ресурсы на сбор и передачу статистики. ttppuutt__ssttaattss..cchhaannnneell__ppaatthh == _p_o_s_i_x___s_h_m_e_m___p_a_t_h [[//ggxxyy--cchhaa..sshhmm]] путь для сегмента разделяемой памяти (POSIX shared memory), используемого при обменом статистикой по каналам (менее 32 символов). ttppuutt__ssttaattss..cclliieenntt__ppaatthh == _p_o_s_i_x___s_h_m_e_m___p_a_t_h [[//ggxxyy--ccllii..sshhmm]] путь для сегмента разделяемой памяти (POSIX shared memory), используемого при обменом статистикой по клиентам (менее 32 символов). ttppuutt__ssttaattss..cchhaannnneell__rreeppoorrtt__mmss == _m_i_l_l_i_s_e_c_o_n_d_s [[55000000]] рапортовать пропускную способность каналов каждые N милисекунд. (Статистика хранится в разделяемой памяти.) ttppuutt__ssttaattss..cclliieenntt__rreeppoorrtt__mmss == _m_i_l_l_i_s_e_c_o_n_d_s [[55000000]] рапортовать пропускную способность клиентов каждые N милисекунд. (Статистика хранится в разделяемой памяти.) ttppuutt__ssttaattss..mmaaxx__ppaacckkeett__ddeellttaa == _b_y_t_e_s [[--11]] предупреждать, если два последовательных пакета разнятся в размере более, чем на N байт, игнорировать разницу, если параметр = -1. Данный параметр позволяет выявлять нестыковки в тех UDP потоках, где пакеты предполагаются равного размера. ИСПОЛЬЗУЙТЕ ОСМОТРИТЕЛЬНО. wwss..** данная секция описывает параметры коммуникации между ggxxnngg и ggxxwwss. wwss..mmaaxx__rreeccoonnnneeccttss == _n_u_m [[1100]] повторять попытку присоединения к ggxxwwss N раз, -1 = бесконечно, 0 = не пытаться. Если контролирующий ggxxwwss "падает", ggxxnngg предпринимает некоторое количество попыток (разделённых паузами) заново присоединиться к ggxxwwss. Таким образом, если следящий за ggxxwwss процесс сможет рестартовать модуль, ggxxnngg может заново присоединиться к нему. wwss..rreeccoonnnneecctt__ddeellaayy == _m_i_l_l_i_s_e_c_o_n_d_s [[550000]] задержка (в милисекундах) между попытками присоединения. bbuuffdd..** данная секция описывает параметры внутреннего кеша, позволяющего ggxxnngg использовать данные одного соединения канала для раздачи многим клиентам. Каждый кешируемый канал хранится как цепочка буферов, представляющих из себя последовательные сегменты приходящих данных. bbuuffdd..kkeeeepp__ffiilleess == ttrruuee || ffaallssee [[ffaallssee]] не стирать (unlink(2)) файлы буферов (сделать их видимыми). Данная опция существует для отладки. ИСПОЛЬЗУЙТЕ ОСМОТРИТЕЛЬНО. bbuuffdd..mmmmaapp__ffiilleess == ttrruuee || ffaallssee [[ttrruuee]] размещать файлы буферов в памяти (с помощью mmmmaapp(2) ), с резервированием пространства в файловой системе. Обеспечивает быстрый доступ к данным, но может истощить оперативную память. bbuuffdd..mmmmaapp__aannoonn == ttrruuee || ffaallssee [[ffaallssee]] размещать файлы буферов в памяти (с помощью mmmmaapp(2) ), ббеезз ррееззееррввиирроовваанниияя пространства в файловой системе. Обеспечивает самый быстрый доступ к данным, но требует большого пространства ффииззииччеессккоойй оперативной памяти. bbuuffdd..mmlloocckk == ttrruuee || ffaallssee [[ffaallssee]] mmlloocckk(2) буферы в физической памяти. Убедитесь, что системные параметры позволяют использовать данную опцию, см. документацию mmlloocckk(2) bbuuffdd..ddaattaa__ddiirr == _p_a_t_h_n_a_m_e [[//ttmmpp]] директория для файлов буферов. Последующие три параметра относятся к накоплению данных канала в кеше. Они устанавливают и общий объём данных и с какой точки (в кеше) данные будут отправляться клиенту в начале работы. bbuuffdd..mmiinn__ttoottaall__dduurraattiioonn__sseecc == _s_e_c_o_n_d_s [[55]] минимум данных, сохраняемых в кеше канала, измеряемых во времени, затраченном на получение этих данных. Буферы канала не подвергаются ротации до достижения этого объёма. Объём, хранимый в кеше, может превышать, но никогда не должен стать меньше данного предела. ggxxnngg может удалить крайний буфер только в том случае, если объём после удаления будет >= _s_e_c_o_n_d_s. bbuuffdd..mmiinn__ttoottaall__ssiizzee == _b_y_t_e_s [[11004488557766]] минимальное количество байт в кеше канала. Буферы не удаляются, пока данный предел не выполняется (см. выше). Два вышеуказанных параметра работают в тандеме, выставляя свои лимиты. ggxxnngg не будет сокращать данные из канала, пока хотя бы один из этих пределов (или оба) не будет выполнен. Если, к примеру, первый предел равен 5 секундам, а второй - 10485760 байтам = 10 Мб, то сокращений не произойдёт, пока мы не накопим 10 Мб или не будем получать данные в течение 5 секунд (в этом случае данных может оказаться менее 10 Мб). Данные канала хранятся в цепочке буферов: от самого "свежего" - голова (HEAD) до самлго "старого" - хвост (TAIL). Новый подписчик (клиент) канала должен выбрать буфер, с которого начнётся передача данных. Параметр ниже указывает алгоритм, по которому ggxxnngg выбирает первый буфер клиента. bbuuffdd..ssttaarrtt__mmooddee == 00 || 11 || --11 || 22 [[11]] определяет алгоритм выбора буфера для клиента: 00 ((HHEEAADD)) выбирает "голову" цепочки, самый "свежий" буфер, смещение 0. 22 ((EEDDGGEE)) выбирает конец самого "свежего" буфера, смещение: END-OF-DATA (последний байт кеша). 11 ((MMIINN__CCAACCHHEEDD)) выбирает буфер, позволяющий передать N секунд или же M байт из кеша; смещение: байт 0 выбранного буфера. --11 ((TTAAIILL)) выбирает "хвост" цепочки; смещение: байт 0 хвостового буфера. Все вышеуказанные методы, кроме EEDDGGEE (2) выбирают нулевое смещение буфера. В этих случаях всегда есть данные, которые можно незамедлительно отослать клиенту, не дожидаясь ввода-вывода. Метод EEDDGGEE устраняет кеширование, только актуальные данные, полученные за время клиентской сессии, посылаются клиенту. MIN_CACHED (1) использует параметры _b_u_f_d_._m_i_n___t_o_t_a_l___d_u_r_a_t_i_o_n___s_e_c и _b_u_f_d_._m_i_n___t_o_t_a_l___s_i_z_e для выбора буфера. Алгоритм стартует с головного буфера и движется к хвосту, аккумулируя объём данных и время для каждого буфера. Как только достигается один из лимитов, алгоритм останавливается на текущем буфере, который и выбирает. bbuuffdd..bbuurrsstt__mmooddee == 00 ((nnoonnee)) || 11 ((ssccaann)) || 22 ((bbuurrsstt)) [[11]] определяет критерий применения метода, позволяющего избежать разростания цепочки буферов с помощью техники "прокалывания пузыря". "Пузырь" - это (длинная) цепочка незадействованных буферов (такой буфер обозначен буквой U), заключённая между небольшим количеством активно задействованных буферов (для них используем букву A). Медленный клиент может "застыть" на одном из буферов, заблокировав его (от сокращения), в то время как остальные клиенты продвигаются дальше. Буфер позади остаётся заблокированным, в то время как буферы впереди становятся незадействованными: AA_U_U_U_U_U_U_U_U_U_U_UA. Последовательность U-буферов и есть пресловутый "пузырь". В режиме 11 ((ssccaann)) модуль распознаёт наличие "пузыря" и пишет предупреждение (в журнал), в режиме 22 ((bbuurrsstt)) модуль пытается "проколоть" пузырь, принудительно разблокировав активный буфер слева от U-последовательности и создав таким образом возможность убрать часть незадействованных буферов из цепочки. bbuuffdd..mmaaxx__uunniitt__ccoouunntt == _n_u_m [[112288]] максимальное количество буферов для всех каналов данного процесса. Как правило, не все буферы задействуются сразу же. Данный параметр - общий лимит, относящийся ко всем каналам. bbuuffdd..pprreeaalllloocc__ccoouunntt == _b_u_f_f_e_r_s [[mmaaxx__uunniitt__ccoouunntt // 44]] количество буферов, выбеляемых в памяти сразу при старте движка. bbuuffdd..mmaaxx__uunniittss__ppeerr__cchhaannnneell == _n_u_m [[11//33 ooff mmaaxx__uunniitt__ccoouunntt,, yyeett wwiitthhiinn 44....1122 rraannggee]] максимальное количество буферов, которое может быть выделено на ОДИН канал. Данное значение должно быть сбалансировано так, чтобы предотвратить возможность какого-то одного канала (с медленными клиентами) истощить общий запас буферов. bbuuffdd..mmaaxx__uunniitt__ssiizzee == _b_y_t_e_s [[1166777777221166]] максимальное количество байт в буфере. Когда данный лимит превышен, в кеш добавляется новый буфер. bbuuffdd..mmaaxx__ddggrraamm__ssiizzee == _b_y_t_e_s [[11550000]] максимально ожидаемый размер UDP пакета (не может превышать MTU). ВВННИИММААННИИЕЕ: установите, если будете работать с _j_u_m_b_o _f_r_a_m_e_s. bbuuffdd..mmaaxx__uunniitt__dduurraattiioonn__sseecc == _s_e_c_o_n_d_s [[3300]] максимальное время проигрыша (звучания) буфера. Когда данный лимит превышен, в кеш добавляется новый буфер. bbuuffdd..aallllooww__eemmeerrggeennccyy__rreeccyyccllee == ttrruuee || ffaallssee [[ffaallssee]] можно принудительно вытеснить самый старый буфер, если невозможно создать новый. ttrraannssffeerr__bbuuffffeerr__ssiizzee == _b_y_t_e_s [[11004488557766]] размер промежуточного буфера для ввода-вывода. Не задействовано, если используется mmmmaapp(2) ccllii__wwrriittee__ddeellaayy..** данная секция отвечает за практику задержек в выводе данных с целью уменьшить количество системных вызовов wwrriittee((22)) достигает некого предельного размера или не истекает условленное время. ccllii__wwrriittee__ddeellaayy..eennaabblleedd == _t_r_u_e_|_f_a_l_s_e [[ttrruuee]] разрешить задержки вывода, если ttrruuee. ccllii__wwrriittee__ddeellaayy..ttiimmeeoouutt__mmss == _d_e_l_a_y___m_s [[110000]] задержка не более _N милисекунд. ccllii__wwrriittee__ddeellaayy..mmaaxx__bbuuffffeerreedd == _m_a_x___b_y_t_e_s [[11004488557766]] задержка не более, чем до _m_a_x___b_y_t_e_s данных. Игнорировать, если 0. ppsseennssoorrss..** сенсоры производительности позволяют делать замеры расхода ресурсов процесса между двумя моментами времени, используя метрики системного вызова uuttiimmee(2) нагрузку на отдельных участках программы. Включая какой-либо из сенсоров, следует отдавать себе отчёт, что это повлечёт за собой системный вызов uuttiimmee(2) при каждом замере. Результаты замеров выводятся приложением по окончании работы, в формате, сходном с выводом системной утилиты ttiimmee(1) Сенсоры производительности - инструмент отладки и профилирования. Их использование неизбежно создаёт дополнительную нагрузку приложению и системе в целом. ИСПОЛЬЗУЙТЕ ОСМОТРИТЕЛЬНО. ССппииссоокк ссееннссоорроовв:: aapppp = общая нагрузка; eevv__lloooopp = обработка событий (всех); eevv__rreeaadd = обработка входных данных; eevv__wwrriittee = обработка исходящих данных; eevv__eerrrr = обработка ошибок; eevv__pppp = post-обработка событий; nngg__cchhaaiioo = ввод-вывод данных канала; nngg__cclliioo = ввод-вывод данных клиента. ppsseennssoorrss..eennaabbllee__aallll == _t_r_u_e_|_f_a_l_s_e [[ffaallssee]] включает все сенсоры сразу, если true, или же выключает, если false. Удобно инициализировать множество сенсоров таким образом в одно из двух положений (ВКЛ/ВЫКЛ). Параметр предназначен для использования в комбинации с ppsseennssoorrss..eexxcceepptt. ppsseennssoorrss..eexxcceepptt == _s_e_n_s_o_r___l_i_s_t [[]] включает перечисленные сенсоры, если _p_s_e_n_s_o_r_s_._e_n_a_b_l_e___a_l_l установлен в ffaallssee, и выключает, если в ttrruuee. Таким образом, данный параметр добавляет или вычитает сенсоры из инициализированного множества. _П_Р_И_М_Е_Р _A_: psensors.enable_all = true; # Включить все сенсоры. psensors.except = ["ev_read", "ev_write"]; # Выключить перечисленные. Включает все сенсоры, кроме _e_v___r_e_a_d and _e_v___w_r_i_t_e. _П_Р_И_М_Е_Р _B_: psensors.enable_all = false; # Выключит все сенсоры. psensors.except = ["ev_read", "ev_write"]; # Включить перечисленные. Включить _e_v___r_e_a_d and _e_v___w_r_i_t_e, остальные выключить. ААВВТТООРРЫЫ Pavel V. Cherenkov ССММООТТРРИИТТЕЕ ТТААККЖЖЕЕ ggiiggaapplluuss(1),ggxxwwss(1) gxpm(1) gxpm - Краткое руководство gxpm(1) ИИММЯЯ ggxxppmm - модуль управления плейлистами в GigA+. ККООММААННДДННААЯЯ ССТТРРООККАА ggxxppmm -Y ipath -S spath -C config [OPTIONS] ООППИИССААННИИЕЕ ggxxppmm(1) формирует плейлисты (в формате MM33UU88) для различных _к_а_н_а_л_о_в (источников) по запросу ggxxwwss процессов. Меда-данные каналов поступают со стороны vvssmm (посредством ggxxsseegg) в сокет _и_с_т_о_ч_н_и_к_о_в (_s_p_a_t_h). По сокету _э_л_е_м_е_н_т_о_в (_i_p_a_t_h) ggxxppmm((11)) отвечает на запросы ggxxwwss: формирует и отправляет плейлисты. ППААРРААММЕЕТТРРЫЫ Модуль принимает следующие обязательные параметры: --YY,, ----iitteemmss _i_p_a_t_h путь к UNIX сокету _э_л_е_м_е_н_т_о_в, обслуживающему запросы от ggxxwwss. --SS,, ----ssoouurrcceess _s_p_a_t_h путь к UNIX сокету _и_с_т_о_ч_н_и_к_о_в, получающему мета-данные от vvssmm просессов. --CC,, ----ccoonnffiigg _p_a_t_h путь к файлу конфигурации (ggxxppmm..ccoonnff по умолчанию). ООППЦЦИИИИ Модуль принимает следующие необязательные параметры: --DD,, ----aappppddaattaa _p_a_t_h путь к данным для плейлистов (по умолчанию, _/_t_m_p). Это корневая директория данных, на один уровень выше директорий конкретного канала. ggxxppmm считает этот путь - базовым для всех данных по каналам. Так что, если все участвующие vvssmm используют единую корневую директорию данных, то это она и есть. Параметр игнорируется, если vvssmm передаёт информацию о директории канала (vvssmm делает это в том случае, когда для канала определён параметр спецификации cchhaa__RROOOOTT). Смотрите подробней на странице vvssmm(1) документации. --FF,, ----pprreeffiixx _U_R_L URL-префикс для всех элементов плейлистов, если префикс уже не указан для канала в его _с_п_е_ц_и_ф_и_к_а_ц_и_и как _c_h_a___P_F_X. Смотрите подробней на странице vvssmm(1) документации. --ll,, ----llooggffiillee _p_a_t_h путь к логу приложения. Не забывайте о правах доступа к директории в соотношении с параметром --runas (см. ниже). --LL,, ----lleevveell _c_r_i_t_|_e_r_r_|_n_o_r_m_|_w_a_r_n_|_i_n_f_o_|_d_e_b_u_g уровень детализации лога. По умолчанию _i_n_f_o, если не переопределён в конфигурации. --pp,, ----ppiiddffiillee _p_a_t_h путь к pid-файлу. --uu,, ----rruunnaass _u_s_e_r_n_a_m_e пользователь, под которым приложение будет работать, если запущено в режиме "демона". По умолчанию, приложение остаётся под пользователем _r_o_o_t (в режиме "демона"). NNBB: рекомендуется ииззббееггааттьь работы модулей под _r_o_o_t. --TT,, ----tteerrmm запуск в рамках терминала (т.е. ннее "демона"). Данный режим подразумевается по умолчанию, когда приложение запускается из-под непривилегированного пользователя. Опция -T может быть задействована, когда приложение нужно запустить из-под _r_o_o_t_P_, ННЕЕ _п_е_р_е_в_о_д_я _е_г_о _в _р_е_ж_и_м _"_д_е_м_о_н_а_"_; _н_а_п_р_и_м_е_р_, _в _ц_е_л_я_х _о_т_л_а_д_к_и_. --VV,, ----vveerrssiioonn вывести версию приложения и закончить работу. --vv,, ----vveerrbboossee установить уровень детализации логов. Данная опция может быть повторена многократно. Каждое дополнительное использование повышает уровень (с изначального 0 = normal) на единицу. NNBB: данная опция ууссттааррееллаа, пользуйтесь вместо неё --ll,, ----llooggffiillee _p_a_t_h в далешейшем. --qq,,----qquuiieett не выводить сообщения на терминал. Данная опция запрещает вывод сообщений на STDOUT, STDERR. Если она не указана, то при запуске приложения из-под непривилегированного режима, модуль ппррооддууббллииррууеетт диагностические сообщения, посылаемые в лог приложения, в поток стандартного вывода. --hh,, ----hheellpp,, --??,, ----ooppttiioonnss вывести краткое руководство по вызову из командной строки. То же будет сделано при запуске модуля без параметров. --KK,, ----ssyysskkeeyy сгенерировать системный ключ (для использования в лицензии) и закончить работу. ККООННФФИИГГУУРРААЦЦИИЯЯ ggxxppmm(1) считывает большинство параметров из файла конфигурации, путь к которому должен быть указан в командной строке. Модуль начинает работу с того, что проставляет значения по умолчанию, затем замещает их значениями из конфигурации, а затем - значениями параметров командной строки. Пример файла конфигурации входит в установочный пакет GigA+. У всех параметров конфигурации данного приложения есть префикс: ggppmm.. (без _x). Так, к примеру, параметр _A должен полностью именоваться как _g_p_m_._A. Параметры конфигурации перечислены ниже: ssrrcc__ssoocckkeett == _p_a_t_h [[]] путь к UNIX сокету _и_с_т_о_ч_н_и_к_о_в, получающему мета-данные от vvssmm просессов. ppll__ssoocckkeett == _p_a_t_h [[]] путь к UNIX сокету _э_л_е_м_е_н_т_о_в, обслуживающему запросы от ggxxwwss. lloogg..** Установки для лог-файлов: ffiillee полный путь к лог-файлу. lleevveell уровень детализации лога: _c_r_i_t_|_e_r_r_|_n_o_r_m_|_w_a_r_n_|_i_n_f_o_|_d_e_b_u_g mmaaxx__ssiizzee__mmbb == _N максимальный размер лог-файла в MB (1MB = 1048576). Каждый раз, когда размер лога превышает данную величину, файл переименовывается в архив, а приложение начинает новый лог. mmaaxx__ffiilleess == _n максимальное количество файлов перед ротацией. Каждый раз, когда количество архивных логов превышает данное значение, самый старый архив стирается. eeoodd__rroottaattee == ttrruuee||ffaallssee [[ffaallssee]] Осуществлять ротацию лога в конце (кажлого) дня. Т.е. начинать новый лог в начале каждого нового дня. rruunnttiimmee..** установки, регулирующие запуск и режим работы. ppiiddffiillee [[]] путь к pid-файлу приложения (работать без pid-файла, если не указан). rruunn__aass__uusseerr _u_s_e_r_n_a_m_e [[]] пользователь, под которым приложение будет работать, если запущено в режиме "демона". По умолчанию, как root. nnoonn__ddaaeemmoonn == ttrruuee||ffaallssee [[ffaallssee]] запуск в рамках терминала (т.е. ннее "демона"). По умолчанию, приложение, запущенное из-под root, работает в режиме "демона". ddaattaa__ddiirr == _d_i_r_e_c_t_o_r_y [[//ttmmpp]] путь к данным для плейлистов (по умолчанию, _/_t_m_p). Это корневая директория данных, на один уровень выше директорий конкретного канала. См. подробно в описании опции -D. iitteemm__uurrll__pprreeffiixx == _U_R_L [[]] строка-префикс для каждого URL сегмента в плейлисте. Имеет смысл задать здесь данный параметр, если все источники используют единый корневой каталог и, следовательно, установка _c_h_a___P_F_X для каждого канала в этом случае будет избыточной. mmaaxx__ssoouurrcceess == _N [[225566]] максимальное количество каналов/источников под контролем модуля [1..1024]. mmaaxx__ssrrcc__ttaasskkss == _N [[225566]] каково максимальное количество плейлистов/задач на один канал/источник [1..512] ? Зависит от источника. Для обслуживания ввссеехх LIVE-запросов по каналу требуется только один плейлист, но для каждого _D_V_R запроса может понадобиться уникальный плейлист. Устанавливайте по ситуации. mmaaxx__ppllaayybbaacckk__ttiimmee == _s_e_c [[660044880000]] == 11 wweeeekk сколько секунд времени источника/канала хранить [600..5184000] ? Как правило, значение зависит от канала и может быть установлено через параметр _c_h_a___C_A_P_A_C_I_T_Y в спецификации канала для vvssmm. mmaaxx__lliivvee__iitteemmss == _N [[66]] максимальное количество сегментов в плейлисте типа LIVE [4..64]. ssrrcc__ttmmoouutt__sseecc == _s_e_c установить тайм-аут для источников (без рабочих задач/плейлистов) в _N секунд в отсутствие входных данных. [1..300] ttaasskk__ttmmoouutt__sseecc == _s_e_c _[_2_0_] завершать задачи по плейлистам, не использованным в течение _N секунд [1..100]. ggxxppmm создаёт файл для _о_т_с_л_е_ж_и_в_а_н_и_я _д_о_с_т_у_п_а (.alk) для каждого плейлиста, подразумевая, что ggxxwwss изменит его содержимое при каждом доступе к данному плейлисту. ggxxppmm регулярно проверяет время последнего изменения alk-файла и завершает задачи по плейлистам, доступ к которым осуществлялся более, чем _N секунд назад. ggzziipp__ppllaayylliissttss == ttrruuee||ffaallssee [[ttrruuee]] создавать сжатые файлы LIVE и LIVE/DVR плейлистов (VOD всегда сжаты). LIVE/DVR потоки, в отличие от LIVE, имеют чётко обозначенное время начала (_u_t_i_m_e), но не имеют обозначенной длительности (_d_u_r_a_t_i_o_n). Подобные потоки не имеют обозначенной точки завершения и могут проигрываться весьма долго. ggzziipp(1) tteexxtt__lliivvee__ppllaayylliissttss == ttrruuee||ffaallssee [[ttrruuee]] создавать LIVE плейлисты только в текстовом формате (переопределяет _g_z_i_p___p_l_a_y_l_i_s_t_s для LIVE потоков). vveerriiffyy__iitteemm__ffiilleessiizzee == ttrruuee||ffaallssee [[ttrruuee]] проверять, существуют ли файлы (сегментов) и совпадает ли размер. vvssmm сообщает ggxxppmm путь к файлу сегмента и его размер. Данная опция даёт указание ggxxppmm убедиться в правильности информации. uussee__ssiidd__ppllaayylliisstt__ddiirr == ttrruuee||ffaallssee [[ffaallssee]] помещать сгенерированные плейлисты в директорию, названную как _c_h_a___I_D источника. vvssmm передаёт _c_h_a___I_D и _c_h_a___R_O_O_T из спецификации канала. Если вышеуказанный параметр установлен в ttrruuee, то в полном пути к плейлисту конечная поддиректория будет названа по имени _c_h_a___I_D. В противном случае, плейлисты будут помещены в корневую директорию данных (_c_h_a___R_O_O_T) с префиксом, соответствующим имени канала. К примеру, пусть _c_h_a___I_D = 'CNN' и _c_h_a___R_O_O_T = '/opt/channel'. Тогда при значении ttrruuee, путь к плейлисту может быть: _/_o_p_t_/_c_h_a_n_n_e_l_/_C_N_N_/_p_l_a_y_l_i_s_t_._m_3_u_8; в другом же случае - _/_o_p_t_/_c_h_a_n_n_e_l_/_C_N_N_-_p_l_a_y_l_i_s_t_._m_3_u_8. rreeffrreesshh__ppllaayylliissttss == ttrruuee||ffaallssee [[ffaallssee]] переписывать содержимое плейлиста при каждом изменении содержания. Если данный параметр ffaallssee, то файл переписывается только в момент обработки запроса на данный плейлист. mmdd__rreeppoorrtt..** установки для перелачи мета-данных модулю ddwwgg(1) через мультикаст-подписку. ggxxppmm публикует в выделенную мультикаст-группу мета-данные о сегментах. Подписчики в рамках охвата мультикаст-сети имеют возможность выделить URL сегментов из сообщений и загрузить соответствующие файлы. eennaabblleedd == ttrruuee||ffaallssee [[ffaallssee]] мета-данные не передаются (а дальнейшие параметры игнорируются), если этот параметр не установлен в ttrruuee. ppuubb__uurrll == _m_u_l_t_i_c_a_s_t_-_U_R_L [[]] URL мультикаст-группы, в которую публикуются данные. Пример: udp://227.3.2.160:2020 lliidd..** == {{ _t_a_s_k_-_l_o_c_k _p_a_r_a_m_e_t_e_r_s }} параметры _ф_а_й_л_а _б_л_о_к_и_р_о_в_к_и _з_а_д_а_ч_и, создаваемого получателем для каждого обработанного сообщения. ddwwgg требуется блокировка задач, чтобы избежать лишних загрузок. Если на сервере запущено N > 1 процессов ddwwgg, каждый из которых подписан на группу _p_u_b___u_r_l, то каждая задача должна быть поручена только одному процессу. ggxxppmm включает уникальный _t_a_s_k_-_l_o_c_k _I_D в каждое сообщение. Процесс ddwwgg, получив сообщение, пытается (атомарно) создать новый файл блокировки. Если файл уже был создан, сообщение пропускается. Параметры таковы: pprreeffiixx = _с_и_м_в_о_л_ь_н_ы_й _п_р_е_ф_и_к_с, mmiinn = _N (N > 0), mmaaxx = _M (M > N). Численная часть "прокручивается" при переходе за максимум. Пример: lid: { pre‐ fix = "h1"; min = 100; max = 299; }; ssrrcc__bbaassee == _U_R_L префикс для URL загрузки сегментов. Если (отвечающий за отдачу файлов) веб-сервер был сконфигурирован так, что корневая директория данных располагается, к примеру, в _h_t_t_p_:_/_/_a_c_m_e_._t_v_:_8_0_8_0_/_s_e_g, то данный URL и должен стать значением параметра. В этом случае, сегмент с относительным путём _C_N_N_/_2_0_1_7_0_6_2_7_-_1_1_/_6_2_9_8_9_9_4_2_9_8_._t_s получит (в плейлисте) рабочий URL: _h_t_t_p_:_/_/_a_c_m_e_._t_v_:_8_0_8_0_/_s_e_g_/_C_N_N_/_2_0_1_7_0_6_2_7_-_1_1_/_6_2_9_8_9_9_4_2_9_8_._t_s. mmccaasstt__iiffcc == _i_n_t_e_r_f_a_c_e имя сетевого интерфейса для мультикаст-сети. Пример: eth0 ААВВТТООРРЫЫ Pavel V. Cherenkov ССММООТТРРИИТТЕЕ ТТААККЖЖЕЕ vvssmm(1),ggxxsseegg(1),ggxxwwss(1),ddwwgg(1) gxseg(1) gxseg - Краткое руководство gxseg(1) ИИММЯЯ ggxxsseegg - это утилита сегментирования потока в GigA+. ККООММААННДДННААЯЯ ССТТРРООККАА ggxxsseegg -i infile [OPTIONS] ООППИИССААННИИЕЕ ggxxsseegg(1) - утилита для деления входного потока на сегменты. vvssmm(1) запускает ggxxsseegg с опциями, соответствующими _с_п_е_ц_и_ф_и_к_а_ц_и_и _к_а_н_а_л_а. Исторически сложилось, что данная утилита не использует файла конфигурации, все параметры указываются в командной строке. ggxxsseegg использует библиотеки _l_i_b_a_v из проекта ffffmmppeegg(1) и таким образом наследует определённые черты этого ПО. Данная утилита не должна вызываться напрямую, vvssmm(1) запускает её по мере надобности. Настоящая страница документации предоставлена для справки, с целью улучшить понимание всех инструментов, задействованных в GGiiggAA++. ИИССХХООДДЯЯЩЩИИЙЙ ППООТТООКК ggxxsseegg выводит сообщения о мета-данных в _S_T_D_O_U_T, все диагностические и отладочные сообщения выводятся в _S_T_D_E_R_R. Это делается для того, чтобы вывод утилиты мог быть включён в конвейер модулей В GGiiggAA++ следующий в конвейере модуль - это wwuuxx(1) , передающий полученное от ggxxsseegg содержимое _S_T_D_O_U_T модулю ggppmm(1) , в порядке получения строк. Подробности о формате исходящих мета-данных в секции ССООООББЩЩЕЕННИИЯЯ,, ИИДДУУЩЩИИЕЕ ННАА ССТТААННДДААРРТТННЫЫЙЙ ВВЫЫЫЫООДД данной страницы. ППААРРААММЕЕТТРРЫЫ Модуль принимает следующие обязательные параметры: --ii||----ssoouurrccee _i_n_f_i_l_e URL источника в формате, совместимом с ffffmmppeegg(1) --NN||----cchhaannnneelliidd _s_t_r_i_n_g уникальный идентификатор канала источника. ggxxsseegg использует идентификатор для формирования полного пути к директории данных канала. ООППЦЦИИИИ Компонент принимает следующие необязательные параметры: --oo||----oouuttffiillee _p_a_t_h||ccooppyy [[]] путь к M3U8-плейлисту или же .m3u8, если путь = 'copy'. При указанном параметре ggxxsseegg создаёт LLIIVVEE M3U8-плейлист по данному пути, обновляя его при каждом добавленном сегменте. Если же вместо пути дана строка 'copy', то за основу берётся файл из URL источника и его расширение заменяется на mm33uu88. Если параметр не указан, плейлист не создаётся. --33||----mm33uuppffxx _p_r_e_f_i_x URL префикс для путей в M3U8-плейлисте. Данный префикс становится перед относительными путями к файлам сегментов. Например, если pre‐ fix=_h_t_t_p_:_/_/_a_c_m_e_._t_v_:_4_0_4_0_/_s_e_g, то для файла _d_a_t_a_/_C_N_N_/_t_3_4_9_3_2_0_0_1_._t_s занесённый в плейлист URL станет _h_t_t_p_:_/_/_a_c_m_e_._t_v_:_4_0_4_0_/_s_e_g_/_d_a_t_a_/_C_N_N_/_t_3_4_9_3_2_0_0_1_._t_s. --11||----llooggssttddoouutt _p_a_t_h "зеркалировать" _S_T_D_O_U_T в означенный файл. --11||----llooggssttddeerrrr _p_a_t_h "зеркалировать" _S_T_D_E_R_R в означенный файл. --SS||----ssttoorraaggee _d_i_r_p_a_t_h [[..]] корневая директория для файлов сегментов, по умолчанию - текущая директория. --RR||----rreellppaatthhss _p_1_:_p_2_:_._._:_p_K пути (разделённые двоеточием) к шардам хранения данных. Подробная информация о шардах в GigA+ содержится в описании параметра cchhaa__SSHHAARRDDSS спецификации каналов на странице vvssmm(1) документации. --GG||----ggrraannuullaarriittyy _m_a_s_k маска по времени для поддиректории хранилища данных канала. Формат маски должен следовать спецификации для функции ssttrrffttiimmee(3) в POSIX API. Подробная информация о масках в GigA+ содержится в описании параметра cchhaa__GGRRAANN__MMAASSKK спецификации каналов на странице vvssmm(1) документации. --UU||----dduurraattiioonn _s_e_c [[55]] длительность (проигрывания) сегмента в секундах. --MM||----mmuuxx _c_o_n_t_e_n_t_-_m_a_s_k [[vvaass]] типы каналов для мультиплексирования (включения в поток), где v=video, a=audio, s=subtitles. --PP||----pprrooffiillee _n_a_m_e [[]] тэг профиля/качества разрешения канала. В настоящее время не используется. --ll||----lloogglleevveell _n_u_m [[11]] уровень детализации лога для ffffmmppeegg(1) библиотек (libav). --mm||----mmaaxxsseegg _M [[110000]] максимальное количество сегментов в LIVE плейлисте. После достижения М приложение начинает стирать сегменты, начиная с самого давнего. --JJ||----jjooiinntt _N [[00]] создавать сводные сегменты из N < M обычных. Пока не используется. --FF||----ffaallsseerroooott _p_a_t_h [[]] временная корневая директория до синхронизации. Подробности смотрите в описании параметра cchhaa__FFAALLSSEE__RROOOOTT в документации _с_п_е_ц_и_ф_и_к_а_ц_и_и _к_а_н_а_л_а для vvssmm(1) --WW||----mmaarrkkeerrddiirr _p_a_t_h [[//ttmmpp]] директория для файлов-маркеров PTS. Для выполнения "замены", ggxxsseegg некоторое время работает в режиме "запасного" процесса и создаёт файлы-маркеры, содержащие значение PTS для последнего созданного сегмента. Данный параметр назначает директорию для подобных файлов. За подробностями по процессу "замены" следует обращаться к описанию параметра cchhaa__RROOLLLLOOVVEERR _с_п_е_ц_и_ф_и_к_а_ц_и_и _к_а_н_а_л_а для vvssmm(1) --uu||----ppiiddssccrriidd [[ffaallssee]] использовать PID, а не _c_h_a_n_n_e_l_i_d в качестве _s_o_u_r_c_e_I_D. ggxxsseegg начинает работу с вывода сообщения, идентифицирующего сегментируемый (данным процессом) источник. Если параметр установлен в ttrruuee, то приложение будет использовать ID процесса (_p_i_d) в качестве уникального идентификатора, а не значение, установленное параметром -N|--channelid. --aa||----mmaaxxssttoorree _s_e_c [[00 == nnoonnee]] определяет квоту для данных канала. Установка значение параметра >0 означает, что в сообщение (для vvssmm), идентифицирующее канал, будет добавлен параметр max_sec=_s_e_c. Параметр сообщает vvssmm максимальный порог количества данных, сохраняемых для данного канала. См. также параметр cchhaa__CCAAPPAACCIITTYY на странице vvssmm(1) документации. --pp||----ppiiddffiillee _p_a_t_h [[ffaallssee]] создать pidfile, выйти, если pidfile или означенный процесс уже существует. --dd||----aallaanngg _l_1_,_l_2_,_._. [[ffaallssee]] сортировать аудио-дорожки в соответствии со списком языков. Пока не используется. --AA||----iinnttmmoouutt _s_e_c [[1100]] выход (с ошибкой), если данные ожидаются больше N секунд. --EE||----eennccrryypptt _s_p_e_c_-_p_a_t_h [[]] использовать данную спецификацию для выдачи задач по шифрованию сегментов (на STDOUT). Пока не используется. --TT||----tthhuummbbnnaaiill _s_e_c_o_n_d_s [[ooffff]] создавать JPEG мини-изображение кадра (thumbnail) каждые N секунд. --tt||----mmaaxxtthhuummbbss _N [[00]] установить максимальное количество мини-изображений {0..99}. Стирать по достижении предела. --gg||----ppnngg [[ffaallssee]] создавать PNG мини-изображения (вместо JPEG). --ee||----eerrrriiggnnoorree [[1100]] максимальное количество {-1..MAXINT} последовательных не-критических ошибок, которое можно пропустить; -1 = пропускать все. --HH||----eerrrrbbaaddttiimmee [[00]] максимальное количество {-1..MAXINT} последовательных ошибок PTS/DTS, которое можно пропустить; -1 = пропускать все. --ss||----ssuussppeenndd [[ffaallssee]] ожидать сигнала SIGUSR2 после начала работы. --kk||----kkeeeeppsseegg [[ffaallssee]] оставлять все сегменты (отменить ротацию). --XX||----eexxiittoonneerrrr [[ffaallssee]] eexxiitt((33)) при критической ошибке. Если параметр не установлен, ggxxsseegg периодически пытается заново открыть источник и начать сегментирование после каждой критической ошибки. (NNBB::: каждая повторная инициализация порождает ууттееччккуу ппааммяяттии в lliibbaavv). --DD||----dduummmmyy [[ffaallssee]] ничего не записывать в сегменты, не создавать файлы сегментов. --II||----iinntteerrlleeaavvee [[ffaallssee]] использовать режим _i_n_t_e_r_l_e_a_v_e_d _I_/_O (libav), если установлена. --ZZ||----ggzziippmm33uu88 [[ffaallssee]] создавать плейлисты, сжатые алгоритмом GZIP. --hh,, ----hheellpp,, --??,, ----ooppttiioonnss вывести краткое руководство по вызову из командной строки. То же будет сделано при запуске модуля без параметров. --qq||----qquuiieett [[ffaallssee]] минимальный вывод диагностики в STDERR. --KK,, ----ssyysskkeeyy сгенерировать системный ключ (для использования в лицензии) и закончить работу. ССООООББЩЩЕЕННИИЯЯ,, ИИДДУУЩЩИИЕЕ ННАА ССТТААННДДААРРТТННЫЫЙЙ ВВЫЫЫЫООДД ggxxsseegg(1) выводит мета-данные на STDOUT в виде однострочных сообщений следующих типов/форматов: ИИССТТООЧЧННИИКК - сообщение этого типа выводится первым, передавая адресату (приложению дальше по конвейеру) параметры потока, который данный процесс будет сегментировать. Формат сообщения таков: SS_s_t_r_e_a_m_I_D iinniitt [[~~]]_c_h_a_n_n_e_l_-_t_a_g ddaattaa__ddiirr==_r_o_o_t_-_d_i_r [[mmaaxx__sseecc==_s_e_c]] [[iitteemm__ppffxx==_p_r_e_f_i_x]] где _s_t_r_e_a_m_I_D: либо _c_h_a_n_n_e_l_-_t_a_g (-N), либо _p_i_d процесса (see -u); _i_n_i_t: тип сообщения; _~_(_t_i_l_d_e_): добавляется, если данный роцесс запущен в резерве (перед "заменой"); _c_h_a_n_n_e_l_-_t_a_g: параметр -N; _r_o_o_t_-_d_i_r:= параметр -S; _s_e_c:= параметр -a; _i_t_e_m_-_f_p_x:= параметр -3. Пример: Sprime1 init prime1 data_dir=data ССЕЕГГММЕЕННТТ данное сообщение передаёт данные о сегменте. Формат сообщения таков: SSEEGGMMEENNTT:: _p_a_t_h _t_i_m_e_s_t_a_m_p _d_u_r_a_t_i_o_n _s_i_z_e _n_u_m_-_i_d _P_T_S где _p_a_t_h: относительный путь к файлу; _t_i_m_e_s_t_a_m_p: UNIX время ннааччааллаа сегмента; _d_u_r_a_t_i_o_n: длительность в секундах; _s_i_z_e: размер файла; _n_u_m_-_i_d: идентификатор задачи шифрования (пока не используется); _P_T_S: PTS время ннааччааллаа сегмента; Пример: SEGMENT: prime1/7918931084.ts 1498837025 4.800000 6566088 0 7918931084 ААВВТТООРРЫЫ Pavel V. Cherenkov ССММООТТРРИИТТЕЕ ТТААККЖЖЕЕ ggppmm(1),wwuuxx(1),vvssmm(1),ffffmmppeegg(1) wux(1) wux (GigA+ адаптер поток-в-UNIX-сокет) Краткое руководство wux(1) ИИММЯЯ wux - утилита копирования входного потока в UNIX-сокет. ККООММААННДДННААЯЯ ССТТРРООККАА wwuuxx [-r] [-m _n_r_e_c_:_r_s_i_z_e] _u_n_i_x_-_s_o_c_k_e_t_-_p_a_t_h [_m_a_n_i_f_e_s_t_-_p_a_t_h] ООППИИССААННИИЕЕ wwuuxx читает данные из SSTTDDIINN и записывает их в надлежащий UNIX-сокет. Данные ожидаются в текстовом формате, и wwuuxx читает их построчно. Кроме того, каждая строка может быть занесена в отдельный (текстовый) файл-манифест. Манифест содержит текстовые строки в записях фиксированной длины, количество записей в самом манифесте ограничено. Когда количество записей достигает максимума, wwuuxx 'прокручивает' манифест, затирая самую старую запись. wwuuxx является частью инфраструктуры GigA+. В GigA+ wwuuxx используется vvssmm(1) для передачи сообщений между модулями ggxxsseegg(1) и ggppmm(1) Пользователям GigA+ нет нужды запускать wwuuxx напрямую (это делают иные модули). Тем не менее, знакомство с параметрами работы данной утилиты не будет лишним. wwuuxx не использует файла конфигурации, его поведение всецело регулируется параметрами командной строки. ППААРРААММЕЕТТРРЫЫ Обязательным параметром является путь к принимающему UNIX-сокету. Все данные, считанные из SSTTDDIINN будут записаны в этот сокет. Путь к файлу манифеста. Параметр необязателен, если манифест не требуется. При отсутствии этого параметра, данные не пишутся в манифест. ККЛЛЮЮЧЧИИ Ключи могут быть указаны в любом порядке, до или после имён файлов. Ключи без аргументов могут быть объединены под одним дефисом. --rr Ожидать ответа из сокета. Если данный ключ отсутствует, приложение не будет ожидать ответных данных в сокете. --mm _m_r_e_c_:_r_s_i_z_e Указывает два разделённых двоеточием значения: максимальное количество записей в манифесте и (фиксированный, в символах) размер записи манифеста. Если манифест используется приложением, то данный ключ ооббяяззааттееллеенн. Минимальный размер записи манифеста - 6644 символа. ППЕЕРРЕЕММЕЕННННЫЫЕЕ ССРРЕЕДДЫЫ Переменной IINNPPAATTHH может быть присвоен путь к текстовому файлу, заменяющему SSTTDDIINN. ААВВТТООРРЫЫ Павел В. Черенков ССММООТТРРИИТТЕЕ ТТААККЖЖЕЕ ggiiggaapplluuss(1),ggppmm(1),vvssmm(1) vsm(1) vsm - Краткое руководство vsm(1) ИИММЯЯ vvssmm - модуль управления подачей видеопотока. ККООММААННДДННААЯЯ ССТТРРООККАА vvssmm [-l logfile] specfile [gxseg-options] ООППИИССААННИИЕЕ vvssmm обеспечивает подготовку входного потока к доставке посредством протокола HLS. Сюда входит разбивка на сегменты, генерация метаданных, обработка оповещений, ошибок и внештатных ситуаций. В vvssmm встроено большое количество бизнес-логики. Внутри модуль представляет из себя скрипт, вызывающий различные утилиты GigA+ (ggxxsseegg, wwuuxx, hhooss, pprrbbssmm) и некоторые сторонние приложения для выполнения собственных задач. В качестве конфигурации используется обыкновенный UNIX-shell скрипт в дальнейшем называемый _с_п_е_ц_и_ф_и_к_а_ц_и_е_й _к_а_н_а_л_а (или просто "спецификацией"). Скрипт состоит из операций присваивания значений зарезервированным переменным среды. Каждый процесс vvssmm ответственен за один (определённый) канал. ППААРРААММЕЕТТРРЫЫ ssppeeccffiillee - это единственный обязательный параметр: путь к файлу _с_п_е_ц_и_ф_и_к_а_ц_и_и _к_а_н_а_л_а. NNBB:: Будьте внимательны к содержанию специфификации, поскольку это, по сути, скрипт, выполняющийся в контексте vvssmm, который может внести изменения так же, как и любой другой shell-скрипт. ННИИККООГГДДАА не запускайте vvssmm в режиме rroooott. Поскольку в этом нет никакой нужды. llooggffiillee - необязательный параметр, указывающий путь к логу приложения, куда будет перенаправлен весь вывод на консоль, в противном случае весь вывод идёт в _S_T_D_E_R_R. ggxxsseegg--ooppttiioonnss - необязательный параметр. Он позволяет передать собственные (дополнительные) параметры модулю ggxxsseegg. Зарезервирован для сложных кастомизаций поведения vvssmm. Не используйте без ккррааййннеейй ннааддооббннооссттии. ССППЕЕЦЦИИФФИИККААЦЦИИЯЯ ККААННААЛЛАА используется как конфигурация vvssmm. Пример с подробными комментариями поставляется вместе с приложением и должен находиться в _/_u_s_r_/_s_h_a_r_e_/_d_o_c_/_g_i_g_a_p_l_u_s_/_e_x_a_m_p_l_e_s_/_v_s_m_-_c_h_a_n_n_e_l_._s_p_e_c (на FFrreeeeBBSSDD следует сделать поправку на _/_u_s_r_/_l_o_c_a_l_/_s_h_a_r_e_/_._.). Пример можно использовать в качестве шаблона собственных спецификаций. Последующие секции дадут описание переменных среды, по сути, параметров спецификации канала. cchhaa__IIDD имя (идентификатор) канала. Данное имя в дальнейшем используется как часть пути к директории канала, поэтому рекомендуется не усложнять его и делать совместимым с именами директорий ОС. Пример: cha_ID="cinemax" cchhaa__GGPPMM путь к UNIX-сокету слушающего порта (метаданных источников) менеджера плейлистов GigA+ (ggxxppmm). ggxxppmm получает уведомления о генерации каждого из сегментов через UNIX-сокет. vvssmm устанавливает соединение с ggxxppmm последством модулей ggxxsseegg и wwuuxx. Пример: cha_GPM="/tmp/gpm-S.sock" cchhaa__UURRLL URL (в ffmpeg-совместимом формате) источника данных канала. Пример: cha_URL="udp://224.0.2.26:5050" cchhaa__RROOOOTT путь к корневой директории верхнего уровня. Данный путь ННЕЕ ддооллжжеенн включать в себя идентификатор канала, поскольку _c_h_a___I_D используется для построения пути к директории канала внутри vvssmm. Например, если _c_h_a___R_O_O_T="/opt/data", то путь к директории канала - /opt/data/${cha_ID}. Пример: cha_ROOT=/opt/data cchhaa__PPFFXX префикс для URL данного канала, используемый в дальнейшем ggxxppmm в плейлистах. Канал может указать свой "собственный" префикс в спецификации. В противном случае будет использован общий префикс, указанный в конфигурации ggxxppmm. Пример: cha_PFX="http://myown.tv:8181/seg/" cchhaa__SSHHAARRDDSS список директорий (с двоеточием в качестве разделителя) подразделов ("шардов") для хранения сегментов данных. Данный параметр ннееооббяяззааттееллеенн, и в его отсутствие данные не распределяются по разделам. Если же разделы указаны, то данные будут поровну распределены по "шардам". Например, при cha_ROOT=_/_o_p_t_/_d_a_t_a и cha_ID=_t_v_5, cha_SHARDS="_v_o_l_1_:_v_o_l_2" сегменты будут поочерёдно поступать в директории _/_o_p_t_/_d_a_t_a_/_v_o_l_1_/_t_v_5 и _/_o_p_t_/_d_a_t_a_/_v_o_l_2_/_t_v_5 Пример: cha_SHARDS="vol1:vol2:vol3" cchhaa__CCAAPPAACCIITTYY определяет количество _с_е_к_у_н_д содержимого канала для хранения. Этот параметр - ключевой для _D_V_R, поскольку он определяет размер "временного окна". vvssmm передаёт данный параметр ggxxppmm, который затем удаляет "просроченные" сегменты в реальном времени. В начеле работы же, если указан параметр cchhaa__HHOOSS (см. ниже), vvssmm запускает утилиту hhooss и даёт ей возможность очистить канал от "просроченных" сегментов. Пример: cha_CAPACITY=14400 cchhaa__DDUURRAATTIIOONN длительность сегмента в секундах, переопределённая для данного канала. Данный параметр ннееооббяяззааттееллеенн, значение по умолчанию - 55 ссееккуунндд. Пример: cha_DURATION=6 cchhaa__GGRRAANN__MMAASSKK определяет маску по временным параметрам для поддиректории внутри хранилища канала. Формат маски должен следовать спецификации для функции ssttrrffttiimmee(3) в POSIX API. Если параметр определён, для каждого сегмента определяется поддиректория согласно текущему времени и указанной маске. Например, при cha_GRAN_MASK="_%_Y_%_m_%_d_-_%_H", сегмент, сгенерированный 6-го июля 2017 г. в 3:56 дня будет помещён в поддиректорию _2_0_1_7_0_7_0_6_-_1_5. Если cha_ROOT=_/_o_p_t_/_d_a_t_a, а cha_ID=_t_v_5, то полный путь к директории сегмента станет: _/_o_p_t_/_d_a_t_a_/_t_v_5_/_2_0_1_7_0_7_0_6_-_1_5 (без шардинга) и _/_o_p_t_/_d_a_t_a_/_v_o_l_1_/_t_v_5_/_2_0_1_7_0_7_0_6_-_1_5 для первого шарда, если cha_SHARDS="_v_o_l_1_:_v_o_l_2". Пример: cha_GRAN_MASK='%Y%m%d-%H' cchhaa__HHOOSS указывает путь к утилите "чистки", запускаемой vvssmm при старте. GigA+ предоставляет свою собственную утилиту (hhooss) для подобных работ, тем не менее, её можно заменить собственным приложением. hhooss отвечает за то, чтобы размер хранилища канала не переполнялся сверх меры, очищая его от "просроченных" сегментов, осуществляя ротацию и архивацию логов и т.п. Если же параметр _c_h_a___H_O_S не указан, подобной "чистки" ннее ппррооииззввооддииттссяя. Подробная информация содержится на сттранице hhooss(1) документации. Example: cha_HOS="hos" cchhaa__MMIITTEEMMSS указывает максимально допустимое количество элементов в _м_а_н_и_ф_е_с_т_е, который ведёт утилита wwuuxx для данного канала. _М_а_н_и_ф_е_с_т _к_а_н_а_л_а - это просто список недавно сгенерированных сегментов данных. ggxxppmm в курсе о манифесте и пытается загрузить его, когда начинает работу с каналом. Это делается чтобы "догнать" канал, который был некоторое время отключен или же "рухнул" (по какой-то причине). Манифест также позволяет ggxxppmm обработать метаданные сегментов, сгенерированных за время, пока ggxxppmm не был в работе. Параметр устанавливает количество элементов в манифесте, ротацию которого осуществляет wwuuxx по принципу FIFO. Если же _c_h_a___M_I_T_E_M_S не указан, то для данного канала ммааннииффеесстт ннее ссооззддааёёттссяя. Пример: cha_MITEMS=2800 cchhaa__MMAAXX__CCEERRRR указывает максимальное количество пропускаемых (критических) ошибок. В некоторых потоках различные аномалии заставляют процедуры ввода-вывода библиотеки lliibbaavv выдавать критические ошибки (как, к примеру, EOD = конец данных). Данный параметр позволяет ре-стартовать цикл ввода-вывода N раз, не прерывая программы. vvssmm устанавливает данный параметр по умолчанию в 55 ((ппяяттьь)). Значение --11 позволяет игнорировать все ошибки ввода-вывода. Пример: cha_MAX_CERR=5 ВВААЖЖННОО:: Пропуск ошибок ввода-вывода означает утечки памяти (скажем спасибо разработчикам библиотеки lliibbaavv). Чем больше значение N, тем больше возможная потеря памяти на данном канале при частых сбоях. Оптимальное значение данного параметра варьируется в зависимости от канала. cchhaa__EERRRR__BBAADDTTIIMMEE указывает максимальное количество последовательных ошибок PPTTSS//DDTTSS, позволяемых ggxxsseegg(1) в процессе обработки потока. Суть ошибки - в получении API библиотеки _l_i_b_a_v некорретных значений PTS/DTS (временных маркеров в пакете MPEG-TS). В логах ggxxsseegg ошибки подобного рода отображаются так: pkt: rc=-28 stream0 buf=0x0/0 pts/dts=-9223372036854775808/-9223372036854775808 cchhaa__LLMMAARRKK__DDIISSKKSSIIZZEE указывает размер канала (сегментов и мета-данных) при полной загрузке (по прошествии cha_CAPACITY секунд). ВВннииммааннииее: hhooss не будет архивировать сегмента пока размер канала не достигнет данной величины. cchhaa__HHMMAARRKK__DDIISSKKSSIIZZEE указывает максимальный возможный размер канала. При превышении данного значения hhooss попытается остановить vvssmm канала. cchhaa__RROOLLLLOOVVEERR устанавливает количество _с_е_к_у_н_д между двумя последовательными "заменами". Процесс vvssmm, проработав N секунд, заканчивает работу, будучи "заменён" другим (недавно стартовавшим), обслуживающим данный канал. Это делается, чтобы скомпенсировать внутренний недостаток ffm‐ peg библиотек _l_i_b_a_v, которые (издавна, по какой-то причине) просто неспособны к непрерывной работе (24/7) и со временем начинают "задыхаться". Итак, "старый" vvssmm завершает работу, а новый процесс принимает на себя задачи старого. Данный параметр устанавливает, как часто происходят подобные "замены". Если параметр не указан, ""ззааммеенн"" ннее ппррооииссххооддиитт. Иной способ регулировать частоту "замен" состоит в вызове (поставляемого с продуктом) скрипта ffoorrccee--rroolllloovveerr..sshh, который должен после установки оказаться в директории _/_u_s_r_/_s_h_a_r_e_/_g_i_g_a_p_l_u_s_/_s_c_r_i_p_t_s (под Linux, _/_u_s_r_/_l_o_c_a_l_/_s_h_a_r_e_/_._._. под FreeBSD). Регулируйте вызовы скрипта через ccrroonnttaabb(1) для наибольшей гибкости частоты и времени "замен". Пример: cha_ROLLOVER=7200 cchhaa__FFAALLSSEE__RROOOOTT указывает путь к директории, в которой "новый" процесс vvssmm хранит данные канала до "замены". Между запуском "нового" процесса и момента "замены", когда "старый" процесс заканчивает работу, проходит некоторое время. В это время оба процесса vvssmm находятся в рабочем состоянии, но только мета-данные "старого" процесса учитываются ggxxppmm. До ухода "старого" процесса, "новому" требуется директория для хранения собственных сегментов данных. На последний сгенерированный сегмент "нового" процесса затем создаётся ссылка в директории данных канала (т.е. директорию, указанную в cha_FALSE_ROOT, нельзя просто очистить после "замены"). Пример: cha_FALSE_ROOT=/opt/bvt-hls/fake cchhaa__PPRRBB указывает путь к утилите "пробы" потока, позволяющей определить, идут ли данные по данному каналу. vvssmm требуется знать, когда канал "отключён от эфира" и передача данных по нему прекращена. Важно отличать данную ситуацию "вне эфира" от иных, поскольку реакцией на иные внештатные ситуации может быть окончание работы vvssmm c кодом ошибки. GigA+ поставляет собственную утилиту "пробы" - pprrbbssmm, но вам предоставлена возможность заменить её своим собственным скриптом или приложением. Если же параметр _c_h_a___P_R_B отсутствует, vvssmm заканчивает работу, если "считает", что канал "отключен от эфира". Пример: cha_PRB=prbsm cchhaa__AADDMMIINN__EEMMAAIILL указывает адрес эл. почты администратора (канала), по которому vvssmm рассылает оповещения о важных событиях, таких как: начало и завершение работы, отключение от эфира из возвращение канала в эфир. Если же параметр отсутствует, оповещения не посылаются. Example: cha_ADMIN_EMAIL='admin@myown.tv' cchhaa__TTRRAANNSSOOPPTT обозначает опции командной строки, передаваемые ffffmmppeegg(1) для перекодировки входящих данных канала, до разбивки на сегменты. Данный подход к перекодировке несомненно упрощённый и должен применяться только в простейших сценариях, таких как перекодировка аудио-потоков внутри канала в нужный кодек. Если данный параметр указан, vvssmm перенаправляет вывод от перекодирующего ffffmmppeegg в ggxxsseegg. Пользуйтесь на своё усмотрение и на собственный страх и риск, не забывайте ппррооттеессттииррооввааттьь опции, прежде чем включать их в спецификацию. Пример: cha_TRANSOPT="-map 0:0 -map 0:1 -map 0:2 -map 0:3 -vcodec copy -c:a mp3 -c:s copy" ААВВТТООРРЫЫ Pavel V. Cherenkov ССММООТТРРИИТТЕЕ ТТААККЖЖЕЕ wwuuxx(1),ggxxppmm(1),hhooss(1),ffffmmppeegg(1),ccrroonnttaabb(1),ggxxsseegg(1) vsm-scripts(5) vsm-scripts - Краткое руководство vsm-scripts(5) ККРРААТТККААЯЯ ИИННФФООРРММААЦЦИИЯЯ Эта страница описывает дополнительные скрипты - hhooss, pprrbbssmm and ffoorrccee--rroolllloovveerr..sshh -. используемые модулем сегментирования потоков vvssmm(1) в GigA+. ООППИИССААННИИЕЕ Модуль vvssmm(1) включает в себя множество бизнес-логики, но отдельные его функции были делегированы сторонним скриптам. Одной из причин этого шага было дать возможность пользователям изменять как логику, так и исполнение сторонних компонентов и, возможно, использовать иные языки разработки для достижения наибольшего эффекта. Вот эти компоненты: hhooss утилита "чистки" данных канала, запускаемая vvssmm в начале работы. Утилита следит за тем, чтобы данные канала не разростались выше предела, определённого в спецификации канала (см. _c_h_a___C_A_P_A_C_I_T_Y in vvssmm(1) documentation). hhooss обособлен от vvssmm в том числе и для того, чтобы его можно было запускать вручную или же как задачу для ccrroonn(8) ППААРРААММЕЕТТРРЫЫ hhooss OPTIONS _c_h_a_n_n_e_l_-_t_a_g hhooss требует лишь один параметр: _c_h_a_n_n_e_l_-_t_a_g краткое имя (идентификационный тэг) канала, как, например, _c_a_b_l_e_1. По данному тэгу hhooss найдёт спецификацию канала и считает оттуда нужные параметры. ООППЦЦИИИИ ----tteerrmm не создавать лог, посылая вывод только в терминал. По умолчанию, hhooss создаёт лог в корневой директории канала и копирует туда все сообщения, посылаемые в STDERR. Данная опция запрещает создание лога. --tt _N_-_s_e_c стирать сегменты старше, чем N секунд. --nn эмуляция прогона (подобно make -n), печатать команды, но не выполнять. --LL потребовать ротацию лога vvssmm. Посылает сигнал о ротации лога соответствующему данному каналу процессу vvssmm(1) ----ssyyssrreepp включать _о_т_ч_ё_т _о _с_о_с_т_о_я_н_и_и _О_С в начало каждого прогона. Отчёт состоит из вывода приложения vvmmssttaatt(8) и распечатки таблицы процессов от ppss(1) , что увеличивает размер лога, но может пригодиться, если сервер окажется перегружен (из-за недостатка ресурсов или же по иной причине). Используйте данную опцию по обстоятельствам. ----mmiinnffrreeee _M_B посылать оповещение, если количество свободной (физической) памяти становится ниже данного лимита. Позволяет установить минимальный размер памяти ОЗУ для работы приложений. Измеряемая память - это не задействованная ОС (в т.ч. как кэш) физическая память. Система (в принципе) может работать и при нулевом её значении. Пример: hos --term --sysrep -L cable1 pprrbbssmm проверяет, передаются ли по каналу данные, т.е. можно ли считать его в _Э_Ф_И_Р_Е или же _О_Т_К_Л_Ю_Ч_Е_Н_Н_Ы_М. vvssmm(1) использует данную утилиту, чтобы отличить отключенный канал от работающего со сбоями или ошибками. Если vvssmm обнаруживает, что канал был ОТКЛЮЧЕН, то шлёт оповещение об отключении администратору, а затем ожидает появления канала в эфире. ППААРРААММЕЕТТРРЫЫ pprrbbssmm [-v] [-p sec] input-url [once|stabilize] pprrbbssmm требует лишь один параметр: iinnppuutt--uurrll - совместимый с ffffmmppeegg(1) URL канала-источника. ООППЦЦИИИИ --vv вывод детальной информации. --pp _s_e_c пауза (в секундах) между проверками. oonnccee||ssttaabbiilliizzee одиночная проверка (once) или проверять вплоть до возвращения канала в эфир (неограниченное количество проверок). Пример: prbsm -p 5 http://acme.tv:4040/udp/224.0.2.26:5050 stabilize ffoorrccee--rroolllloovveerr..sshh инициирует процесс "замены" vvssmm. Скрипт был обособлен, чтобы процесс "замены" мог быть инициирован в нужное время через ccrroonnttaabb(1) ППААРРААММЕЕТТРРЫЫ ffoorrccee--rroolllloovveerr..sshh _c_h_a_n_n_e_l_-_r_o_o_t_-_d_i_r требует начала "замены" на канале, ассоциированном с данной директорией. Пример: force-rollover.sh /opt/channels/cnn ААВВТТООРРЫЫ Pavel V. Cherenkov ССММООТТРРИИТТЕЕ ТТААККЖЖЕЕ vvssmm(1),ggppmm(1),ccrroonnttaabb(1),ffffmmppeegg(1) Version 0.1 19 сентября 2017 vsm-scripts(5)