| 1.1, maxkit (ok), 17:12, 18/05/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
 Жаль, никак не прикрутят последовательное скачивание файла. Это единственное, чего не хватает, из-за чего приходится пользоваться qbittorrent'ом.
| | |
| |
| 2.2, me (??), 17:39, 18/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
Есть же вроде какой-то скрипт, который это реализует
| | |
| |
| 3.6, maxkit (ok), 18:41, 18/05/2011 [^] [^^] [^^^] [ответить]
| –2 +/– |
Я не знаю о таком скрипте. Но, возможно, Вы не верно меня поняли. Я имел в виду последовательное скачивание файла, а не очерёдность скачивания торрентов. Это чтобы можно было поставить на скачку видео - и тут же начать его просмотр.
| | |
|
| 2.7, Аноним (-), 18:54, 18/05/2011 [^] [^^] [^^^] [ответить]
| +7 +/– | |
> Жаль, никак не прикрутят последовательное скачивание файла.
Разработчики разбираются в протоколе и врядли будут прикручивать довольно деструктивную (для сети в целом) функцию добровольно. Есть исходники - вы и прикручивайте, если настолько надо.
| | |
| |
| 3.8, iZEN (ok), 19:43, 18/05/2011 [^] [^^] [^^^] [ответить]
| –6 +/– |
 Почему же это деструктивная функция? Для фильмов и музыки последовательное скачивание и обмен первыми блоками является ниболее важным этапом, так как воспроизведение такого контента можно начать не тогда, когда он полностью скачался, а с начала запуска p2p-обмена (если скорость скачивания больше воспроизводимого битрейта самого фильма). Не нужно ждать докачки, чтобы посмотреть видеоролик, возможно он окажется не тем, чем хотелось бы. Это разгрузит каналы от ненужного пользователям трафика.
| | |
| |
| 4.9, Ytch (?), 22:04, 18/05/2011 [^] [^^] [^^^] [ответить]
| +11 +/– | |
>Почему же это деструктивная функция?
Раздающий должен оставаться на раздаче гораздо дольше. Допустим, 50 пиров "последовательным" образом скачали 80% ролика за час и в этот момент раздающий "свалил", результат - ни у кого нет полного ролика. При тех же условиях, но "классическом" способе скачивания уже в среднем минут через 15-20 все части будут у кого-нибудь еще "на руках". Повышение "живучести" налицо.
| | |
| |
| 5.11, iZEN (ok), 23:02, 18/05/2011 [^] [^^] [^^^] [ответить]
| –1 +/– |
>>Почему же это деструктивная функция?
> Раздающий должен оставаться на раздаче гораздо дольше. Допустим, 50 пиров "последовательным"
> образом скачали 80% ролика за час и в этот момент раздающий
> "свалил", результат - ни у кого нет полного ролика.
Зато они посмотрят эти 80% (или только начало — кому как захочется — но они не будут ждать до конца скачки всего ролика. Разбегутся или будут ждать/давать новичкам посмотреть — это уже личный выбор пиров, а не раздающего.
> При тех
> же условиях, но "классическом" способе скачивания уже в среднем минут через
> 15-20 все части будут у кого-нибудь еще "на руках". Повышение "живучести"
> налицо.
При тех же условиях, раздающему будет по барабану, скачали ролик или нет. Он просто уйдёт, никого не предупредив, оставив абсолютно всех ни с чем, с обломками невоспроизводимого.
| | |
| |
| 6.15, Ytch (?), 01:16, 19/05/2011 [^] [^^] [^^^] [ответить]
| +/– | |
>Зато они посмотрят эти 80% (или только начало — кому как захочется — но они не будут ждать до конца скачки всего ролика. Разбегутся или будут ждать/давать новичкам посмотреть — это уже личный выбор пиров, а не раздающего.
Кто-то (или даже большинство) может захотеть весь ролик, например, если что-то действительно интересное.
> При тех же условиях, раздающему будет по барабану, скачали ролик или нет. Он просто уйдёт, никого не предупредив, оставив абсолютно всех ни с чем, с обломками невоспроизводимого.
О чем и речь, только вероятность этого тем меньше, чем быстрее ролик окажется более чем в одних руках, а при последовательном скачивании всеми это событие может наступить очень не скоро. Не у всех есть возможность быть на раздаче 24 часа 7 дней в неделю.
| | |
| |
| 7.16, iZEN (ok), 01:51, 19/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
>>Зато они посмотрят эти 80% (или только начало — кому как захочется — но они не будут ждать до конца скачки всего ролика. Разбегутся или будут ждать/давать новичкам посмотреть — это уже личный выбор пиров, а не раздающего.
> Кто-то (или даже большинство) может захотеть весь ролик, например, если что-то действительно интересное.
Для видео имеет практический смысл максимальная целостность кусков, а первые кусочки видео имеют наибольшую ценность для получателя. Традиционный протокол bittorent не учитывает ранжирование кусочков, разбрасывает из по пирам более-менее равномерно. Такая стратегия распространения неприемлема для видеопотока, чтобы его можно было смотреть непрерывно.
Например, видеотрансляция с веб-камеры в сеть могла бы происходить, используя p2p-механизм распространения контента, когда подключившийся пользователь начинает смотреть видеопоток с камеры, кэширует определённой длительности фрагмент (грубо: создаёт копию буфера данных видеокамеры), другие пользователи могли бы не подключаться к видеокамере, а подключиться к пользователю, который уже закэшировал начало потока и распространять видео далее среди новых подключившихся. На видеокамере в этом случае не нужно хранить весь видеопоток, а только тот фрагмент, для которого рейтинг скачивания не превысил единицу. Это существенно съэкономит аппаратное обеспечение видеосервиса и разгрузит сеть.
| | |
|
| 6.24, Аноним (-), 14:30, 19/05/2011 [^] [^^] [^^^] [ответить] | +/– | Проблема только в том что кому будет нужен весь ролик - вообще не сможет его ник... большой текст свёрнут, показать | | |
|
| 5.19, maxkit (ok), 02:11, 19/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
>>Почему же это деструктивная функция?
> Раздающий должен оставаться на раздаче гораздо дольше. Допустим, 50 пиров "последовательным"
> образом скачали 80% ролика за час и в этот момент раздающий
> "свалил", результат - ни у кого нет полного ролика. При тех
> же условиях, но "классическом" способе скачивания уже в среднем минут через
> 15-20 все части будут у кого-нибудь еще "на руках". Повышение "живучести"
> налицо.
Этим процессом логичнее было бы управлять раздающей, а не принимающей стороне. Никто не мешает реализовать функцию "раздать максимально быстро весь файл", а вот при скачивании файлов - очень неплохо было бы иметь возможность качать последовательно. Интегрально нагрузка на каналы та же, а удовольствия - больше.
| | |
| |
| 6.22, Аноним (-), 12:34, 19/05/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Никто не мешает реализовать функцию "раздать максимально быстро весь файл"
Никто. И уже реализовали. Суперсид называется.
| | |
| 6.25, Аноним (-), 14:31, 19/05/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Интегрально нагрузка на каналы та же, а удовольствия - больше.
Интегрально, файл будет качаться явно дольше. При том у всех вообще. Если вы хотите потоковое видео и аудио - вы не по адресу: торрент - это не потоковое видео и никогда таковым не являлся.
| | |
|
| 5.35, konkor (?), 15:55, 20/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
1 time
supersid -block1-> 1 lich
2 time
supersid -block2-> 1 lich
1 lich -block1-> 2 lich
3 time
supersid -block3-> 1 lich
1 lich -block2-> 2 lich
2 lich -block1-> 3 lich
и так по геометрической прогрессии. Кроме того если суперсид имеет канал шире может раздать в один промежуток времени разные блоки разным личам, ну а если еще и мультикаст одних и тех же блоков разным клиентам...
| | |
| |
| 6.36, konkor (?), 15:59, 20/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
ЗЫЖ и чем отдача в сеть последовательности 1,2,3,4,5 и 2,4,5,3,1 отличается по времени?!
Если сидер уйдет с раздачи на 80% то лучше получить данные 1,2,3,4 а не 2,4,5,3. Логично?
| | |
|
|
| 4.23, Аноним (-), 14:13, 19/05/2011 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Почему же это деструктивная функция?
Потому что ведет к ухучшению равномерной доступности всех частей файла и в результате общей деградации скорости закачки в среднем.
> Для фильмов и музыки последовательное скачивание и обмен первыми блоками
> является ниболее важным этапом,
Именно первые+последние несколько блоков еще фиг с ними, сильно погоду не делают, а запревьюить и сделать выводы о том надо ли это вообще качать - позволяют. А вот последовательная скачка файла вообще - ломает логику протокола торрента. Этот протокол никогда не создавался для последовательной скачки.
> так как воспроизведение такого контента можно начать не тогда, когда
> он полностью скачался, а с начала запуска p2p-обмена (если скорость
> скачивания больше воспроизводимого битрейта самого фильма).
Проблема только в том что данное поведение приводит к тому что начальные части файла присутствуют у намного большего числа пиров чем конечные. Ну и в результате те кому нужны части с хвоста - начинают обнаруживать что скорость закачки просела. Средняя скорость скачки файла - падает: в стае получается избыток начальных частей, которые уже никому не нужны, их не получается лить и бартер частями не случается. И недостаток конечных частей, которые попросту некому лить на всю толпу желающих.
> Не нужно ждать докачки, чтобы посмотреть видеоролик, возможно он
> окажется не тем, чем хотелось бы. Это разгрузит каналы от ненужного
> пользователям трафика.
Именно предварительный даунлоад начала + конца файла еще куда ни шло, а вот последовательная скачка всего файла - это уже вредительство просто.
| | |
| 4.31, Аноним (-), 19:55, 19/05/2011 [^] [^^] [^^^] [ответить]
| +/– | |
>>>Почему же это деструктивная функция?
Потому что рушит сам принцип протокола. А он гласит - редкие части скачиваются первыми. Если нарушить - вся раздача встанет.
| | |
|
|
| 2.10, Аноним (-), 22:06, 18/05/2011 [^] [^^] [^^^] [ответить]
| +/– | |
>Жаль, никак не прикрутят последовательное скачивание файла.
Это противоречит всей идеи. Какой смысл будет в 10 сидах если они все буду одни и те же куски качать? Все будут сидеть на стремной скорости. Именно рандомность кусков позволяет качать со всех, кто учавствует в раздаче/приеме.
| | |
| |
| 3.12, iZEN (ok), 23:06, 18/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
>>Жаль, никак не прикрутят последовательное скачивание файла.
> Это противоречит всей идеи. Какой смысл будет в 10 сидах если они
> все буду одни и те же куски качать?
Они будут качать куски друг у друга, так как время появления пиров не одномоментное.
> Все будут сидеть
> на стремной скорости. Именно рандомность кусков позволяет качать со всех, кто
> учавствует в раздаче/приеме.
Рандомность подключения пиров обеспечивает разгрузку канала раздающего. Те, из пиров, кто подключился раньше, смогли скачать большую часть начала ролика. Те, кто подключается к обмену позднее, данные качают у тех, кто уже скачал. Чуете в чём фикус? Это не противоречит идеям равноправного обмена.
| | |
| |
| 4.28, Аноним (-), 15:17, 19/05/2011 [^] [^^] [^^^] [ответить] | +/– | А не будут Пусть в стае 100 пиров Пусть есть 10 сидеров и еще 90 которые качаю... большой текст свёрнут, показать | | |
|
| 3.13, iZEN (ok), 23:18, 18/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
>>Жаль, никак не прикрутят последовательное скачивание файла.
> Это противоречит всей идеи. Какой смысл будет в 10 сидах если они
> все буду одни и те же куски качать? Все будут сидеть
> на стремной скорости. Именно рандомность кусков позволяет качать со всех, кто
> учавствует в раздаче/приеме.
Продолжу предыдущее сообщение.
Так называемая ПИРАМИДА с "волной" распространения видеоконтента от раздающего через тех, кто раньше всех к нему подключился, к тем, кто вступает в p2p-обмен позднее. Соответственно, такая архитектура информационного обмена гораздо устойчивее и надёжнее: раздающий может дождаться распространения своего контента (рейтинг 1) и свалить (разгрузить исходящий канал для следующего ролика), а дальше работает первый из пиров, который скачал весь ролик и раздаёт недостающее другим, у которых 80..90..95%. Дальше это "плато" раздаёт нижним "слоям" — в любом случае, распространение полной информации возможно при рейтинге не ниже 1 в каждом "слое" пиров, а не для одного пира, исключая раздающего, конечно. Для видеороликов полное скачиваение не так принципиально, сколько их целостность в самом начале для обеспечения идентификации и запуска волны скачивания.
Стратегия последовательного скачивания контента незаменима по своей сути для работы p2p-телевидения и радио с шифтингом потоков.
| | |
| |
| 4.27, Аноним (-), 14:36, 19/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Продолжу предыдущее сообщение.
> Так называемая ПИРАМИДА с "волной" распространения видеоконтента от раздающего через тех,
> кто раньше всех к нему подключился,
Все замечательно. Кроме того что все это - не про битторент. Если тебе надо потоковое видео - отлично, надизайни протокол или используй уже надизайненые. Но при чем тут торрент?!
| | |
|
| 3.18, maxkit (ok), 02:08, 19/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
>>Жаль, никак не прикрутят последовательное скачивание файла.
> Это противоречит всей идеи. Какой смысл будет в 10 сидах если они
> все буду одни и те же куски качать? Все будут сидеть
> на стремной скорости. Именно рандомность кусков позволяет качать со всех, кто
> учавствует в раздаче/приеме.
Уважаемый товарищ Аноним, позвольте я Вас поправлю. Во-первых, не "идеи", а "идее". Во-вторых, сид - это тот, у кого есть полная копия торрента, в-третьих, в случае "рандомности" зависимость от пиров - так же велика, достаточно одному отвалиться, кусок выпадет, в-четвёртых, с возможностью последовательного скачивания скорость уже не так критична.
| | |
|
| 2.14, Аноним (-), 23:33, 18/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
А чем вас не устраивает qbittorrent?
По моему очень даже неплохая вещь. А главное - разраб отзывчивый человек. Все баги фиксит оперативно
| | |
| |
| 3.17, maxkit (ok), 02:04, 19/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
Устроил, я им пользуюсь. Автор - да, отзывчив, я имел с ним дело. Но Transmission - тоже отличная программа и не требует загрузки Qt. Вот только последовательного скачивания не хватает. Ведь очень полезная функция.
| | |
| |
| 4.20, anonymous (??), 08:06, 19/05/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Вот только последовательного скачивания не хватает. Ведь очень полезная функция.
Ну во первых время вылечет ...
Вон у меня на 10мегабитах файл 1.5 гига качается минут 10-15.... подумаешь.
Я так понял при последовательном скачивании закачивание у всех должна закончится одновременно. И кто первым начал качать и у всех кто подрубится до окончания скачивания
хотя бы еще 1 человеком. ФИгня какая то выходит :(
P.S. Я так понял они очередь не могут осилить так как эта функция достаточно сложна
по алгоритму ...
| | |
| |
| 5.29, Аноним (-), 15:18, 19/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
> P.S. Я так понял они очередь не могут осилить так как эта
> функция достаточно сложна по алгоритму ...
Последовательно качать - чего там сложного? Просто вредительская функция с точки зрения сети в целом.
| | |
| 5.32, Тот_Самый_Анонимус (?), 07:31, 20/05/2011 [^] [^^] [^^^] [ответить]
| +/– | |
>Вон у меня на 10мегабитах файл 1.5 гига качается минут 10-15.... подумаешь.
У тебя 10 Мбит, у меня 64 кбита. ты скачаешь за 10-15 минут, я за два дня, и буду качать у тебя, если ты останешься на раздаче. Где тут нарушение логики?
| | |
| 5.34, maxkit (ok), 13:58, 20/05/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> Вон у меня на 10мегабитах файл 1.5 гига качается минут 10-15.... подумаешь.
А я на 20 МБитах иногда смотрю HD, и качать по полтора часа 9 ГБ - не очень хочется, когда можно просто начать просмотр сразу.
> Я так понял при последовательном скачивании закачивание у всех должна закончится одновременно. И кто первым начал качать и у всех кто подрубится до окончания скачивания
хотя бы еще 1 человеком. ФИгня какая то выходит :(
Это вполне можно реализовать в раздающей части. Решать проблему головной боли с помощью мадам гильотины - не лучшее средство.
| | |
|
|
| 3.30, Аноним (-), 15:19, 19/05/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> А чем вас не устраивает qbittorrent?
Например, отсутствием нормального демона под ремотное управление. Переть кутю на сервера? Спасибо, я лучше пешком постою.
| | |
|
| 2.37, konkor (?), 16:12, 20/05/2011 [^] [^^] [^^^] [ответить]
| +/– |
qbittorrent такое может... надо поробывать спасибо)))
и еще раз суперсиду все равно отдавать полседовательно или в разброс...
| | |
|
| 1.5, VecH (ok), 18:23, 18/05/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 Скрипт есть, но хочется нативной поддержки
а в вебморде еще лучше :)
| | |
|
