Печать

[navip999]

Хотелось бы отписаться по поводу раздачи трафика. С начала когда запускается сервер отдача идет хорошая. (2-3мбайт) Но через час отдача падает до 1-2мбайт и даже меньше. Нельзя ли сделать как в сопке чтобы раздавало стабильно 12 пирам? А  ТС как я посчитал 3-5 раздает (я вещал со скоростью 2мбит)

[Constantin]

Хотелось бы отписаться по поводу раздачи трафика. С начала когда запускается сервер отдача идет хорошая. (2-3мбайт) Но через час отдача падает до 1-2мбайт и даже меньше. Нельзя ли сделать как в сопке чтобы раздавало стабильно 12 пирам? А  ТС как я посчитал 3-5 раздает (я вещал со скоростью 2мбит)

Количество соединений на источник, это настраиваемый параметр. Как только он пройдет нормальную отладку, мы добавим эту настойку на страничку с параметрами трансляции. ( более удобней и эффективней сейчас использовать для трансляций версию под Убунту или Дебиан )

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

Трансляция у ваших пользователей шла без задержек?

[kattery]

Читаю но так и не поняла обьясните пожалуйста вот смотрю я канал НТВ+...  ID мне к примеру известен...я плачу за просмотр этого канала или нет???....

[Constantin]

Читаю но так и не поняла обьясните пожалуйста вот смотрю я канал НТВ+...  ID мне к примеру известен...я плачу за просмотр этого канала или нет???....

Это вопрос не к нам!  Мы предоставляем технологию, а не контент. Это вопрос к тому кто предоставляет вам ID

[navip999]

Хотелось бы отписаться по поводу раздачи трафика. С начала когда запускается сервер отдача идет хорошая. (2-3мбайт) Но через час отдача падает до 1-2мбайт и даже меньше. Нельзя ли сделать как в сопке чтобы раздавало стабильно 12 пирам? А  ТС как я посчитал 3-5 раздает (я вещал со скоростью 2мбит)

Количество соединений на источник, это настраиваемый параметр. Как только он пройдет нормальную отладку, мы добавим эту настойку на страничку с параметрами трансляции. ( более удобней и эффективней сейчас использовать для трансляций версию под Убунту или Дебиан )

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

Трансляция у ваших пользователей шла без задержек?

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

[Constantin]

Хотелось бы отписаться по поводу раздачи трафика. С начала когда запускается сервер отдача идет хорошая. (2-3мбайт) Но через час отдача падает до 1-2мбайт и даже меньше. Нельзя ли сделать как в сопке чтобы раздавало стабильно 12 пирам? А  ТС как я посчитал 3-5 раздает (я вещал со скоростью 2мбит)

Количество соединений на источник, это настраиваемый параметр. Как только он пройдет нормальную отладку, мы добавим эту настойку на страничку с параметрами трансляции. ( более удобней и эффективней сейчас использовать для трансляций версию под Убунту или Дебиан )

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

Трансляция у ваших пользователей шла без задержек?

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

Откровенно говоря, я не знаю как работает сопкаст,  но наша задача была  максимально разгрузить каналы источника, а не нагрузить их по максимуму. Собственно, в идеале, источник вообще должен работать только с узлами поддержки и тогда скорость отдачи источника будет полностью прогнозируемая. В любом случае, все еще будет оптимизироваться и улучшаться.

Собственно, если у вас не меняется битрейт потока, то вам и не нужно менять id трансляции.
А вообще, для постоянной трансляции лучше просто сделать страничку со своим каналом и пользователь всегда будет знать ее адрес. imho

P.S. Учитывая что вы бродкастер, обязательно посмотрите этот пост http://oldforum.acestream.media/index.php?topic=1410.msg4809#msg4809 ( Мы вчера обратили внимание, что пользователи не могли нормально законнектиться к  разным трансляциям, из-за того машины бродкастеров с трудом переваривали большое количество коннектов ( тысячи зрителей ), поэтому, чтобы такого не происходило с вашими трансляциями, воспользуйтесь указанной нами рекомендацией

[vladimir29]

Откровенно говоря, я не знаю как работает сопкаст,  но наша задача была  максимально разгрузить каналы источника, а не нагрузить их по максимуму. Собственно, в идеале, источник вообще должен работать только с узлами поддержки и тогда скорость отдачи источника будет полностью прогнозируемая. В любом случае, все еще будет оптимизироваться и улучшаться.

На мой взгляд это не совсем правильная политика распределения отдачи с серверами поддержки, они должны быть лишь как дополнение, хотя не исключаю возможность включения трансляции бродкастеру только с подключением сервера поддержки, но этот параметр он должен включать сам если ему это будет необходимо(например он имеет отдачу 5 мбит/с, естественно что уже проблематично будет раздать трансляцию например в 3 мбит/с, поэтому он может включить возможность подключения к самому источнику лишь серверу поддержки, а обычные зрители пиры будут получать этот поток лишь от этого сервера).
Стабильность сопкаста кроется в правильном распределении пиров в случае слабых скоростей загрузок и отдач. Хотя там всего лишь используется 11 юзеров пиров по умолчанию(там это нерегулируемый параметр и это один из минусов сопок), но при этом все нормально раздают друг другу поток из-за того, что если на одного из подключенных пиров падает отдача, то тут же ищется новый пир, который будет забирать необходимую отдачу у бродкастера, а после того как он его найдет, старый пир просто отключается от источника. Аналогично это работает на раздаче и у обычного юзера, который смотрит трансляцию. В свою очередь обычный пир для загрузки потока также ищет новых пиров, если его существующие пиры начинают плохо отдавать поток ему, после нахождение хороших пиров отключаются старые, которые плохо отдавали поток. Но что самое интересное если начинает серьезно проседать буфер у сопки, то пир который смотрит трансляцию не отключает своих плохих пиров, с которых тянет трансляцию и при этом подключает все новых и новых чтобы получить заветные данные для прогрузки буфера и как только этот буфер прогружается до нормального значения (а в идеале это 100% ) он постепенно отключает своих плохих пиров, которые плохо ему раздают поток. Как правило ему хватает 3-5 сильных пиров и несколько слабых, чтобы нормально прогружать буфер сопкаста. Еще одно важное значение для стабильности имеет протокол UDP у сопкаста, так как в случае неправильного куска трансляции происходит перезакачивание этого же куска с другого пира, на протоколе TCP этого вроде как не происходит.
У TS явно несколько другая топология соединений пиров между собой, я пока не совсем понял как именно обмениваются данными пиры между собой, но думаю вы сами это прекрасно знаете и надеюсь вы улучшите эту топологию, так как сейчас слишком много пиров подключается к юзеру и источнику, которые проще говоря просиживают свое место на порту в холостую, и должного обмена пирами сейчас не происходит, которые к тому же еще и плохо раздают другим трансляцию(пока пеняем это на windows, в linux дела с этим происходят получше).

[Constantin]

Откровенно говоря, я не знаю как работает сопкаст,  но наша задача была  максимально разгрузить каналы источника, а не нагрузить их по максимуму. Собственно, в идеале, источник вообще должен работать только с узлами поддержки и тогда скорость отдачи источника будет полностью прогнозируемая. В любом случае, все еще будет оптимизироваться и улучшаться.

На мой взгляд это не совсем правильная политика распределения отдачи с серверами поддержки, они должны быть лишь как дополнение, хотя не исключаю возможность включения трансляции бродкастеру только с подключением сервера поддержки, но этот параметр он должен включать сам если ему это будет необходимо(например он имеет отдачу 5 мбит/с, естественно что уже проблематично будет раздать трансляцию например в 3 мбит/с, поэтому он может включить возможность подключения к самому источнику лишь серверу поддержки, а обычные зрители пиры будут получать этот поток лишь от этого сервера).

Все правильно! А что, это разве противоречит тому что я написал.

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

Ну "стабильность" сопкаста я уже увидел, поэтому это слово не совсем уместно к этой программе. Ну, а то что вы называете стабильностью, то это кроется в более большем объеме предварительной буферизации, а не в правильном распределении пиров. Лучше чем протокол bittorrent, для пиринговой передачи тяжелого контента, пока еще не придумали. 

Хотя там всего лишь используется 11 юзеров пиров по умолчанию(там это нерегулируемый параметр и это один из минусов сопок), но при этом все нормально раздают друг другу поток из-за того, что если на одного из подключенных пиров падает отдача, то тут же ищется новый пир, который будет забирать необходимую отдачу у бродкастера, а после того как он его найдет, старый пир просто отключается от источника. Аналогично это работает на раздаче и у обычного юзера, который смотрит трансляцию. В свою очередь обычный пир для загрузки потока также ищет новых пиров, если его существующие пиры начинают плохо отдавать поток ему, после нахождение хороших пиров отключаются старые, которые плохо отдавали поток. Но что самое интересное если начинает серьезно проседать буфер у сопки, то пир который смотрит трансляцию не отключает своих плохих пиров, с которых тянет трансляцию и при этом подключает все новых и новых чтобы получить заветные данные для прогрузки буфера и как только этот буфер прогружается до нормального значения (а в идеале это 100% ) он постепенно отключает своих плохих пиров, которые плохо ему раздают поток. Как правило ему хватает 3-5 сильных пиров и несколько слабых, чтобы нормально прогружать буфер сопкаста. Еще одно важное значение для стабильности имеет протокол UDP у сопкаста, так как в случае неправильного куска трансляции происходит перезакачивание этого же куска с другого пира, на протоколе TCP этого вроде как не происходит.

Откуда у вас такие сведения по алгоритмам загрузки и где можно почитать такую документацию по сопкасту

У TS явно несколько другая топология соединений пиров между собой, я пока не совсем понял как именно обмениваются данными пиры между собой, но думаю вы сами это прекрасно знаете и надеюсь вы улучшите эту топологию, так как сейчас слишком много пиров подключается к юзеру и источнику, которые проще говоря просиживают свое место на порту в холостую, и должного обмена пирами сейчас не происходит, которые к тому же еще и плохо раздают другим трансляцию(пока пеняем это на windows, в linux дела с этим происходят получше).

Мы будем стараться сделать программу лучшей из лучших, и мы вам благодарны за помощь и участие в организации масштабных тестов ( 9 тыс. зрителей на вашей трансляции, это было круто! )

[vladimir29]

Все правильно! А что это разве противоречит тому что я написал.

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

Откуда у вас такие сведения по алгоритмам загрузки и где можно почитать такую документацию по сопкасту

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

Мы будем стараться сделать программу лучшей из лучших

И вам спасибо, что улучшаете свой софт, а то китайцы со своим сопкастом так за длительное время почти ничего и не изменили, да еще и служба поддержки практически никогда не отвечает(мне вообще ни разу не ответила).
Вообщем ждем новый релиз TS с улучшенным движком.
P.S. Увеличьте в новой версии буфер примерно до 20-30 секунд по умолчанию. Эти цифры как показывают опыты более оптимальны

[Bloodzeed]

i have tested this the main problem with the buffering is when someone leaves ofrconnects to the stream poll that you're in will cause buffering

[gfdgerte]

а как на ipad смотреть??

[Constantin]

Вообщем ждем новый релиз TS с улучшенным движком.
P.S. Увеличьте в новой версии буфер примерно до 20-30 секунд по умолчанию. Эти цифры как показывают опыты более оптимальны

Увеличивать по умолчанию буфер мы не будем, так как мы хотим добиться максимально быстрого старта, с минимальным отставанием от оригинального источника трансляции. На данный момент у нас получилось выйти на результат 3 сек, поэтому, после отладки, мы вероятнее всего сделаем его по умолчанию еще меньше!

Но, мы реализуем/добавим другие интересные фича, как пауза и перемотка назад ( до - 60 мин. ) Это будет очень удобно для тех кто опадал на начало какой-то трансляции или кому просто надо отвлечься на какое-то время, но нет желания пропускать фрагмент трансляции. Эти функции также обеспечат нормальный/гладкий просмотр ( без задержек), любительских трансляции ( где нет стабильного источника и нет узлов поддержек ) или для тех у кого нестабильный интернет ( сильно гуляют скорости загрузки )

[Bloodzeed]

how do you get supports node on windows? also if support mode is only for linux can a linux support mode connect to a windows
stream and support it?

its like like another seed for the stream?

[forvard]

Доброго времени суток! Не нашел подходящей темы, или нашел, не знаю...
вопрос по он-лайн просмотру с трекера рутор, а не по бродкастингу.
Вот какая проблема: после установки ПО протестил, как написано, все работает, лайв трансляции тоже идут без лагов, вернее вчера шли, с сайта http://livefootball.ws, единственно не работает он-лайн просмотр с торрент-трекеров, конкретно с рутора, в плеере пишет urlopen error [errno 10013]

что делаю не так и как поправить?

[asa]

http://oldforum.acestream.media/index.php?topic=1296.0