!Joy! дотошность, конечно, похвальная, но учитывая что
(и на этом самом роутере софт времен царя Гороха) на заметку мы это дело возьмем, но править не факт что будем - т.к сейчас исправь “ошибку” здесь, а завтра эта правка аукнется в десятке других мест.
Benny. Править или не править это конечно ваше право. Для себя, я решение думаю найду, возможно понадобиться еще небольшая помощь от вас. Под винду, я благодоря вам библиотеку перекомпилил тоже, осталось разобраться с андройдом.
Но по делу, ошибка на роутере вызвана не недоработкой софта роутера, а нарушением стандарта XML. То что на других роутерах сделана защита от дурака (не в коем случае не в обиду, просто выражение) это конечно их фишка, но есть стандарт, я более чем уверен, что такая проблемма не только у меня, просто многие пользователи вообще не знают и не понимаю, с чем это есть и как оно должно работать, я об upnp.
Давайте я сошлюсь на википедию.
[details=Spoiler]Решение проблемы неоднозначности разметки
Употребление разметочных символов в символьных данных затрудняет распознавание конструкций разметки и может создать проблему неоднозначности структуры. В XML эта проблема решается следующим образом: < и & не могут присутствовать в символьных данных и в значениях атрибутов в их непосредственном виде, для их представления в этих случаях зарезервированы специальные сущности:
Символ Замена
< <
>
& &
Кроме того, для употребления апострофов и кавычек внутри значений атрибутов используются следующие сущности:
’ '
" "
Правило замены символов, используемых в разметке, на ими обозначаемые сущности не распространяется на символьные данные в секциях «CDATA», зато выполняется во всех остальных местах документа.
[/details]
В случае с acestream, вы этого всего не касаетесь, вы просто вызываете метод билиотеки UPNP_AddPortMapping() где шестым аргументом передаете свое значение в виде строки, это значение попадает в метод и занимает свое место в XML документе, и вот здесь возникает трабл.
Вызов метода библиотеки с корректным аргументом, должен решить эту проблему и вряд-ли что то может испортить, т.к. это стринговый параметр не влияющий не на что кроме передачи роутеру названия службы для которой проброшен порт. Если там не будет неразрешенных символов, то и проблем не будет.
Этот-же аргумент вы возможно передаете также в методы
UPNP_AddAnyPortMapping()
UPNP_GetGenericPortMappingEntry()
UPNP_GetSpecificPortMappingEntry()
В общем я поток своих мыслей закончил 
Если вы мне подскажите как подменить библиотеку miniupnpc на андройде, обещаю от вас отстать и больше не возвращаться к этому вопросу.:)))
Нет, это как раз “недоработка софта”, а именно upnpd-демона, и то, что в последующих версиях она исправлена - говорит в пользу этого довода.
Ссылка на xml в разрезе “что можно/чего нельзя использовать в строках” правильная, вот только голова об этом должна болеть у автора библиотеки, а не у ее пользователя. Т.е либо автор реализует корректный парсинг строк (включая и “защиту от дурака”), либо явно предупреждает в документации, что в параметрах “foo, bar” использование спец. символов (включая “< >” и их комбинации) - запрещено.
Не исключено, особенно если этот “не только я” также упорно использует старую версию софта с багами. Лично я считаю, что такие пользователи ССЗБ, и не понимаю, почему мы должны ради них писать “костыли” для обхода багов в прошивке, пусть даже в конкретном случае это не сильно трудозатратно.
На выходных врядли, это уже на следующей неделе узнаю.
Не исключено, особенно если этот "не только я" также упорно использует старую версию софта с багами. Лично я считаю, что такие пользователи ССЗБЗлостные Буратины сидят на этих версиях по нескольким причинам: а) Они пользователи с большой буквы "П" и не знают не умеют шиться перешиваться... Купили железку и пользуются. б) Они продвинуты, и поменяли 10-ток прошивок и выбрали для себя самую стабильную из перепробованных... Ведь согласитесь, свежее не всегда лучше... Это в частности касается роутеров TPLINK. Давайте пробежимся по нашей переписке
-Есть предположение, что движок "не дружит" [b]с последними[/b] версиями miniupnpd.... .......................................... -Тогда действительно странно - [b]со старыми прошивками проблем быть не должно.[/b] .......................................... -Не исключено, что [b]проблема обратная - на роутере слишком старая версия[/b] (mini)upnpd.Получается, как в том анекдоте про пирожок с мясом, мало откусил, еще не видишь мясо, много откусил его опять нет. :) И как же бедному юзверю выбрать эту середину, чтобы в цель попасть :) Особенно если об upnpc upnpd он не чего не знает.
и не понимаю, почему мы должны ради них писать "костыли" для обхода багов в прошивке, пусть даже в конкретном случае это не сильно трудозатратно.Ну наверное из-за этого...
В целом мы заинтересованы в том, чтобы с upnp было как можно меньше проблем, но....И тут получается, как сказано в одном выражении Все, что сказано до слова "но" не имеет ни какого смысла... :) © из Игр Престолов, если не ошибаюсь. :)
Костыль или велосипед это сомнительное название для этой правки по моему мнению, с таким же успехом можно сказать, что использование encodeURIComponent при отправке GET запросов тоже костыль. При этом, я согласен с вами, что автор библиотеки должен предусмотреть экранирование спец символов или предупредить о запрете их использования, но если не предусмотрел… то что забить на это… ведь проблема есть и её можно избежать. Пусть даже в свежих версиях библиотеки это устранено, но есть же железо которое уже не поддерживается разработчиком, а кастомы это не для каждого пользователя.
Разработчики другого софта видимо берут это в расчет, раз на этом роутере с прошивкой старой, как говно мамонта без проблем работают с этой функцией.
Я еще раз категорически утверждаю, править или нет, решать только вам. Если нужно, чтоб было меньше жалоб на upnp, то наверное да, а если ждать, что железо и его софт будет подстраиваться под движок то я бы не делал, в конце концов кому не нравится, пусть не пользуются, можно же всегда руками пробросить.
В андройде вроде нашел библиотеку по пути data/data/org.acestream.media/files/python/lib/python2.7/lib-dynload/ судя по содержимому собрана на 12й ubuntu. Это оно?
Не “злостные”, а “злобные”.
а) это было бы актуально в 2013-2014 году. С тех пор много воды утекло, и вероятность того, что у этих пользователей на сегодняшний день поголовно роутеры с багнутой прошивкой 2012 года (которая, к тому же, не распространялась официально) не сильно велика.
б) за пару десятков метров стоит 1043 ТП-Линк (первой ревизии), который с рожденья не использовался с “родной” прошивкой - только альтернативные. Плюс россыпь ТП-Линков попроще (из популярных 740(1), 840(1) и т.д) на которых как заводские, так и альтернативные прошивки - ни на одном из них этот баг не воспроизводится.
Ну и “продвинутый пользователь” + “древняя заводская прошивка” - для меня лично оксюморон.
Все просто - за “бедного юзверя” подумали производители роутера/прошивок. В свою очередь мы всегда рекомендуем пользователям обновлять софт их роутеров при подозрении, что “что-то не так” именно в прошивке.
Это передергивание, т.к в первой цитате я специально выделил италиком, что про “ССЗБ” и “не понимаю” - это лично мое мнение, а во второй - наша "заинтересованность" не распространяется на некрофилов. Для “бедного пользователя” же гораздо важнее это сообщение
Согласен, но в случае упомянутого роутера это не так - на сайте производителя можно найти актуальную версии ПО. Плюс есть как минимум две альтернативы - DD-WRT и OpenWRT. И при всем уважении к “дотошности”, лично я сомневаюсь, что были проверены все альтернативные прошивки для этой модели. Скорей поверю в то, что “когда-то не пошло, а теперь и заниматься этим недосуг”.
Не знаю. Андроидная версия движка - не моя “парафия”.
И при всем уважении к "дотошности", лично я сомневаюсь, что были проверены все альтернативные прошивки для этой модели. Скорей поверю в то, что "когда-то не пошло, а теперь и заниматься этим недосуг".Ну почему же не пошло, я же написал, что на то время из того что было, было выбрано, то что понравилось в работе... не одним upnp живет роутер, есть еще UDP Multicast, нагрузка под торрентами и т.д., да и с upnp проблем не наблюдалось, до этой ситуации. Я не говорю, что все прошивки кроме моей говно.. я говорю о том, что работает, не трожь... ну нашился я в свое время, нашился... :) Если подобные проблемы будут повторятся с другим ПО и это будет критично, возможно займусь поиском на что перепрыгнуть. А пока, для себя лично, считаю, более полезным и интересным не перешивать и тестировать прошивки роутера, находя то одни то другие баги в их работе, гораздо с большим интересом покопался в исходниках той же miniupnpc и попробовал разобраться в её работе, для саморазвития. К стати ещё раз повторюсь, спасибо вам за помощь в этом вопросе.
Есть ещё один вопрос, в одном из первых сообщений в этой теме, один из пользователей жаловался на то, что при убиение движка и его последующего запуска, появлялся новый проброс в роутере, Вы тогда ответили, что
"Перезапускать" корректно, или же после падения/насильственного убиения процесса? В первом случае движок всегда отписывается UPNP серверу - "я закончил, редирект можно убрать", т.е подобного быть не должно.Во втором случае не все так просто, и конктретно для miniupnpd есть смысл посмотреть на его параметры “clean_ruleset_threshold” и “clean_ruleset_interval”.
Хотел спросить, сегодня такое-же поведение при падении, или, движок научился находить свой проброс и не создает новый?
Просто как я понял вызывая UPNP_GetSpecificPortMappingEntry, параметры intClient, intPort и desc передаются по ссылке и потом в эти переменные присваиваются значения полученные из ответного xml, а следовательно, вы их уже можете проверить и в случае совпадения запрос на проброс можно уже не слать. Или я ошибаюсь?
Да. Но - “просто собрать в линуксе” получится только для х86 версий Андроида. Под АРМ нужно городить среду кросскомпиляции “с++/python для АРМ”, либо собирать прямо на устройстве с целевым CPU/ABI.
“На то время” понятно, речь про актуальные (современные) прошивки.
Да, в этом смысле ничего не менялось. Падение и/или принудительная остановка движка - аварийная ситуация, и ради этого городить свой огород вокруr upnp - сомнительная затея, проще отключить его вообще.
Понял… Ну что ж, просто только котята родятся… Будем грызть дальше
Под вашим давлением пошел вчера на хбт почитать последние страницы по моему девайсу… даже руки немного зачесались перепрыгнуть на что то альтернативное, но потом опять передумал Ну работает он у меня 24/7 месяцами не перезагружаясь, обслуживая 9 проводных клиентов и столько же по wifi, ну что мне ещё от него должно быть нужно??? Кроме того, меня домашние сожрут пока я буду его настраивать, это же интернет, телик работать не будет…
В общем, как будет скучно поиграюсь с этим наверное, а пока…
Давайте о роутере закончим…, эту тему мы более чем раскрыли.
Понял.
Ну тогда, просто чтоб были в курсе, что то что я описывал в прошлом сообщение работает, по крайней мере в консольной прилажухе. После того как отрабатывает UPNP_GetSpecificPortMappingEntry для запрошенного внешнего порта, в intClient, intPort и desc находятся данные полученные от роутера об этом клиенте.
В AceStream по умолчанию для входящих соединений задан порт 8621, что приводит к тому, что если в сети несколько устройств с AceStream, только одно из них способно открыть этот порт для себя, и будет работать в активном режиме. И только оно одно будет способно скачивать и раздавать потоки всем. Остальные устройства будут в пассивном режиме, что значит, что качать и раздавать они могут только активным пользователям. Если сюда прибавить пользователей без белого ip, а так же без upnp или с выключенным upnp, получается пользователей в пассивном режиме намного больше, чем в активном. Они качают поток с активных пользователей, но никому не раздают, т.к. большинство так же в пассивном режиме. И поток фактически глохнет, вместо приумножения. Из-за большого количества пассивных нахлебников вытекает нестабильность трансляций, не только у них, но и у всех.
Во всех торрент клиентах порт при первом запуске генерируется автоматически. В некоторых клиентах есть опция генерировать порт при каждом запуске. Это устраняет коллизию портов в рамках домашней сети, и все устройства по UPNP автоматически отрывают себе разные порты и работают в активном режиме.
Считаю в AceStream необходимо сделать так же. И может быть пойти еще дальше, и сделать перебор нескольких портов, если первый выбранный уже кем-то занят.
Так же AceStream при раздаче потоков должен отдавать приоритет пользователям в активном режиме. Пользователям в пассивном режиме следует раздавать поток по остаточному принципу.
Это уже сделано посредством upnp - движок запрашивает у роутера проброс порта, и если такой порт уже используется, то значение порта увеличивается на 1.
Если же в силу каких либо причин (неработоспособность или отключенный upnp) автоматическое изменение порта не работает, то никто не запрещает изменить порт вручную - эта опция есть во всех клиентах, как для ПК, так и для Андроида.