[sfstudio]

Там же жуткий код с кучей костылей.

Мне проще было написать с нуля msd чем туда что то встроить.

 

Видали и более жуткий. Каждому своё.

 

Ты просто ещё не пришёл к IPv6 :)

 

Ну есть у меня нативный ipv6 сейчас, толку с него только нету в силу недоступности интересующих меня ресурсов по v6 чуть более чем полностью. Ну разве что гугл работает. =)

 

В моём случае достаточно просто мультикаст прокидывать между сетями, притом можно даже только в сторону абонента.

 

Мультикаст большиснтво DLNA совместимых старых ящиков приземлить не в силе. Один фиг надо в http оборачивать поток. Т.е. один фиг мультикаст надо приземлить на роутере. Итого смысл сведётся всё к тому же xupnpd+udpxy.

 

Те ты предлагаешь вендорлок решение.

 

Я свои решения не прячу, они все доступны в git проекта. Кому надо - затянет. Я просто не хочу грузить CPU обработкой транзитного трафика в юзерспэйсе. А вот сделать эдакий хэлпер на уровне ядра гораздо менее накладно. А там оператор у себя может просто DLNA развернуть и не париться. В итоге всё останется на месте и нат и прочее, достаточно будет ровно одной галки Pass DLNA LAN<=>WAN. Надо подумать. Но вот как-то тратить время на то, что никто не будет юзать откровенно лень, не встречал операторов с DLNA в их сети. Да и один фиг всё это городушки какую схему не посмотри.

[Ivan_83]

Мультикаст большиснтво DLNA совместимых старых ящиков приземлить не в силе. Один фиг надо в http оборачивать поток. Т.е. один фиг мультикаст надо приземлить на роутере. Итого смысл сведётся всё к тому же xupnpd+udpxy.

Ещё раз: в моей схеме ВСЁ на стороне провайдера.

И не эти поделки для персонального мучения а вполне себе то что нагрузку держит.

Основная проблема в том, что мультикаст анонсы протокола SSDP (часть UPnP/DLNA) не долетают через роутеры до девайсов юзера.

 

Я свои решения не прячу, они все доступны в git проекта. Кому надо - затянет.

Ты же понимаешь что никто тут не в силах, за исключением пары исключений, и те не станут ибо стянуть мало, нужно по зоопарку абонентов это внедрять. Итого всегда встаёт вопрос о покупке готового.

Уболтать вендоров - та ещё история, они не почешутся ради скромных партий и суппорту там не будет.

[rdc]

сильно разная нагрузка.

Это не столь важно на фоне преимуществ.

Например, я могу подать ipv6 любому абоненту, даже если его роутер вообще таких слов не знает.

У меня телеприставка MAG, купленная абонентом в магазине самостоятельно, втыкается и работает, поймав настройки по dhcp.

Я могу конкретному устройству абонента включить фильтрацию порнухи - или, наоборот, отключить.

Работает DLNA, и будут работать любые новые протоколы, которым ещё предстоит появиться.

И всё это централизованно, с любым зоопарком абонентских вайфаев.

[sfstudio]

Основная проблема в том, что мультикаст анонсы протокола SSDP (часть UPnP/DLNA) не долетают через роутеры до девайсов юзера.

 

Вот я и грю один фиг городить на user-cpe что-то.

 

Ты же понимаешь что никто тут не в силах, за исключением пары исключений, и те не станут ибо стянуть мало, нужно по зоопарку абонентов это внедрять. Итого всегда встаёт вопрос о покупке готового.

Уболтать вендоров - та ещё история, они не почешутся ради скромных партий и суппорту там не будет.

 

Ну эт уже не мои проблемы. Был спрос на udpxy в итоге даже ***линк терь из коробки его интегрит. Так и тут. Впрочем и я не буду заниматься рукоблудием с хэлперами и прочим если не будет на это спроса. Иначе можно обрасти 100500 непонятными и никому не нужными хренями. А пока в природе операторов с DLNA не видел, а значит единственный пусть приземлять TV на DLNA не смарт ТВ без приставки эт xupnpd+udpxy на роутере, и эта схема у нас настраивается в "3 клика". А запас по CPU (трафик-то аппаратно натиться и роутиться т.е. CPU свободного валом) позволяет юзать эту схему вполне комфортно.

 

сильно разная нагрузка.

Это не столь важно на фоне преимуществ.

Например, я могу подать ipv6 любому абоненту, даже если его роутер вообще таких слов не знает.

У меня телеприставка MAG, купленная абонентом в магазине самостоятельно, втыкается и работает, поймав настройки по dhcp.

Я могу конкретному устройству абонента включить фильтрацию порнухи - или, наоборот, отключить.

Работает DLNA, и будут работать любые новые протоколы, которым ещё предстоит появиться.

И всё это централизованно, с любым зоопарком абонентских вайфаев.

 

Важно, ибо стоит доп денег это как минимум.

 

Давайте мож таки со схемами доступа в другой раздел? Ну там о кабельных сетях, там вроде обсуждают как правильно организовать сиё. А тут мы обсуждаем что делать с имеющейся операторской схемой, а не потенциальные хочу/могу. Ибо тупик тут об этом спорить. Никто не услышит и все продолжат юзать сложившуюся схему. А вот там можете донести своё прогрессивное видение народу.

[rdc]

Дык я говорю про решение, которое легко внедряется на сети оператора с dhcp.

 

Кстати, ещё у абонентских роутеров местами бывает очень смешной нат.

Пример - абонентский IP-телефон регистрируется в каком-нибудь SIP сервисе, src port 5060, dst port 5060.

После чего нат роутера НЕ ЗАПОМИНАЕТ хост SIP-сервиса, а тупо открывает 5060 порт на вход.

Далее абоненту начинают названивать какие-то долбозвоны из интернетов, которые сканят паблик в поисках открытого 5060, и днём и ночью, чуть ли не каждую минуту звонок.

Абонент сначала не понимает, что творится, жалуется SIP-сервису (те в логах ничего не видят, разумеется), далее мучает провайдера.

Встречал такое поведение на разных роутерах, причём я был как в роли провайдера со сторонним SIP-сервисом, так и в роли SIP-сервиса со сторонним провайдером.

Пробовали менять src port - но когда ип уже засвечен, долбозвоны начинают сканить на нём разные порты, и поможет уже только смена ипа.

Пару раз удавалось вылечить заменой штатной говнопрошивки на *wrt - но в целом - нафига вообще нужен такой абонентский недо-нат?

Пусть лучше нормальный полноценный нат крутится у провайдера, люди будут крепче спать…

[sfstudio]

Да хоть как оно внедряется, не с теми осуждаете внедрение. =) Будут внедрять вашу схему - будем работать с ней, мне же мороки будет меньше.

 

Это косяк контрак хэлпера, дреееевний косяк. Давно пофикшен у нормальных людей.

[rdc]

Я подозреваю, что это не контрак, т.к. эти роутеры были с "аппаратным" натом.

Или он тоже поверх контрака сделан?

[Ivan_83]

приземлять TV на DLNA не смарт ТВ без приставки эт xupnpd+udpxy на роутере, и эта схема у нас настраивается в "3 клика".

В моей схеме это 0 кликов со стороны юзера, если интегрировать в роутер.

Те провайдер держит у себя SSDPd+nginx+php скрипт + msd. Всё что требуется от юзера - чтобы до него долетал мультикаст от SSDPd.

 

А запас по CPU (трафик-то аппаратно натиться и роутиться т.е. CPU свободного валом) позволяет юзать эту схему вполне комфортно.

udpxy комфортным не бывает: пока он подпишется на мультикаст, пока ящег/плеер накопит данных для старта декодинга проходит минимум 5-10 секунд. (ну на магах может и за 3, смотря как повезёт с ключевым кадром)

В моей схеме юзер подключается к провадейрскому msd у которого из кольцевого буфера сразу вылетает достаточно+запас для инита плеера и старта декодинга, те переключение/включение от 0 секунд.

[sfstudio]

Я подозреваю, что это не контрак, т.к. эти роутеры были с "аппаратным" натом.

Или он тоже поверх контрака сделан?

 

Трафик для которого требуются какие-то специальные манипуляции типа SIP, FTP control и т.д. не попадают в PPE (читай обрабатываются софтово). PPE в SOHO роутерных SOC не умеют самостоятельно делать подобные подвыверты. Да и в любом случае в PPE биндятся уже попавшие в контрак сессии, по другому никак.

[sfstudio]

В моей схеме это 0 кликов со стороны юзера, если интегрировать в роутер.

 

Столько же кликов как и в случае с преднастроенным и включенным по дефолту xupnpd. Но вот по дефолту включать всякую муйню...

 

Те провайдер держит у себя SSDPd+nginx+php скрипт + msd. Всё что требуется от юзера - чтобы до него долетал мультикаст от SSDPd.

 

В нашей схеме провайдеру достаточно держать у себя на сервере плэйлист и всё. И всё бы было бы хорошо если бы провайдеры договорились, что отдают плэйлист с одного фиксированного доменного имени, но даже об этом они не договоряться, а вы грите что-то разворачивать потом куда-то интегрировать ещё...

 

udpxy комфортным не бывает: пока он подпишется на мультикаст, пока ящег/плеер накопит данных для старта декодинга проходит минимум 5-10 секунд. (ну на магах может и за 3, смотря как повезёт с ключевым кадром)

В моей схеме юзер подключается к провадейрскому msd у которого из кольцевого буфера сразу вылетает достаточно+запас для инита плеера и старта декодинга, те переключение/включение от 0 секунд.

 

1) Кому как. Уж хз насчёт 10сек, не замерял, но явно быстрее.

2) Ну т.е. провайдерский msd должен быть всегда подписан на все каналы вещаемые иначе не откуда сразу вылететь т.к. в буфере ничего не будет до запроса.

[Ivan_83]

Столько же кликов как и в случае с преднастроенным и включенным по дефолту xupnpd. Но вот по дефолту включать всякую муйню...

SSDPd сильно проще твоей связки :)

 

В нашей схеме провайдеру достаточно держать у себя на сервере плэйлист и всё. И всё бы было бы хорошо если бы провайдеры договорились, что отдают плэйлист с одного фиксированного доменного имени, но даже об этом они не договоряться, а вы грите что-то разворачивать потом куда-то интегрировать ещё...

ИМХО их бесполезно спрашивать, нужно всё делать самому, как лучше.

Вон сделали retracker.local а провайдеры потом у себя поднимали его.

 

2) Ну т.е. провайдерский msd должен быть всегда подписан на все каналы вещаемые иначе не откуда сразу вылететь т.к. в буфере ничего не будет до запроса.

Уху. И стоит он у провайдера. Есть ещё вариант когда центральный всегда подписан а узловые просто по хттп ретранслируют с него когда нужно, на практике я такое пока не внедрял. Те клиент подключает к узловому, запрашивает канал, если он первый то узловой мсд цепляется к центральному, вытягивает от туда пол кольцевого буфера/хх мегабайт и отдаёт клиенту, ну и далее отдаёт по мере поступления. Последний клиент ушёл - соединение до центра завершается.

[sfstudio]

Ну вот как кто-нить надумает внедрять - так сразу и добавлю из коробки вашу или не вашу реализацию или хелпер рожу ядерный что бы уж совсем красиво. Пока я не вижу желающих внедрить подобное и именно в этом проблема.

[vladlit]

Ощибочное высказывание, TR-069 принят в РФ и используется у многих операторов уже.

 

Принят эт наверное внутрь? И подробнее о многих. Ну вот их десятков тысяч многих операторов хотя бы у 500 используется? С каким железом?

 

А вообще странный. Вам операторы работающие в РФ, на операторском форуме грят не принято костылить ТРы и иже с ними в РФ, вы из дружественого Израиля их убеждаете, что они давно в большинстве своём жить не могут без этого безобразия и во всю все уже внедрили по самые гланды.

 

И он как раз призван решать проблемы связанные со сложностью настроек на абонентских устройствах

 

Сложность настроек абоненских устройств решается стандартными средствами - нормальным доступом в виде IPOE с выдачей реквизитов по DHCP. Но вместо того, что бы избавиться от одних костылей, некоторые бывшие телефонисты или домушники пытаются привернуть новые.

 

Раз 800 стоит подумать оператору, прежде чем расширять свою зону ответственности и полагаться на подобный изврат.

 

P.S. Вы бы не палились хотя бы с адресов Benzel. Нам ваши сказки и ваши продухты (аля Autmated TR-069 Tester да и ACS) и даром не нужны. =) Торгуйте своими костылями плз в другом месте.

 

PP.S. Более того, тема чистый оффтопик для вашей неуклюжей пока яще не рекламы, а так тупо очковтирательства.

 

PP.SS. Хочется попиариться - создайте тему и предложите плюшки народу. Не надо тупо какать по всем темам где хоть как-то упоминается TR-069.

Во-первых, очень грубо отвечать так незнакомому человеку, я ничего вам лично не написал и ничего здесь не рекламировал.

Во-вторых, если я что то заявил, то я это знаю и не важно откуда я сам. Могу перечислить операторов у которых используется ТР-069.

В-третьих, 800 раз подумали и посчитали, и как не странно решили, что это правильно и выгодно как для самого оператора так и для его клиентов. Поверьте мне, не дураки придумали этот стандарт и не дураки его используют.

В-четвертых, есть понятие бизнес решения и есть люди, которые принимают такие решения в организациях, вам этого не понять, вы не из той области. Вы ко всему подходите со своей колокольни, не понравилось вам допиливать поддержку ТР-069 в своем проекте, так все, в топку его.

И учить меня не надо, я лично участник BroadBand форума, который создал и продолжает развивать этот стандарт.

Изменено 26 декабря, 2016 пользователем vladlit

[Ivan_83]

TP-069 оффтоп завязываем.

[junky]

Здраствуите.

 

Непланируите ли вы перенести код на ГитХуб?

 

Спасибо.

[sdy_moscow]

3 часа назад, junky сказал:

Непланируите ли вы перенести код на ГитХуб?

Он из Крыма. Шутка :-) ? А может  и угадал....

[paradox_]

лол а он и так на гитхабе валяется

 

да не он из москвы

[Ivan_83]

https://github.com/rozhuk-im/ssdpd

https://gitlab.com/rozhuk-im/ssdpd

https://notabug.org/rozhuk.im/ssdpd

 

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252087

 

Выбирайте что больше нравится, могу ещё куда то отзеркалить, если оно бесплатное и адекватное.