Неужели так трудно понять что общая скорость отдачи всех пиров не может быть больше битрейта трансляции умноженного на общее количество пиров!?
Я где-то упоминал вообще об общей скорости отдачи? Вроде нет и никогда с этим не спорил... Да и
то что Вы пишете о ней, понять не сложно, только Вы тоже должны понять, что не нужно всех мерить одним аршином... и пытаться разделить общий суммарный битрейт на всех поровну... Я уже давно понял, что Вы идеалист... и от реальности оооочень далеко где-то там... в своих теориях и идеальных условиях... Спускайтесь на землю! 
Меня лично теория не сильно волнует, да и думаю остальных тоже, для меня куда важнее результаты! А результаты в полевых условиях пока у Вас так себе... И я Вам пытаюсь показать на некоторые моменты в которых могут скрываться одни из причин мешающих достижению максимального результата...
Пример который я до этого привел, это не идеалистичность а обычная математика, которая показывает что не может вестись речи о какой-то отдачи от всех пиров, которая в 10 раз больше битрейта! Для большей ясности ответьте мне на вопрос, какая максимальная скорость отдачи будет от одного пира, если предположить что в пуле/рое из 10 пиров, половина не раздает вообще, а четыре раздают на скорости битрейта?
А реальность заключается в том, что для организации качественной трансляции нужно учитывать топологию сетей и ставить сервера поддержки ( Сервера поддержки - это и будет то, что можно назвать "супер-сидами", хотя относительно самого протокола битторент и непосредственно файловообмена для них предусмотрена немного иная функция и задача, но название очень уместное ) . Частично проблему задержки можно еще решить за счет большого буфера с приличным отставанием, как это сделано у сопкаст. Увы, но у нас это изначально не было предусмотрено так как мы не собирались готовить конкурента сопкасту, так как нам нужно было добиться минимального отставания и максимально быстрого старта. И уже сейчас, при нормальной профессиональной организации трансляции, такое отставание можно свести до 3 сек, а запуск воспроизведения и переключение между каналами происходит даже быстрее чем переключение спутниковых каналов.
Эти условия также непосредственно влияют и на скорости загрузки/отдачи. То есть, чем больше буфер, тем больший объем данных ходит между пользователями в определенном диапазоне времени. В сравнении с сопкаст, этот объем данных у них раз в 6 больше чем у нас ( у нас он по умолчанию 10 сек., а у них явно не менее 60 сек ). Чтобы было еще более понятней о чем я, то поясню: если мы врубим по умолчанию буфер в 1 час, то скорость скачивания и отдачи будет у многих взлетать под потолок, за счет того что весь объем данных на час просмотра доступен сразу, а не дозировано на протяжении часа
P.S. Для всех! Сейчас у нас опция "буфер потока", работает не корректно и при ее значительном увеличении будут постоянная буферизация, так как будут происходить скачки вперед и плеер будет опять уходить на буферизацию, поэтому больше 30 сек. даже не ставьте.
В ближайшее время мы подготовим версию где будет корректно работать эта опция для любого диапазона времени, а также добавим нормальную работу паузы и функцию TimeShift. Вот с этими функциями, это действительно можно использовать как хорошую альтернативу сопкаст, если конечно врубить минутный буфер, как у сопкаст, вместо 10 сек. Ну а на сегодняшний день, любительские трансляции не для всех будут хорошо работать.
P.P.S. Мы однозначно прислушиваемся к советам, выводам и мнению как к вашему, так и других бродкастеров. Ну и конечно мы все это будем улучшать, улучшать и еще раз улучшать, но на это нужно время и многочисленные тесты.
Автор
Тема: Тестируем ПО Torrent Stream (ACE Stream) 2.0. ( для Windows ) (Ru) (Прочитано 631174 раз)