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

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

Сообщений: 621



« : 20 января 2007, 09:59:09 »

Если будут обрабатываться заголовки, то это будет делать отдельный список?



Отлично! Реализовано в версии HC 1.0 RC1 с помощью скриптов Lua !
« Последнее редактирование: 11 января 2008, 09:43:10 от DenZzz » Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #1 : 20 января 2007, 12:32:13 »

Сергей

Цитировать
Если будут обрабатываться заголовки, то это будет делать отдельный список?

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

Тогда сюда можно будет перенести и блокировку "больших файлов", и блокировку файлов по типу "Content-Type", и сохранение в кэш по типу и многое другое!
Реализовать все это можно будет через универсальный список "Управление по заголовкам". Например, такой:

   Заголовок        Условие   Правило                URL                     Действие              Приоритет  
Content-Length>300000.*-1
Content-Type=.*image.*.*Блокировать1
Content-Type=.*image.*handycache\.ruТолько из кэша2
Content-Type=.*image.*.*Запись в кэш3

Строки с равным приоритетом объединять по "И".
Список проверять сверху вниз до первого срабатывания строки (группы строк, объединенных одним приоритетом).

Действия могут быть такими: Блокировать, Не обновлять, Только из кэша, Запись в кэш.

Хранить заголовки на диске для файлов неизвестных типов можно в одном индексном файле, либо в файлах типа #h .
Либо вообще не хранить заголовки, а сделать, как сейчас работает блокировка "больших файлов":
  • Сначала проверяем обычные списки по URL;
  • Если решено качать из Инета, то получаем заголовки и принимаем окончательное решение.

Над составом столбцов, действий и логикой еще надо подумать. Давайте обсудим...
« Последнее редактирование: 20 января 2007, 13:36:02 от DenZzz » Сообщить модератору   Записан
NothingAnother
Beta tester
*****

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

Сообщений: 434

Spoiler


« Ответ #2 : 20 января 2007, 15:35:01 »

Имхо, действия "Блокировать" и "Только из кэша" смысла не имеют, т.к. заголовки берутся из уже загруженного (за исключением "Chunked") объекта - что же тут блокировать?
А вот для контента неинформационного характера, определяемого по полю "Content-Type" весьма полезным будет действие "Переместить объект в каталог..."
Сообщить модератору   Записан

Мы тоже не всего читали Шнитке!..
© В. Вишневский
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #3 : 20 января 2007, 20:47:45 »

NothingAnother

Цитировать
Имхо, действия "Блокировать" и "Только из кэша" смысла не имеют, т.к. заголовки берутся из уже загруженного (за исключением "Chunked") объекта - что же тут блокировать?

Имеют! Мы можем начать качать объект (получить заголовки и первые килобайты) и после этого заблокировать дальнейшую загрузку! Это не имеет смысла, конечно, для маленьких объектов, а больших - вполне разумно! Именно так сейчас работает опция "Не загружать большие файлы"!

Цитировать
А вот для контента неинформационного характера, определяемого по полю "Content-Type" весьма полезным будет действие "Переместить объект в каталог..."

Поясни смысл.  Что за объекты "неинформационного характера", в какой каталог перемещать и для чего?
Сообщить модератору   Записан
NothingAnother
Beta tester
*****

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

Сообщений: 434

Spoiler


« Ответ #4 : 20 января 2007, 21:19:48 »

Мы можем начать качать объект (получить заголовки и первые килобайты)...skipped...Именно так сейчас работает опция "Не загружать большие файлы"
Сумневаюсь... :Улыбка
Цитировать
Что за объекты "неинформационного характера", в какой каталог перемещать и для чего?
application/zip, audio/mp3, video/mpeg, etc.
Сообщить модератору   Записан

Мы тоже не всего читали Шнитке!..
© В. Вишневский
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #5 : 20 января 2007, 21:32:49 »

NothingAnother

Цитировать
Сумневаюсь...

В чем сомневаешься, что именно так и работает? А как ты думал? Подмигивающий

Может, Документация тебя убедит (правда, ее я писал): Улыбка
Цитировать
Здесь вы можете запретить загрузку определенных файлов, размер которых превышает заданный размер. При проверке размера происходит запрос файла в Интернете и анализ HTTP-заголовка "Content-Length". Если размер файла больше предельного, то загрузка прерывается. Если сервер передает файл без заголовка "Content-Length", то он будет загружен полностью независимо от конечного размера.


Цитировать
application/zip, audio/mp3, video/mpeg, etc.

Предлагаешь их перемещать не в кэш HC, а куда-то в другое место?
Сообщить модератору   Записан
NothingAnother
Beta tester
*****

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

Сообщений: 434

Spoiler


« Ответ #6 : 20 января 2007, 21:51:18 »

В чем сомневаешься, что именно так и работает?
Признаться - да, в этом...
Цитировать
А как ты думал?
Надеялся, что с помощью "HEAD". Если всё действительно происходит именно так - не буду далее пользоваться этой опцией Грустный
Цитировать
Предлагаешь их перемещать не в кэш HC, а куда-то в другое место?
Ну да, на усмотрение юзера, что-то типа "download-root". И не только их, а иже с ними есть ещё немало...
Сообщить модератору   Записан

Мы тоже не всего читали Шнитке!..
© В. Вишневский
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #7 : 20 января 2007, 22:28:17 »

NothingAnother

Цитировать
Надеялся, что с помощью "HEAD". Если всё действительно происходит именно так - не буду далее пользоваться этой опцией


Нет, когда создавалась эта опция, было решено не терять время на HEAD, а сразу начинать закачку GET, а потом уже принимать окончательное решение.
Лично у меня на медленном канале HC успевает скачать только 1-2 кб, а потом срабатывает блокировка! А у тебя как и почему тебя это пугает? Подмигивающий
Сообщить модератору   Записан
NothingAnother
Beta tester
*****

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

Сообщений: 434

Spoiler


« Ответ #8 : 20 января 2007, 23:05:18 »

Лично у меня на медленном канале HC успевает скачать только 1-2 кб, а потом срабатывает блокировка! А у тебя как и почему тебя это пугает?
У меня DSL, реальная скорость ко мне - где-то около 2.5 мегабайт. Но вряд ли это имеет значение - если даже для приёма первой порции данных через сокет просто выделяется достаточно малый буфер, так он же в свою очередь сам заполняется из другого буфера - сетевого (они находятся на разных уровнях OSI, соотв. на 4-ом - транспортном и на 3-ем - сетевом). Размер (оптимизированный) сетевого буфера у меня - 256 KB, так что меньше не ограничить...
Сообщить модератору   Записан

Мы тоже не всего читали Шнитке!..
© В. Вишневский
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #9 : 20 января 2007, 23:22:53 »

NothingAnother

Цитировать
Размер (оптимизированный) сетевого буфера у меня - 256 KB, так что меньше не ограничить...

Хм, тогда в будущем для получения заголовков есть смысл задуматься об опции "Использовать HEAD-метод для быстрых каналов"... Подмигивающий
Сообщить модератору   Записан
Дем
Постоялец
***

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

Сообщений: 167



« Ответ #10 : 21 января 2007, 12:09:56 »

Лично у меня на медленном канале HC успевает скачать только 1-2 кб, а потом срабатывает блокировка! А у тебя как и почему тебя это пугает?
У меня DSL, реальная скорость ко мне - где-то около 2.5 мегабайт. Но вряд ли это имеет значение - если даже для приёма первой порции данных через сокет просто выделяется достаточно малый буфер, так он же в свою очередь сам заполняется из другого буфера - сетевого (они находятся на разных уровнях OSI, соотв. на 4-ом - транспортном и на 3-ем - сетевом). Размер (оптимизированный) сетевого буфера у меня - 256 KB, так что меньше не ограничить...
А почему ты думаешь, что данные сначала заполняют буфер доверху, и только потом попадают в НС?
Такое происходит только в случае, если программа не успевает или сознательно ограничивает скорость приёма.
Первый же прибежавший пакет (~1400 байт) попадает в НС и приводит к нужной реакции, так как как правило заголовок в него влезает полностью.
Разумеется, пока соединение рвётся, сервак успеет передать ещё некое количество информации - но не так уж и много. Надо реально смотреть сколько.
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #11 : 21 января 2007, 12:28:43 »

NothingAnother

Да, собственно, ты проводил "полевые испытания"? Улыбка
Сколько реально успевает скачать HC на твоем DSL до срабатывания блокировки "больших файлов"?
Сообщить модератору   Записан
NothingAnother
Beta tester
*****

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

Сообщений: 434

Spoiler


« Ответ #12 : 21 января 2007, 19:50:53 »

ты проводил "полевые испытания"?
Нет

почему ты думаешь, что данные сначала заполняют буфер доверху, и только потом попадают в НС?
Уже не думаю, вспомнил, что структура итерфейсного буфера - стек типа FIFO
Цитировать
Первый же прибежавший пакет (~1400 байт) попадает в НС и приводит к нужной реакции, так как как правило заголовок в него влезает полностью
Не совсем так. Если HC не читает из буфера сокета побайтно (надеюсь, что - нет, это вешает процессор), а реагирует на завершение операции WinSockAPI асинхронно посредством callback-функции, то данные станут доступны в двух случаях - буфер сокета заполнен или все данные из интерфейсного буфера считаны. При создании объекта сокета ему выделяется буфер размером по умолчанию 4K, но это можно изменить в зависимости от задачи. Если буфер уменьшить - увеличится нагрузка на процессор, если увеличить - увеличится расход памяти. Оптимум находится, как возможность уместить статистически усреднённый сетевой ресурс в буфер "за один заход". В своё время я считал статистику своего серфинга для 40000 файлов. "Загрузоки" - контент больше 1M не учитывался. Получилось, что 50% умещаются в 8K, 90% - 16K, 95% - 32K, 98% - 64K. Для себя я выбрал 16K ("за один заход" принимаются 9 из 10 ресурсов), у mai62, естественно, свои резоны... Но к чему я веду - "...приводит к нужной реакции..." вовсе не "Первый же прибежавший пакет..."
Цитировать
пока соединение рвётся, сервак успеет передать ещё некое количество информации - но не так уж и много. Надо реально смотреть сколько
Надо. Неохота. Лениво...
Сообщить модератору   Записан

Мы тоже не всего читали Шнитке!..
© В. Вишневский
Дем
Постоялец
***

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

Сообщений: 167



« Ответ #13 : 22 января 2007, 02:43:21 »

Цитировать
Если HC не читает из буфера сокета побайтно (надеюсь, что - нет, это вешает процессор), а реагирует на завершение операции WinSockAPI асинхронно посредством callback-функции, то данные станут доступны в двух случаях - буфер сокета заполнен или все данные из интерфейсного буфера считаны.
Немножко не так. callback происходит по появлению информации в буфере. Любого количества. Но - данные по сетке ходят пакетами. И меньше пакета в буфер попасть не может.
Типичная длина пакета - 1420 байт, заголовок порядка килобайта...
Сообщить модератору   Записан
NothingAnother
Beta tester
*****

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

Сообщений: 434

Spoiler


« Ответ #14 : 22 января 2007, 08:07:51 »

Типичная длина пакета - 1420 байт
Минимальная длина, гарантирующая пакет от фрагментации при проходе его по любому маршруту в WWW - 576B, и реально таких пакетов в инете немало
Цитировать
заголовок порядка килобайта
Не учитывая куки 150-300B, c куками ессно поболее, но они, как правило, находятся в конце заголовков. Это просто уточнение, всё равно информация о размере (Content-length), скорее всего действительно доступна уже в первом пакете. Но!:
Цитировать
callback происходит по появлению информации в буфере. Любого количества
Глубоко сумневаюсь. :Улыбка Это выхолащивает суть асинхронного буферированного чтения входного потока и становится эквивалентно побайтному приёму. Попав в интерфейсный буфер, пакеты исчезают как сущность и превращаются в "поток". И объект сокета в свой буфер считывает уже не пакеты, а этот самый поток до завершения операции чтения по событию наполнения буфера или достижению конца потока. Смысл callback-вызовов - реакция приложения на завершение операции API. А в этом случае какой операции? Чтению байта? Тогда и буфер не нужен Подмигивающий
« Последнее редактирование: 22 января 2007, 08:13:39 от NothingAnother » Сообщить модератору   Записан

Мы тоже не всего читали Шнитке!..
© В. Вишневский
Дем
Постоялец
***

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

Сообщений: 167



« Ответ #15 : 22 января 2007, 09:53:55 »

Цитировать
Минимальная длина, гарантирующая пакет от фрагментации при проходе его по любому маршруту в WWW - 576B, и реально таких пакетов в инете немало
Угу. Хватает. Но, тем не менее, 1420 байт тоже частое явление...

Цитировать
Смысл callback-вызовов - реакция приложения на завершение операции API.
Вопрос в том, завершение какой операции мы хотим увидеть. И какие настройки выдаём сокету в связи с этим.
Поэтому возможен вызов callback (в соответствии с параметрами открытия сокета)  в трёх ситуациях:
1) завершение приёма/наполнение буфера
2) приход пакета данных
3) приход фрагмента пакета

И какой режим выбран у автора - вопрос к нему Улыбка
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #16 : 22 января 2007, 10:14:16 »

NothingAnother

Цитировать
Надо. Неохота. Лениво...

Может, все-таки, пересилишь лень и проведешь "полевые испытания"!?
Время на это уйдет гораздо меньше, чем на теоретические споры в этой теме! Подмигивающий
Сообщить модератору   Записан
Rick
Администратор
*****

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

Сообщений: 868


WWW
« Ответ #17 : 22 января 2007, 12:19:33 »

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

Цитировать
Глубоко сумневаюсь. :Улыбка Это выхолащивает суть асинхронного буферированного чтения входного потока и становится эквивалентно побайтному приёму. Попав в интерфейсный буфер, пакеты исчезают как сущность и превращаются в "поток". И объект сокета в свой буфер считывает уже не пакеты, а этот самый поток до завершения операции чтения по событию наполнения буфера или достижению конца потока. Смысл callback-вызовов - реакция приложения на завершение операции API. А в этом случае какой операции? Чтению байта? Тогда и буфер не нужен Подмигивающий
Наполнение буфера означает, что продолжающие поступать пакеты будут отвергаться, затем запрашиваться вновь. Поэтому начало чтения с момента заполнения буфера - путь к ошибкам и многократным повторам.
Чтение из буфера начинается по факту появления в нем данных, однако система может быть не готова сделать это (занята) - для этого и нужен буфер и в этом же и ассинхронность: данные поступили, но считаны могут быть с задержкой - по готовности системы сделать это.

И мы ударились в теорию вместо того, чтобы оценить "цену вопроса": сколько "лишних" данных будет принято. И похоже кроме тебя некому провести такой эксперимент.
Сообщить модератору   Записан
Дем
Постоялец
***

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

Сообщений: 167



« Ответ #18 : 22 января 2007, 15:00:49 »

Раз уж вам лень - я у себя протестил. (канал 512К)
У большинства - в районе 1150 байта (±10)
у примерно 15% - в районе 2610
у примерно 2% - в районе 4070

Размер пакета прослеживается однозначно Улыбка
Сообщить модератору   Записан
Rick
Администратор
*****

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

Сообщений: 868


WWW
« Ответ #19 : 22 января 2007, 15:15:41 »

Раз уж вам лень - я у себя протестил. (канал 512К)
У NothingAnother канал ~21Мбит/с - поэтому и хотелось бы, чтобы тест провел он.

Цитировать
У большинства - в районе 1150 байта (±10)
у примерно 15% - в районе 2610
у примерно 2% - в районе 4070
Это что? Размер заголовка, или объем поступивших данных до принятия решения об отказе загрузки этого файла? Интересует именно второе. И как измерял.
Сообщить модератору   Записан
Страниц: [1] 2  Все   Вверх
  Отправить эту тему    Печать  

 
Перейти в: