catBasilio
23-01-13 21:05
реквестирую поддержку плеером соответствующей прокси для сетевой папки вашего сайта, чтобы upd потоки вида 123.123.123.123:1234 сам редиректил на http://my_proxy_ddress:9090/udp/123.123.123.123:1234, чтобы не нужно было снифать соответвующие урлы с сетевой папки и править их вручную.

чтобы на подобии SimpleTV было.
Admin
23-01-13 21:18
плеер - он клиент а не сервер
HEOH
23-01-13 21:19
catBasilio переведи на понятный, обычным юзерам язык....
catBasilio
23-01-13 21:53
непонял на счет сервера? в настройках SimpleTV (он тоже плеер и тоже клиент)можно задать адрес прокси, и когда из плейлиста он читает строку вида udp://bla.bla.bla:1234 он ее автоматически преобразует и обращается к серверу по адресу http://my_proxy_addr:port/udp/bla.bla.bla:1234
смысл чтобы не править руками плейлисты.

2HEOH: iptv в локальной сети обычно распространяется по udp (широковещательные пакеты данных, которые принимают все компьютеры с подсети). но если телевизор подключен по wifi, то роутер генерирует лавину широковещательных пакетов всем доступным устройствам и wifi захлебывается от этой лавины. поэтому на домашнем роутере ставится некой преобразователь из широковещательных udp пакетов в обычные tcp, адресованные конкретному устройству. из-за отсутствия широковещательных пакетов wi-fi не захлебывается и по телевизору нормально можно смотреть видео.
Admin
23-01-13 22:06
теперь понятно
конкертные предложения есть?
vag
23-01-13 23:03
catBasilio, у вас не совсем верное представление от работе протоколов, в частности UDP.
Понятие широковещательного запроса (пакета, адресуемого "всем" интрефейсам) никак не связано ни с UDP ни с TCP, точнее в данном случае оба протокола имеют широковещательные пакеты (уровня L2 и L3, т.е. в физическом сегменте сети).
Также, у вас несколько не корректное представление о трансляции IPTV в локальных сетях/сетях провайдера. Широковещательные пакеты (в исходном смысле этого слова) не используются для трасляции данных видео. Мало того, сами ссылки вида udp://a.b.c.d:1111 - говорят о сокетной сути соединения (конкретный получатель (а не "все" - т.е. не широковещательный), конкретный порт (т.е. не 0 )). Поэтому ваше объяснение не корректно.
Для широкополосной (не широковещательной) групповой передачи данных потоков используется протоколы группового управления- протокол группового управления в Интернете (Internet Group Management Protocol, IGMP) Подробности о нем вы можете найти, напримре в википедии и в специализированных источниках.

Вернемся к сути проблемы (назначении) проксирования UDP в TCP.
Тут преследуестся совершенно другая цель.
Для начала:
UPD -протокол передачи пользовательских дейтаграм, не нацелен на соединение. Иными словами UDP не контролирует и не знает дошел пакет до потребителя (ТВ) или нет. Он работает быстрее (нет потребности в получении уведомлений о том, что пакет дошел), но хорош на небольших дистанциях ИЛИ качественных сетях, т.е где потеря пакета крайнемаловероятна...
TCP -Transmission Control Protocol - протокол нацеленный на соединение. Перед передачей данных два усройства обязаны "договориться" и далее каждый переданный пакет в обязательном порядке должен быть подтвержден получающей стороной. Если подтвержение не получено или пакет пришел с неправильными данными (контрольной суммой), то передающая сторона ЕЩЕ РАЗ передает то же потерянный пакет. Таким образом TCP "гарантирует доставку" данных (как минимум знает доставлены данные или нет), а UDP - не гарантирует доставку.
Имеено в этом кардинальная разница и собственно говоря "суть" проксирования UDP в TCP.

Резюме:
Для некачественной сети (в частности слабый WiFi, большие расстояния, много сетевых устройств) UDP не способен корректно передать все данные без потерь.
Для качественной сети (вероятность потерль данных близка к нулю) UDP ошутимо предпочтительнее, поскольку существенно меньше нагружает сеть и в результате работает ощутимо быстрее.

В итоге, трансляция UDP c "дальнего источника" (например от вас из Москвы, до меня в Ростов) будет происходить с большой потерей данных. Если сделать тоже самое но в TCP - ВСЕ ДО ЕДИНОГО пакета буду доставлены от вас ко мне (обрывы кабеля и пр. катаклизмы мы исключаем).

Проксирование имеет смысл в точке перехода "источник-граница качественной сети" ======"плохая сеть".

Надеюсь я смог популярно разъяснить суть и задачи проксирования (он полезно, но только при определенных условиях)
catBasilio
23-01-13 23:09
2vag:
что такое UDP и TCP я знаю. Но ваше описание проблемы тоже неправильное.
так моя домашняя сеть смеет следующую структуру


цитата:
[provider]---ethernet ---[home nub with wi-fi]---wifi---[TV]
так вот, расстояние от wi-fi роутера до телевизора - 2 метра(правда через стену). сигнал очень сильный, так что udp пакеты тут точно не теряются. расстояние от [provider] до дома - 3 километра. и udp пакеты тут тоже не теряются. Но!!! если смотреть iptv через wifi и по udp то wifi канал засоряется так, что ни одно устройство больше работать с сетью не может. так на ноутбуке яндекс даже не открывается. а при http все работает нормально. на роутере статистика потерянных пакетов == 0. так что тут дело не в плохой сети.
catBasilio
23-01-13 23:30
2admin
предложения есть!
в настройках TheDark media center добавить чекбокс "использовать прокси"
и пункт с адресом самого прокси и порта. и при парсинге плейлиста заменять udp-шные протоколы на адрес прокси.
vag
23-01-13 23:41
Я не затрагивал вопросы работы стеков этих двух протоколов.
В случае работы устройстройства в сокете TCP обработка данных в обязательно порядке идет через конвейер стека (иными словами последовательность поступления пакетов не совсем важна - они всегда соберутся в исходной последовательности, поскольку каждый пакет TCP одного содинения имеет сквозную нумерацию (квитирование/квитанцию)).

Подробности, например здесь
У UDP сборка данных из пакетов происходит несколько иначе. Гарантий сборки - нет.
В добавок ко всему у UDP используется мультиплексирование при передачи данных, что вносит "сумятицу" и дополнительно нагружает канал передачи данных (среду). В результате ТВ "рассыпает" картинку Подробности о UDP например здесь

catBasilio, посмотрите, включена или у вас поддержка протокола IGMP и корректно ли ТВ (точнее просматриваемый канал данных) включается в группу подписки. Некотрые роутеры (обычно решения выше SOHO) это показывают в логах групповых соединений.
Если протокол не поддержан/не включен или в "квартиру валит" весь UDP трафик порта WAN (характерно для виртуальных соединений интерфеса WAN и LAN роутера типа "мост"(bridge)) это ощутимо усугубит ситуацию передачи данных (засорения канала).

Также, обратите внимание, что близкое расстояние источник-приемник WiFi, повышенная мощность передатчика, работа на том же частотном канале что и ваш сосед, металиические экранирующие/отражающие поверхности - очень сильно снижают "качество" канала передачи данных. Для TCP это совершенно не критично, а для UDP - очень плохо.

Если у вас в квартире проксирование дает положительный результат - то это хорошо и вам проще использовать проксирование, чем "вычищать" канал.
Однако если вы планируете "проксировать" данные для всех (например, для меня лично или для пользователя из Якутии, именно это я понял из вашего первого сообщения), то эта затея врядли будет иметь успех (в техническом плане).

Кстати, обратите внимание, что практически все роутеры класса SOHO имеют низкую производительность стекировани UPD пакетов, в то время как основной приоритет у них направлен на текирование (обслуживание) TCP. Это обясняется тем, что практически весь трафик классического интернет пользователя идет в TCP (в UDP - только запросы DNS), а ресурсы (аппаратные) таких роутеров сильно ограничены. Т.е. "трансляция/натирование UDP на роутерах происходит медленнее и сильнее их "забивает" (при их большом числе).
catBasilio
23-01-13 23:52
2vag
IGMP работает нормально, я сам IGMPproxy на роутере настраивал, и через ethernet все шоколадно.

вот тут http://forum.ip-home.net/index.php?/topic/915-%D0%BA%D0%B0%D0%BA-%D0%BF%D0%BE%D0%B4%D1%80%D1%83%D0%B6%D0%B8%D1%82%D1%8C-iptv-%D0%B8-wifi/

человек очень доходчиво расписал проблему, у дело тут не в неправильно настроенном IGMP или плохой сети.
vag
23-01-13 23:53

цитата:
2admin
предложения есть!
1. в настройках TheDark media center добавить чекбокс "использовать прокси"
Предложение не плохое:

+ добавляется гибкость в пользовании виджета (можно улучшить "прием" каналов)

+ исключается потребность в ручную (или парсером) редактировать собственные плейлисты

+ единственный способ изменить "чужие" плейлисты (те, которые нельзя отредактировать "дома")

- необходимо или оговарить формат преобразование адреса запроса (текст подмены в URI) или добавить текстовое поле в настройки, чтобы пользователь сам указал что и на какой текст заменить (прокси могут быть разные) прежде чем сгенерировать запрос/соединение к потоку IPTV

- дополнительные вопросы у пользователей :)
catBasilio
23-01-13 23:59

цитата:
- необходимо или оговарить формат преобразование адреса запроса (текст подмены в URI) или добавить текстовое поле в настройки, чтобы пользователь сам указал что и на какой текст заменить (прокси могут быть разные) прежде чем сгенерировать запрос/соединение к потоку IPTV
тут надо посмотреть как известные прокси это делают. Возможно там нет большого зоопарка в форматах. В том же SimpleTV задается только адрес и порт. И он сам все подставляет.
Admin
23-01-13 23:59
только к чему эту прокси применять а к чему нет?
добавлять прокси можно заставить сервер
а "чужие" плейлисты можно скачать, да и нада ли проксировать их?
формат обычно одинаковый
http://ip_proxy:port/udp/ip_server:port
catBasilio
24-01-13 00:08
2Admin
можно по типу протокола фильтровать например
udp://@233.3.2.8:5000
rtp:// ...
ну и так далее
vag
24-01-13 00:14
catBasilio
по ссылке человек корректно изложи идею, НО у него в логике рассуждения отсутствует "роутер" с натированием (преобразованием адресов). В его изложении "WAN" трафик (а он действительно пересыщен UDP) "ретранслируется в сеть LAN как есть. Т.е. то что я оговарил ка "мост". В этом случае дейсвительно его выкладки логичны и обоснованы - пускать "весь" (в том числе и чужой) трафик UDP в квартиру очень плохая идея. С этим не поспоришь :)
Однако у вас роутер и он отскает UDP запросы на WAN порт от LAN порта (между ними у вас NAT). Т.е. к вам в квартиру попадут ТОЛЬКО нужные вашему ТВ совершенно конкетные UDP пакеты. (повторю - я исключаю, что вы настроили проброс портов и подключили "мост". В это случае весь UDP с WAN имеет полное право "ломануться" к вам в квартиру)

И тем более, если у вас поднят сервис управления групповыми подключеними (по протоколу IGMP) - никакой "левый" UDP к вам в квартиру (на WiFi) не пойдет.
Про приоретет UDP он высказал тоже, что и я чуть выше. Т.е. у UDP приоритет низкий (зависит от производительности роутера, но в целом на SOHO это именно так).

Поскольку у вас IGMP и нет (надеюсь) моста - о его (по ссылке) выкладках можете забыть (кроме преимуществ/недостатоков/особенностей самого протокола UDP).

Т.е. источник проблем в вашем случае "не здесь", а скорее всего описан мною выше.

Т.е. сути это не меняет (в данном вашем случае UDP имеет смысл перегнать в TCP), но "техническая составляющая" у вас явно другая.

Попробуйте (если есть возможность) построить прокси (только для теста) на РС (с двумя портами) и посмотрите что иемнно ретранслируется в локальный сегмент с точкой доступа по WiFi и что именно приходит на вход вашего прокси (только "нужные" UDP пакеты - это хорошо будет видно по заголовкам пакета - "цель" (там будет MAC вашего ТВ).. или "все подряд"). Естественно на ТД WiFi выпускайте трафик после этой РС (шлюз/прокси) - это упрстит понимание происходящих "эфирных передач".
vag
24-01-13 00:20

цитата:
только к чему эту прокси применять а к чему нет?
Если прокси "квартирный" то ко всем без исключения UDP запросам

На всегда "чужие" плейлисты можно скачать простым способом (например из вашей сетвой папки), да и не нужно это, при наличии "групповой подмены части URI"

Admin, в приципе идея высказанная топикстартером очень даже неплохая (с учетом слабого железа самих ТВ и не идельности наших домашних сетей - это актуально ) и если у вас есть возможность ее реализовать (надесь, что это не особо сложно), то виджет однозначно от этого только выиграет.
catBasilio
24-01-13 00:20
2vag завтра, если время будет, попробую сниффером пройтись. потом отпишусь, что там куда гуляет.
Admin
24-01-13 00:28
а если это пакеты каналов из инета
у них у всех свои прокси и их можно было менять
всех под одну гребенку не получится
catBasilio
24-01-13 00:38
2admin
я предполагал, что прокси -локальный и он стоит где-то на роутере, где есть с одной стороны lan подключение, по которому он получает каналы, а с другой стороны - wifi куда он отдает уже проксированные данные. если это канали из инета, то он тоже их будет проксировать и в wifi тоже будет отправляться нормальный трафик
vag
24-01-13 01:17
Admin, прокси имеется в виду локальный (т.е. у клиента дома или очень близко к нему :) - у провайдера/друга/в этом же городе). Поэтому можно не задумываясь (если в настройках виджета стоит опция "использовать прокси : _адрес_прокси_) менять абсолютно все запросы формата UDР (считать строку запроса выбранного канала/источника из плейлиста, если он идет как UDP, то подменить (в тексте запроса) начальную часть URI на введенную клиентом (адрес прокси+формат запроса), таким образом сформировав новый текстовый вариант строки запроса и передать его на "исполнение" как и раньше ). Запросы TCP оставлять как есть - т.е. передавать на исполнение то, что считали с плейлиста. Это никоим образом ни на что (в плохую сторону) не повлияет. В конце концов до "прокси-сервера" все равно пойдут данные в том виде, в каком они определены в исходной (оригинальной) ссылке плейлиста.

Т.е. в данном случае для виджета это абсолютно не ресурсоемкое решение (железо ТВ для ресурсоемких вариантов явно слабова-то) - подмен одной текстовой строки URI (Uniform Resource Identifier - унифицированный идентификатор ресурса)) другой и далее такая же ее обработка и "до подмены"
catBasilio, ну если слово "сниффер" вас не пугает, тогда лично я спокоен за результат. Естетственно вы должны снифферить через хаб (не свич) или через коммутируемый свич, настроив один из портов на "зеркало" (полная ретрансляция всех пакетов - т.е. по сути сделать "хаб") - это в случае эзернета. Для WiFi - прием всех пакетов (без фильтрации по MAC поле "получатель").
Обратите внимание (если адаптер+сниффер позволят) на число "отброшенных" пакетов в контролируемом вами сегменте сети - тоже может оказаться полезным.
catBasilio
24-01-13 21:59
2vag
я посмотрел что у меня по сети гуляет. снифер запускал прямо на роутере, на wifi порт.
конфигурация wifi:

config 'wifi-device' 'radio0'
option 'type' 'mac80211'
option 'macaddr' '00:xx:xx:xx:xx:xx'
list 'ht_capab' 'SHORT-GI-40'
list 'ht_capab' 'TX-STBC'
list 'ht_capab' 'RX-STBC1'
list 'ht_capab' 'DSSS_CCK-40'
option 'disabled' '0'
option 'channel' '6'
option 'country' 'US'
option 'txpower' '20'
option 'hwmode' '11ng'
option 'htmode' 'HT40+'
option 'noscan' '1'

конфигурация IGMP proxy:
phyint eth1 upstream ratelimit 0 threshold 1
altnet 233.3.0.0/16
altnet 239.255.0.0/16
altnet 213.140.0.0/16
altnet 10.3.0.0/16
altnet 10.230.0.0/16
phyint br-lan downstream ratelimit 0 threshold 1

eth1 - порт ethernet от провайдера
br-lan - виртуальный мост, который объединяет выходные ethernet порты и wi-fi

снифал командой
tcpdump -i wlan0 > log.txt
результат:
catBasilio
24-01-13 21:59
20:26:41.485715 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.485774 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.508356 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.508423 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.531263 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.531321 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.556727 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.556791 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.579718 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.579783 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.602587 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.602649 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.625491 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.625548 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.650052 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.650115 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.673157 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.673218 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.696029 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.696165 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.718897 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.718958 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.741836 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.741895 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.766336 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.766397 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.789283 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.789344 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.813199 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.813263 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.836215 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.836275 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.860905 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.860967 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.883785 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.883846 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.906777 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.906837 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.929684 IP 213.140.243.122.60000 > 233.3.2.2.5000: UDP, length 1316
20:26:41.929736 ARP, Reply 192.168.1
catBasilio
24-01-13 22:01
ip роутера 192.168.1.1
ip телевизора 192.168.1.187
адрес трансляции udp://@233.3.2.2:5000


© Разработка проекта TheDark Design.
© При использовании информации ссылка на сайт smart-tv-home.ru обязательна.
© Все исходные материалы принадлежат их законным правообладателям.