» HandyCache ( Часть 4 )

forever
ну есть сила в этих словах... согласен...



Добавлено:
forever
хотя потоки ntfs - хорошая нычка, куда можно прятать много полезностей, не плодя новых файлов

может тут стоит частично и поступиться принципами портируемости - больно уж плюсы хороши

а поставить систему с ntfs - не такая уж большая проблема, если не раздувать из этого много шума

зы
на слабых машинках (где обычно w98 ставят) можно для обеспечения ntfs поставить тот же nt4 wks - у меня вон на работе до сих пор сервера nt4 на минимальном железе стоят

forever

Цитата:

Кэш может храниться на любой файловой системе. На любой! Имхо предложение несмотря на всю заманчивость неприемлимо в принципе.

Все приемлемо. Просто юзеры, у которых не будет NTFS, не смогут юзать данную фичу. Под каждого не подстроишься. Вот, тот же KAV использует фичи с потоками NTFS.

Добавлено:
DenZzz

Цитата:

Цитата: Использовать эту реализация для списков - белый, черный, запись в кэш, не обновлять.

Про "Только из кэша" не забыл? Например, мне надо вписать туда картинки по типу Content-Type: image...

rs

Цитата:

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

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


Цитата:

больно уж плюсы хороши

Не уверен. Не вижу того, что нельзя было бы сделать без потоков и не замыкаясь на одну FS - а значит универсально.


Цитата:

а поставить систему с ntfs - не такая уж большая проблема, если не раздувать из этого много шума

Хвост вертит собакой.


Цитата:

на слабых машинках (где обычно w98 ставят) можно для обеспечения ntfs поставить тот же nt4 wks

А зачем? Проблема не в том, чтобы научить 98-ю работать с NTFS - просто в этом может не быть смысла: на слабых машинах FAT32 может оказаться быстрее.
Да и на современных машинах FAT32 рано списывать со счетов. Старенькая статейка Быстродействие FAT и NTFS заставляет задуматься, а на чем же лучше хранить кэш НС: на FAT32 или на NTFS. Возможны варианты.
Попадается и экзотика типа хранения кэша на флешке. Ну какой NTFS на флешке?

unreal666

Цитата:

Просто юзеры, у которых не будет NTFS, не смогут юзать данную фичу.

За что ж их так ограничивать?


Цитата:

Под каждого не подстроишься.

А что мешает использовать не потоки а файлы - и всем будет счастье.


Цитата:

Вот, тот же KAV использует фичи с потоками NTFS.

Не в курсе. А как? Он их проверяет на предмет наличия гадостей? Или он их действительно использует?

unreal666

Цитата:

Для списка "Только из кэш" данная фича бесполезна... такое правило будет равносильно правилу в списке "Не обновлять".

Ты не прав! Допустим файла нет в кэше, начали его качать (получили заголовки) и выяснили, что "Content-Type: image...", - список "Не обновлять" продолжит закачку, а "Только из кэша" тормознет и отправит браузеру "404"! В этом их принципиальная разница!
Собственно, также сейчас работает блокировка "больших файлов" и будет работать блокировка ака "Черный список", т.к. никах данных о заголовках этих файлов изначально (до начала загрузки) у нас нет!


Цитата:

Вот, тот же KAV использует фичи с потоками NTFS.

А ты разве не в курсе, что KAV решил отказаться от использования потоков?

Цитата:

Специалисты «Лаборатории Касперского» планируют внедрение в следующей версии Антивируса Касперского альтернативного механизма, не использующего технологию iStreams, для обеспечения того же уровня производительности.

Линк: http://www.kaspersky.ru/news?id=177713739

forever

Цитата:

Хвост вертит собакой.

ну это как посмотреть...
следовать принципам только во имя самих же принципов тоже не очень разумно...

о быстрдействии файловых систем... еще в те времена, когда nt была в версии 3.5 я провёл простой эксперимент - разместил большую БД на ntfs диске с компрессией и без, запустил какие-то задачки, лопатящие базы данных - результат: неспотря на то, что на БД с компрессией как бы расходуются ресурсы на компрессию-декомпресиию, получилось, что скорость обработки на компрессированной БД была раза в два выше... я иак рассудил, что временнАя экономия на меньших расстояниях перемещения головок диска для более сжатого файла с лихвой компенсирует временнЫе затраты на компрессию-декомпрессию...

учитывая, что на тесте выключения питания сервера на fat и ntfs - последний никогда не терял данные, выбор типа файловой системы для меня произошёл раз и на всегда - ntfs+компрессия



Цитата:

А что мешает использовать не потоки а файлы - и всем будет счастье.

можно, но тогда на каждый файл в кэше нужно создавать пару - типа паспорта этого файла и писать в него всю сопутствующую информацию

тут конечно имеем все дела типа удвоения количества файлов в кэше, фрагментаци и т.п.

хотя если сделать паспорт опцональным - то мне кажется решение также приемлемое, те кому это будет действительно нужно пожертувют минусами удвоения

DenZzz

Цитата:

Линк: http://www.kaspersky.ru/news?id=177713739

Во башка моя дырявая! А ведь я это уже раньше читал. Интересно, что получается пользователи KAV так же пролетят с предлагаемым использованием потоков, как и пользователи других файловых систем:

Цитата:

Если Антивирус Касперского активен, потоки скрыты и к ним нет доступа со стороны любых процессов, включая системные. Если продукт отключен, то потоки становятся видимыми при помощи специальных программ.

Добавлено:
rs

Цитата:

следовать принципам только во имя самих же принципов тоже не очень разумно...

А где ты усмотрел признаки слепого следования принципам только ради самих принципов?


Цитата:

я провёл простой эксперимент - разместил большую БД на ntfs диске с компрессией и без

"Большая БД" - это же не большая куча мелких файлов раскиданных по куче разных каталогов? Тест однобокий получился.


Цитата:

на тесте выключения питания сервера на fat и ntfs - последний никогда не терял данные

Мне повезло меньше. За мою практику два (!) раза слетала MFT.

rs

Цитата:

тут конечно имеем все дела типа удвоения количества файлов в кэше

Можно и один индексный файл создать, как уже здесь предлагалось...

DenZzz
плюс HC в том, что в нём нет НИКАИХ индексов - благодаря этому можно без проблем суммировать кэши с разных компов, давать пищу моему историку и т.п.

не хотелось бы терять такой большой плюс


Добавлено:
forever

Цитата:

А где ты усмотрел

может быть в себе?..



Цитата:

Тест однобокий получился.

никто не спорит
просто факт из моего опыта, имеющий для меня вес... не более того

rs

Цитата:

не хотелось бы терять такой большой плюс

Инфа о том, что KAV не даст использовать этот "большой плюс", считай, похоронила всю идею. Обломить пользователей файловых систем отличных от NTFS + пользователей KAV - как еще посильнее нагадить НС?

Кстати, способ хранения это вопрос второй.

Цитата:

на каждый файл в кэше нужно создавать пару - типа паспорта этого файла и писать в него всю сопутствующую информацию

Объясни плз, а что, собственно, хранить? И зачем? После того как файл получен зачем нужно хранить заголовки HTTP?
Content-Length - смотрим размер файла. Content-Type - имея файл в руках есть сомнения? Что еще?

rs

Цитата:

плюс HC в том, что в нём нет НИКАИХ индексов

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

forever

Цитата:

а что, собственно, хранить?

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

Цитата:

Кстати, способ хранения это вопрос второй.

можно и так сказать

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


Цитата:

Кстати, "историк" к этому причастен!

сорри


ну тогда в паспорт можно кроме юзера - дату писать, к примеру

Добавлено:

Цитата:

Кстати, "историк" к этому причастен!

и ещё - а это РЕАЛЬНО мешает? всё равно дата от касания историка меньше текущей

NothingAnother

Цитата:

Плагины - это здОрово, но как ты оцениваешь перспективу предложений?

Хранение заголовков в потоках NTFS мне не нравится, причины изложил forever.
Еще один аргумент: как переносить кэш с компа на комп, например, на флэшке?
Это не значит, что нужно отклонить идею в принципе, нужно просто поискать другой способ хранения.
Обсуждается пока в основном способ хранения. Хотелось бы больше услышать, что вы думаете по существу предложенной функции.

forever

Цитата:

А что мешает использовать не потоки а файлы - и всем будет счастье.

Мне не нужны лишние файлы в кэше.
И никто не мешает юзать одновременно и с файлами и с потоками. Кто что надо, тот и будет юзать (но только одно из них). И сделать конвертер между потоками файлов и файлом индекса.

DenZzz

Цитата:

Ты не прав! Допустим файла нет в кэше, начали его качать (получили заголовки) и выяснили, что "Content-Type: image...", - список "Не обновлять" продолжит закачку, а "Только из кэша" тормознет и отправит браузеру "404"! В этом их принципиальная разница!

Я прав. Список "Только из кэша" срабатывает до загрузки файла из Инета (т.е. до запроса файла из Инета), так что никакого "..тормознет и отправит браузеру.." не будет. После запроса файла из Инета срабатывают только два списка - "Запись в кэш" и "Преобразование URL".

Добавлено:
DenZzz

Цитата:

Зато индекс можно держать в памяти,

Ну и на фиг мне в памяти индекс сотен тысяч файлов? Это сколько же памяти такой индекс сожрет.

Добавлено:
mai62

Цитата:

Еще один аргумент: как переносить кэш с компа на комп, например, на флэшке?

Сделать конвертер из индексного файла в потоки NTFS и наоборот.

unreal666
Так все-таки, что именно по замыслу следует хранить в потоках/индексах? Для каких файлов хранить, для каких нет? И почему заголовки не поместить в сами файлы?

Цитата:

Так все-таки, что именно по замыслу следует хранить в потоках/индексах?

HTTP-заголовок Content-Type.

Цитата:

Для каких файлов хранить, для каких нет?

Для всех загруженных файлов.

Цитата:

И почему заголовки не поместить в сами файлы?

Куда?

unreal666

Цитата:

HTTP-заголовок Content-Type.

А в каких случаях имея сам этот файл в кэше нельзя будет определить тип его содержимого? Зачем что-то хранить если это можно определить по атрибутам/расширению/заголовку?

Цитата:

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

Когда расширение файла не совпадает с типом. На многих форумах картинки с этого же форума не имеют расширения.

Цитата:

Зачем что-то хранить если это можно определить по атрибутам/расширению/заголовку?

1. По атрибутам ничего не определишь.
2. Расширение не всегда соответствует типу, особенно при закачке файлов через антилич.
3. Какому заголовку?

unreal666

Цитата:

Какому заголовку?

НС распознает файлы картинок по сигнатуре

unreal666

Цитата:

1. По атрибутам ничего не определишь.

Content-Length если понадобится.


Цитата:

3. Какому заголовку?

Тому что mai62 называет сигнатурой (и наверное правильно). Я привык называть заголовком. Первые байты файла.

Цитата:

НС распознает файлы картинок по сигнатуре

И что он с этой инфой потом делает? Ведь в HC нет опции "Не обновлять картинки" или подобной.
Тем более файлы не ограничены только картинками. А как насчет флеш, файлов Java (.java, .class, .jar), шифрованных JavaScript и т.д. и т.п ?

Если бы можно было создавать свой собственный файл сигнатур и использовать эти сигнатуры в списках (например, с тем же правилом, начинающимся на *).
Т.е. например этот файл имеет конкретное имя и валяется в папке HC.
И прописывать в нем строки вида:
Тип Сигнатура Сдвиг (Offset) Описание

unreal666

Цитата:

И что он с этой инфой потом делает?

Генерирует заголовки, сопровождающие файлы из кэша

Добавлено:

Цитата:

А как насчет флеш, файлов Java (.java, .class, .jar), шифрованных JavaScript и т.д. и т.п ?

Про картинки я для примера написал. Конечно распознать все возможные форматы НС не сможет и иметь родные заголовки было бы неплохо. Только желательно без жертв

unreal666

Цитата:

не получится исполхзовать список "Запись в кэш". Это только для файлов, которые уже есть в кэше.

А что мешает изучить свежеполученный http-заголовок?


Цитата:

не все файлы имеют сигнатуры

Ну и поступать с ними по законам военного времени! В смысле обрабатывать только обычными правилами. Какие из т.с. "нужных" файлов не имеют сигнатур/ не поддаются идентификации?

forever

Цитата:

А что мешает изучить свежеполученный http-заголовок?

Ну запишу я по заголовку файлы в кэш. А как мне потом применять это для других списков. У меня ведь нет инфы какому типу файла какой заголовок соответствует по понятием HC. Да и все равно в HC нет сигнатур всех типов файлов.

Цитата:

Какие из т.с. "нужных" файлов не имеют сигнатур/ не поддаются идентификации?

Какие бывают "нужные" - не знаю. Но то, что для кого-то не нуные, дл другого моет быть нужным. Например iso-файлы. HTML и txt файлы не всегда можно отличить друг от друга (Content-Type у них разный).
Да и вообще постоянно пополнть базу сигнатур - это глюк.

mai62
Цитата:

Хранение заголовков в потоках NTFS мне не нравится, причины изложил forever

Весь пафос forever'a (в данном контексте only ) сводится к мышлению маргинального люмпена - "если у меня нет - пусть и у него не будет"

Цитата:

как переносить кэш с компа на комп, например, на флэшке?

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

P.S. А что насчёт head'еров?

unreal666

Цитата:

Список "Только из кэша" срабатывает до загрузки файла из Инета (т.е. до запроса файла из Инета)

Все существующие сейчас списки по URL можно проверять ДО загрузки файла из Инета, т.к. URL нам уже известен!

А "Заголовочный список" в большинстве случаев будет проверяться ПОСЛЕ начала загрузки, т.к. многих файлов (и их заголовков) до начала загрузки в кэше просто нет! Это справедливо почти для всех списков: "Черного", "Белого", "Запись в кэш" и "Только из кэша". Единственное исключение - список "Не обновлять" - тут достаточно проверить наличие файла в кэше и его заголовок!

Например, как в твоей интерпретации "Черный" список заблокирует файл "по типу", пока не начнет его качать?! Как "Только из кэша" узнает, что надо тормознуть закачку, пока не проверит тип файла?
Я приводил реальный пример: в кэше файла нет - начали качать (узнали заголовок) - выяснилось, что он входит в "Только из кэша" или "Черный список" - остановили закачку - послали браузеру "404".

Поэтому нельзя лепить твои правила для заголовков в общие списки для URL, т.к. они должны проверяться в разное время! Поэтому я и предлагаю проверять заголовки отдельным списком ПОСЛЕ проверки по URL и ПОСЛЕ начала закачки (получения заголовков)!

Кроме того, в существующих списках просто недостаточно полей для описания заголовочных правил! Как сгруппировать 2 заголовочных правила (например, надо заблокировать "картинки по типу" размером больше 200 кБ)?
Все эти проблемы можно решить вынесением заголовочных правил в отдельный список! Что я и предлагаю...

Добавлено:
rs

Цитата:

и ещё - а это РЕАЛЬНО мешает? всё равно дата от касания историка меньше текущей

Это НЕРЕАЛЬНО мешает! Я уже больше года чищу кэш от всякого старья вручную! Потому что по дате доступа HC удаляет 0 (ноль) файлов, т.к. дата доступа файлов постоянно обновляется!

Кто в этом виноват:
- "Историк" при наполнении истории по файлам кэша;
- Поиск в кэше по содержимому через TC, "Архивариус" и т.п.;
- Архиваторы;
- Антивирусы;
- Перенос кэша на другой диск;
- и т.д.

А я бы хотел автоматом удалять все старые сайты, на которые не заходил больше 6 месяцев, но сделать это сейчас не представляется возможным...

NothingAnother

Цитата:

Весь пафос forever'a (в данном контексте only )

В данном контексте only forever'а или only пафос?


Цитата:

сводится к мышлению маргинального люмпена - "если у меня нет - пусть и у него не будет"

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

Редко мое мнение совпадает со мнением forever в этом топике , но по вопросу использования NTFS-потоков я сразу высказался против, нарушив всеобщую эйфорию!
Зацикливаться на одной файловой системе - это зло!

Цитата:

Сделать конвертер из индексного файла в потоки NTFS и наоборот.

Это двойное зло , т.к. надо будет поддерживать 2 метода! Это даже KAV с сотней программистов не может себе позволить! А сколько багов будет и неразберихи...

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

по поводу потоков NTFS: в принципе едея неплоха, но все эти ограничения - не есть хорошо

forever

Цитата:

И почему заголовки не поместить в сами файлы?

это еще хуже - зачем бинарные файлы поганить (да и текстовые лишний раз править не желательно)

unreal666

Цитата:

И сделать конвертер между потоками файлов и файлом индекса.

иметь и то и другое, зачем? Может все-таки файлик (опционально отключаемый )?

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

Есть еще идея заюзать какую-нибудь бесплатную библиотеку примитивной базы данных. От нее требуется лишь:
- хранить объект со след. записями: URL, имя файла (относительно папки кеша), всякие заголовки
- выдавать объекты по урлу или имени файла
- быстро удалять/изменять объекты
- сохранять файл и освобождать память по нашему запросу
- распространеность, должны иметься альтернативные инструменты для редактирования такой базы

Еще вариант заюзать библиотеку типа "Nini" и реализовать все что надо через обычный "ini" или "reg" (файл реестра)

V0lt

Цитата:

зачем бинарные файлы поганить

Бинарники разумеется не имелись в виду.


Цитата:

да и текстовые лишний раз править не желательно

Они и так правятся. HTTP-заголовки и пишутся.