HandyCache форум

Главная категория => Новые предложения => Тема начата: DenZzz от 15 января 2007, 23:44:08



Название: Докачка файлов и загрузка по частям
Отправлено: DenZzz от 15 января 2007, 23:44:08
Эта тема уже ни раз всплывала на ру-борде, но потом благополучно забывалась...

Суть такова: если сервер или провайдер (плохая связь и т.п.) внезапно разорвали соединение во время закачки файла, то при следующей попытке не начинать качать файл с начала (как сейчас!), а попытаться его докачать с того места, где закачка была прервана!

Тогда во многих случаях и менеджер закачек не понадобится!
А пользователи на плохих каналах получат дополнительную экономию трафика!

Естественно, динамический контент докачать не получится. А вот картинки, архивы, музыку и т.п. известной длины - вполне!

Вроде и mai62 был не против этой идеи... :)
Давайте подумаем и обсудим, нужна ли такая опция и как ее лучше реализовать!


Название: Re: Докачка файлов
Отправлено: Сергей от 16 января 2007, 09:03:52
Конечно нужна.
Обсуждали не раз и алгоритм один уже предлагался.
Суть в том, чтобы сохранять запросы Partial Content тоже, и склеивать на лету.


Название: Re: Докачка файлов
Отправлено: Сергей от 16 января 2007, 09:15:34
К именам фрагментов лучше добавлять просто информацию о месте его в полном файле.
Например, дописывать такую строчку #305806
Так мы узнаем, что фрагмент начинается с позиции 305806 байт от начала.
Длину фрагмента узнаем по размеру файла с этим фрагментом.
Фрагмент начинающийся с нулевой позиции называем так-же как и сейчас: file.new или лучше file#0

Если это будет реализовано, я съэкономлю кучу трафика на Windows Update.

Цитировать
Сколько же там кусочков будет, тысячи?

Да. Но, как правило, кусочки идут по порядку. Тогда можно их на лету склеивать. Т.е. дописывать в концы файлов а не создавать новые.


Название: Re: Докачка файлов
Отправлено: Rick от 16 января 2007, 09:51:16
Цитировать
Суть такова: если сервер или провайдер (плохая связь и т.п.) внезапно разорвали соединение во время закачки файла, то при следующей попытке не начинать качать файл с начала (как сейчас!), а попытаться его докачать с того места, где закачка была прервана!
1. Этим же занимается программа (браузер) запросившая файл.
2. А что делать с недокачанными обрывками остановленых и так и не возобновленных загрузок? Будут лежать мертвым грузом в кэше до очистки?


Название: Re: Докачка файлов
Отправлено: Сергей от 16 января 2007, 10:02:42
Цитировать
1. Этим же занимается программа (браузер) запросившая файл

Чем? Кэшированием? С какого перепугу?

Цитировать
2. А что делать с недокачанными обрывками остановленых и так и не возобновленных загрузок? Будут лежать мертвым грузом в кэше до очистки?

А что сейчас происходит с недокачанными кусками .new ?
Тоже нерешенный вопрос. Сейчас они не удаляются но и не докачиваются потом.


Название: Re: Докачка файлов
Отправлено: Rick от 16 января 2007, 10:17:10
Чем? Кэшированием? С какого перепугу?
Хоть убей, не вижу в цитате на которую я отвечал слова "кэш" и производных от него.

Цитировать
А что сейчас происходит с недокачанными кусками .new ?
Тоже нерешенный вопрос. Сейчас они не удаляются но и не докачиваются потом.
Т.е. проблема только усугубится увеличением таких обрывков? А есть предложения по решению?


Название: Re: Докачка файлов
Отправлено: Сергей от 16 января 2007, 10:26:08
Хоть убей, не вижу в цитате на которую я отвечал слова "кэш" и производных от него.

Докачка с места разрыва подразумевает сохранение в кэше (кэширование) скачанных данных.


Т.е. проблема только усугубится увеличением таких обрывков? А есть предложения по решению?

Проблема как раз разрешится. Сейчас фрагменты лежат мертвым грузом. А тут они пойдут в дело. И будет их не много а по одному фрагменту на каждый файл.


Название: Re: Докачка файлов
Отправлено: Rick от 16 января 2007, 10:41:30
Докачка с места разрыва подразумевает сохранение в кэше (кэширование) скачанных данных.
Когда я в Opera скачиваю какой-то файл я могу остановить загрузку, затем продолжить ее. Так же и в FF. Т.е. файлы загружаемые через "Сохранить" или "Сохранить как..." разумеется кэшируются браузером и при возобновлении закачки браузер посылает запрос с какого места следует продолжить загрузку.
Недокачанные файлы со страниц (картинки например) так же попадают в кэш браузера и в случае разрыва связи мы и видим "полкартинки". Пытаются ли браузеры докачивать такие файлы - не уверен, вроде бы нет.
Так а здесь и сейчас о каких файлах идет речь? Какие файлы предлагается пытаться докачивать (тип, размер), а какие нет?


Проблема как раз разрешится. Сейчас фрагменты лежат мертвым грузом. А тут они пойдут в дело. И будет их не много а по одному фрагменту на каждый файл.
Возможность работы многопоточной "качалки" через НС не учитывается?


Название: Re: Докачка файлов
Отправлено: Сергей от 16 января 2007, 10:59:05
Цитировать
при возобновлении закачки браузер посылает запрос с какого места следует продолжить загрузку.

Т.е имеем Partial Content клиент посылает запросы на скачку не всего файла а только фрагментов. Мы эти фрагменты корректно сохраним в кэше и склеим если нужно.

Цитировать
Пытаются ли браузеры докачивать такие файлы
Не пытаются. Качают заново. В таком случае, HC бы просто сразу отдал браузеру уже скачанное начало файла а серверу послал запрос на остаток. Браузер будет думать, что качает с начала.

Цитировать
Какие файлы предлагается пытаться докачивать
Файлы с известным размером.
Кстати, желательно еще сохранять в кэше размер файла лежащего на сервере. 

Цитировать
Возможность работы многопоточной "качалки" через НС не учитывается?
Об этом и речь.


Название: Re: Докачка файлов
Отправлено: mai62 от 16 января 2007, 11:04:42
Несколько дней назад вспоминал эту тему, к тому подтолкнуло резкое ухудшение качества моего выхода в интернет, часто обрывается закачка файлов в несколько десятков килобайт. Хотелось автоматом начинать докачку сразу при обрыве, без участия пользователя. Пока не нашел с какой стороны подступисться (связь с сервером ведь уже потеряна, нужно возобновлять соединение, а поток, работающий с этим файлом, находится уже на стадии завершения своей работы).
Сделать докачку при обновлении вроде не сложно, единственное, что мешает - мусор в кэше.
Цитировать
А что сейчас происходит с недокачанными кусками .new ?
Тоже нерешенный вопрос. Сейчас они не удаляются но и не докачиваются потом.
Оставлять их не планировалось, уни должны и будут удаляться.
Цитировать
Так а здесь и сейчас о каких файлах идет речь? Какие файлы предлагается пытаться докачивать (тип, размер), а какие нет?
Думаю, обо всех недокачанных: картинках, html, скрипnах и т.д. Они, как ни печально, тоже не всегда загружаются полностью, не только многомегабайтные архивы.


Название: Re: Докачка файлов
Отправлено: Сергей от 16 января 2007, 11:13:00
Цитировать
Оставлять их не планировалось, уни должны и будут удаляться.
Почему сейчас не удаляются? Когда они должны удаляться по твоему?
Я за то, чтобы их оставлять, и удалять только по команде очистки кэша.

html данные можно докачивать только в том случае, если страница на сервере не изменилась. Т.е. сервер сообщает размер и дату. Размер не изменился а дата не новее файла в кэше.
Дату мы храним а атрибутах файла.
Где хранить размер?


Название: Re: Докачка файлов
Отправлено: Rick от 16 января 2007, 11:37:57
Т.е имеем Partial Content клиент посылает запросы на скачку не всего файла а только фрагментов. Мы эти фрагменты корректно сохраним в кэше и склеим если нужно.
Не нужно. Если браузер посылает запрос на фрагмент, то и склейку он выполнит сам. Если в ответ на запрошенный фрагмент отдать весь файл будет ошибка.

Цитировать
Не пытаются. Качают заново.

Верно. Браузер же "не знает", что файл недокачен - просто показывает то что есть в кэше. А по команде "Обновить" обновляет естественно целиком.

Цитировать
Файлы с известным размером.

Имхо это необходимое но недостаточное условие. Например, пытаться докачивать картинку в 1,5КБ нужно? Имхо нет - больше времени уйдет на выяснение возможности докачать, чем скачать с нуля.

Цитировать
Кстати, желательно еще сохранять в кэше размер файла лежащего на сервере.

Есть мысли в каком виде это делать?

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

Цитировать
Думаю, обо всех недокачанных: картинках, html, скрипnах и т.д. Они, как ни печально, тоже не всегда загружаются полностью, не только многомегабайтные архивы.
Думаю, не все докачки одинаково полезны. :) Мелкие файлы имхо докачивать - только время терять. Вопрос в границе: что считать "мелкими". Может быть есть и другие критерии по которым файл не нужно пытаться докачивать.


Название: Re: Докачка файлов
Отправлено: Сергей от 16 января 2007, 11:55:17
Цитировать
Если браузер посылает запрос на фрагмент, то и склейку он выполнит сам.
Ты чего-то не понял, наверное. Браузер не трогает файлы в кэше HC. Откуда ему знать о нем?
И следовательно склеить не сможет.

Цитировать
Если в ответ на запрошенный фрагмент отдать весь файл будет ошибка.
А зачем отдавать весь файл при запросе фрагмента?
Что запросил браузер, то и должен получить.

Цитировать
Например, пытаться докачивать картинку в 1,5КБ нужно?
А часто обрывается закачка маленьких файлов? Вот большие картинки надо докачивать.
Можно задать в опциях порог, меньше которого не докачивать а тянуть заново.

Цитировать
Есть мысли в каком виде это делать?
file_name#start.size


Название: Re: Докачка файлов
Отправлено: Сергей от 16 января 2007, 11:59:18
Squid точно кэширует фрагменты. Много раз такое замечал. Канал у нас в институте был слабый. Когда запускал многопоточную закачку в ReGet, то иногда начало файла скачивалось мгновенно. Видимо, кто-то начинал качать через IE и обрывал. Но информация сохранялась в кэше.


Название: Re: Докачка файлов
Отправлено: Rick от 16 января 2007, 12:10:07
Ты чего-то не понял, наверное. Браузер не трогает файлы в кэше HC. Откуда ему знать о нем?
И следовательно склеить не сможет.
Когда я читаю "клиент посылает запросы на скачку не всего файла а только фрагментов" я понимаю, что клиент - это браузер посылающий запрос НС, а "Мы эти фрагменты корректно сохраним в кэше и склеим если нужно" - здесь "мы" - это собственно НС. Если клиент, посылающий запрос на фрагмент и склевающий "мы" - это один и тот же НС - да, я действительно что-то понял неправильно.

Цитировать
А зачем отдавать весь файл при запросе фрагмента?
Что запросил браузер, то и должен получить.
Именно об этом я и говорил.


Название: Re: Докачка файлов
Отправлено: Сергей от 16 января 2007, 12:16:21
Мы эти фрагменты корректно сохраним в кэше и склеим если нужно

... и отдадим фрагменты попутно клиенту (браузеру, качалке), который склеит их у себя, разумеется. :)


Название: Re: Докачка файлов
Отправлено: mai62 от 16 января 2007, 13:07:52
Rick
Цитировать
А почему нельзя не отдавать файл запросившей прогамме (браузеру) удерживая соединение с ним открытым и ждать восстановления коннекта с инетом (ограничив время ожидания), после чего отправлять запрос на дозакачку?
Если соединение разорвалось, то можно уже не ждать, оно само не восстановится. И я не писал, что нельзя отправлять запрос на дозакачку. Я писал
Цитировать
Пока не нашел с какой стороны подступисться (связь с сервером ведь уже потеряна, нужно возобновлять соединение, а поток, работающий с этим файлом, находится уже на стадии завершения своей работы).


Название: Re: Докачка файлов
Отправлено: Rick от 16 января 2007, 13:25:40
Если соединение разорвалось, то можно уже не ждать, оно само не восстановится.
Давай разделим понятия соединения (НС-сервер, НС-браузер) и соединение с инетом ("коннект") - а то похоже путаемся. Или Я путаюсь.
Дык вот: при обрыве коннекта, соединение НС-сервер разумеется тоже разрывается. НС "машет ручкой" браузеру и соединение НС-браузер так же закрывается. Суть того, что я писал в посте выше: не закрывать соединение НС-браузер а ожидать восстановление коннекта (не до бесконечности конечно). Восстановится ли коннект ручной командой пользователя или автоматом ("перезвонить при обрыве") - не важно. При появлении коннекта установить новое соединение НС-сервер, запросить докачку файла и получив отдать его ожидающему браузеру.

Цитировать
И я не писал, что нельзя отправлять запрос на дозакачку. Я писал
Цитировать
Пока не нашел с какой стороны подступисться (связь с сервером ведь уже потеряна, нужно возобновлять соединение, а поток, работающий с этим файлом, находится уже на стадии завершения своей работы).
А почему/зачем "поток, работающий с этим файлом, находится уже на стадии завершения своей работы"?


Название: Re: Докачка файлов
Отправлено: Кирилл от 16 января 2007, 14:40:11
А может быть стоит вместо приделывания к HC собственного менеджера закачек, дать возможность для загрузки больших файлов использовать внешний? Дабы не пытаться забивать гвозди микроскопом.


Название: Re: Докачка файлов
Отправлено: Rick от 16 января 2007, 14:53:41
дать возможность для загрузки больших файлов использовать внешний? Дабы не пытаться забивать гвозди микроскопом.
Ты не совсем верно понял проблему: в основном речь не о загрузке больших файлов, а обычных страниц и их элементов. Но будет работать и для больших файлов если кто-то будет их качать через HC (зачем?) - т.е механизм одинаковый.
Представь, что на странице тяжеловесные картинки - дисконнект - качай картинки с нуля. Речь идет о том, чтобы докачать их после восстановления связи.


Название: Re: Докачка файлов
Отправлено: Сергей от 16 января 2007, 15:02:43
Цитировать
Но будет работать и для больших файлов если кто-то будет их качать через HC (зачем?)
Иногда нет другого способа выхода в сеть как через http-прокси.


Название: Re: Докачка файлов
Отправлено: Дем от 16 января 2007, 22:24:39
Цитировать
Ты не совсем верно понял проблему: в основном речь не о загрузке больших файлов, а обычных страниц и их элементов. Но будет работать и для больших файлов если кто-то будет их качать через HC (зачем?) - т.е механизм одинаковый.
Да, понятие "большой" - оно относительно...
Вот например типичная страничка на фишках - полсотни картинок в среднем по сто кил каждая. Это как - много или мало?


Название: Re: Докачка файлов
Отправлено: Дем от 26 января 2007, 23:11:34
Тут пришла мысль, что надо бороться не столько с последствиями, сколько с причиной появления недокачанных файлов.
А она - в логике работы НС.  А именно - в том, что оно пытается заглотить больше, чем может проглотить.
Реально пользовательский канал пропускает одновременно 1-2-3 потока закачки, а НС пытается закачать сразу 9.
Естественно, остальные стоят. А по окончании закачки этих 1-2 открываются новые, и качаются именно они, а старые стоят. И наконец рвутся по таймауту.
(http://img170.imageshack.us/img170/5481/hcloadcs6.jpg)
Может добавить в логику работы "не создавать новую закачку, если существующие занимают более 3/4 канала"?



Название: Re: Докачка файлов
Отправлено: mai62 от 27 января 2007, 00:28:08
Мне так кажется, закачки не НС содает (он всего лишь посредник), а браузер. Многие браузеры имеют возможность настройки макс. количества одновременных соединений, почему бы ими не воспользоваться?


Название: Re: Докачка файлов
Отправлено: Rick от 27 января 2007, 00:44:09
А она - в логике работы НС.  А именно - в том, что оно пытается заглотить больше, чем может проглотить.
Сколько браузер затребовал одновременно - столько и "заглатывается".

Цитировать
А по окончании закачки этих 1-2 открываются новые, и качаются именно они, а старые стоят.
Качаются не именно новые, а те, на которые поступают данные от удаленного сервера. Т.е. что прислали - то и качается.

Цитировать
Может добавить в логику работы "не создавать новую закачку, если существующие занимают более 3/4 канала"?
Если запрос ушел, а данные не поступают, или перестали поступать - какую часть канала занимает такая закачка?


Название: Re: Докачка файлов
Отправлено: Дем от 27 января 2007, 04:55:02
Цитировать
Сколько браузер затребовал одновременно - столько и "заглатывается".
Но это не означает, что ему нужно столько давать...
Тем более что без прокси он не 9 устанавливает, а в разы больше... Но он - при обрыве докачивает!

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

В общем, ситуация в том, что НС не только не выполняет свою задачу - кешировать содержимое на диск (ибо докачанные броузером файлы не сохраняются) - но зачастую и прямо мешает, не давая докачать, отвечая "файл не изменился"
Так что, если нельзя быть уверенным, что интересующий меня контент остался в кеше - встаёт вопрос о целесообразности пользования ей...


Название: Re: Докачка файлов
Отправлено: Rick от 27 января 2007, 05:20:58
Но это не означает, что ему нужно столько давать...
По какому критерию определять сколько давать?

Цитировать
Тем более что без прокси он не 9 устанавливает, а в разы больше...
Именно. И HC здесь просто посредник - без него все происходит абсолютно так же.

Цитировать
Но он <браузер>- при обрыве докачивает!
Да неужто? Пример можно кроме "сохранить как"?

Цитировать
Не запросили бы - прислали данные на ранее открытые. Но им даже шанса не дают...
Так перестают они поступать из-за наличия очередной закачки...
1. Претензии к браузеру.
2. По какому критерию ты предлагаешь определять кому давать шанс? Как ты себе представляешь "раздачу шансов"?
В очереди стоит закачка - запрос отправлен, а данных нет. Что предлагаешь делать: дать ей "шанс" - ждать пока пойдут данные (а они вообще могут не придти), или давать шанс следующим в очереди?

Цитировать
В общем, ситуация в том, что НС не только не выполняет свою задачу - кешировать содержимое на диск (ибо докачанные броузером файлы не сохраняются)
Что означает "докачанные браузером файлы"?

Цитировать
но зачастую и прямо мешает, не давая докачать, отвечая "файл не изменился"
Пример?


Название: Re: Докачка файлов
Отправлено: Дем от 27 января 2007, 14:37:19
Цитировать
По какому критерию определять сколько давать?
как пользователь скажет. Цифирька в настройках. Мне 2 достаточно.
Цитировать
Именно. И HC здесь просто посредник - без него все происходит абсолютно так же
Я же писал выше - не так. Браузер устанавливает соединения по количеству картинок и т.п. на странице. Другое дело - сколько из них сервер ассептит.

Цитировать
Да неужто? Пример можно кроме "сохранить как"?
Строчка из лога:
26.01.2007/21:58:34 local httр://k.foto.radikal.ru/0611/f35b9126a086.jpg 77348 12676 16% 2 "200 OK" П.2, З.4
26.01.2007/22:06:27 local httр://k.foto.radikal.ru/0611/f35b9126a086.jpg 64672 27023 41% 2 "206 Partial Content" П.2
26.01.2007/22:07:50 local httр://k.foto.radikal.ru/0611/f35b9126a086.jpg 40529 25583 63% 2 "206 Partial Content"
26.01.2007/22:09:23 local httр://k.foto.radikal.ru/0611/f35b9126a086.jpg 14946 14946 100% 2 "206 Partial Content"

Кто это докачал, по-твоему? И попал ли этот файл в кеш?
Цитировать
1. Претензии к браузеру.
2. По какому критерию ты предлагаешь определять кому давать шанс? Как ты себе представляешь "раздачу шансов"?
В очереди стоит закачка - запрос отправлен, а данных нет. Что предлагаешь делать: дать ей "шанс" - ждать пока пойдут данные (а они вообще могут не придти), или давать шанс следующим в очереди?
1. Б-Г, к сожалению, недоступен :)
2. Невнимательно читаешь :) Написал же - если уже качается со скоростью >3/4 пропускной (собственно, граничную цифирь в настройках указать, а не заниматься шаманством по определению этой скорости)
Цитировать
Что означает "докачанные браузером файлы"?
См выше.
Цитировать
Пример?
httр://fchan.hentaiplanet.net/src/s_1168052051176_pinned.jpg 74042 4101 5% 2 "200 OK" З.4
httр://fchan.hentaiplanet.net/src/s_1168052051176_pinned.jpg    2 "304 Not Modified (HC)" Н.4


Название: Re: Докачка файлов
Отправлено: NothingAnother от 27 января 2007, 15:13:53
Я же писал выше - не так. Браузер устанавливает соединения по количеству картинок и т.п. на странице
Да и так - тоже не совсем ;) У большинства современных браузеров в настройках есть "кол-во соединений/на сервер", и уже исходя из этого лимита он разбрасывется запросами (ессно, если контент HTML его просит об этом)


Название: Re: Докачка файлов
Отправлено: Rick от 27 января 2007, 17:19:14
> По какому критерию определять сколько давать?
как пользователь скажет. Цифирька в настройках. Мне 2 достаточно.

Ну это ты сгоряча. ;)

Цитировать
Браузер устанавливает соединения по количеству картинок и т.п. на странице. Другое дело - сколько из них сервер ассептит.

Так какие претензии к НС? Что он не так делает?

Цитировать
Кто это докачал, по-твоему? И попал ли этот файл в кеш?
Кто докачал - хотел бы от тебя узнать ответ. Как-кто-откуда - я бы хотел проверить вывод. Попал ли в кэш? Насколько я понимаю нет.

Цитировать
Невнимательно читаешь :) Написал же - если уже качается со скоростью >3/4 пропускной (собственно, граничную цифирь в настройках указать, а не заниматься шаманством по определению этой скорости)

Взаимный упрек в невнимательности/недопонимании. :) Давай пофантазируем: браузер запросил N URL. НС в соответствии с твоими пожеланиями сделал запрос только к 2-м. Какое-то из соединений "заглохло": данные не начали поступать или их передача с какого-то момента прекратилась. Вопрос, что делать: ждать (может быть до истечения таймаута по всем N запросам?) а не пойдут ли опять данные, или сделать запрос к следующему URL из N-2 ожидающих в очереди? Или сделать запрос по всем URL, а там уж система сама поделит кому-чего-сколько?

Цитировать
httр://fchan.hentaiplanet.net/src/s_1168052051176_pinned.jpg 74042 4101 5% 2 "200 OK" З.4
httр://fchan.hentaiplanet.net/src/s_1168052051176_pinned.jpg    2 "304 Not Modified (HC)" Н.4

А почему браузер прислал такой запрос? Причины? ;)


Название: Re: Докачка файлов
Отправлено: Дем от 27 января 2007, 21:10:49
Цитировать
Так какие претензии к НС? Что он не так делает?
Слишком много соединений открывает...
Цитировать
Кто докачал - хотел бы от тебя узнать ответ.
Страничку я браузером открывал, так что кроме него больше некому :)
Цитировать
Какое-то из соединений "заглохло": данные не начали поступать или их передача с какого-то момента прекратилась. Вопрос, что делать:
1) ждать (может быть до истечения таймаута по всем N запросам?) а не пойдут ли опять данные, или сделать запрос к следующему URL из N-2 ожидающих в очереди?
2) Или сделать запрос по всем URL, а там уж система сама поделит кому-чего-сколько?
1) Вопрос интересный
2) А она не умеет! Ей проще перезапросить, чем регулировать... В чём и проблема...
Цитировать
А почему браузер прислал такой запрос? Причины?
Какой "такой"? :) Обычный он прислал... Других для данного случая у него не предусмотрено :)


Название: Re: Докачка файлов
Отправлено: Rick от 27 января 2007, 23:09:19
Слишком много соединений открывает...
Не больше чем у него запрошено. НС - посредник! О чем уже несколько раз было сказано, кстати. Интереснее бы звучал вопрос "несколько приложений одновременно направляют свои запросы через НС - каково распределение приоритетов между ними?"

Цитировать
Страничку я браузером открывал, так что кроме него больше некому :)
Я говорил, что хочу проверить вывод, хочу провести эксперимент и сам получить такой же результат. Для этого мне нужно знать какой браузер и какой URL. Мне любопытно - поспособствуй пожалуйста в удовлетворении этого моего любопытства. О результате, разумеется, здесь же и сообщу.

Цитировать
Вопрос интересный
А ответ будет?

Цитировать
А она не умеет! Ей проще перезапросить, чем регулировать... В чём и проблема...
Можно подробнее о предпосылках, на которых постоен такой вывод?

Цитировать
Какой "такой"? :) Обычный он прислал... Других для данного случая у него не предусмотрено :)
Как должно быть:
Цитировать
304 Not Modified (Не модифицировано)
Если клиент выполнил условный запрос GET и получил доступ, а документ не был модифицирован, сервер должен реагировать этим статусным кодом. Отклик не должен содержать тела сообщения.
Если отклик 304 указывает на то, что объект не кэширован, тогда браузер должен игнорировать отклик и повторить запрос уже в безусловном режиме.
Дык вот и вопрос: а кто собственно не так что-то делает?


Название: Re: Докачка файлов
Отправлено: Дем от 28 января 2007, 02:20:12
Цитировать
Я говорил, что хочу проверить вывод, хочу провести эксперимент и сам получить такой же результат. Для этого мне нужно знать какой браузер и какой URL.
Браузер - Махтрон на ИЕ7. А вот как ты собираешься получить тот же результат при других исходных - не знаю...
Цитировать
Интереснее бы звучал вопрос "несколько приложений одновременно направляют свои запросы через НС - каково распределение приоритетов между ними?"
Многооконный браузер - это и есть "несколько приложений", ибо одно окно не ведает, что другие творят.
А вот почему в части случаев он пытается докачать, а в части нет (хотя сервер докачку поддеживает) - не знаю. Скорей всего причина в различном наполнении заголовков запроса.
И мне тоже интересно, почему, когда браузер напрямую запрашивает - картинка закачивается заново, а когда через НС - не закачивается. Может потому, что  в If-Modified-Since не только дата, но и длина файла указывается - а сервер правильную знает. В отличие от НС, который её помнить не считает нужным.
Цитировать
Дык вот и вопрос: а кто собственно не так что-то делает?
Какая разница - кто? Важно, что кто-то - неправильно. Что нуждается в лечении.
Причём - на браузер или сервер у меня средств воздействия нет. А вот прослойку между ним и сервером я выбрать с нужными функциями могу.
И если НС пригодна лишь для диалапщиков - ну что ж, придётся искать другую...


Название: Re: Докачка файлов
Отправлено: Rick от 28 января 2007, 03:04:19
Браузер - Махтрон на ИЕ7. А вот как ты собираешься получить тот же результат при других исходных - не знаю...
Макстон то у меня есть, а вот IE7 нет. :(

Цитировать
Многооконный браузер - это и есть "несколько приложений", ибо одно окно не ведает, что другие творят.
Что за новости? Хотя... может быть в IE так и есть - не знаю. У меня Опера - в ней окна прекрасно "ведают, что творят другие".

Цитировать
И мне тоже интересно, почему, когда браузер напрямую запрашивает - картинка закачивается заново, а когда через НС - не закачивается. Может потому, что  в If-Modified-Since не только дата, но и длина файла указывается - а сервер правильную знает. В отличие от НС, который её помнить не считает нужным.
1. If-Modified-Since - это только дата.
2. Есть две большие разницы: одно дело, ты сказал браузеру загрузить картинку и он берет ее из собственного кэша (в том виде как она там есть - может и недокачанную) или из инета с уловным запросом (If-Modified-Since), и другое дело, когда ты требуешь от браузера обновить картинку - браузер посылает серверу безусловный запрос "дай".

Дык вот в случае если между браузером и инетом HC - то, на условный запрос HC ответит 304 (если файл закачивался через HC и файл одинаков у браузера и НС), но и если браузер отправляет _безусловный_ запрос HC отдаст ему файл из своего кэша - этим и достигается экономия: то, за чем тупой браузер вечно лезет в сеть ему отдается из кэша.
Вот и получается, что и на условный и на безусловный запросы браузеру отдается файл из кэша - при условии конечно, что заданные правила в HC для данного URL не предписывают НС иного поведения.
Здесь можно задаться вопросом, а зачем НС хранит недокаченный файл в кэше? Ответ: и недокаченный файл может быть востребован с пользой - например, в автономном режиме.

Цитировать
Какая разница - кто? Важно, что кто-то - неправильно. Что нуждается в лечении.
Неважно кого лечить - лишь бы лечить? ;)


Название: Re: Докачка файлов
Отправлено: mai62 от 28 января 2007, 04:11:34
Дем
Цитировать
И если НС пригодна лишь для диалапщиков - ну что ж, придётся искать другую...
Вольному воля. Никто тебя не заставляет пользоваться НС, не нравится - не надо. Желаю успехов.


Название: Re: Докачка файлов
Отправлено: Сергей от 28 января 2007, 12:27:33
Цитировать
httр://fchan.hentaiplanet.net/src/s_1168052051176_pinned.jpg 74042 4101 5% 2 "200 OK" З.4
httр://fchan.hentaiplanet.net/src/s_1168052051176_pinned.jpg    2 "304 Not Modified (HC)" Н.4

А почему браузер прислал такой запрос? Причины? ;)

Может браузер не виноват и HC сам посылает If-Modified-Since когда не следует?


Название: Re: Докачка файлов
Отправлено: Дем от 28 января 2007, 19:06:50
Цитата: Rick
1. If-Modified-Since - это только дата.
Увы... Из лога:
GET http://diary.ru/block_layout.css HTTP/1.1
Accept: */*
Accept-Language: ru
UA-CPU: x86
Accept-Encoding: gzip, deflate
If-Modified-Since: Tue, 23 Jan 2007 22:39:06 GMT; length=8187

Цитата: Rick
2. Есть две большие разницы: одно дело, ты сказал браузеру загрузить картинку и он берет ее из собственного кэша (в том виде как она там есть - может и недокачанную) или из инета с уловным запросом (If-Modified-Since), и другое дело, когда ты требуешь от браузера обновить картинку - браузер посылает серверу безусловный запрос "дай".
при нажатии F5 - запрос на докачку. С непопаданием в НС. А учитывая урезанный размер кеша браузера - через какое-то время этого файа у меня на компе вообще нет.
Цитата: mai62
Вольному воля. Никто тебя не заставляет пользоваться НС, не нравится - не надо. Желаю успехов.
Не обижайся! Программа у тебя отличная, и если она кому не подошла - не твоя вина.
И я хочу только помочь сделать её лучше, даже если сам пользоваться не буду.


Название: Re: Докачка файлов
Отправлено: Дем от 31 января 2007, 01:16:46
Во, поймал:

GET /images/sex_pribor.jpg HTTP/1.1
Accept: */*
Accept-Language: ru
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; Maxthon; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: yanazinovieva.narod.ru
Proxy-Connection: Keep-Alive
Pragma: no-cache
Cookie: nuid=2066190201169682986

HTTP/1.0 200 OK
Date: Tue, 30 Jan 2007 22:05:41 GMT
Server: ZX_Spectrum/1997 (Sinclair_BASIC)
Last-Modified: Fri, 08 Dec 2006 23:21:20 GMT
ETag: "da914-fccd-4579f370"
Accept-Ranges: bytes
Content-Length: 64717
Connection: close
Content-Type: image/jpeg



GET http://yanazinovieva.narod.ru/images/sex_pribor.jpg HTTP/1.1
Accept: */*
Accept-Language: ru
UA-CPU: x86
Accept-Encoding: gzip, deflate
If-Modified-Since: Fri, 08 Dec 2006 23:21:20 GMT; length=58956
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; Maxthon; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Proxy-Connection: Keep-Alive
Host: yanazinovieva.narod.ru
Cookie: nuid=2066190201169682986

HTTP/1.0 304 Not Modified (HC)
Server: HandyCache
Proxy-Connection: Keep-Alive


PS: А как народовцы с типом своего сервера прикольнулись :)


Название: Re: Докачка файлов
Отправлено: Rick от 31 января 2007, 05:08:09
Дем
Цитировать
Во, поймал:
А как ловил? Хотел было повторить эксперимент - не получается. На Опере не получается.

Согласно стандарта:
Цитировать
Поле If-Modified-Sinc
Поле заголовка запроса If-Modified-Since используется с методом GET, для того чтобы сделать его условным. Если запрошенный объект не был модифицирован со времени, указанного в этом поле, объект не будет прислан сервером, вместо этого будет послан отклик 304 (not modified) без какого-либо тела сообщения.
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
Пример поля:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Дата - никаких размеров.

Обращаюсь к тому сайту - никаких размеров в If-Modified-Since в логе не вижу.

Вывод: то, что IE при запросе в поле If-Modified-Since указывает length не значит, что такой его запрос вообще будет понят. Удаленным сервером в т.ч.

А Server: ZX_Spectrum/1997 (Sinclair_BASIC) - это действительно весело. :D


Название: Re: Докачка файлов
Отправлено: Дем от 31 января 2007, 10:52:53
Цитировать
А как ловил? Хотел было повторить эксперимент - не получается. На Опере не получается.
так специально оно не ловится... Надо чтобы закачка файла оборвалась....
Цитировать
Согласно стандарта:
Ну насколько помню это опциональный параметр, лень по RFC шарить. ИЕ его использует, и часть серверов его понимает - IIS точно :)
Но суть не в нём, а в его значении. Которое не совпадает с "истинным размером" файла. И показывает, что в ряде случаев ИЕ плевать хотел на Content-Length.
А так как ословодов всё-таки большинство - то проблема актуальна.

Да, кстати - SeaMonkey ответ "304" не получает, несмотря на запрос с If-Modified-Since, отдаётся файл из кеша:

31.01.2007 10:34:42 # 195 >>> URL: http://balancer.ru/forum/punbb/img/avatars/2600.jpg
GET http://balancer.ru/forum/punbb/img/avatars/2600.jpg HTTP/1.1
If-Modified-Since: Wed, 31 Jan 2007 07:32:52 GMT
Host: balancer.ru
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ru-RU; rv:1.9a1) Gecko/20060823 SeaMonkey/1.5a
Accept: image/png,*/*;q=0.5
Accept-Language: ru,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://balancer.ru/forum/punbb/viewtopic.php?id=35655&p=6
If-None-Match: "22db2d-f85-bb918880"

31.01.2007 10:34:42 # 195 <<< URL: http://balancer.ru/forum/punbb/img/avatars/2600.jpg
HTTP/1.1 200 OK
Via: 1.1 PROXY
Date: Wed, 31 Jan 2007 07:28:16 GMT
Age: 949
Content-Length: 3973
Content-Type: image/jpeg


Название: Re: Докачка файлов
Отправлено: Rick от 31 января 2007, 11:14:11
специально оно не ловится... Надо чтобы закачка файла оборвалась...
Обрывать не пробовал.

Цитировать
SeaMonkey ответ "304" не получает, несмотря на запрос с If-Modified-Since, отдаётся файл из кеша:
Согласно твоего лога файл получен с удаленного сервера, а не из кэша.


Название: Re: Докачка файлов
Отправлено: Дем от 31 января 2007, 12:55:00
Цитировать
Согласно твоего лога файл получен с удаленного сервера, а не из кэша.
не, это именно из кеша.
первый раз было:
31.01.2007 10:32:50 # 190 <<< URL: http://balancer.ru/forum/punbb/img/avatars/2600.jpg
HTTP/1.1 200 OK
Via: 1.1 PROXY
Date: Wed, 31 Jan 2007 07:28:16 GMT
Server: Apache
Keep-Alive: timeout=15, max=97
ETag: "22db2d-f85-bb918880"
Content-Length: 3973
Content-Type: image/jpeg
Разница очевидна...


Название: Re: Докачка файлов
Отправлено: Rick от 31 января 2007, 13:14:46
не, это именно из кеша.
Было бы из кэша НС - было бы 200 From cache
Хотя... Может это только в Мониторе было бы так, а в логе иначе. Мне неведомо.


Название: Re: Докачка файлов
Отправлено: mai62 от 31 января 2007, 14:08:09
Дем
Цитировать
Разница очевидна...
Не проще ли вместо того, чтобы выдавать свои догадки за истину, посмотреть как отдается на самом деле из кэша?

31.01.2007 14:06:13 # 1685 <<< URL: http://i.ru-board.com/avatars/PrinceJohn.gif
HTTP/1.0 200 OK
Server: HandyCache
Last-Modified: Mon, 15 May 2006 08:24:36 GMT
Content-Length: 666
Content-Type: image/gif
Proxy-Connection: Keep-Alive


Название: Re: Докачка файлов
Отправлено: Дем от 31 января 2007, 19:23:13
Цитировать
Не проще ли вместо того, чтобы выдавать свои догадки за истину, посмотреть как отдается на самом деле из кэша?
Я вообще из НС-лога копипастил....


Название: Re: Докачка файлов
Отправлено: Rick от 31 января 2007, 23:10:23
Я вообще из НС-лога копипастил...
Ну и что это доказывает/опровергает?


Название: Re: Докачка файлов
Отправлено: cepera_ang от 19 февраля 2007, 18:12:14
Думаю эта тема подойдет. Может быть уже обсуждали - сохранять в кеше кусочки 206 Partial Content. Просто некоторый софт (windows update, windows media player) берет файлы не целыми файлами, а кусочками по 25-50кб. Вообще есть ли возможность их сохранять и склеивать в единое целое?


Название: Re: Докачка файлов
Отправлено: DenZzz от 19 февраля 2007, 20:18:46
Вообще есть ли возможность их сохранять и склеивать в единое целое?

Пока нет. "Partial Content" уже обсуждали на первой странице этого топика!


Название: Re: Докачка файлов
Отправлено: Сергей от 19 февраля 2007, 22:59:56
А очень как нужно. Это поважней индексов будет.


Название: Re: Докачка файлов
Отправлено: Дем от 21 февраля 2007, 20:48:34
Собственно, можно пока задействовать упрощённую схему:
1) оставлять недокачанные файлы
2) если очередная закачка начинается там, где закончилась предыдущая - дописывать.


Название: Re: Докачка файлов
Отправлено: Илья от 13 марта 2007, 16:52:56
А вооще можно какнить сохранять ответы 206. Это Windows Update качает файлы и потом их склеивает. Можно было бы сделать так чтоб эти файлы сохранялись, а росле переустанови винды они заново качались WU и всё было бы гуд :D. Но пока  :-[


Название: Re: Докачка файлов
Отправлено: Илья от 13 марта 2007, 17:02:11
Можно было бы сделать так что файлы которые не успели загрузиться из инета они остались в разширении какомнить ну типа *.HC(разрешение файла). Апотом когда появилась возможность докачать то HC берет и добавляеть информацию к файлу с кусками. Ко нечно для этих делов имеються проги загрузчики, но оми не всегда удобно пользоваться. файл размером несколько сот Кб не будеш им качать потому что он сильно долго разгоняеться, а так взял скачал и потом если надо то и ещё раз скачал, но уже из кеша. Такое бывает что куданить кинул файл и найти его не можешь, то береш заходишь в браузер открываешь страницу и качаешь его из кеша.


Название: Re: Докачка файлов
Отправлено: Михаил от 31 августа 2007, 01:46:53
Давайте подумаем и обсудим, нужна ли такая опция и как ее лучше реализовать!
Имхо, такое умение будет для НС очень полезным. Подход видится следующий:
Все недокаченные ответы 200 сохраняются в кэше (к примеру, с расширением new как сейчас). При поиске в кэше file, а затем file#m, не останавливаемся в случае их отсутствия/неактуальности. Ищем file#new. Если такой есть, и он актуален по времени, то в случае, если он не изменился на сервере, докачиваем только недостающий хвост. Если же менялся, либо сервер не понимает - закачиваем файл целиком заново.
Видимый недостаток - необходимость каждый раз, когда файла нет в кэше, затрачиваться на дополнительный поиск на диске file#new, которого в большинстве случаев не будет.


Название: Re: Докачка файлов
Отправлено: Кирилл от 01 сентября 2007, 11:48:12
Михаил
Все опять упирается в функцию хранения заголовков в кеше.
Ее отсутствие реально тормозит прогресс программы.
Ибо самое подходящее место для хранения информации о степени докачанности файла - в файле-заголовке или паспорте.
Все-таки (опциональное) хранение заголовков вводить необходимо уже сейчас - слишком много функций от этого выиграют.


Название: Re: Докачка файлов
Отправлено: Денис от 01 декабря 2007, 18:59:37
Когда уже сделаете докачку? Без нее и прoкси - не прoкси.


Название: Re: Докачка файлов
Отправлено: DenZzz от 02 декабря 2007, 21:31:54
Без нее и прoкси - не прoкси.

И много ты знаешь кэширующих прокси с докачкой файлов?


Название: Re: Докачка файлов
Отправлено: Сергей от 03 декабря 2007, 10:40:34
DenZzz За сквидом замечал такое свойство. Думаешь показалось?


Название: Re: Докачка файлов
Отправлено: mai62 от 03 декабря 2007, 12:05:48
Я сижу за СКВИДом и не заметил такого свойства.


Название: Re: Докачка файлов
Отправлено: Сергей от 03 декабря 2007, 13:15:51
mai62 но ведь хотя бы частично (http://handycache.ru/component/option,com_smf/Itemid,10/topic,94.msg654/#msg654) реализовать это можно? Иначе кучу трафика приходится заново перекачивать.
Цитировать
как правило, кусочки идут по порядку. Тогда можно их на лету склеивать. Т.е. дописывать в концы файлов а не создавать новые.

Чанки ведь склеиваются? Там тоже самое практически.


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


Название: Re: Докачка файлов
Отправлено: mai62 от 03 декабря 2007, 13:36:20
У меня никогда не было сомнений в полезности этой функции. В данном случае у меня сомнения в том, что это делает СКВИД (вовсе не для оправдания отсутствия этого в НС).


Название: Re: Докачка файлов
Отправлено: Денис от 03 декабря 2007, 13:55:01
Цитировать
В данном случае у меня сомнения в том, что это делает СКВИД
(http://img221.imageshack.us/img221/3433/20071203164845ec9.png)
Добавлено: 03 Декабря 2007, 16:51:55

Отсутствие докачки противоречит главной возможности HC - экономии трафика.


Название: Re: Докачка файлов
Отправлено: mai62 от 03 декабря 2007, 14:20:33
Мне кажется ты не понял о чем речь в этой теме.
Насколько я понял на твоей картинке какая-то программа для закачки файлов и она работает через СКВИД. И пусть работает. Такую работу и сейчас НС поддерживает.
В этой же теме речь идет о том, чтобы НС сам докачивал файлы при обрыве загрузки, программа-клиент может и не знать ничего об обрыве и докачке.


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

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


Название: Re: Докачка файлов
Отправлено: DenZzz от 03 декабря 2007, 15:49:02
Там вообще ftp. Который не кэшируется вовсе сейчас.

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

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

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

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

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

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


Название: Re: Докачка файлов
Отправлено: Сергей от 03 декабря 2007, 16:28:23
Ладно. Давайте не будем спорить о том что нужнее. Обе ситуации актуальны.

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

А вот со вторым вариантом возможны подводные камни, которые надо будет еще долго тестировать.


Название: Re: Докачка файлов
Отправлено: mai62 от 03 декабря 2007, 16:39:03
Цитировать
Всего-лишь разрешить писать в кэш
Разрешить мало. Надо где-то хранить служебную информацию, как-то проверять актуальность имеющихся кусков. И отлаживать все это еще как-то надо.


Название: Re: Докачка файлов
Отправлено: Сергей от 03 декабря 2007, 16:54:10
Какая служебная информация понадобится?
Каких кусков? Кусок же один - это файл .NEW Проверять надо только его размер. Если он совпадает со значением в поле Range то дописывать.


Название: Re: Докачка файлов
Отправлено: DenZzz от 03 декабря 2007, 17:07:42
Каких кусков? Кусок же один - это файл .NEW Проверять надо только его размер. Если он совпадает со значением в поле Range то дописывать.

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


Название: Re: Докачка файлов
Отправлено: Сергей от 03 декабря 2007, 17:27:28
Опять 25 :(

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

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

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

Все эти проблемы высосаны из пальца.


Название: Re: Докачка файлов
Отправлено: DenZzz от 04 декабря 2007, 00:58:16
Какое отношение это имеет к нашему вопросу. Файл может измениться в любой момент и при обычной загрузке которая сейчас реализована.

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

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


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

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

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


Название: Re: Докачка файлов
Отправлено: Сергей от 04 декабря 2007, 12:35:51
Я рассмотрел две ситуации. Одна не противоречит другой. Мы не говорим которая нужней. Обе надо реализовать!!!! Они разные и никак друг на друга не влияют.

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

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

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

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

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

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

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

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

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



Название: Re: Докачка файлов
Отправлено: Денис от 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, ожидать появление докачки в нем можно, имхо не раньше, чем через пару лет.


Название: Re: Докачка файлов
Отправлено: Сергей от 04 декабря 2007, 15:56:29
Цитировать
Хранить информацию о частично закачиваемых файлах (URL, размеры принятых кусков, e-tag, last modified и прочее) можно в отдельном файле. Не понимаю в чем проблема?
Почитай в теме Индексирование кэша (http://handycache.ru/component/option,com_smf/Itemid,10/topic,76.0/)

Цитировать
HC, обнаружив запрашиваемый файл в кеше, видит, что тот загружен не до конца (возможно он был загружен даже другим клиентом) отправляет запрос range и если получает ответ partial content докачивает, а клиенту отдает HTTP1.1 200 OK. Первую часть (уже загруженную) отдает из кеша, остальную загружает из интернета.
Тут те же подводные камни что и при одновременной загрузке одного URL разными клиентами. Сервер может отдавать всем разные данные в зависимости от содержимого куков или других параметров.


Название: Re: Докачка файлов
Отправлено: DenZzz от 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 разными клиентами в один и тот же момент времени в кэш пишет тот, кто занял временный файл первым. Собственно, как и сейчас!
В идеале, хорошо бы придерживать параллельные закачки, но это уже совсем другая тема... (http://handycache.ru/component/option,com_smf/Itemid,10/topic,132.0/)


Название: Re: Докачка файлов
Отправлено: Дем от 05 декабря 2007, 01:03:11
Цитировать
- При получении ответа 206 сравнивает его заголовки Last-Modified и ETag с соответствующими сохраненными в первый раз. Если этих заголовков нет в 206, то можно извлечь полную длину файла из Content-Range и сравнить ее с Content-Length из первой части.
- Если заголовки совпадают, то HC сразу же отдает клиенту начало файла из кэша и следом качаемое продолжение.
- Если заголовки не совпадают, то HC разрывает соединение с сервером, очищает временный файл и шлет серверу исходный запрос клиента (без Range). Получаемые данные пишет во временный файл и передает клиенту и т.д. ...
Собственно, если сервер получит запрос 206 с неправильными (устаревшими) Last-Modified и ETag - то он как правило сам всё сделает и выдаст новую версию.


Название: Re: Докачка файлов
Отправлено: Михаил от 05 декабря 2007, 01:49:24
Цитировать
HC разрывает соединение с сервером, очищает временный файл и шлет серверу исходный запрос клиента (без Range)
Никаких повторных запросов. Надо использовать If-Range.
По размеру сопоставлять некорректно. Это все равно, как если б мы начали сопоставлять по размеру любой файл из кэша, не попадающий в список Н, и в случае совпадения прерывать его загрузку.


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

Но тут придется писать во временный файл все получаемые данные а не только те что попадают под список Запись в кэш.


Название: Re: Докачка файлов
Отправлено: Михаил от 05 декабря 2007, 08:56:15
Цитировать
хранить исходные заголовки прямо в начале временного файла .NEW, которые создает HC при закачке
Сейчас файл .new в конце закачки просто переименовывается. Если сразу писать в него заголовок, каждый такой файл придется после успешной закачки читать с диска, парсить, отсекая заголовки, а затем писать на диск уже итоговый файл. В подавляющем большинстве случаев это будет пустая работа, т.к. закачка не будет прерванной.
Хорошо бы делать такую запись в файл .new не всегда, а только в тех случаях, когда НС установил, что закачка прервана.


Название: Re: Докачка файлов
Отправлено: DenZzz от 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 то смотреть что уже скачано и если заголовки совпадают то отдать клиенту уже скачанный кусок и потом отдавать получаемые данные двум клиентам параллельно.

Да, нечто подобное уже предлагалось в теме: "Придерживать параллельные закачки (http://handycache.ru/component/option,com_smf/Itemid,10/topic,132.0/)".



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

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

P.S. Ведь, можешь же вносить дельные предложения для всеобщего блага, а не только для закрытия дыр любимой Оперы! ;)


Название: Re: Докачка файлов
Отправлено: Михаил от 05 декабря 2007, 10:21:04
Цитировать
дополнительная сверка размера файла пришлась бы кстати
В принципе, да. Нужно лишь делать такое поведение отключаемым.


Название: Взятие из кэша при запросе с Range
Отправлено: Михаил от 23 декабря 2007, 01:15:02
Если получен запрос с "Range: bytes=...", и файл отдается из кэша, то хорошо бы отдавать лишь нужный кусок с ответом 206. Сейчас отдается весь файл с ответом 200.
Добавлено: 23 Декабря 2007, 00:43:21

Вижу, что при запросе с Range IMS не вставляется. Почему? Получается, тянем из сети то, что можем выдать из кэша.


Название: Re: Взятие из кэша при запросе с Range
Отправлено: mai62 от 23 декабря 2007, 01:23:34
Согласен, надо как-нибудь добраться.


Название: Re: Взятие из кэша при запросе с Range
Отправлено: Михаил от 23 декабря 2007, 01:36:03
Заметил один связанный с этим баг. У меня между НС и удаленным сервером стоит Proxomitron, разжимающий приходящие gzip-ответы. У соседа его нет. Кэш общий. Сосед когда-то закачал файл, и он лежит в кэше в gzip-виде. Запрашиваю этот файл я. Мой клиент тянет в два потока - шлет обычный запрос (назовем его первый), ответ на который в будущем оборвет посредине, и запрос с Range (второй) с прерванного места до конца. Ответ на первый запрос берется из кэша (т.к. сработал IMS), и клиенту отдается кусок gzip-файла. Ответ на второй запрос шлет сервер (т.к. IMS не вставлялся), исходя из размера несжатого файла. В итоге клиент, склеив два куска, получает абракадабру.


Название: Re: Взятие из кэша при запросе с Range
Отправлено: DenZzz от 23 декабря 2007, 13:02:56
Если получен запрос с "Range: bytes=...", и файл отдается из кэша, то хорошо бы отдавать лишь нужный кусок с ответом 206. Сейчас отдается весь файл с ответом 200.

Чревато тем, что у клиента может оказаться часть совсем не того файла, что есть у нас в кэше, и склеив их, клиент получит все ту же абракадабру! Отдавая сейчас весь файл из кэша, HC это предотвращает!

Сейчас мы не храним ни ETag, ни истинный IMS файлов в кэше. Соответственно, сопоставить их с запросом клиента, мы не можем! Следовательно, никто не может гарантировать, что в кэше у нас лежит именно тот файл, часть которого запрашивает клиент!

Сравнивать IMS клиента с датой файла в кэше, конечно можно, но это крайне ненадежный способ идентификации неизменности файла, т.к. он зависит от точности системной даты и времени, от скорости канала и т.д. ...


Название: Re: Взятие из кэша при запросе с Range
Отправлено: Михаил от 23 декабря 2007, 13:42:36
Чревато тем, что у клиента может оказаться часть совсем не того файла, что есть у нас в кэше, и склеив их, клиент получит все ту же абракадабру!
Тогда клиент запросит If-Range, If-Unmodified-Since или If-Match, чтоб убедиться в неизменности контента. Если таких заголовков нет (например, используем менеджер закачек), то можно смело отдавать из кэша только нужный кусок и ответ 206.
И IMS вставлять при этом тоже нужно.

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


Название: Re: Взятие из кэша при запросе с Range
Отправлено: DenZzz от 23 декабря 2007, 15:51:28
Тогда клиент запросит If-Range, If-Unmodified-Since или If-Match, чтоб убедиться в неизменности контента. Если таких заголовков нет (например, используем менеджер закачек), то можно смело отдавать из кэша только нужный кусок и ответ 206.

Я не раз наблюдал в ReGet-е в процессе докачки на медленном канале сообщение типа: "Размер файла на сервере изменился! Удалить временный файл и начать закачку с начала?"
Причем, если жмешь "Нет", то он просто останавливает докачку!
А когда конечный размер файла неизвестен или не совпадает, то ReGet сразу трубит, что докачка невозможна и качает в 1 поток, а случае разрыва соединения предлагает начать все с начала! И это правильно!

Поэтому твой пример с багом выше вызывает у меня недоумения! Первая часть из кэша пришла с одним размером, вторая часть с сервера - с другим (без GZIP разница в разы, трудно не заметить)!
Какой менеджер закачек у тебя позволяет себе склеивать такой битый файл? ИМХО, это баг менеджера закачек!


P.S. Вообще-то, этой теме самое место в разделе "Новые предложения"! Вопрос о кэшировании/отдаче из кэша "206" уже много обсуждался в теме "Докачка файлов (http://handycache.ru/component/option,com_smf/Itemid,10/topic,94.0/)", куда и будут присоединены эти посты...


Название: Re: Докачка файлов
Отправлено: Михаил от 23 декабря 2007, 20:58:38
Какой менеджер закачек у тебя позволяет себе склеивать такой битый файл? ИМХО, это баг менеджера закачек!
Он не позволяет себе склеивать. Он перезапрашивает кусок еще и еще и получает ту же несовместимую картину. Это FlashGet. Не знаю, отключается ли у него такая настойчивость. Даже желания нет это изучать. Сейчас проще пустить его в обход НС.

А вот как берется повторно из кэша. Клиент запросил первый раз. НС начал выдавать файл.
Цитировать
GET http://fatal.ru/404.html HTTP/1.1
Host: fatal.ru
Accept: */*
Referer: http://fatal.ru
User-Agent: Mozilla/4.0 (compatible; MSIE 5.00; Windows 98)
Connection: close

HTTP/1.1 200 OK
Server: HandyCache
Content-Length: 3736
Last-Modified: Tue, 18 Jul 2006 18:44:54 GMT
Content-Type: text/html; charset=windows-1251
Connection: Keep-Alive
Посреди закачки клиент шлет запрос куска от 1688 байта до конца файла. Первую при этом оборвет на 1687 байте. А НС отдает не запрашиваемый кусок, а весь файл.
Цитировать
GET http://fatal.ru/404.html HTTP/1.1
Host: fatal.ru
Accept: */*
Referer: http://fatal.ru
User-Agent: Mozilla/4.0 (compatible; MSIE 5.00; Windows 98)
Range: bytes=1688-
Connection: close

HTTP/1.1 200 OK
Server: HandyCache
Content-Length: 3736
Last-Modified: Tue, 18 Jul 2006 18:44:54 GMT
Content-Type: text/html; charset=windows-1251
Connection: Keep-Alive
А можно было б отдать лишь нужную часть. При этом по совпадающему общему размеру и полю LM клиент понял бы, что это подходящая часть.


Название: Re: Докачка файлов
Отправлено: Сергей от 24 декабря 2007, 14:57:46
Цитировать
Если получен запрос с "Range: bytes=...", и файл отдается из кэша, то хорошо бы отдавать лишь нужный кусок с ответом 206. Сейчас отдается весь файл с ответом 200.
А на каком основании вообще берется файл из кэша? Мы ведь не сохраняем в кэше Partial Content? Значит и читать не имеем права. Пусть так же тянется из инета и в кэш не лезет.


Название: Re: Докачка файлов
Отправлено: Михаил от 24 декабря 2007, 17:58:52
А на каком основании вообще берется файл из кэша?
Сработал, например, список Н.
Цитировать
Мы ведь не сохраняем в кэше Partial Content? Значит и читать не имеем права.
Мы сохраняем в кэше целый файл. Что нам мешает на соответствующий запрос отдать его часть?
Цитировать
Пусть так же тянется из инета и в кэш не лезет.
Из инета ничего не тянется. Посмотри приведенный пример. Там все из кэша.


Название: Re: Докачка файлов
Отправлено: Михаил от 24 декабря 2007, 22:09:06
Не работает закачка в два потока не изменившихся html-файлов. Клиент запрашивает файл, сервер отвечает 304, и НС отдает файл из кэша. Клиент снова запрашивает, но уже кусок этого же файла - IMS не вставляется, и сервер отдает нужный кусок. Файл вроде один и тот же, но НС при записи в кэш добавлял в HTML свои тэги, и файл от НС уже не стыкуется с тем куском, который передает сервер. В итоге баг.
Если б НС вставлял IMS в запрос с Range, получил бы и второй раз ответ 304, и мог выдать нужный кусок из кэша без конфликта.


Название: Re: Докачка файлов
Отправлено: Сергей от 25 декабря 2007, 10:53:52
Сработал, например, список Н.
Почему тогда не срабатывает список З? URL же удовлетворяет списку?
Цитировать
Мы сохраняем в кэше целый файл. Что нам мешает на соответствующий запрос отдать его часть?
Точно так же - ничто не мешает записывать в кэш запрошенное продолжение недокачанного файла

Цитировать
Из инета ничего не тянется. Посмотри приведенный пример. Там все из кэша.
Так не должно было браться из кэша. Отсюда и твой глюк.


Название: Re: Докачка файлов
Отправлено: Михаил от 25 декабря 2007, 14:17:15
Почему тогда не срабатывает список З? URL же удовлетворяет списку?
При срабатывании Н и наличии файла в кэше он не просматривается.
Цитировать
ничто не мешает записывать в кэш запрошенное продолжение недокачанного файла
Мешает невозможность хранения метаинформации. Но мы рассматриваем пример, когда файл уже весь есть в кэше.
Цитировать
Так не должно было браться из кэша.
Наоборот, должно было. Только не весь файл, а запрошенная часть.


Название: Re: Докачка файлов
Отправлено: Сергей от 27 декабря 2007, 14:48:12
Цитировать
При срабатывании Н и наличии файла в кэше он не просматривается.
Ты не понял. Я о том что PartialContent отключает запись в кэш но не влияет на чтение.
Это нелогично. Игнорировать так игнорировать.


Название: Re: Докачка файлов
Отправлено: MRV_Pahan от 15 декабря 2009, 12:35:32
А по какой причине заглохла эта ветка?
Ведь докачки как не было так и нет.

Хуже того, в связке Опера - Хэндикэш - Глобакс файлы принимаются с ошибками.
Т.е. качаем даже небольшой файл (порядка 1-2 метра) и при нестабильном соединении Хэндикэш начинает закачку заново, но опера об этом почему-то не "узнает" и продолжает закачку как будто закачка продолжилась.
В результате файл испорчен.
В цепочке Опера - Глобакс все корректно докачивается.


Название: Re: Докачка файлов
Отправлено: DenZzz от 15 декабря 2009, 13:04:50
Т.е. качаем даже небольшой файл (порядка 1-2 метра) и при нестабильном соединении Хэндикэш начинает закачку заново, но опера об этом почему-то не "узнает" и продолжает закачку как будто закачка продолжилась.

Не верю! HC так просто не умеет делать! Закачкой рулит браузер, HC только исполняет его запросы и по своей воле ничего заново закачивать не может. Приложи отладочный лог такого случая, посмотрим, что на самом деле у тебя происходит...



Название: Re: Докачка файлов
Отправлено: divinets от 14 марта 2010, 17:35:14
Предлагаю научить HC возвращать Partial Content не только из интернета, но и из кэша.
Пример: есть большой файл в кэше и медленный клиент который не успевает за свою сессию скачать этот файл. В результате даже при возможности его качалки продолжить с места разъединения, HC отказывает ему и разрешает качать только весь файл целиком, т.е. с начала.
Есть возможность исправить в будущих версиях?


Название: Re: Докачка файлов
Отправлено: rosman от 13 мая 2010, 12:00:09
Докачка когда-нибудь появится или нет? Очень нужная идея, но почему-то так и не реализованная


Название: Re: Докачка файлов
Отправлено: Parcher от 05 сентября 2010, 20:14:18
Извините меня, если данный вопрос уже где-то обсуждался. Но наряду с докачкой, планируется ли сделать многопотоковую закачку файлов? К примеру можно было сделать работу многопотоковой закачки файлов по правилам (качать в несколько поток файлы с расширением... и размером больше.... исключения....)


Название: Re: Докачка файлов
Отправлено: DIGGER от 06 сентября 2010, 14:51:15
Parcher, такого реализовать не возможно в принципе!
Многопоточность реализуема на стороне браузера, и только. (Не с проста ж есть всякие менеджеры закачек)


Название: Re: Докачка файлов
Отправлено: Parcher от 06 сентября 2010, 15:36:03
А если запрос отправлять в менеджер закачки? К примеру в ReGet. Или это гемор?


Название: Re: Докачка файлов
Отправлено: DenZzz от 06 сентября 2010, 16:24:41
Parcher, такого реализовать не возможно в принципе!

На счет принципиальной невозможности реализации не согласен! Реализовать можно, но сложно!
Например: расширение HC получает от браузера запрос на большую картинку и качает ее по частям в несколько потоков, потом отдает браузеру все части в нужном порядке и пишет в кэш.


Название: Re: Докачка файлов
Отправлено: DIGGER от 06 сентября 2010, 16:38:48
На сколько я понял, то речь шла о файлах по 50-100-700mb, а если так картинки качать, то это ж какой должен быть тормознутый канал у сервера (сайта)?

А вообще можно такое реализовать, но зачем мне архивов на 2гига в кэше?

+ как быть со всякими депозитами? Они не дают качать в несколько потоков :(

Выгоды явной не вижу.

P.S. Был не прав по поводу не возможности, каюсь. (точнее я откинул возможность на стадии складирования архивов в кэш - это не правильно)


Название: Re: Докачка файлов
Отправлено: Parcher от 06 сентября 2010, 18:32:39
Да дело не в размере кеша. К примеру просто случай - просмотр видео на youtube.ru в высоком качестве. Иногда что-то начинает тормозить и закачка идет очень медленно при скорости 7000 кб/с по оптике. Но при этом если ссылку на видео кинуть в ReGet, то файл качается на максимальной скорости и в несколько поток. Просто если делать такое расширение, то нужно прописать при каких обстоятельствах и для каких сайтов и файлов оно будет срабатывать.


Название: Re: Докачка файлов
Отправлено: DenZzz от 06 сентября 2010, 21:20:28
А если запрос отправлять в менеджер закачки? К примеру в ReGet. Или это гемор?

Это гораздо проще, чем писать свое расширение а-ля ReGet с нуля. Если менеджер закачки умеет забирать из командной строки URL и класть файл в заданное место в кэше, то расширение сможет его потом забрать и передать браузеру.

К примеру просто случай - просмотр видео на youtube.ru в высоком качестве. Иногда что-то начинает тормозить и закачка идет очень медленно при скорости 7000 кб/с по оптике.

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


Название: Re: Докачка файлов
Отправлено: Parcher от 06 сентября 2010, 23:23:39
Если менеджер закачки умеет забирать из командной строки URL и класть файл в заданное место в кэше, то расширение сможет его потом забрать и передать браузеру.

Не знаю, как из командной строки добавить URL и папку сохранения файла в ReGet, но это умеет делать программка для оперы oGet. В меню правой кнопки добавляется строка "Закачать с oGet" и URL передается в ReGet. Может этот oGet поковырять?!

Случай на самом деле не такой уж и простой. Браузер начинает качать клип сначала и одновременно воспроизводит его в браузере. При достаточной скорости канала видео ты начнешь смотреть сразу и до конца без задержек и тормозов.

Скрость канала порой бывает ни при чем. По крайней мере у себя замечал такую вещь: инет работает нормально, а видео размеров 50 мб. грузиться по полчаса, при том, что это же видео в ReGet в несколько потоков грузиться за пару минут. В таком случаи все равно приходиться ставить видео на паузу и ждать пока хоть сколько-то загрузится. А если хотя бы в 2-3 потока грузить, то может быть что-то и изменится. Вот у меня такая мысль и возникла.
В общем, это так, для размышления.


Название: Re: Докачка файлов
Отправлено: Parcher от 09 сентября 2010, 02:08:54
Прочитал интересную вещь про reget. В планировщике можно по завершению закачки запускать различные проги и скрипты. Если при помощи скрипта после завершения закачки нужный файл перемещать в нужную папку? А НС уже брал бы закаченный файл.
Добавление закачки через командную строку:
-Add
Передает параметры уже запущенному экземпляру ReGet. Если ReGet не запущен и ключ -NoStart не указан, запускает новый экземпляр ReGet.

-NoStart
Предотвращает запуск ReGet при использовании ключа /Add

-NoSplash
Предотвращает показ информационного экрана (сплэша) при старте ReGet.


Название: Re: Докачка файлов
Отправлено: DenZzz от 09 сентября 2010, 12:52:42
Если при помощи скрипта после завершения закачки нужный файл перемещать в нужную папку?

А как скрипт ReGet узнает путь к нужной папке в кэше? Ему сложно будет повторить всю процедуру преобразования URL, заложенную в HC. Так что, путь ему нужно будет как-то сообщить...

Я тут подумал, что в принципе расширение HC может и само забирать файл из папки загрузок ReGet и писать его в кэш HC. Как будет время, попробую...


Название: Re: Докачка файлов
Отправлено: Parcher от 09 сентября 2010, 15:54:02
Как будет время, попробую...

Вот на этом СПАСИБО! :)


Название: Re: Докачка файлов
Отправлено: divinets от 23 февраля 2011, 23:36:17
Повторюсь, потому что не было никаких по этому поводу комментариев.

Предлагаю научить HC возвращать Partial Content не только из интернета, но и из кэша.
Пример: есть большой файл в кэше и медленный клиент который не успевает за свою сессию скачать этот файл. В результате даже при возможности его качалки продолжить с места разъединения, HC отказывает ему и разрешает качать только весь файл целиком, т.е. с начала.
Есть возможность исправить в будущих версиях?


Название: Re: Докачка файлов
Отправлено: DenZzz от 24 февраля 2011, 12:50:21
Есть возможность исправить в будущих версиях?

Теоретически это можно сделать расширением.


Название: Re: Докачка файлов
Отправлено: divinets от 25 февраля 2011, 18:11:02
Я не представляю как его написать. Может кто сможет?


Название: Re: Докачка файлов и загрузка по частям
Отправлено: Aly от 12 июня 2011, 12:16:14
Так что в итоге?
Будет докачка?
Предлагаю: "обычную" докачку, т.е. с того места где прервалось, а закачка по частям это лучше качалкам оставить.
Сделать как отдельную опцию с включением только для отдельных типов файлов или URL.


Название: Re: Докачка файлов и загрузка по частям
Отправлено: HKLM от 10 января 2012, 22:07:09
В последней версии RC3 1.0.0.377, цитата: "Добавлена поддержка Partial Content при выдаче из кэша;"
Что это? Как посмотреть на его работу?


Название: Re: Докачка файлов и загрузка по частям
Отправлено: mai62 от 10 января 2012, 23:49:56
Клиент должен запросить загрузку не всего файла, а его части. Раньше при выдаче файла из кэша НС отдавал файл целиком, теперь будет отдавать затребованный кусок. Такое поведение клиента можно наблюдать, например,  при обновлении Windows.
Отдача файла не целиком, а частью, легко обнаруживается по ответу 206 вместо 200.


Название: Re: Докачка файлов и загрузка по частям
Отправлено: HKLM от 13 января 2012, 23:35:13
Как раз, проблема, возможно с этим. Открываю в браузере файл, он полностью скачался, но в мониторе непонятно что видно. Сначала дисконнект, потом Partial Content. Кусочками он докачался.
Но почему не сработала запись в кэш? Если это возможно хорошо бы сделать запись в кэш полного файла.
цепочка: Опера-НС-туннель.нет
Еще непонятно, почему вначале разрывает закачку? Два разных файла скачивал, таже проблема.

(http://img814.imageshack.us/img814/9264/partialcontent2.png) (http://imageshack.us/photo/my-images/814/partialcontent2.png/)


Название: Re: Докачка файлов и загрузка по частям
Отправлено: mai62 от 13 января 2012, 23:46:27
Если файл прошел через НС частями, то его в кэше не будет. Partial Content поддерживается только при чтении из кэша.


Название: Re: Докачка файлов и загрузка по частям
Отправлено: Stepby от 27 января 2012, 09:45:53
Это уже круто:)


Название: Re: Докачка файлов и загрузка по частям
Отправлено: Stepby от 07 марта 2012, 11:47:29
Есть в менеджере закачек CetRight интересный пункт в настройка "В качестве Proxy"
(http://s1.hostingkartinok.com/uploads/images/2012/03/9b90d84b22c8389406598532b53a3a1a.jpg) (http://hostingkartinok.com)
Хотя проверил, чёт не докачивает через него, нет партиал контента :(


Название: Re: Докачка файлов и загрузка по частям
Отправлено: Anymore от 02 июня 2012, 00:47:39
Возможно боян... предлагаю использовать алгоритмы WGET.


Название: Докачка файлов и загрузка по частям
Отправлено: ruffeoff от 12 июля 2012, 14:03:49
Тоже порой при отправлении сообщения в стадии загрузки находится достаточно долго. Но не критично для меня.


Название: Re: Докачка файлов и загрузка по частям
Отправлено: shveicar от 17 августа 2012, 00:28:57
Здравствуйте.
Из всего прочитанного выше,- остался нерешенным вопрос: как сохранить видео в кеше если загрузка файла отображается на мониторе, (файл открывается win media pleer)
и при загрузке идет ответ 206  Partial Content - дальше загрузка доходит до 100% и файл в кеше отсутствует. Как заставить сохранятся такие файлы в кеше? расширение видео, самое обычное .wmv


Название: Re: Докачка файлов и загрузка по частям
Отправлено: ftb от 13 мая 2013, 01:38:11
Здравствуйте.
Возникла недавно схожая ситуация при работе в клиенте FireStorm SecondLife.
Записи монитора во вложении (при отправке сообщения форма ответа выдает "Слишком много внешних ссылок")

Естественно кэшировать Хенди отказывается и клиент запрашивающий контент делает это всякий раз при входе в локацию.

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


Название: Re: Докачка файлов и загрузка по частям
Отправлено: juku от 31 января 2014, 13:41:57
Добрый день

Ну что, не у кого нету идей по поводу сохранения видео,файлов и тд с запросом 206  Partial Content. Потому что жесткий диск большой, а интернет не очень быстрый, чтоб постоянно грузить с нэта видео или еще что-то.

Очень сильно буду благодарен тому кто поможет.


Название: Re: Докачка файлов и загрузка по частям
Отправлено: olDjeka от 03 февраля 2014, 05:02:02
Посмотрите здесь (http://forum.ru-board.com/topic.cgi?forum=5&topic=29338&start=2360#16).


Название: Re: Докачка файлов и загрузка по частям
Отправлено: juku от 05 февраля 2014, 09:17:22
Работает замечательно. Спасибо olDjeka.


Название: Re: Докачка файлов и загрузка по частям
Отправлено: Dimiyan от 29 ноября 2014, 19:54:24
Люди да когда уже добавят "докачку" ?!?!?!?!? Я уже устал по 5ть раз перегружать все картинки :( я сижу с телефона в темной глуши и просто жажду возможности докачивать :-( отключать картинки это не вариант и многократно их перекачивать тоже! Спасите сделайте уже кто то плагин! Зачем делать все с нуля? сделать плагин использующий возможности внешних менеджеров закачки, например Internet Download Manager кстати у него есть функция граббера сайтов: какую просматривать, вложенность ссылок или только текущую страницу, достаточно автоматизировать процесс передачи данных между менеджером и хенди, мне кажется для проггера реализовать это в плагине будет пару пустяков !!!


Название: Re: Докачка файлов и загрузка по частям
Отправлено: Anymore от 29 ноября 2014, 20:48:26
Dimiyan, http://handycache.ru/component/option,com_smf/Itemid,10/topic,337.msg41430/#msg41430


Название: Re: Докачка файлов и загрузка по частям
Отправлено: Dimiyan от 01 декабря 2014, 17:11:31
О спасибо, поставил Hyperpool настроил в хенди переадресацию по условию картинки и всю остальную ересь и рад, докачавает на ура!!! :-) Я так посмотрел, что Hyperpool это тот же аналог хенди со своим аналогом анна серв и хисториком и кэшем, почему его не используют как более лучшую альтернативу хенди?


Название: Re: Докачка файлов и загрузка по частям
Отправлено: LordMerlin от 01 декабря 2014, 18:58:27
Используйте, кто мешает?


Название: Re: Докачка файлов и загрузка по частям
Отправлено: Dimiyan от 01 декабря 2014, 19:34:57
Никто не мешает, я просто хочу понять у какой проги больше возможностей, функционала, докачка конечно в пользу хипер пула. Мне интересно если на этом форуме человек дал мне намек на его использование, наверно сам его юзал и почему он на нем не остался, если у него такой же, даже в чем-то более богатый функционал.


Название: Re: Докачка файлов и загрузка по частям
Отправлено: Dimiyan от 02 декабря 2014, 01:34:11
Пропользовался я Hyperpool и скажу я вам это долгое и мучительное занятие :-) Hyperpool долго не может установить коннект ну прям очень долго пользоваться невыносимо, из хенди вижу запрос попадает в Hyperpool и закачка картинки весит, Hyperpool пробует переподключиться и опять висит в докачках раз на 50й соединится и скачает какую нибудь картинку но не все и опять стоит в хенди убераю прокси и все летает! Подскажите как заставить Hyperpool коннектиться к интернету или другое решение по докачке для хенди ????


Название: Re: Докачка файлов и загрузка по частям
Отправлено: Anymore от 02 декабря 2014, 11:56:40
У HyperРool много версий, далеко не каждая версия работает как часы.  К тому-же HyperРool куда более сложнее настраивать. Ещё здесь другие акценты, докачка, приоретизация, кросплатформенность. А вот таких вещей как, например авторизация нет. И интерфейс жуткий, попробуй настроить родительский прокси, это прям подвиг.


Название: Re: Докачка файлов и загрузка по частям
Отправлено: LordMerlin от 02 декабря 2014, 13:33:32
Ну и плюс расширений таких как в Хэнди нет.


Название: Re: Докачка файлов и загрузка по частям
Отправлено: Dimiyan от 02 декабря 2014, 14:08:46
Так он и стоит у меня как родительский для картинок, сначала стаял полностью но это был гемор, потом условие только на картинки сделал, но он какой-то импотент :-) начинает закачку с 50 го раза :-( но действительно качает и ду расширений в хенди уйма. В факе еще советовали проксимикон, по нему что можете сказать? юзабилити, настраиваемость, функции??


Название: Re: Докачка файлов и загрузка по частям
Отправлено: LordMerlin от 02 декабря 2014, 15:59:48
Попробуйте поиграться с настройками таймаута самого Хэнди.
Так же есть расширение, вносящее задержку в загрузку картинок на узких каналах зачастую помогает.
Проксомитрон был хорош до появления СМ.
Ним можно что хочешь делать с заголовками пакетов входящих и исходящих. Модифицировать код страницы.


Название: Re: Докачка файлов и загрузка по частям
Отправлено: Dimiyan от 02 декабря 2014, 20:44:41
Я поигрался с настройками но не понял, что в какую сторону менять, фак прочитал, но так как то заумно написано то ли я недопер?


Название: Re: Докачка файлов и загрузка по частям
Отправлено: KDEboroda от 18 марта 2016, 20:29:40
У меня задача схожая, но в чём-то обратная.
При моих 64 кбит/с это сильно упростило бы жизнь.
В кэше ЕСТЬ ЗАГРУЖЕННЫЙ ЦЕЛЫЙ файл (больше 1 Мбайт), а программа просит его части (206 Partial Content), почти целого размера файла :(. 2 минуты на мегабайт + зависание соединений - и в итоге страница НИКОГДА не загружается полностью :(. А хотел взглянуть.
Ну и, конечно же, пригодилось бы закачивание любых частей файла в кэш.
В идеале - с объединением частей, когда они сомкнутся.
В приятностях - с возможностью управлять этим поведением и с возможностью докачать целые варианты/очистить части.