LINUX.ORG.RU
ФорумTalks

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


0

0

Пара вопросов:

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

2. Пишу сейчас веб-морду к многопоточной prozilla на основе библиотеки libprozilla. Работа на заказ.
Могу написать еще один велосипед под GPL - форк от prozilla. Стоит ли ?
Если да, то чем плоха стандартная прозилла ? Качество кода можно не упоминать - оно не очень хорошее.
Есть мысль написать демона на основе libprozilla + документировать API к нему.

Homepage: http://prozilla.genesys.ro/

★★★★★

Ответ на: комментарий от pacify

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

~$ apt-cache search prozilla
~$

Жаль =(

ManJak ★★★★★
()

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

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

anonymous
()

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

Relan ★★★★★
()
Ответ на: комментарий от Relan

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

Deleted
()

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

pacify ★★★★★
() автор топика
Ответ на: комментарий от pacify

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

anonymous
()

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

asgard
()
Ответ на: комментарий от asgard

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

pacify ★★★★★
() автор топика

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

shinobi
()
Ответ на: комментарий от pacify

Смысл в том, что 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

putpixel
()
Ответ на: комментарий от putpixel

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

pacify ★★★★★
() автор топика
Ответ на: комментарий от pacify

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

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

putpixel
()
Ответ на: комментарий от pacify

2pacify:

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

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

Die-Hard ★★★★★
()

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

ManJak ★★★★★
()

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

Scream
()
Ответ на: комментарий от Die-Hard

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

pacify ★★★★★
() автор топика
Ответ на: комментарий от pacify

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

Xellos ★★★★★
()
Ответ на: комментарий от putpixel

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

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

anonymous
()

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

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

Shmuma
()
Ответ на: комментарий от Shmuma

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

Dieter ★★★
()
Ответ на: комментарий от Shmuma

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

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

Gharik
()
Ответ на: комментарий от Dieter

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

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

Shmuma
()

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

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

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

Obidos ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.