+  HandyCache форум
|-+  Главная категория» Новые предложения» Докачка файлов и загрузка по частям
Имя пользователя:
Пароль:
Страниц: 1 2 3 [4] 5 6 7   Вниз
  Отправить эту тему    Печать  
Автор Тема: Докачка файлов и загрузка по частям  (Прочитано 148869 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Денис
Новичок
*

Репутация: +0/-0
Offline Offline

Сообщений: 6


« Ответ #60 : 03 декабря 2007, 13:55:01 »

Цитировать
В данном случае у меня сомнения в том, что это делает СКВИД

Добавлено: 03 Декабря 2007, 16:51:55

Отсутствие докачки противоречит главной возможности HC - экономии трафика.
Сообщить модератору   Записан
mai62
Автор HC
*****

Репутация: +226/-4
Offline Offline

Сообщений: 6383


« Ответ #61 : 03 декабря 2007, 14:20:33 »

Мне кажется ты не понял о чем речь в этой теме.
Насколько я понял на твоей картинке какая-то программа для закачки файлов и она работает через СКВИД. И пусть работает. Такую работу и сейчас НС поддерживает.
В этой же теме речь идет о том, чтобы НС сам докачивал файлы при обрыве загрузки, программа-клиент может и не знать ничего об обрыве и докачке.
Сообщить модератору   Записан
Сергей
Beta tester
*****

Репутация: +9/-2
Offline Offline

Сообщений: 621



« Ответ #62 : 03 декабря 2007, 14:33:08 »

Там вообще ftp. Который не кэшируется вовсе сейчас. И не особо надо.
В этой же теме речь идет о том, чтобы НС сам докачивал файлы при обрыве загрузки, программа-клиент может и не знать ничего об обрыве и докачке.
Вот это тоже сомнительная фича. Сервер может и не поддерживать докачку.

Намного нужнее писать в кэш файлы которые докачивает сам клиент. При последовательной загрузке в один поток. Примеры клиентов: Windows Update, Offline Explorer.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #63 : 03 декабря 2007, 15:49:02 »

Там вообще ftp. Который не кэшируется вовсе сейчас.

Вообще-то кэшируется, если GET-методом, как на скрине!

Цитировать
Вот это тоже сомнительная фича. Сервер может и не поддерживать докачку.

Если сам сервер не поддерживает докачку, то и клиент никаких Partial Content не дождется! Что тогда ты хочешь склевать в кэше?

Цитировать
Намного нужнее писать в кэш файлы которые докачивает сам клиент. При последовательной загрузке в один поток. Примеры клиентов: Windows Update, Offline Explorer.

Как раз нужнее то, о чем говорит mai62, т.к. это касается каждого, кто пользуется браузерами, т.е. абсолютно всех!

Например, зашел ты на сайт с большой картинкой. Браузер начал ее качать, но связь оборвалась! После восстановления связи если ты нажмешь "Обновить", то закачка опять начнется с самого начала! Вот в этом случае HC мог бы быстро отдать из кэша скачанное в прошлый раз начало картинки и послать на сервер запрос с Range, чтобы получить только ее окончание!
Сообщить модератору   Записан
Сергей
Beta tester
*****

Репутация: +9/-2
Offline Offline

Сообщений: 621



« Ответ #64 : 03 декабря 2007, 16:28:23 »

Ладно. Давайте не будем спорить о том что нужнее. Обе ситуации актуальны.

Но, мой вариант, думаю, реализовать намного проще.
Всего-лишь разрешить писать в кэш то, что раньше игнорировалось. Кому от этого станет хуже?
Вот бы увидеть такую фичу в версии 1.0. Цены бы не было НС.

А вот со вторым вариантом возможны подводные камни, которые надо будет еще долго тестировать.
« Последнее редактирование: 03 декабря 2007, 16:50:31 от Сергей » Сообщить модератору   Записан
mai62
Автор HC
*****

Репутация: +226/-4
Offline Offline

Сообщений: 6383


« Ответ #65 : 03 декабря 2007, 16:39:03 »

Цитировать
Всего-лишь разрешить писать в кэш
Разрешить мало. Надо где-то хранить служебную информацию, как-то проверять актуальность имеющихся кусков. И отлаживать все это еще как-то надо.
Сообщить модератору   Записан
Сергей
Beta tester
*****

Репутация: +9/-2
Offline Offline

Сообщений: 621



« Ответ #66 : 03 декабря 2007, 16:54:10 »

Какая служебная информация понадобится?
Каких кусков? Кусок же один - это файл .NEW Проверять надо только его размер. Если он совпадает со значением в поле Range то дописывать.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #67 : 03 декабря 2007, 17:07:42 »

Каких кусков? Кусок же один - это файл .NEW Проверять надо только его размер. Если он совпадает со значением в поле Range то дописывать.

А если клиент или несколько клиентов будут требовать куски не по порядку? А если размеры кусков будут разными или пересекаться? А если после закачки первого куска файл на сервере изменится (причем, его размер может остаться прежним!)? Проблем много...
Сообщить модератору   Записан
Сергей
Beta tester
*****

Репутация: +9/-2
Offline Offline

Сообщений: 621



« Ответ #68 : 03 декабря 2007, 17:27:28 »

Опять 25 Грустный

Цитировать
А если клиент или несколько клиентов будут требовать куски не по порядку?
Я говорил при последовательной загрузке в один поток одним клиентом. Если это условие не соблюдается то делать как сейчас - игнор записи в кэш. Так хоть что то будет в кэш писаться. Более сложные ситуации реализуем потом.

Цитировать
А если размеры кусков будут разными или пересекаться?
аналогично - игнор

Цитировать
А если после закачки первого куска файл на сервере изменится
Смешно. Какое отношение это имеет к нашему вопросу. Файл может измениться в любой момент и при обычной загрузке которая сейчас реализована.

Все эти проблемы высосаны из пальца.
« Последнее редактирование: 03 декабря 2007, 17:39:33 от Сергей » Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #69 : 04 декабря 2007, 00:58:16 »

Какое отношение это имеет к нашему вопросу. Файл может измениться в любой момент и при обычной загрузке которая сейчас реализована.

В процессе отдачи файла сервером для нас он измениться не может! Т.е. мы на 100% получим рабочий файл, хотя, возможно, уже устаревшую его версию.

Если же запрашивать файл по частям, то после получения начальных кусков, файл может измениться на сервере и конец ты получишь от другого файла!
Склеив их, HC получит битый файл в кэше! Надеюсь, зто понятно?


Я говорил при последовательной загрузке в один поток одним клиентом.

Слишком частная ситуация! Windows Update вообще мало кто пускает через HC! Чтобы это сделать, нужно поковыряться в реестре. Менеджеры закачек обычно ходят напрямую и качают в несколько потоков и т.д.

А вот браузерами пользуются абсолютно все! Надо делать докачку так, чтобы она пригодилась большинству и чтобы потом не пришлось все переделывать!
« Последнее редактирование: 04 декабря 2007, 02:10:57 от DenZzz » Сообщить модератору   Записан
Сергей
Beta tester
*****

Репутация: +9/-2
Offline Offline

Сообщений: 621



« Ответ #70 : 04 декабря 2007, 12:35:51 »

Я рассмотрел две ситуации. Одна не противоречит другой. Мы не говорим которая нужней. Обе надо реализовать!!!! Они разные и никак друг на друга не влияют.

Цитировать
Склеив их, HC получит битый файл в кэше! Надеюсь, зто понятно?
Но и клиент, независимо от того запишется ли файл в кэш, получит битый файл.
В любом случае перекачивать. Надеюсь это тоже понятно?
Этот аргумент не имеет отношения к теме разговора совершенно.

Цитировать
Слишком частная ситуация! Windows Update вообще мало кто пускает через HC!
Заблуждаешься. Когда интернет доступен только через прокси, например как у mai62, то обновление придется пускать через него. Иначе никак. И в реестре тут ковыряться не надо. Это делается стандатрной и хорошо документированной командой proxycfg
Другой вопрос, что тем, у кого интернет нормальный, пускать обновления через HC пока бесполезно. Т.к. нифига в кэше не сохраняется если канал слабый. При обрывах дальше клиент докачивает и данные идут мимо кэша.

Цитировать
Менеджеры закачек обычно ходят напрямую и качают в несколько потоков и т.д.
Значит мы им тут ничем не помешаем.

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

Цитировать
А вот браузерами пользуются абсолютно все! Надо делать докачку так, чтобы она пригодилась большинству и чтобы потом не пришлось все переделывать!
А я о чем? Это надо хорошо обдумать и реализовать в будущем.
Но какое отношение данная фича имеет к тому что я прошу?

DenZzz напряги ум перед тем как писать и вникни лучше в то что я пишу. Не надо сразу все воспринимать в штыки.

Имеем две задачи.

1. Докачивать в случаях когда клиент этого не умеет или не просит об этом.
2. Записывать в кэш данные которые поступают к нам при докачке средствами клиента.
 
Первая ситуация безусловно интересна. Но сложна в реализации.
Во втором случае чаще случается так что докачка идет последовательно в один поток.
И продожить запись будет нетрудно.
Более сложные ситуации можно вообще не рассматривать, т.к. это гарантированно будет менеджер закачек и данные его нам не желательно все равно сохранять в кэше.

ЗЫ Надеюсь не слишком грубо выразился Подмигивающий Прошу не банить.

Сообщить модератору   Записан
Денис
Новичок
*

Репутация: +0/-0
Offline Offline

Сообщений: 6


« Ответ #71 : 04 декабря 2007, 15:10:01 »

Цитировать
Если же запрашивать файл по частям, то после получения начальных кусков, файл может измениться на сервере и конец ты получишь от другого файла!
Склеив их, HC получит битый файл в кэше! Надеюсь, зто понятно?
Для проверки идентификации файла есть заголовки E-tag, Last modified, к тому же при изменении файла он крайне редко совпадает с новым по размеру. И такая же проблема возникает и менеджеров закачек, но они же все равно поддерживают докачку.
Цитировать
1. Докачивать в случаях когда клиент этого не умеет или не просит об этом.
2. Записывать в кэш данные которые поступают к нам при докачке средствами клиента.
В первом случае клиент не отправляет запрос range. HC, обнаружив запрашиваемый файл в кеше, видит, что тот загружен не до конца (возможно он был загружен даже другим клиентом) отправляет запрос range и если получает ответ partial content докачивает, а клиенту отдает HTTP1.1 200 OK. Первую часть (уже загруженную) отдает из кеша, остальную загружает из интернета.

Хранить информацию о частично закачиваемых файлах (URL, размеры принятых кусков, e-tag, last modified и прочее) можно в отдельном файле. Не понимаю в чем проблема?
Вот менеджеры закачек при паузе и их перезапуске помнят же с на сколько частей они разбивали файл и с какого места.

Но, учитывая скорость выпуска новых версий HC, ожидать появление докачки в нем можно, имхо не раньше, чем через пару лет.
Сообщить модератору   Записан
Сергей
Beta tester
*****

Репутация: +9/-2
Offline Offline

Сообщений: 621



« Ответ #72 : 04 декабря 2007, 15:56:29 »

Цитировать
Хранить информацию о частично закачиваемых файлах (URL, размеры принятых кусков, e-tag, last modified и прочее) можно в отдельном файле. Не понимаю в чем проблема?
Почитай в теме Индексирование кэша

Цитировать
HC, обнаружив запрашиваемый файл в кеше, видит, что тот загружен не до конца (возможно он был загружен даже другим клиентом) отправляет запрос range и если получает ответ partial content докачивает, а клиенту отдает HTTP1.1 200 OK. Первую часть (уже загруженную) отдает из кеша, остальную загружает из интернета.
Тут те же подводные камни что и при одновременной загрузке одного URL разными клиентами. Сервер может отдавать всем разные данные в зависимости от содержимого куков или других параметров.
« Последнее редактирование: 04 декабря 2007, 16:24:35 от Сергей » Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #73 : 04 декабря 2007, 19:36:26 »

Но и клиент, независимо от того запишется ли файл в кэш, получит битый файл.
В любом случае перекачивать.

Разумеется. Но ты же предлагаешь писать этот файл в кэш не просто, чтобы он там был и никак не использовался!? Наверное, ты хочешь, чтобы HC выдавал этот файл (или его части) другими клиентам, которые попросят, не качая снова из инета!?
В таком случае, в список "Не обновлять" придется добавить соответствующее правило! А это означает, что HC будет выдавать этот битый файл из кэша и при последующих запросах! Т.е. клиент утрачивает возможность получить корректный файл! Разве не так?

Цитировать
DenZzz напряги ум перед тем как писать и вникни лучше в то что я пишу. Не надо сразу все воспринимать в штыки.

Я его и не расслаблял! Просто пытаюсь выяснить, чем же твоя задача восстребованней и проще в реализации, чем моя.

Цитировать
Имеем две задачи.
1. Докачивать в случаях когда клиент этого не умеет или не просит об этом.
2. Записывать в кэш данные которые поступают к нам при докачке средствами клиента.
Первая ситуация безусловно интересна. Но сложна в реализации.
Во втором случае чаще случается так что докачка идет последовательно в один поток.

Согласен. Задачи две, но их реализация пересекается по многим пунктам! И хорошо бы реализовывать их одновременно, чем потом доделывать/переделывать!

Цитировать
ЗЫ Надеюсь не слишком грубо выразился Подмигивающий Прошу не банить.

Да уж, за последние дни чего только не начитался! Если так пойдет дальше, скоро терпение кончится и начнутся репрессии!  Подмигивающий



Хранить информацию о частично закачиваемых файлах (URL, размеры принятых кусков, e-tag, last modified и прочее) можно в отдельном файле. Не понимаю в чем проблема?

Можно в отдельном файле, можно в индексе, но я предлагаю хранить исходные заголовки прямо в начале временного файла .NEW, которые создает HC при закачке (кроме "chunked")! По моим наблюдениям, все менеджеры закачек именно там их и хранят!

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

Ну так на то мы и будем хранить заголовки! Content-Length, Last-Modified и ETag позволят однозначно идентифицировать неизменность файла!
Алгоритм докачки, когда клиент ее не поддерживает, примерно такой:
- Клиент прислал повторный запрос на файл, закачка которого в первый раз прервалась.
- HC ищет в кэше его временный файл и читает оттуда информацию о размере скачанной в первый раз части (х) и заголовки.
- HC формирует запрос с заголовком: Range: bytes=(х+1)-  и передает его на сервер.
- При получении ответа 206 сравнивает его заголовки Last-Modified и ETag с соответствующими сохраненными в первый раз. Если этих заголовков нет в 206, то можно извлечь полную длину файла из Content-Range и сравнить ее с Content-Length из первой части.
- Если заголовки совпадают, то HC сразу же отдает клиенту начало файла из кэша и следом качаемое продолжение.
- Если заголовки не совпадают, то HC разрывает соединение с сервером, очищает временный файл и шлет серверу исходный запрос клиента (без Range). Получаемые данные пишет во временный файл и передает клиенту и т.д. ...

ИМХО, ничего сверхсложного в этой реализации нет...
Добавлено: 04 Декабря 2007, 20:17:07

P.S. При одновременной загрузке одного URL разными клиентами в один и тот же момент времени в кэш пишет тот, кто занял временный файл первым. Собственно, как и сейчас!
В идеале, хорошо бы придерживать параллельные закачки, но это уже совсем другая тема...
Сообщить модератору   Записан
Дем
Постоялец
***

Репутация: +6/-3
Offline Offline

Сообщений: 167



« Ответ #74 : 05 декабря 2007, 01:03:11 »

Цитировать
- При получении ответа 206 сравнивает его заголовки Last-Modified и ETag с соответствующими сохраненными в первый раз. Если этих заголовков нет в 206, то можно извлечь полную длину файла из Content-Range и сравнить ее с Content-Length из первой части.
- Если заголовки совпадают, то HC сразу же отдает клиенту начало файла из кэша и следом качаемое продолжение.
- Если заголовки не совпадают, то HC разрывает соединение с сервером, очищает временный файл и шлет серверу исходный запрос клиента (без Range). Получаемые данные пишет во временный файл и передает клиенту и т.д. ...
Собственно, если сервер получит запрос 206 с неправильными (устаревшими) Last-Modified и ETag - то он как правило сам всё сделает и выдаст новую версию.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #75 : 05 декабря 2007, 01:49:24 »

Цитировать
HC разрывает соединение с сервером, очищает временный файл и шлет серверу исходный запрос клиента (без Range)
Никаких повторных запросов. Надо использовать If-Range.
По размеру сопоставлять некорректно. Это все равно, как если б мы начали сопоставлять по размеру любой файл из кэша, не попадающий в список Н, и в случае совпадения прерывать его загрузку.
Сообщить модератору   Записан
Сергей
Beta tester
*****

Репутация: +9/-2
Offline Offline

Сообщений: 621



« Ответ #76 : 05 декабря 2007, 06:15:41 »

Цитировать
P.S. При одновременной загрузке одного URL разными клиентами в один и тот же момент времени в кэш пишет тот, кто занял временный файл первым. Собственно, как и сейчас!
Файл пишет ведь не клиент а HC. Сейчас всегда одинаковые ссылки качаются повторно, а можно было бы повторить тот же алгоритм.
Если другой клиент запрашивает тот же URL то смотреть что уже скачано и если заголовки совпадают то отдать клиенту уже скачанный кусок и потом отдавать получаемые данные двум клиентам параллельно.
Добавлено: 05 Декабря 2007, 07:13:39

Но тут придется писать во временный файл все получаемые данные а не только те что попадают под список Запись в кэш.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #77 : 05 декабря 2007, 08:56:15 »

Цитировать
хранить исходные заголовки прямо в начале временного файла .NEW, которые создает HC при закачке
Сейчас файл .new в конце закачки просто переименовывается. Если сразу писать в него заголовок, каждый такой файл придется после успешной закачки читать с диска, парсить, отсекая заголовки, а затем писать на диск уже итоговый файл. В подавляющем большинстве случаев это будет пустая работа, т.к. закачка не будет прерванной.
Хорошо бы делать такую запись в файл .new не всегда, а только в тех случаях, когда НС установил, что закачка прервана.
« Последнее редактирование: 05 декабря 2007, 09:09:20 от Михаил » Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #78 : 05 декабря 2007, 09:46:49 »

Никаких повторных запросов. Надо использовать If-Range.
По размеру сопоставлять некорректно.

If-Range в паре с Range - это хорошо. Но если ETag и Last-Modified неизвестен, то ты предлагаешь вообще не докачивать файлы? Как уже говорили, вероятность, что изменившийся файл будет с тем же размером, низка...

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

И такой алгоритм уже не раз просили реализовать пользователи! ИМХО, он ничем не хуже правил того же списка "Не обновлять"!
Как ты сам писал, I-M-S не всегда эффективен, поэтому дополнительная сверка размера файла пришлась бы кстати!
Кому в равной степени важна и актуальность данных, и экономия - смогут отключить "Не обновлять" и оставить только проверки I-M-S, I-N-M и размера. Когда первые 2 сервер не поддерживает, сверка размера станет последним рубежом экономии!
Думаю, в будущем это можно будет реализовать с помощью скриптов: HC будет передавать Lua на обработку длину файла в кэше, а скрипт скажет выдавать его из кэша или нет.
Но это уже совсем другая история за рамками данной темы...



Если другой клиент запрашивает тот же URL то смотреть что уже скачано и если заголовки совпадают то отдать клиенту уже скачанный кусок и потом отдавать получаемые данные двум клиентам параллельно.

Да, нечто подобное уже предлагалось в теме: "Придерживать параллельные закачки".



Хорошо бы делать такую запись в файл .new не всегда, а только в тех случаях, когда НС установил, что закачка прервана.

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

P.S. Ведь, можешь же вносить дельные предложения для всеобщего блага, а не только для закрытия дыр любимой Оперы! Подмигивающий
« Последнее редактирование: 05 декабря 2007, 09:59:20 от DenZzz » Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #79 : 05 декабря 2007, 10:21:04 »

Цитировать
дополнительная сверка размера файла пришлась бы кстати
В принципе, да. Нужно лишь делать такое поведение отключаемым.
Сообщить модератору   Записан
Страниц: 1 2 3 [4] 5 6 7   Вверх
  Отправить эту тему    Печать  

 
Перейти в: