Нужна ли многопоточность в качалках ?

Кстати, тут пишут, что прозиллы в Дебиане уже нет -
http://lists.debian.org/debian-russian/2006/09/msg00435.html

Да, точно нет =(

~$ apt-cache search prozilla
~$

Жаль =(

>1. Нужна ли многопоточность в качалках ? Пользуетесь ли вы ей ?

Вот неплохо бы один файл тянуть с нескольких FTP/HTTP/HTTPS, как в RevConnect для DirectConnect...

Пользуюсь wget'ом, необходимости в многопоточности для себя не вижу. Идея с демоном интересна, с сочетании с хорошим и простым front-end'ом могла бы пойти в массы. :)

>Пользуюсь wget'ом, необходимости в многопоточности для себя не вижу. Идея с демоном интересна, с сочетании с хорошим и простым front-end'ом могла бы пойти в массы. :)

Многопоточность нужна, когда канал никак не режется, или когда на один поток фиксированная максимальная скорость. А если все и так хорошо - зачем она нужна? :)

да не скажи... многопоточность все-таки позволяет поднять скорость, а идея с демоном вообще +100

Кстати, не напомните, почему Виталию Луговскому не нравились пакеты с configure ?
Я вот скрипт компиляции библиотеки libprozilla тоже без них пишу. Но хотелось бы мнения "за" и "против" ...

Я, например, не люблю configure за его охрененыо большой размер и за скорость работы.

> 1. Нужна ли многопоточность в качалках ? смотря какая =) многопоточность как абстракное понятие - штука неплохая. причём если иметь возможность управлять каждым потоком, например, иметь возможность указать каждому какую-нибудь проксю, отличную от проксей, указанных другим потококам. другое дело - как сие будет реализовываться. если для каждого потока используется тред - фтопку. если используются неблокирующие сокеты, то why not? тк при закачки в несколько потоков прироста скорости не будет, вся производительность всё равно упрётся в пропускной канал карточки. так что главная цель таких вот потоков - грамотное разбиение закачки на задачи. а юзать поделье, неоправданно использующее треды, очень не хочется.

В библиотеке libprozilla используются pthreads по одному на кусок файла. Несколько проксей не предусмотрено.
С проксями можно доработать напильником, хотя проще переписать библиотеку "с нуля".
Мне не переписать - знаний по сетям парктически никаких ...

Нафига? Есть же curl.

первое, что подумалось, увидев топик, что нужна, т.к. это плохо, когда все тренажеры заняты =)

$ man curl | pr | grep -i thread | wc -l
Reformatting curl(1), please wait...
0

Смысл в том, что curl'ом можно тянуть файл по кускам, в том числе и с разных url, а потом склеить.

bash$ curl -r 0-199999999 -o blah-blah.iso.part1 $url1 &
bash$ curl -r 200000000-399999999 -o blah-blah.iso.part2 $url2 &
bash$ curl -r 400000000- -o blah-blah.iso.part3 $url3 &
bash$ cat blah-blah.iso.part? > blah-blah.iso

Хм, полезная вещь.
Но заказчик хочет еще иметь возможность приостанавливать закачку.

Ну и что? Прибей все процессы. Надо будет продолжить - bash$ curl -r (длина закачанного куска в байтах + 1)-199999999 -o blah-blah.iso.part1.1 $url1 &

И так для каждого процесса.

2pacify:

> В библиотеке libprozilla используются pthreads по одному на кусок файла.

ИМХО странный подход... Многократные коннекты к удаленному серверу могут помочь преодлеть лишь "наивно" выставленные ограничения на сервере по траффику на соединение. Хотя, как я понимаю, такое в России до сих пор практикуется...

Ой, забыл написать, что - да, нужна.

aria2c, вчера шарился по портежам искал чонить подобное прозилле, нашел её :)

Да не, тут все просто ... Два-три потока достаточно, чтобы более полно использовать канал - пока ожидается ответ от сервера - запрашивать следующий пакет.
Таким образом, удается обойтись без неблокирующих сокетов. :)

Половина ftp-серверов тут же отправит в баню навечно.

>Ну и что? Прибей все процессы. Надо будет продолжить - bash$ curl -r >(длина закачанного куска в байтах + 1)-199999999 -o >blah-blah.iso.part1.1 $url1 &

А SIGSTOP и SIGCONT для кого придуман?

Многопоточность однозначно нужна, только качая в 5 потоков я выбираю весь канал у своего чудо-провайдера.

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

А что такого можнл качать с http/ftp что нужна многопоточность? там же практически ничего нет, разве что качать бинарики, сорсы?

> Многопоточность однозначно нужна, только качая в 5 потоков я выбираю весь канал у своего чудо-провайдера.

Вот она только тем и нужна, кто у всяких чудорасов сервится :)

Сервер под Linux в Москве с 10 Мбит анлимом, доступный по ssh. На нем круглосуточно крутится rtorrent+edonkey.

Скачанное утягивается по http в наш Мухосранск. Получается реально быстрее и дешевле.

Изречение 1. За многопоточное скачивание _с_одного_сервера_ -- кастрировать, отрубать руки, перерабатывать на метан.

Изречение 2. За поиск зеркал и многопоточное качание в один поток с каждого найденного источника -- премию за написание очередного торрент/ослоклиента.

Пояснение к Изречению 1. Именно из-за таких даунов с нетрадиционной ориентацией админинистрация mp3.int.ru была вынуждена наглухо забанить подсети МТУ. Если владелец сервера ставит некоторое ограничение, то это делается не просто так, а чтобы сервисом одновременно могли пользоваться больше людей.