Извините, мой просчёт (одной рукой правим, другой портим) - выложил новый архив исходников: 37-1.Originally Posted by Oleg
Senior Member
выложен новый файл 37-1.tgz
Извините, мой просчёт (одной рукой правим, другой портим) - выложил новый архив исходников: 37-1.
Registered User
Приветствую!
С восхищением пользую последнюю прошивку (1.9.2.7-10) на WL500W, спасибо Олегу и соратникам ). Давно хотел расшарить дома иптв, пробовал сам на линуксовом шлюзе - не заборол, а тут такое счастье )
счастье пока вышло непостоянным,
исходные - локалка, статичный внутренний ип, иптв в тестовом режиме, техподдержка не комментирует). WL500W новый/свежепрошитый без допсофта, очевидно не сильно загруженный.
результат: iptv player напрямую с провода провайдера показывает великолепно, глюки квадратные) очень редки. В режиме роутинга мультикаста получаем глюки чаще, беспроводной сегмент загибается. В режиме прокси работает великолепно на 1 клиенте, при подключении второго картинка на первом рассыпается, глючат оба постоянно. Когда загружена сеть провайдера (днём) нормально не работает и 1 клиент - постоянные сбои..
в логах в основном подобное сообщение:
Mar 31 18:39:58 udpxy[141]: write_buf: write: Connection reset by peer
изредка:
Mar 31 14:52:11 udpxy[131]: read_buf: read: Resource temporarily unavailable
Mar 31 21:47:34 udpxy[189]: write_buf: write: Resource temporarily unavailable
Читал, что иногда провайдеры борются с клиентским роутингом посредством низкого значения TTL - может есть смысл копать сюда..?
помогите советом, спасибо )
Senior Member
гадание на udpxy
Желательно получить весь журнал в режиме отладки (-v), конечно, а пока - лишь размышления.
означает, что клиент прервал соединение.write_buf: write: Connection reset by peer
Прервал он его, скорее всего потому, что долго и безрезультатно ждал данных от udpxy, которых тот не послал вовремя. Паачэму нэ послал ?!- Думаю (гадаю), при такой загрузке сети данные с multicast идут с перебоями и udpxy ждал, пока ему придёт достаточно данных, чтобы отправить клиенту весь буфер (комбинация -B len, -R num определяет размер этого буфера). Ждал долго, и клиент таки не дождался и обрубил соединение - такой вот сценарий напрашивается. Как проверить? - Уменьшить буфер путём вариации значений параметра -R num (см. предыдущие посты). Повторюсь, но -R 1 отменяет буферизацию как таковую (но и это не гарантирует избавления от сбоев, если данные по multicast будут долго не доходить до роутера) - следовательно, разница в поведении должна быть (меньше записей connection reset by peer). Прошу проверить эту гипотезу.
Если гипотеза оправдается, то сделаю внутренний тайм-аут для буфера, при котором udpxy пошлёт всё, что было (сейчас есть тайм-аут на получение данных по мультикасту (read_buf: read: Resource temporarily unavailable), но он достаточно большой - 5 секунд, но, видимо, клиенту хватает и меньшего времени, чтобы оборвать соединение. Тайм-аут можно сделать и параметром, если будет на то нужда.
Сообщите о результатах проверки - постараюсь помочь.
Senior Member
K вопросу оптимизации: когда несколько юзеров смотрит один канал - запущено несколько процессов потребляющих примерно одинаковое количество CPU, собственно мысль: почему бы при таком условии не отдавать уже преобразованный ( 'родительским' процессом) поток, а не преобразовывать для каждого одно и то же.
P.S. возможно так и делается, исходники пока не копал, выводы из внешних наблюдений
P.P.S для 'разгрузки' прикрутил icecast (шибко не смеяться, видеопоток неоднократно получалось им relay-ить), поток, зараза, дампит нормально, если wget-ом (уже с icecast-a) забирать - тоже полученный файл нормально смотрится плеерами, а в реалтайме если подключаться - не показывает...
Senior Member
об оптимизации
Нет подобной оптимизации - но дискуссии об этом были (с _oz_) ещё при зарождении udpxy, и победило стремление к простоте архитектуры (а то ведь, знаете, так и .NET можно написать, начав с hello world- если бес попутает).
Тогда рассуждения, помнится, привели нас к мысли, что такой мощности устройство наврядли будет способно поддержать много клиентов, а уж вероятность при этом, что из клиентов N>1 будет смотреть один и тот же канал - ещё меньше. Так вот, стоит ли огород городить? Ситуация, мне кажется, с двумя одинаковыми каналами - не совсем стандартная, так пусть скажут те, кто действительно пользуется "многоклиентностью" не на шутку - нужно ли?
Last edited by bsl45; 01-04-2008 at 07:10.
Senior Member
UDPXY в прошивке 1.9.2.7-10 на WL500W работает чудесно (еще раз хочу поблагодарить bsl45 за столь нужный и качественный продукт), одновременно у меня может смотреть 3 клиента (xbox 360, и два ноута) НИКАКИХ проблем на WL500W не замечено. картинка чистая, без глюков, даже если смотреть разные каналы, или если все смотрят 1. (все сразу не пробовал, а вот 2 ноута один и тот же канал показывают очень хорошо) Xbox смотрит по проводу, ноуты по wifi.
Senior Member
Так прога не только на асусе может работать, но и на более злой машине, а оптимизация в любом случае не повредит...
Ещё попутно думаю чем-бы зарелеить http видеопоток, icecast как уже писал, не помог...
Registered User
а не могли бы вы чуть поподробнее рассказать як вы бокс подружили с wl'ом?
Last edited by serioja; 01-04-2008 at 13:38.
Senior Member
так эта - плейлист в него загнал типа
http://192.168.1.1:81/udp/233.233.233.233:5000/tv.mpg
и он стал хавать его.
Собственно я изначально это делал по этому описанию, а потом появился замечательный udpxy и стало все проще.
Last edited by catmat; 01-04-2008 at 14:32.
Registered User
так там же про первый бокс-то написано, а вы говорите, что у вас 360й... или там просто руками вдалбливать каждый канал?
Senior Member
Переход на раздачу "разделяемых" видеопотоков влёчёт весьма ощутимые изменения в архитектуре: дополнительный тред/процесс на каждый потребляемый канал + синхронизация. Если это действительно востребовано пользователями и оправдано сокращением расхода ресурсов процессора - будем имплементировать. А прежде, чем оптимизировать, надо бы обосновать (как с любой оптимизацией). В связи с чем хотелось бы получить выкладки на расход ресурсов CPU udpxy на wl500g при N>1 клиенте на одном канале.
Я у себя на "злом" копьютере попробовал, так, признаться, его не "впечатлило" - расход ресурсов CPU оказался ничтожен на каждый клиентский процесс.
Senior Member
Насчет востребовано ли пользователями асуса - наврядли, конечному юзеру по барабану сколько там процессов, лишь бы казало картинку, тут скорее кодерская привычка чтонить заоптимизить
Senior Member
Чтобы не вдаваться в философию, проясню свою точку зрения: опитмизировать будем, как только станет ясным, что затраты на оптимизацию адекватны желаемому эффекту. Востребованность в данном случае выражается в том, что (многие) пользвователи скажут: да, мы часто смотрим много одинаковых каналов через udpxy, и потребление ресурсов сильно снижает производительность устройства.Насчет востребовано ли пользователями асуса - наврядли, конечному юзеру по барабану сколько там процессов, лишь бы казало картинку, тут скорее кодерская привычка чтонить заоптимизить
Идея сделать всё оптимальным мне знакома, но простота и надёжность - прежде всего (особенно на устройстве). Текущая архитектура требует минимум синхронизации (отсюда простота, масштабируемость и скорость) и обеспечивает максимум изоляции (автономность, надёжность). Потому и не хочется ломать без веской причины.
Senior Member
Так можно и вообще не ломать саму прогу, а организовать перед ней некий отдельный icecast-style кеш-рекордер-репитер, a-ля 'tcpxy'
При этом станет возможно использовать его вообще отдельно, и релеить/записывать видео/радио потоки...
Senior Member
Можно и так, если будет на то желание общественности. На запись желание было - и запись теперь есть (udpxrec). Будут конкретные потребности и соответствующие (насущные) сценарии применения - будем решать вопрос.Так можно и вообще не ломать саму прогу, а организовать перед ней некий отдельный icecast-style кеш-рекордер-репитер, a-ля 'tcpxy'
При этом станет возможно использовать его вообще отдельно, и релеить/записывать видео/радио потоки...
Posting Permissions
Reply With Quote