HandyCache форум

Часто сталкиваюсь с такой проблемой. Она меня очччень раздррражает  >:(
Заключается в том, что если браузер или прога, работающие через HandyCache запрашивает одно и то же несколько раз, то HandyCache усердно начинает качать такие страницы, изображения и т.д. снова и снова.
 Почему бы не проверять адрес URL хотя бы.
Недопустимо закачивать один и тот же URL параллельно в пяти потоках!!!   >:(
Где экономия?  ???

Браузер не может запрашивать одно и то же параллельно. Скорее всего, он качает разные страницы, которые имеют одинаковый URL. Я встречал такое.
Вот пример
http://www.skylink.ru/info/tarifs.aspx?p=1&id=1&r=77
Там есть ссылки на группы тарифов. Каждая ссылка открывает один и тот-же URL.

А вот в ситуации, когда несколько клиентов одновременно начинают качать одно и то-же, надо бы качать один раз. Эта тема уже поднималась на Руборде.

Многооконный браузер (а сейчас все такие) - он и есть "несколько клиентов"

Qua

Подтверждаю, если с одного сайта открыть несколько окон IE (или вкладок в Макстоне), то одна и та же новая картинка будет параллельно качаться в несколько потоков (это видно в Мониторе HC). 
Аналогичная картина, если в сети сразу несколько пользователей одновременно ходят по одним и тем же сайтам!
 
Таким образом, если картинка на 500 кб и открывается 10 окон, то получим 4.5 Мб лишнего трафика! 
Поэтому придерживать дублирующие активные закачки одного и того же файла не помешало бы...

В ToDo (http://handycache.ru/component/option,com_smf/Itemid,10/topic,20.0/) это уже внесено, как: "Реализовать опцию "Придерживать параллельные закачки"...

Это еще один гвоздь в гроб IE ;)

А почему придерживать? Клиент не должен ждать пока другой докачает.

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

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

Вариант с придержкой закачки тоже реален т.к. при плохом канале новый экземпляр файла никак не закачается быстрее того что уже качается  :) так  что  для конечного пользователя все равно будет ускорение ПОЛНОЙ загрузки файла (да да порно будет появлятся сразу а не постепенно :) )

Тут не учтены трудности при многопоточной закачки, но думаю для качалки перезапросить файл труда не составит

Oneri
еще надо проверять ситуации, когда по одному URL качаются разные данные.
не из кэща а из некоторого буфера. Т.к. в кэш может и не сохраняться.

Тогда как минимум надо обрабатывать заголовки :(

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


В данном случае буфер не имеет смысла:
1. Перерасход памяти (а если качается большой файл) как пример файл качается из браузера и качалки через НС
2. Насколько я понимаю что в данном случае пользователя интересует получение актуальных данных и смысла в буфере здесь нет. 

Буфер на диске, разумеется.

Еще один вариант - не качать параллельно только те URL, на которые может сработать список "Не обновлять".

Логика проста: если бы закачки были не параллельные, а последовательные одна за другой, то второй, третий и т.д. раз файл взялся бы из кэша! Тогда зачем его качать параллельно!

Если же мы знаем, что по одному URL могут быть разные данные (динамический контент), то ему не место в списке "Не обновлять" - просто исключаем его из списка (или в "Белом списке" пишем соответствующее правило).

Проблема в том, что контент статический.

Сергей


Это проблема касается не только IE !

Представь в локальной сети 10 пользователей в Опере ходят через HC одновременно по одному фотоальбому в Инете! Вероятность, что все 10 одновременно наткнуться на одну и туже 3х-мегабайтную фотку велика! И Опера им ничем не поможет - все десять пользователей начнут параллельно качать эту фотку, забив под завязку и без того медленный канал на длительное время! ;)


Контент статический, а данные каждый раз разные? Так бывает?

В локальной сети кроме общего кэша никто не поможет :)

А вот как говорил Дем:
У Оперы в этом случае все в порядке: один файл, запрошенный из нескольких окон, качается единожды - для всех "клиентов".

DenZzz
Да. Я привел пример выше.

Я в курсе. Тут виноват будет HC.
Просто не ожидал такого странного поведения от IE.

Проблема есть. Хотелось бы ее решить.

Почему бы в HC не реализовать подобное? Понимаю что сложно. Но ведь сделали норвежцы? Чем мы хуже?

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

Не вижу принципиальной разницы! Как будто Опера сама знает, по какой ссылке дальше кликнет пользователь или какую закладку откроет! ;)
У HC тоже есть очередь активных закачек, которой он может управлять по своему усмотрению!

Тот мой пост, что вы видите самым первым - просто наболело, далее трезво.  ;)

Объясню шире - может прояснит чего...

Преамбула:
Я часто пользуюсь различными картографическими сервисами NASA, MS Local.Live, GoogleMaps, поделками вроде Яndex.Карты и другими. Причем, к одному и тому же сервису обращаюсь разными прогами (мне действительно так удобнее - разные по возможностям компы, да и цели). Пользуюсь всем этим непременно в связке с Ханжой Кешкой (HandyCache служит чем-то вроде универсального и понятно устроенного единого кеша), с которым худо-бедно наплевать на несовместимость всех этих софтин.  ;D

Проблема:
Единственное что меня сильно огорчает (см. выше) при работе HC - многочисленные повторения закачки одних и тех же ресурсов. Это хорошо видно в нижней части "Монитора" - одновременно в несколько потоков качается один и тот же URL. Хроническая "болезнь" практически всех картографических прог.
Собственно, на одном компе (домашнем) эта проблема не очень-то заметна, на других (привет из прошлого) - дюже достаёт. Паразитный трафик! В такой нужный момент, на таком хилом канале.

Просьба:
Я понимаю, что виноват не столько HC, сколько проги - запрашивают один и тот же ресурс по нескольку раз... Но, ведь можно наверное реализовать проверку - загружается ли запрашиваемая страница в данный момент (если URL закачивается, то не повторять загрузки, а игнорировать запрос или взять из кэша).

То, что подчеркнуто и есть новое предложение.

Вопрос со статическим контентом и разными данными принципиально не настраиваемый?

P.S. Трезво тоже не то, надеюсь основную мысль донёс.
А, в целом, Кешка - мой лучший друг для связи с миром!  :D

Прежде всего надо определиться с терминами. Если контент (иначе - содержимое) статичен, то о каких различных данных можно говорить?! Это просто два различных представления (человеческое и машинное) одного и того же понятия. Уточни свой вопрос так, чтобы это можно было понять не на уровне "наверное, он имел в виду..."

Qua


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

А может проще подойти - если файл сохраняется в кеш - выдать клиенту сохранённый кусок и потом передовать из одного входящего в два исходящих.
А если в кеше нету - значит нету.

Я это предлагал. Автор сказал, что это сложная задача. Не все так просто там.

Я имел в виду, существует ли вероятность того, что указав в настройках (с помощью выражений или скажем галочки) "Не допускать нескольких параллельных загрузок одного URL"  можно отделаться от части проблемы (моей), даже пожертвовав теми случаями когда:
Цитата
и ответ DenZzz

Я все-таки не пойму как возможен "статический контент с разными данными"? Одно исключает другое.

URL'ы там разные:
ctl00$CpMCol$DataGrid1$ctl02$ctl00 - Индивидуальные
ctl00$CpMCol$DataGrid1$ctl03$ctl00 - Корпоративные
ctl00$CpMCol$DataGrid1$ctl04$ctl00 - Тарифы на роуминг

Точнее, это не сами URL - это аргументы для функции JavaScript формирующей URL.

Там вместо ссылок запускаются java скрипты. В итоге загружается страница имеющая такой же URL. И в кэш записывается поверх старой страницы.
Попробуй полистать тарифы в автономном режиме. Ничего не выйдет.

Там вообще веб-форма. И параметры через post передаются. Гиблое дело.

Хоть и оффтоп, но раз затронут случай, может, подумаем, как расправляться с Post-ом?
Например, встретив Post-запрос, так же как и для GET-запроса с параметрами создаем папку с названием, взятым из URL в его заголовке. Затем возникает проблема установления взаимно однозначного соответствия тела Post-запроса с наименованием файла в кэше, куда мы хотим его записать. Как упрощенный вариант можно предложить в качестве имени брать все тело Post-запроса (естественно, преобразованное через процедуру замены спецсимволов), обрезанное (при необходимости) до количества символов, равного ограничению на длину имени файла в операционной системе, либо равного значению, задаваемому нами самими. Таким образом, на части таких запросов достигнем счастья (не анализировал, но может, эта часть и не такая уж маленькая).

Какая замена спецсимволов? Там вообще двоичные данные передаваться могут.
Можно посчитать контрольную сумму передаваемого к серверу блока данных и на его основе создать уникальное имя файла. Хотя, может я и заблуждаюсь.

Сергей
Хорошая идея насчет контрольной суммы. Может, как автор идеи создашь тему для обсуждения, чтоб мы тут не оффтопили?

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

Кто первый начал, тот и пишет.

Может как нить визуализировать такие коллизии? Когда запись невозможна.
Чтоб было видно что запись в кэш не удалась. Заодно вовремя заметить ситуации когда кэш переполнен. А то сейчас выдает ошибку только когда папка недоступна. Пусть, например, значок будет мигать.