MiO Опубликовано 10 мая, 2014 · Жалоба Всё делает прога сама и выдаёт детальную статистику по абоненту в виде: 192.168.10.11:51958 (192.168.10.11:51958) [conn time: 0+01:30:42, flags: 775, cc: htcp, maxseg: 1348, snd_block_min_size: 64 kb, precache: 4096 kb, data to send: 1104 kb] [user agent: RealtekVOD/1.0.0 (Linux)] TCP FSM state: SYN_SENT ca_state: 0 retransmits: 0 probes: 0 backoff: 1 Options enabled on conn: TIMESTAMPS SACK WSCALE RFC1323 send shift value: 1 RFC1323 recv shift value: 10 Retransmission timeout (usec): 220000 ato (usec): 40000 Max segment size for send: 1348 Max segment size for receive: 536 unacked: 0 sacked: 0 lost: 0 retrans: 0 fackets: 0 last_data_sent: 308 last_ack_sent: 0 Time since last recv data (usec): 5442464 last_ack_recv: 88 pmtu: 1500 rcv_ssthresh: 30032 rtt: 22000 rttvar: 21000 snd_ssthresh: 8 snd_cwnd: 10 advmss: 1448 reordering: 3 rcv_rtt: 0 rcv_space: 28960 total_retrans: 1356 вот конкретно total_retrans, означает что какие-то пакеты до абонента не дошли и были перепосланы (проблема может быть правда в чём угодно, начиная от WIFI заканчивая флоу контролем...) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maxlapshin Опубликовано 10 мая, 2014 · Жалоба Нет, это ретрансмиты уже на http. Я про захват UDP Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 10 мая, 2014 · Жалоба Нет, это ретрансмиты уже на http. Я про захват UDP Если только в статистике самой ОС их нарыть. СС считает, crc32 для psi тоже. PID: 0 [Packets: 881, Size: 165628, Scrambling: 0, TE count: 0, CC errors: 1, CRC32 errors: 0, Data errors: 0] PID: 17 [Packets: 53, Size: 9964, Scrambling: 0, TE count: 0, CC errors: 0, CRC32 errors: 0, Data errors: 0] PID: 18 [Packets: 606, Size: 113928, Scrambling: 0, TE count: 0, CC errors: 1, CRC32 errors: 0, Data errors: 0] Programm: 12101 [PID: 3301, Data PIDs count: 2] PID: 3301 [Packets: 319, Size: 59972, Scrambling: 0, TE count: 0, CC errors: 2, CRC32 errors: 0, Data errors: 0] PID: 321 [Packets: 212122, Size: 39878936, Scrambling: 0, TE count: 0, CC errors: 1, CRC32 errors: 0, Data errors: 0] PID: 401 [Packets: 16172, Size: 3040336, Scrambling: 0, TE count: 0, CC errors: 1, CRC32 errors: 0, Data errors: 0] Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maxlapshin Опубликовано 10 мая, 2014 · Жалоба Из /proc/net/udp оказалось очень полезно прочесть. Там несложно парсится и можно к каждому захватывающему сокету привязать статистику. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Барагоз Опубликовано 10 мая, 2014 · Жалоба из минусов (не существенных): 1. раньше потребляли столько мультикаста сколько каналов смотрят - щас из-за того что всё каналы кэшируются потребляем сразу всё Минус всё-таки очень существенный. У меня, например, бОльшая часть каналов просто так для ассортимента, реально смотрят абоненты процентов 20 из них, и если я с аплинка начну потреблять сразу все, всё умрёт напрочь, т к канал на это не рассчитан. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maxlapshin Опубликовано 10 мая, 2014 · Жалоба А чего, ondemand не может? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 10 мая, 2014 · Жалоба OnDemand может, но тогда не будет прекеша и каналы будут заметно дольше включатся (для первого кто включил канал), как на обычном udpxy. Есть и крутилки: - сколько времени держать канал после отключения последнего клиента который этот канал смотрел; - ждать или нет накопления прекеша для первого клиента. Если сеть своя, и есть узкий канал, то можно поставить мсд с обеих сторон, с одной настроить OnDemand по tcp-http на другой мсд, а с другой чтобы мсд постоянно каналы держал, и получится что прекеш будет довольно шустро прилетать и через узкий канал будет по одному tcp потоку на каждый канал который смотрят, те дубликации потоков на каждого не будет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maxlapshin Опубликовано 11 мая, 2014 · Жалоба Ну tradeoff понятен: в режиме ondemand только HLS быстро стартует. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 11 мая, 2014 · Жалоба Это если аплинк хлс даст, а так будет цедить мультикаст как обычный udpxy. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Helios Опубликовано 15 мая, 2014 · Жалоба а будет возможность резервирования источников? Допустим 2-3 мультикаст группы и определенные правила по переключению на вторую-третью и обратно если одна отвалилась? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 15 мая, 2014 · Жалоба а будет возможность резервирования источников? Допустим 2-3 мультикаст группы и определенные правила по переключению на вторую-третью и обратно если одна отвалилась? Будет, но там есть нюансы: если у вас mpeg2-ts поток различается в источниках (те pid-ы и прочая служебная начинка) то клиентов скорее всего нужно будет скинуть, для их же блага. Если поток одинаковый то можно не скидывать. Касательно правил, какие примерно вам нужны? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Helios Опубликовано 16 мая, 2014 · Жалоба - поток пропал - поток стал "пустой" (ниже определенного битрейта) - поток стал "с ошибками" (если возможно анализировать качество потока) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 16 мая, 2014 · Жалоба кстати, было бы круто на события "поток пропал", "поток с ошибками" и т.д. запускать внешние скрипты, можно было бы запилить простенькую систему оповешения Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
and_cesbo Опубликовано 17 мая, 2014 · Жалоба Резервирование источников есть в Астре : https://cesbo.com/solutions/streaming/ можно указать любое количество источников разного типа (DVB,UDP,RTP,HTTP,Файлы) переключение будет происходить по порядку на основе данных от встроенного анализатора (Нет потока, Поток зашифрован, Низкий битрейт, Также можно установить лимит потерь пакетов при котором происходит переключение на резерв). В расширенной версии вся информация передаётся на систему мониторинга. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Helios Опубликовано 21 мая, 2014 · Жалоба еще хочется чтобы можно было бить выходные http потоки по tcp портам, а не толко по URL. удобнее файрволом ограничивать доступ абонентам Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 6 ноября, 2014 · Жалоба Добавил Lite версию в шапку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...