0000011: Добавить детектирование пустых тайлов во время закачки

Notes
(0000122) DJ VK (manager) 24-08-2010 06:37	Вот например спутник Yahoo. Версия 1.7 качается нормально. Но по краям обрастает тайлами 4768 байт - такого изображения нет. Удобно их отрезать. Нужно научить программу понимать 1)размер тайла 2) контрольную сумму или чтото позволяющее убедиться что тайл - заглушка. Ведь нормальное изображение тоже может иметь такую длину. Примечание Но версия карт 1.9 с абсолютно теми же снимками порой дает сбои и такие тайлы попадаются и внутри снимков. По хорошему такие тайлы надо не сохранять чтобы на карте заполнения все было видно. Вот как отличить эти два события? ведь в одном случае мы имеем дело с отсутствием тайла, а в другом - временную ошибку сервера, повторяющуюся или постоянно на одном тайле, или только через раз на соседнем тайле. Чтото похожее бывает при глючном (может шифрованном?) прокси - отклик тайл не существует приходит на существующие тайлы! Пользователю включать замену тайлов при загрузке? или не придется, tbe игнорируется? Или новый чекбокс будет?

(0000156) gpsMax (manager) 31-08-2010 14:24	на всякий случай, было обсуждение на форуме, про размер файлов и хэш. http://sasgis.org/forum/viewtopic.php?f=2&t=13&start=1540#p13959

(0000159) vdemidov (manager) 31-08-2010 14:54	Ну это я собственно на форуме и писал :)

(0000160) gpsMax (manager) 31-08-2010 15:04	Ну чтобы ссылку долго не искать, и не вспоминать, о чем речь :-)

(0000434) Parasite (administrator) 09-11-2010 04:51	>на всякий случай, было обсуждение на форуме, про размер файлов и хэш. А если на сервере страничку или темплейт 404х поменяют хотя бы на 1 символ (что случается чуть менее чем постоянно) - мы получим кучу хлама в кэш в виде "таки непустых тайлов, по мнению САСа". Уж лучше проверять принятое на попытку распаковки битмапа: если размер принятого битмапа равен размеру указанному в настройках (256\256 в большинстве случаев) - то это явно тайл. Если же это был 404й еррор от сервера (хтмл) - то, ясен пень, в битмап строго ожидаемого размера он не распакуется, проверку не пройдет и в кэш не попишется - даже если на сервере полностью весь дизайн страниц поменяют.

(0000439) vdemidov (manager) 09-11-2010 08:16	Ну речь не идет про html, речь про то, что некоторые сервисы возвращают пустой png правильного размера. Или например белый джепег с надписью тайла нет.

(0000441) Parasite (administrator) 09-11-2010 16:52	Может тогда по количеству уникальных цветов в тайле как-то вычислять их? Правда, тогда будут клюки на действительно монотонных тайлах (например гуглекарта+океан)...

(0000451) vdemidov (manager) 10-11-2010 07:14	Ну это уже позже. Для начала я хочу просто добавить механизм, который будет получать скачанные данные и говорить это пустой тайл или нет. Как он это будет делать сейчас не сильно важно. Для начала пусть размер и хеш проверяет, позже можно будет сделать более хитрые проверки вплоть до использования скриптов.

(0003670) zOn (reporter) 04-09-2011 11:16 edited on: 04-09-2011 11:18	может быть в zmp сервиса класть тайл-заглушку от конкретного сервиса и обзывать его 404.[ext]? тогда при закачке САС может сравнивать тайлы с этим 404 и принимать решение о сохранении в кэш. Но сервисы периодически меняют данную заглушку. Тогда можно просто ч/з контекстное меню скопировать его из окна САС в буфер (что бы не рыть кэш) и пересохранить в zmp. Это при минимальной доработке программы. В идеале добавить в пункт контекстного меню "Копировать..." подпункт "Заглушка" (программа сама скопирует и переименует тайл в нужное место. В чем смысл/удобство - пользователю не надо вычислять кол-во цветов, размер, хэш и т.д., а программа из образца может извлекать любые параметры.

(0003674) vasketsov (manager) 04-09-2011 12:31	>и обзывать его 404.[ext] а если таких заглушек одновременно может быть с десяток разных для конкретного сервиса? >пересохранить в zmp вроде как политика софта исходит из того, что в zmp программа ничего не пишет.

(0003675) zOn (reporter) 04-09-2011 12:45	>а если таких заглушек одновременно может быть с десяток разных для конкретного сервиса? тоже подумал об этом. 404_[n].[ext] - не? >вроде как политика софта исходит из того, что в zmp программа ничего не пишет. параметры то мы не трогаем.

(0003725) vdemidov (manager) 06-09-2011 10:28	>>вроде как политика софта исходит из того, что в zmp программа ничего не пишет. > параметры то мы не трогаем. Мы весь ZMP не трогаем из программы. Если пользователь правит его руками, то сам себе злобный буратино.

(0003726) zOn (reporter) 06-09-2011 10:30	ну можно не в zmp, а в отдельную папку [404] складывать картинки [name service]_404_[n].[ext]

(0003748) vasketsov (manager) 06-09-2011 17:24	>в отдельную папку А чего ж тогда не в папку с кэшем?

(0003751) zOn (reporter) 06-09-2011 17:37	можно и в папку с кэшем, только кэш может быть мобильным или в ТруКрипте.

(0003775) Tolik (manager) 07-09-2011 15:01	А есть ли алгоритм определения "пустых" файлов изображений, вообще, безотносительно карт? Я имею в виду: как детектировать картинку, все пиксели которой имеют одинаковый цвет/ прозрачность?

(0003776) zOn (reporter) 07-09-2011 15:12 edited on: 07-09-2011 15:17	сам же и ответил на свой вопрос - по количеству цветов=1 правда туда могут попасть и "белые пятна гуглкарт. но ведь такой тайл пустышку также можно кинуть в 404.

(0003777) Tolik (manager) 07-09-2011 15:18	Ну я хотел не на глаз :) Какая программа может это делать? И кстати, в jpeg, по-моему, всегда много цветов (RGB - 2^24).

(0003780) zOn (reporter) 07-09-2011 16:57 edited on: 07-09-2011 16:58	ХЗ. много программ может показать кол-во цветов. Я смотрел в FSviewer бесплатный. ты не путай палитру и реальное кол-во цветов.

(0003785) Parasite (administrator) 08-09-2011 05:23	>Ну я хотел не на глаз :) >Какая программа может это делать? Задача и проста, и сложна одновременно. :) Сложна тем, что _для машины_ нет никакой разницы - чистый это квадрат или заполненный в шахматном порядке, машина в любом случае оперирует понятием битмапа (массива пикселей), а уже то что в них содержится - то есть, "общекультурная" составляющая изображения - определяется уже человеком. Машины у нас еще не обладают ни интеллектом, ни чувством композиции, ни способностью "оценки необходимости" для данной конкретной задачи. Как уже сказали выше - пустой тайл может быть отсутствием изображения ВООБЩЕ (и тогда он не нужен) либо частью общего изображения там, где просто нету других обьектов попадающих в тот же тайл (и тогда этот тайл - нужен). Оценку этого со 100% точностью может дать только обладающий интеллектом и владеющий рамками "разброса необходимостей" в данной конкретной задаче - а для машины эти тайлы (как массив точек) таки идентичны. Задача же проста тем, что _просто_ пустой тайл от _просто_ заполненного отличается элементарно: 1. Если в тайле используется индексный цвет (GIF, PNG итд) - то по кол-ву заюзанных цветов, в чистом пустом тайле будет ровно 1 индекс цвета (чем и годны - занимать при этом они будут вот буквально неск.байт, и без артефактов даже при стократтном увеличении). 2. В форматах использующих "обычные" цвета - задается базовый цвет "чистого" тайла И девиации цвета в обе стороны от него. Например 255.255.255 как базовый и 250.250.255 как возможные девиации на артефакты сжатия, косяки цветокодирования и проч. Все тайлы с содержимым полностью (или на заданный процент) попадающим в мЕньшую часть от условия - считаются чистыми, все которые в большую - считаются заполненными. При этом вычисляется даже один пиксель на тайле, так как его содержимое (например 0.0.0 для черной точки) уже однозначно "выкидывает" тайл с указанными выше параметрами из разряда чистых. При этом метод таки подвержен ложным срабатываниям - не потому что метод плохой, а потому что косяков и артефактов в жпеге может быть выше заданного порога девиации - и тогда визуально-чистые тайлы будут помечаться как заполненные. Почему? А на стыке тайлов например артефакт появился, и его цвет стал на 1% отличаться от общей массы остальных тайлов. Выход - либо опускать порог девиации (но тогда можно нарваться на прямо противоположный эффект - змалозаполненные тайлы будут помечаться как "чистые"), либо более точно описывать порог - и даже несколько их (а это гимор программеру, и усложнение\замедление алгоритма анализа содержимого ровно на число проверок на пороговые значения). Канонiчно делают так: изображение переводят из JPEG в LAB (получают монохромные LAB-слои), для к.LAB-слоя делают проверку по порогу для данного цветового слоя, на выходе - результаты проверок слоев суммируют по "общему пороговому для всей картинки" и на основании его делают вывод о заполнении. Это можно делать (и широко применяется) даже ручками в фотошопе - например в LABе на ура вычисляются следы правок и ретуши исходного цифроизображения, итд. :)

(0003786) zOn (reporter) 08-09-2011 05:30	Parasite >изображение переводят из JPEG в LAB вы таки правда думаете, что отцы-писатели будут это писать? я конечно только за, НО - сколько на это потребуется "машино-часов". чистые тайлы - не беда, даже если они проскочат, т.к. на их месте всё равно ничего нет. основная задача не пустить в кэш "затычки", которые займут место нормальных тайлов с контентом.

(0003788) Parasite (administrator) 08-09-2011 05:56	>вы таки правда думаете, что отцы-писатели будут это писать? Я ничего не думаю - я отвечаю на заданный предыдущим оратором черным по белому вопрос. А перевод из одного цвет.режима в другой цвет.режим - банальнейшая операция, при наличии годной документации (особенно если их при этом никуда выводить не нужно, и не добиваться визуального сходства при конверсии RGB\CMYK например, как в смежных задачах). В фотошопе например - один клик (Image->Mode->Lab colors). Весь алгоритм занимает намного меньше "человеко\часов" чем Вы считаете. :) Да и готовые однозначно есть скорее всего - задача из разряда "написать Hello_word на время", только на тему анализа массивов данных. Я ее сам когда-то кодил в свое время в дремучем прошлом веке в виде лабораторной работы по AI. На голом ASMе. То ли 3, то ли 5 страниц получилось (абсолютно без готовых внешних модулей, исключая готовый JPEG-декодер - накоденный предыдущим деятелем уже на его лабораторной работе)...:)

(0003795) Snake (reporter) 08-09-2011 08:28	можно свои пять копеек? А если в программу добавить функцию обучения? Например появился такой "тайл-затычка", правой кнопкой на него и пометить "тайл-затычка", в дальнейшем вычисляется например хеш и сохраняется в SASPlanet.ini или в отдельный файл типа карта такая-то хеш такой. ну или типа того.

(0003801) gpsMax (manager) 08-09-2011 17:37	И чего, каждый будет придумывать свои затычки? Не, это надо централизованно делать. Или, как минимум, тогда отсылать разработчикам.

(0003804) zOn (reporter) 08-09-2011 17:56	Макс, на общий функционал не влияет - пусть делают. Еще авторам думать пользователей, как им надо со своим кэшем обращаться? Дадут инструмент, а уж пользователи сами будут решать какие тайлы банить. В конце концов, никаких деструктивных последствий от лишней затычки не предвидется. Её легко удалить.

(0003808) gpsMax (manager) 09-09-2011 04:32	Я к тому, что это решение предполагает множественное изобретение велосипедов пользователями. Было бы куда лучше, если бы первые из них могли отправить свои находки разработчикам, которые бы растиражировали эти настройки на всех.

(0003812) zOn (reporter) 09-09-2011 05:13	Макс, зачем разработчикам это? в программе сотня ресурсов, все пользуются разными. ведь самому не сложно прям из окна программы отправить заглушку в фильтр.

(0003820) vasketsov (manager) 09-09-2011 11:00 edited on: 09-09-2011 11:02	>если бы первые из них могли отправить свои находки разработчикам, которые бы растиражировали эти настройки на всех Ну так что может быть проще? Идея кидать затычки в папку с кэшем сама просится. В архиве с программой же есть кусок кэша с первыми зумами. А "отправлять" можно и на форум (в соответствующую тему или в общую), как сейчас инфу о новых картах, которые потом в "плюсовой" попадают. >ведь самому не сложно прям из окна программы отправить заглушку в фильтр Её сперва найти надо. А так конечно и zmp самому несложно забацать.

(0003821) zOn (reporter) 09-09-2011 11:09	>Её сперва найти надо. А так конечно и zmp самому несложно забацать. а чего её искать? вот она на экране - глаза мозолит. http://sasgis.org/mantis/view.php?id=11#c3670

(0008675) Dima2000 (developer) 04-09-2012 07:14	Недавно (?) яндекс стал отдавать гибрид с пустышкой не отсутствием тайла, а прозрачным тайлом (размером обычно 334 байта). Т.к. BanIfLen давно убили, то кэш засирается этими прозрачными тайлами миллионами. Что неприятно, бывают и нормальные тайлы с надписями того же размера. Т.е. просто удалить тайлы заданного размера во первых весьма геморно, во вторых опасно. Заинтересовался этим вопросом и сварганил быстренько построение гистограммы распределения тайлов по размерам. Оказалось для всех моих карт пустышки сильно лидируют в штуках (обычно их больше на два-три порядка!). Но, бывают и нормальные тайлы того же размера. Потому предложение. В папочку в zmp класть образцы тайлов, которые прибивать при скачке. Обычно таких наберётся всего несколько штук, места много не займут. И обновить список сможет сам пользователь, хоть из САС-а, хоть из проводника. Количество образцов опрашивать при загрузке zmp при старте. Проверять скачанный тайл на точное равенство образцу (с проверкой образцов лишь того же размера). А для упрощения предлагаю так же добавить в param.txt тег типа IgnorebyCRC32=, в котором перечислять или пары (размер,crc) или лишь crc. Кто умеет считать crc тот сможет и сам добавить игнорируемые тайлы без сохранения образца. Разумеется crc проверить первой, а потом уже образцы. Показ соответствующей CRC32 для тайла под мышой можно добавить и в меню по правой кнопке мыши в дополнительные операции. Решение не идеальное, но относительно простое и достаточно эффективное.

(0008678) Parasite (administrator) 04-09-2012 07:40 edited on: 04-09-2012 07:48	Так и что же мешает иметь это на своей стороне (ВНЕ саса), в виде одного скрипта и набора файликов для прибития в папочке? Запускать хоть по расписанию, хоть по выходу с САСа, хоть как угодно еще: ------------- #!/bin/perl use File::Basename; use Digest::MD5; require "settings.txt"; my $baddir=$folder_bad; #bad_dir my $dir=$folder_to_cleanup; #откуда пойдем плясать my $deleteflag=$deleteflag_config; #удалять или только рапортовать &recur_init($baddir); print "-------------------------------------------------------------------------------\n"; print "Всего найдено ".($i/2)." плохих образцов.\n"; $nulled=0; $size=0; $size_hash=0; &recur($dir); print "-------------------------------------------------------------------------------\n"; print "Нулевых тайлов : ".$nulled."\n"; print "Совпадений размеров : ".$size."\n"; print "Совпадений размеров И хэшей: ".$size_hash."\n"; exit; sub recur_init{ my $dir = shift; opendir DIR, $dir or return; my @contents = map "$dir/$_", sort grep !/^\.\.?$/, readdir DIR; closedir DIR; $i=0; @bad_array = (); foreach (@contents){ if (!-l && -d){ recur_init($_); } else{ $name=basename($_); print "".(($i/2)+1).". Найден плохой тайл \"".$name."\"\n"; $blob=blob($_); $tilesize=length($blob); $ctx = Digest::MD5->new; $ctx->add($blob); my $tilehash = $ctx->hexdigest; print " \|-length = ".$tilesize." байт\n"; print " \|-hash = ".$tilehash."\n"; print "\n"; push @bad_array,$tilesize;push @bad_array,$tilehash; $i=$i+2; } } } sub recur{ my $dir = shift; opendir DIR, $dir or return; my @contents = map "$dir/$_", sort grep !/^\.\.?$/, readdir DIR; closedir DIR; foreach (@contents){ if (!-l && -d){ recur($_); } else{ print $_."\n"; my $tilesize=(-s($_)); if ($tilesize==0) { #тайл нулевой длины if ($deleteflag == 1) { $file=$_; $file=~tr/\//\\/; unlink ("$file") \|\| warn "Cannot delete file $file:", $!; print "Тайл ".($_)." удален (длина 0 байт).\n"; } $nulled++; } else { for ($ii=0;$ii<$i;$ii=$ii+2) { if ($tilesize == $bad_array[$ii]) { $size++; #считаем хэш $blob=blob($_); $ctx = Digest::MD5->new; $ctx->add($blob); my $tilehash = $ctx->hexdigest; if ($tilehash eq $bad_array[$ii+1]) { print "Тайл нашего размера и нашего хэша.\n"; if ($deleteflag == 1) { $file=$_; $file=~tr/\//\\/; print $file."\n"; unlink ("$file") \|\| warn "Cannot delete file $file:", $!; print "Тайл ".$file." удален (длина И хэш совпали).\n"; } $size_hash++; } } } } } } } sub blob { open (BLOB, "<", shift) or die "Can't open file!"; my $data; my $blob; binmode BLOB; while (!eof(BLOB)) { read(BLOB,$data,8); $blob .= $data; }; close BLOB; return $blob; } ------------- 1. Сканируем рекурсией папку с плохими тайлами, собираем массив длина\хэш 2. Сканируем рекурсией папку с кэшем на предмет равенства каждого тайла со значениями длины в массиве: 2а. Тайлы с длиной 0 байт - однозначно плохие и без проверки. 2б. Если найдено равенство длины проверяемого тайа с массивом - проверяем равенство хэшей только для этого тайла (для разгрузки процессора) 2в. Если размер и хэш совпали - то либо отлинковываем тайл от ФС, либо только рапортуем о числе таковых (согласно конфига скрипта). 3. Для детектирования новых кривых тайлов достаточно просто положить его пример в папочку для кривых тайлов. У меня это висит в кроне и запускается каждую ночь. Никаких плохих\пустых\нулевых тайлов нет и в помине.

(0008679) Dima2000 (developer) 04-09-2012 07:44 edited on: 04-09-2012 07:48	Ничего не мешает. Удалялку я себе тоже написал, не проблема. Но зачем снаружи, если удобнее встроить в саму Планету? Ведь она занимается закачкой тайлов и проверкой сохранять ли их в кэш (по дате или равенству существующему). И меньше дисковых операций будет, что весьма полезно. А ещё чем удобен список хешей в zmp - можно распространять сразу же с дистрибутивом Планеты.

(0008680) Parasite (administrator) 04-09-2012 08:02	>Но зачем снаружи, если удобнее встроить в саму Планету? Затем, что если нужно именно чистить кэш (как задачу к выполнению) а не ждать введения фичи в САС (как идею) - то это можно делать уже сегодня и при этом гораздо эффективнее чем САСом (например, выделение памяти под вышеизложенное - минимально, в отличие от ГУЕвого саса со всеми его библиотеками паровозом. САСа пока не заставить это делать по расписанию, а скрипту сам Аллах завещал жить в планировщике, итд. Ну а про возможности кастомизации всего процесса я и вообще молчу). И, до кучи - качать в кэш САСа можно тоже без САСа, по той же причине. Как по мне, так САС нужен именно для работы (глазками\ручками) с наработанным кэшем, а все системные операции лучше и эффективнее делать из оси и более заточенными для этого системными инструментами - коль скоро для оси это просто куча файлов. Имхо. Вон зед для беркли тоже совершенно отдельную самостоятельную standalone утилитку сделал именно по этой же причине скорее всего.

(0008681) Dima2000 (developer) 04-09-2012 08:24 edited on: 04-09-2012 08:25	Задача вовсе не чистить кэш, это лишь следствие недостатков Планеты, а не допускать его засорения. Что как раз дело именно Планеты. Или закачиваете тайлы в кэш вы тоже отдельными утилитами? Ну, это дело ваше. А по мне Планеты нужна и для закачки в кэш. Напомню известное высказывание "чисто не там где убирают, а там не мусорят". Т.е. сначала намусорить в кэш Планетой, а потом убрать за собой отдельной утилитой - вариант конечно вполне рабочий, но кривой. И самый эффективный способ - не чистить кэш после засирания, а не допускать записи в него мусора.

(0008682) Parasite (administrator) 04-09-2012 08:49 edited on: 04-09-2012 08:51	>а не допускать его засорения. Что как раз дело именно Планеты. У каждого свои представления о мусоре, на минуточку. Вот например мне - пустые\однотонные тайлы нужны (коль скоро они пришли с сервера), и стирать их я не собираюсь, а если кто-то будет это делать за меня (типа как "стирание" доступных снимков DG в соседнем тикете вона) - то буду давать по рукам, если дотянусь. Просто как пример. >Или закачиваете тайлы в кэш вы тоже отдельными утилитами? В 90% случаев - да. Не вижу никакого смысла таскать по системе гуевое приложение там, где всё прекрасно обходится и без него. Благо те же 90% картосервисов - отнюдь не оригинальны, и качаются практически одним и тем же алгоритмом с минимальными доработками. Помножить это всё на 30-40 копий этогоприложения, ибо качаю много и далеко не в 1 поток. В оставшихся 10% (когда неохота писать своё) - то САСом, причем весьма и весьма ранних версий (оно стабильнее при долгой работе, а все новые фичи "просто-качалке" не нужны и даже вредны). 090228 прекрасно живет без перезапуска второй год и качает весьма втяжелую, а ночнушка месячной давности не прожила этого месяца - скрешилась, ГУЙ стал пустым и без единой надписи, хотя карта под курсором ездила как обычно... >а не допускать записи в него мусора. Для меня, повторяю, мусор - это всё то, что НЕ пришло с сервера (типа нулевых тайлов). То, что пришло с сервера - уже контент, и только я желаю решать о степени нужности оного для меня любимого. PS: я не против того, что САС будет чистить свой кэш - я просто призываю помнить, что сколько качальщиков - столько и мнений, так что фиксированный вариант (типа "тайлы в ЗМП") - заведомо тупиковый, и в итоге куча народа будет лазить туда и убирать эту фичу сомнительного достоинства. И я буду первым. Так уже было с BanIfLen, когда оно блокировало загрузку нормальных тайлов того же размера - а бан при этом не обходило... А вот было бы очень приятно, если бы был пункт в меню САСа "Показать мне папку с примерами тайлов - и я сотру с кэша любые 100% дубликаты". Это да, это полезно. Наполнение папки и все ответственности за это деяние будут лежать целиком на хомяке, а не на авторе того ЗМП.

(0008683) Dima2000 (developer) 04-09-2012 09:13	Я тоже повторюсь, у всех предпочтения разные. Я вот качаю Планетой. И мне не нравится что она записывает в кэш пустые тайлы (и не нулевого размера). И хочется не операции чистки кэша, а именно не записывать в него ненужную (лично мне) информацию. Ибо запись плюс последующее удаление напрягает диск и вообще не комильфо. А теперь давайте вспомним не о нас, а об остальных пользователях, которые запускают Планету "из коробки" и пользуются ей, а не своими личными прибамбасами для закачки. И кто не хочет заморачиваться самостоятельным обучением Планеты определять пустышки. Зачем им пустышки в кэше? Ну если кому и надо, то я же не предлагал всегда и насильно удалять, а лишь настройку в zmp. Ибо считаю что в zmp этому самое место. А кому нужно всё с сервера - закомментируют тег в param.txt и сотрут/переименуют папочку образцов. Всё. BanIfLen ошибалось, потому и вредно и убирали. А тут ошибок быть не должно (сравнение ведь точное). >пункт в меню САСа "Показать мне папку с примерами тайлов - и я сотру с кэша любые 100% дубликаты" это совершенно другой вопрос, как раз к сторонней утилите на уровне файлов. И мне такое не нужно, тем более со всего кэша, а не по выделению. В общем, не обязательно в zmp, но хоть что-то сделайте же наконец!!!! В Планете, а не отдельно.

(0008684) Parasite (administrator) 04-09-2012 09:52	>об остальных пользователях, которые запускают Планету "из коробки" и пользуются ей САС (как и 95% любого опенсорца) на наст.время довольно далек от концепции "продукт в коробке". Чтобы полноценно юзать его - нужно обладать сведениями о матчасти несколько выше среднего. И общее развитие в сторону нужности фич разработчику, а не имиджу "продукта в коробке" - это только усиливает. Так что предлагаю не думать об остальных пользователях, коль скоро их тут в теме не видно и за себя они совершенно не говорят (ровно по той же причине - багтрекер это тоже не "коробка"). Скорей всего, их устраивает и так, как есть. >А кому нужно всё с сервера - закомментируют тег в param.txt В ответ я могу лишь предложить стереть ненужное тем, кому что-то не нужно. Ибо в "продукте из коробки" никто не будет редактировать ZMP даже если об этом будет написано на каждом углу, поверьте. Примеры - на форуме, ежедневно. И перебдеть и дать всё по умолчанию - всё еще лучше, чем недобдеть и стереть нужное. Просто потому, что стереть имеющееся никогда не поздно - а вот восстановить случайно стертое может быть и ой, и лучше бы чтобы ответственность за это была на криворуком хомяке а не на программе. >А тут ошибок быть не должно (сравнение ведь точное). Вопрос не в точности сравнения, а в неопределенности базы для оного. Даже среди нас обоих двух - уже разногласия, что считать мусором а что - нет. :) >тем более со всего кэша, а не по выделению. Это детали. Можно и по выделению, и с выбором конкретной карты...я лишь дал понять за общую идею. >но хоть что-то сделайте же наконец!!!! В Планете, а не отдельно. Ну, этому тикету уже более 2х лет некоторым образом. :)

(0008685) Dima2000 (developer) 04-09-2012 10:07	Ок, забудем про пользователей. Вам не нужно пропуск пустышек в самом САС-е при скачке? А мне нужно. Если сделать, то будет выбор, пользоваться или нет. Сейчас нет ни выбора, ни возможности. Я даже готов по умолчанию отключенной чтобы это было, кому надо разберутся и включат. Что, надо только мне? Т.е. и делать значит мне? Понятно, спасибо за внимание.

(0008686) Parasite (administrator) 04-09-2012 10:24 edited on: 04-09-2012 10:27	>Вам не нужно пропуск пустышек в самом САС-е при скачке? Для меня пустышка - файл нулевой длины. Пропуск таких - мне нужен. И САС вроде уже давно такое в кэш не кидает, слава Аллаху (а раньше - бывало, да. Года 4 назад). Никаких других автоматических и не установленных мною лично пропусков лично мне - не нужно, и даже вредно. И за все эти годы лично у меня не было ни единого случая, когда мне вдруг понадобился бы такой отдельный пропуск именно в сасе. >Что, надо только мне? Т.е. и делать значит мне? Понятно, спасибо за внимание. Вы немножечко не так поняли. Я - не программер САСа, ни одного байта в сорцы собственно программы не внёс (ну разве что в виде уже моих хотелок, реализованных другими), и я тут только и исключительно для обсуждения вопроса. И коль скоро нужное делается быстрее и более эффективнее со стороны, чем с САСа - то имею мнение, что данная доработка не то чтобы не нужна, а просто малоприоритетна даже в виде "Показать сасу папочку - и пускай он чистит". Но это только мое локальное мнение, равное Вашему по силе. Я его не диктую, а просто высказываю вслух.

(0008703) vasketsov (manager) 05-09-2012 07:43 edited on: 05-09-2012 07:57	>Что, надо только мне? Не только. Та же беда с panoramio например или wiki - отдаётся пустой KML (KMZ), который не нужен, который программа пытается открыть и показать при показе слоя. Так что это совершенно нормальное желание. Да и хранить кучу пустых KML (а их количество на больших зумах будет преобладать) совершенно неразумное занятие, хоть это файловый кэш, хоть не файловый. >В папочку в zmp класть образцы тайлов, которые прибивать при скачке Не взлетит. В этом случае концептуально исключается такая операция по ПКМ, как "а вот этот тайл пожалуйста больше не хочу видеть". Потому как zmp неприкосновенен. Ну и в принципе zmp ради этого ковырять некошерно, с него куча юзеров кормятся, пожалейте авторов публикуемых zmp. Место таким тайлам - прямо вот в самом кэше, где-то в простом легкодоступном (в том числе из простых сторонних файловых утилит и батников) укромном местечке.

(0008704) vdemidov (manager) 05-09-2012 08:32	В самом кэше таким тайлам тем более некошерно лежать. Они явно относятся к конкретной карте, а не кэшу (например сменили тип кэша для карты и что, вся инфа о пустых тайлах потерялась?). Этой информации самое место в Zmp и файле Maps.ini как ее туда запихивать это уже другой вопрос.

(0008706) Dima2000 (developer) 05-09-2012 14:00	Ага, если не в zmp, то в maps.ini. Или и там и там. >концептуально исключается такая операция по ПКМ, как "а вот этот тайл пожалуйста больше не хочу видеть". Не исключается: можно по ПКМ хэш/crc файла записывать в maps.ini (раз zmp трогать нельзя), он имеет приоритет перед zmp. Хотя тоже не очень кошерно, при обновлении программы рекомендуют maps.ini стирать ...

(0008707) Parasite (administrator) 05-09-2012 14:20	Господа, а почему вам настойчиво не нравится решение "Показать САСу папку с плохими тайлами - и он вычистит свой кэш"? Как по мне, так это самое гуманное и наименее больное решение для всех (к тому же зависящее целиком от выборов\решений хомяка, а не [дефолтной] логики программы).

(0008708) vdemidov (manager) 05-09-2012 14:26	ИМХО, луше не мусорить, чем потом чистить кэш.

(0008709) Parasite (administrator) 05-09-2012 14:29	>ИМХО, луше не мусорить, чем потом чистить кэш. Верно, но понятия мусора - у каждого свои. А программа - одна для всех.

(0008710) vdemidov (manager) 05-09-2012 14:34	Ну а поскольку пишу ее я, то и понятия будут в ней использоваться мои :)

(0008711) Parasite (administrator) 05-09-2012 14:44	Ога. А непонятки на форуме по типу "Пащиму у меня океаны не грузятсо???" разруливать - мне. :)

(0008712) zOn (reporter) 05-09-2012 14:47	а что бы небыло непоняток можно выводить надпись на тайле: "Отфильтровано САС.Планет!" и сразу станет ясно почему не грузит.

(0008713) bk99 (reporter) 05-09-2012 15:27	Сделать: - отдельную папку с образцами "плохих" тайлов; - в настройках Планеты - вкладку с чекбоксами (по умолчанию unchecked) "Не загружать/фильтровать тайлы вида ...", на каждый вид "плохого" тайла отдельный чекбокс (по количеству категорий "плохих" тайлов). Хочешь - удаляй всю папку (тогда соответствующая вкладка будет пустой, а можно вкладку в этом случае вообще не отображать). Хочешь - не удаляй папку, а просто отметь соответствующие чекбоксы, и всё, что для тебя лишнее, будет фильтроваться. Спасибо за внимание!

(0008715) Dima2000 (developer) 05-09-2012 16:25	Не-не-не! Никаких десятков чекбоксов для сотен карт! Папку (как и файлы в ней) можно и не удалять, а переименовывать, она и перестанет срабатывать. Это если кому временно не надо. >Верно, но понятия мусора - у каждого свои. А программа - одна для всех. Вот потому и надо дать настраивать поведение, т.е. указывать какие именно тайлы считать мусором и отфильтровывать. И не в исходном коде, а в инишках и/или папках с образцами. Кому важны прозрачные тайлы - не будут их фильтровать и всё.

(0008716) vasketsov (manager) 05-09-2012 18:26	>Они явно относятся к конкретной карте, а не кэшу Покуда кэш относится к карте - это одно#уйственно ))) Вот гляди. В разных версиях тайлов с одного сервиса могут быть разные пустышки. Прецеденты уже были: голубизна на kosmosnimki была сначала одна одинаковая, а потом стала разная другая. Оно конечно может и можно было бы сделать про добавлением новых пустышек, но в новой версии тайлов формально старый размер уже не соответствует пустышкам. Вывод - на сервисе при смене версии могут меняться пустышки. А zmp неверсионен, там только хранится значение версии, но не параметры в разрезе версий. Зато версионен кэш. Более того - см. ниже после ). >сменили тип кэша для карты и что, вся инфа о пустых тайлах потерялась? Если тип кэша меняется с (условно) z10\x11\y12 на z10\y12\x11 - ничего не потеряется (если скажем в корне кэша будет папка emptytiles и в ней нагажено). Если тип кэша меняетс с файлового на экзотический невайловый типа СУБД или вообще хз какой - ну так и скачанные тайлы "потеряются", это исключительно вопрос миграции кэша между типами. >самое место в Zmp Разве что как референсный источник для конкретной версии карты, указанной в Zmp. ) А теперь страшная военная тайна: фильтарция пустышек возможна минимум на двух уровнях. Основной смысл процедуры - экономия места. На уровне закачки можно проверять contenttype, размер, хэши и т.п. - и вообще не помещать пустышки в кэш, будто бы ответ 404. Пустые KML сами просятся под нож, а вот с картинками всё сложнее. Но есть и второй вариант - условно его можно назвать архивацией кэша, и вообще говоря он может быть реализован вот хоть прямо сейчас исключительно в рамках самого хранилища. Суть в том, что при сохранении в хранилище пустышки (одной из перечня установленных пустышек) будет сохраняться некая метка (как с tne, но не tne). При последующем запросе этого тайла само хранилище будет разыменовывать эту метку в оригинальную пустышку. Реализуется это хоть даже автоматически исходя из гистограммы, или исходя из настроек в виде перечня пустышек или их размеров - но совершенно прозрачно для программы и юзера, даже Paraiste будет думать, что у него хранится оригинальный синий морской тайл 100500 раз, а не один единственный раз в списке "пустышек" (при этом "пустышки" могут быть как реальным ненужным мусором, так и просто неким крайне часто встречающимся тайлом). При этом на уровне хранилища формально поиск и проверка соответствия тайла "пустышке" может выполняться возможно быстрее и проще, и вообще алгоритмы могут быть совершенно разными. В этом смысле крайне разумно иметь все данные для работы хранилища непосредственно в самом хранилище. А первый вариант с резкой "пустышек" до хранилища чтобы использовал эти же данные. С возможностью переключения пользователем вида резки "пустышек" в любой момент исходя из конкретной карты, наличия места и т.п. Но это конечно во многом фантазии. Основная же логика такова: пустышки - это тайлы, тайлы - версионные, значит и пустышки обязаны поддерживать версионность, а значит они могут быть только в версионной сущности (кэш или любая другая), а не в неверсионном zmp (в котором данные относятся только к той версии, которая в нём указана, пусть даже из него будут взяты пустышки для этой версии).

(0008718) vdemidov (manager) 05-09-2012 19:17	Именно в этой хотелке я подразумеваю именно фильтрацию на уровне закачки и возврат ответа как если бы был 404 код. Все остальное в данном топике флуд. И место этим настройкам имено в параметрах конкретной карты. Тайлохранилище вообще не в курсе закачки и тд. Соответственно настройкам фильтрации там не место. Все.

(0008719) vasketsov (manager) 05-09-2012 19:24	>подразумеваю именно фильтрацию на уровне закачки Как предполагаешь реализовывать зависимость пустышек от Version в zmp?

(0008722) vdemidov (manager) 06-09-2012 03:52	А зачем эта зависимость вообще нужна?

(0008723) Parasite (administrator) 06-09-2012 03:53 edited on: 06-09-2012 03:56	>указывать какие именно тайлы считать мусором и отфильтровывать. И не в исходном коде, а в инишках и/или папках с образцами. Ну дак я же именно это и предлагал. Отдельную папку для отстойника, куда САМ ХОМЯК будет класть небогоугодные ему тайлы. И по умолчанию (при дистрибуции саса) папка должна быть чистой, т.е. никакой дефолтной фильтрации не. >даже Paraiste будет думать, что у него хранится оригинальный синий морской тайл 100500 раз, а не один единственный раз в списке "пустышек" Так Parasite уж 4й год подменяет нужные ему тайлы с точным совпадением по MD5 - на хардлинк на единственную пустышку в той самой папке небогоугодных. Причем разных пустышек (и не только) может быть много, все - в одной папке, и соответственно будет туча разных хардлинков вместо тучи тайлов. И это работает на какой угодно тип контента - с КМЛом ровно та же история, к примеру...Особенно годно это получается в базоводе, да. Для Беркли - самое то. А вот на FAT и прочие флешки ЭТО лучше не переносить - кэш потом будет чуть более чем дырявый.... :) >Как предполагаешь реализовывать зависимость пустышек от Version в zmp? Помещением этой новой но другой пустышки в кучку к сотоварищам прошлых версий, и разовым пробеганием сабжем по уже новому кэшу (если он к тому моменту уже наработан). Не нужно трогать ZMP, имхо - там хомяко-зависимым сущностям типа "а я вот не считаю, что это мусор!" не место.

(0008724) Dima2000 (developer) 06-09-2012 04:46	>я подразумеваю именно фильтрацию на уровне закачки и возврат ответа как если бы был 404 код. Я полностью согласен с вдемидовым. Если под пустышкой понимать тайл с отсутствующей информацией о карте/слою (прозрачный или заполненный логотипом), то такой тайл от версии очевидно не зависит, прозрачность она в любой версии прозрачность. И можно их смело фильтровать невзирая на версии (и даже невзирая на карту/слой! но это возможно перебор, не настаиваю). >в новой версии тайлов формально старый размер уже не соответствует пустышкам. Пустышки проверяются не только по размерам (как похоже было с BanIfLen), но и по хэшу (crc32 или md5, не суть) или даже по точному бинарному совпадению файлов. Потому на несовпадение размеров - пофиг, лишнего не отфильтруется. >Так Parasite уж 4й год подменяет нужные ему тайлы с точным совпадением по MD5 - на хардлинк на единственную пустышку в той самой папке небогоугодных. Я тоже так хочу! Покажите что в SASPlanet.ini надо добавить чтобы Планета стала так делать? И плевать на глюки с переносом кэша в другое место или на FAT. Но вот отдельной приблудой - не интересует! >Не нужно трогать ZMP, имхо Если не класть это в zmp, то в отдельную папочку в корне Планеты с там же ini файликом с описанием какой файл к какой карте (по GUID) относится. И считывать этот ini при загрузке zmp-ек (при старте). Вместо пути к файлу в ini может быть лишь хэш файла (с размером) - для ускорения операций, ну вот не хочу всегда хранить образцы, мне проще несколько символов хэша в текст добавить. При желании добавление (с проверкой дублей) туда тайлов можно организовать и по ПКМ. Ещё при желании убивание из всего кэша (или лишь выделенной области) пустышек можно добавить в закладку "Операции с выделенной областью - Удалить", там этому самое место. Это и будет та самая операция "чистки кэша", на которой кто-то там так настаивает. Но это не отменяет реализации вышеприведённой фильтрации при получении файла с сервера!

(0008727) Parasite (administrator) 06-09-2012 05:43	>Пустышки проверяются не только по размерам (как похоже было с BanIfLen), но и по хэшу (crc32 или md5, не суть) или даже по точному бинарному совпадению файлов. Потому на несовпадение размеров - пофиг, лишнего не отфильтруется. Совпадение хэща при несовпадении размера называется коллизией, они таки вероятны с гарантией стремящейся к 100% при числе уникальных тайлов стремящемся к числу разрядности хэша - и лучше бы этого не было.... Для отхода от этого можно делать два разнородных хэша (например "тяжелый" MD5 и "быстрый" CRC32), и проверять схождение обоих одновременно. Это исключит коллизию какого-то одного из этой пары. C другой стороны - хэшировать, да еще и дважды, и проверять каждый пришедший тайл - таки CPU-intensive operation. На быстром коннекте или массовой закачке - будем тормозить-ссс.....Как правило, при скачке САСом еще и чего-то делают, по карте ездят итд... Поэтому я и предлагал делать чистку кэша посторонней тулзой на уже готовой куче кэша (и пускай она тормозит как угодно), а не САСом в пределах его работы. Он и так в последнее время зело задумчивый и неторопливый по сравнению с первыми версиями, там вот еще только доп.тормозов и не хватало... >Покажите что в SASPlanet.ini надо добавить чтобы Планета стала так делать? Это на данном этапе развития САСа надо добавлять не в SASPlanet.ini, а в hands.pl например. :) >И плевать на глюки с переносом кэша в другое место или на FAT. Это будут не глюки, а отсутствие поддержки хард\софтлинков файловой системой FAT (а как правило на флешках - именно она). То есть, все эти связи на единственный тайл будут проскипаны, и вместо тайла будет дырка и пустое место. При перезаписи на ФС, умеющую линкование - этого глюка не будет. Это не проблема САСа и не проблема кэша, это проблема файловой системы. И это лечится, например, все той же сторонней тулзой которая делает экспорт - туда вводится фича "Follow FS links", и она вместо каждой встреченной линки начинает писать реальный тайл, на который та линка ссылается. Кэш при этом, разумеется, распухнет ровно на число этих прописанных одинаковых тайлов-пустышек. >с описанием какой файл к какой карте (по GUID) относится Зачем? Пустышка, найденная по хэшу - она и в Африке пустышка, и на другой карте будет той же самой пустышкой. Или Вы считаете, что на другой карте на тайле с тем же хэшем что и у пустышки - внезапно появится изображение Нью-Васюков? :)

(0008728) vasketsov (manager) 06-09-2012 08:35	>зачем эта зависимость вообще нужна? Я так понимаю, это становится нормой нечетатьъ, где букв чуть больше чем хочется, и главное быстрее обвинить оппонента в троллинге, и повторять это раз за разом? Ну мы так далеко уедем, чо. Будет как с тайлами. И зачем поддержка версий тайлов, наверняка думалось кому-то изначально. Пример был приведён. Было изменение на космоснимки.ру, что была одна "пустышка", стало множество других "пустышек", меняется это при смене их API. Так что прецедент уже есть. Тем более что логика совершенно стандартная, равно как и для тайлов: запрошена версия и нет запрошенной версии - берём предыдущую известную, и т.п., ничего не взялось - берём без версии (если версия не указана - начинаем с последней известной). И дополнительно второй "ручной" режим - для переходных ситуаций, обновлений и т.п. - берём только в точности запрошенную версию, если верси не запрошена - только без версии. >прозрачность она в любой версии прозрачность Господа, вы опять упираетесь в какие-то частные случаи, дальше которых не желаете сунуть свой нос. Пример с KML приведён. Может ли быть у пустых KML-ек в разных версиях сервиса разный размер? Да запросто, в заголовке подрубаем расширение или форматируем по-другому, параметры нам добавляем, копирайты - и готово дело. А теперь вопрос на IQ+10 - а может ли новый увеличенный размер пустышки соответствовать старому нормальному тайлу? Да. Как ни странно может. Ну и какие "гистограммы" вы собираетесь строить по KML-ю (а вообще говоря по KMZ)? Дружочки, да сас порвётся чтобы при загрузке распарсить KMZ-KML и убедиться, что в произвольном KML ему нечего показать. То что с сервера приходит прозрачная картинка - это не более чем частный случай. А для разных сервисов и разных версий скрести по сусекам в лице всех возможных в природе "пустышек" KMZ и их размеров/хэшей - это какой-то слишком уж экстенсивный путь. >И это работает на какой угодно тип контента - с КМЛом ровно та же история Блин, ну хоть кто-то меня понял ))))

(0008729) vdemidov (manager) 06-09-2012 08:44	Ну пусть будут несколько разных версий в одной куче. Хоть 100 разных. Проверять все. Пустой тайл от смены версии менее пустым не станет. Всего то делов.

(0008730) Dima2000 (developer) 06-09-2012 09:11 edited on: 06-09-2012 09:19	>Вы считаете, что на другой карте на тайле с тем же хэшем что и у пустышки - внезапно появится изображение Нью-Васюков? Это не я так считаю, а кто-то приводит примеры с синим фоном, который в одной карте пустышка, а в другой - полезная информация (скажем для спутника это пустышка, а для карты - нет). >проверять каждый пришедший тайл - таки CPU-intensive operation Вовсе нет. Имхо, на скачивание тайла, обработку всяких там http хидеров и прочего тратится в разы больше времени, чем на подсчёт crc32 или md5. А я ведь предлагал перед подсчётом хэша сначала размеры сравнить и считать хэши ЛИШЬ ПРИ СОВПАДЕНИИ РАЗМЕРОВ! Если размер пришедшего тайла отличается от размеров всех пустышек - это ТОЧНО НЕ пустышка. Для этого и хранить кроме хэша пустышки ещё и её размер. >была одна "пустышка", стало множество других "пустышек" Ну и будут лежать и старые и новые, делов-то. Они же всё равно ОБА пустышки. Лишнего не отфильтруется. А при подозрении на фильтрацию лишнего - отключаем фильтрацию и проверяем что закачается снова (тупо глазками при обзоре карты), это быстро и просто. Если оно не будет удобно работать с KML - да наплевать, мне и тайлов хватит за глаза. Хотя и не понимаю почему нельзя положить образец "пустого" (по любому критерию by user) KML/KMZ в папочку и отфильтровывать и их тоже при закачке. Изменился размер или содержимое? Снова добавить. И снова. И снова. Пока не надоест. А когда надоест - улучшить фильтрацию пустышек на входе (между закачкой и сохранением в хранилище) - но это уже другой тикет будет, не про тайлы. Обращу внимание, в данном тикете речь про тайлы. Ни о каком парсинге KML/KMZ здесь речи не идёт вообще, работаем исключительно в терминах полученных с сервера файлов, без какой-либо привязки к их типу. PS. Блин, да что с этими тегами выделения, постоянно не срабатывает закрывающий. :(

(0008731) Dima2000 (developer) 06-09-2012 09:27	Идея с хранением двух разных хэшей файла мне нравится. Можно сначала для всех скачанных файлов проверять crc32 и при совпадении с любой пустышкой проверять второй хэш (MD5?). Скорость расчёта CRC32 при табличном методе (расход памяти 1кб) практически равна скорости прохода по файлу (в ОЗУ) - более гигабайта/с. При размере файлов до 100кб это <0.1мс. Т.е. тормозить точно не будет. А можно хранить не CRC32, а CRC128/CRC256, с ней коллизии невероятны. Скорость расчёта та же самая, только памяти выделить 4/8кб под таблицу.

(0008732) vdemidov (manager) 06-09-2012 09:31	Проблема у CRC64, 128, 256 что они нифига не стандартизированы и каждый считает их как бог на душу положит. И реализаций кстати тоже на делфи я не много встречал. А в плане некриптографических функций, которые быстро считаются есть еще CityHash MurMurHash, но они реализованы на С и тащить их в делфу муторно.

(0008733) Parasite (administrator) 06-09-2012 09:33	>кто-то приводит примеры с синим фоном, который в одной карте пустышка, а в другой - полезная информация Залинковать оба на единственный тайл в куче, и забыть. >На скачивание тайла, обработку всяких там http хидеров и прочего тратится в разы больше времени, чем на подсчёт crc32 или md5. Вы, мягко говоря - заблуждаетесь. Задержка может быть на стадии коннекта с сервером\ожидания ответа - но это никоим разом не то, о чем я говорил. И соответственно на локальных серверах (где задержка стремится к нулю) Ваше видение вопроса просто положит САС в кому. Вообще же лично я вижу это всё как правоклик на тайле, выбор в меню "Фильтровать этот тайл" (по которому он будет скопирован в папку к плохишам - независимо от его типа\содержания), и с этого момента и далее - иметься САСом ввиду. Для полноты картины можно еще и кнопочку "Почистить имеющийся кэш согласно активных фильтров" где-нибудь, с физическим удалением неугодных. Активные фильтры даже сохранять в инишнике не надо - они построятся САСом при запуске на основании содержимого папки с плохишами. Имхо, как-то так.

(0008734) Parasite (administrator) 06-09-2012 09:41	>Можно сначала для всех скачанных файлов проверять crc32 и при совпадении с любой пустышкой проверять второй хэш (MD5?) Нужно для начала проверять размер, а потом (при равности размеров) уже идти хэшироваться. Ибо размер для начала говорится самим сервером - ничего высчитывать не придется, а 99.9% тайлов с размером не сойдутся - и соответственно 99.9% работы уже будет сделано вообще без усилий. А оставшиеся, уже прошедшие этот первичный фильтр - уже на хэш. А иначе - просто представьте себе ситуацию "Кто-то с быстрым интернетом поплыл на лодке, включив САС как навигатор". А ведь буквально на прошлой неделе такой тикет тут был (правда, пока еще не про тормоза). :) >А можно хранить не CRC32, а CRC128/CRC256, с ней коллизии невероятны. Коллизии вероятны на абсолютно любой хэш-функции. И они могут случиться буквально на первой же паре тайлов (ну вот так карты лягут).

(0008735) vdemidov (manager) 06-09-2012 09:45	У хороших хеш функций вероятность настолько мала, что фиг словишь. То что ты словил на своем кэше с md5 значит что ты криво ее использовал. А про то что сравнивать по размеру, и только потом считать хэш тебе уже сто раз писали. Так что нагрузки это не создаст вообще никакой.

(0008736) Dima2000 (developer) 06-09-2012 09:50 edited on: 06-09-2012 09:53	>Коллизии вероятны на абсолютно любой хэш-функции. Угу, с вероятностью менее 10^-40, ну очень часто :-D, один раз за всю историю вселенной. Именно в этом смысле я употребил слово "невероятны". И давайте не будем ещё и тут разводить флейм о вероятностях и их понимании. Если кого страшат коллизии в CRC - оставят точные образцы пустышек и не будут надеяться на хэш. Сравнение двух файлов (оба в памяти, пустышки при этом придётся кэшировать) - тоже более гигабайта/с. Выделить динамически под кэш пустышек пару мегов памяти (а это порядка сотни разных пустышек, вы ещё наберите столько для каждой качаемой карты/слоя) имхо не проблема. Да их даже и ОС закэширует при тупом чтении с диска.

(0008737) Dima2000 (developer) 06-09-2012 09:58	>Вообще же лично я вижу это всё Полностью согласен с этим. На использовании хэшфункций не настаиваю, пусть будут лишь образцы файлов. Только при добавлении проверять на дубликаты и всё.

(0008738) Parasite (administrator) 06-09-2012 10:04	>У хороших хеш функций вероятность настолько мала, что фиг словишь. Коллизии определяются не "хорошестью" функции, а банальной длиной хэш-выхлопа. Для хэша длиной 1 бит вероятность коллизии равна 1\2 при любой "хорошести" алгоритма его подсчета, это ж очевидно. А "хорошесть" функции - это годность "просаливания" (и соответственно "разброса" самого выхлопа) при еще вменяемой общей производительности. >То что ты словил на своем кэше с md5 значит что ты криво ее использовал. Ну да, конечно. Я тебе могу сгенерить и прислать два разных файла неравных по байтам, но равных по МД5. Причем они будут экзешниками и даже работать, выдавая что-то типа "Hello Kolya" и "Hello Vasya" соответственно. Впрочем, генератор коллизий MD5 бесплатен и доступен даже тебе. >про то что сравнивать по размеру, и только потом считать хэш тебе уже сто раз писали Вообще-то это я сам писал всем другим уже раза 4 в этом тикете. >Так что нагрузки это не создаст вообще никакой. Хэш-функции весьма ресурсоемки, и одни из самых "тяжелых" прикладных алгоритмов. Но разумеется, отправка\прием ответа с сервера на порядки дольше.

(0008739) Parasite (administrator) 06-09-2012 10:12 edited on: 06-09-2012 10:17	>Угу, с вероятностью менее 10^-40, ну очень часто :-D, один раз за всю историю вселенной. Вероятность на то и вероятность (а не гарантированное число последовательных приближений к) что может случиться даже при первом проходе. И при втором. И при третьем. А потом три полных цикла вообще не случаться. >Сравнение двух файлов (оба в памяти, пустышки при этом придётся кэшировать) - тоже более гигабайта/с. У Вас там очень забористая трава. Тот же MD5 при вычислении 10000 хешей для сообщения длиной 10000 байт в реализации OpenSSL показывал скорость 84 771 Кб/с. Это в весьма хорошей, быстрой и вылизанной реализации, и не отвлекаясь более ни на что типа отрисовки битмапов, запросов\ответов на сервер или наложения слоев там.

(0008740) vdemidov (manager) 06-09-2012 10:45	>Я тебе могу сгенерить и прислать два разных файла неравных по байтам, но равных по МД5. Причем они будут экзешниками и даже работать, выдавая что-то типа "Hello Kolya" и "Hello Vasya" соответственно. Ты мне лучше наконец покажи два реальных тайла у которых совпали хэши MD5. Получить искусственно коллизию это одно, а вот схлопотать ее в реальной жизни это совсем другое.

(0008741) Parasite (administrator) 06-09-2012 11:14 edited on: 06-09-2012 11:15	>Получить искусственно коллизию это одно, а вот схлопотать ее в реальной жизни это совсем другое. На самом деле это одно и то же, ибо байтики одинаковы и там и там, и соответственно сама математическая возможность коллизии - равновероятна. Просто в генераторе она дается без перелопачивания, и ее можно пощщупать ручками и поэкспериментировать, отлаживая свой софт на уже готовой паре. И вроде как года 2 назад я тебе присылал пару таки коллизионных тайлов - я их у себя находил, обсуждали уж давно. Но мы отклонились. Своё личное видение вопроса чистки кэша я изложил чуть выше, у кого какие добавления\оспаривания? Чтоб не ловить даже возможные коллизии - я и предложил пару разнородных хэшей для тех тайлов, у которых сошлись и размер и первый хэш. Для первого хэша можно юзать "быстрый" CRC32, того получается три ступени защиты от false positive: размер, crc32, MD5 (причем проверять бы их последовательно, а не в пределах одного if ... and ... and ...). Все три сошлись - таки дупликат с гарантией, близкой к числу атомов во Вселенной. :) У меня, собссно, вопрос: а зачем нам "не писать" плохие тайлы в кэш? Можно же поставить линк на тот плохой тайл в куче. Места это не займет, а при просмотре в САСе - кэш будет таки без дырок. NTFS вроде линки делает, а кто не NTFS - можно выдать варнинг.... Как такая идея?

(0008742) bk99 (reporter) 06-09-2012 14:58	Прошу прощения, что встреваю. > Чтоб не ловить даже возможные коллизии - я и предложил пару разнородных хэшей Да и пусть ловятся! Если кто и наткнётся, то, в конце концов, сделает отдельный багрепорт, а насяльника починит, ничего страшного в этом нет. Этот инцидент ведь не об этом, а о принципиальной возможности отсекать "плохие" тайлы. Надо сначала разобраться с этим, а вылизывать можно и потом (а может и не придётся этого делать вовсе). Чтоб не растекаться, так сказать, по древу...

(0008743) vasketsov (manager) 06-09-2012 16:39	>Если кто и наткнётся, то, в конце концов, сделает отдельный багрепорт Во-первых, когда кто-то наткнётся - может быть очень больно по причине некоторого _неизвестного_ количества кривизны в кэше. Во-вторых, от разработчиков потребуется менять алгоритм проверки, скорее всего добавить или изменить один из алгоритмов вычисления хэша. Если хранилище хранит хэш, это потребует крайне неприятной длительной модификации данных в хранилище. Так что алгоритм проверки и выбор хэшей должен быть максимально рабочим. Это то место, где максимально требуется совместимость с уже накачанными данными. >а зачем нам "не писать" плохие тайлы в кэш? Ну Виктор вполне обоснованно считает, что с точки зрения кэша тайлов, это к нему не относится. Правда это формально не безупречная логика. Настройки резки тайлов вполне могут быть в zmp или maps.ini (типа режем - не режем), но вот данные для резки не обязаны там быть. По идее это формально должно быть некое версионное хранилище пустышек, плоское по структуре (без xyz). В случае кэша в СУБД как раз таки наиболее логично и "пустышки" там же иметь. Соответственно если включена резка при закачке - выкачиваем из хранилища "пустышки", строим если надо хэши (если хранилище не поддерживает их хранение) и используем. При этом возможно использование прямых ссылок из тайлов в "пустышки" (линки в СУБД или на уровне ФС).

(0008744) Dima2000 (developer) 06-09-2012 17:41	>Чтоб не ловить даже возможные коллизии - я и предложил пару разнородных хэшей Они тоже совпадут с вероятностью равной произведению вероятностей отдельных хэшфункций. Т.е. ничем ПРИНЦИПИАЛЬНО не лучше той же CRC128/CRC256, которая в отличии от MD5 (и иже с ними) считается таблично и очень быстро. >У Вас там очень забористая трава. Уж какая есть. :) Считать CRC32/128 тривиально, 1/4 команды сдвига, 2/5 xor, 1/4 чтения новой crc, плюс инкремент указателя, сравнение и условный переход - на всё это хватит 2-3/5-8 такта процессора, что даст скорость порядка гигабайта/с, ну пусть полгигабайта/с. У меня на старом P4@3ГГц CRC32 считается 200МБ/с и это на чистом дельфи, без всяких оптимизаций (а вставка на асме сразу >320МБ/с), на более новых процах будет ещё раза в два быстрее. Давайте прекратим обсуждения хэшфункций и остановимся на точном сравнении с образцами (с предварительной проверкой размера)? Это даже немного быстрее CRC и полностью исключает вероятность ошибок. А то флуд не остановить, а смотря на него никто делать так и не соберётся ...

(0008745) vdemidov (manager) 06-09-2012 19:03	Я еще раз объясняю как собираюсь делать. В змп и maps.ini у каждой карты будет список размеров и хешей тайлов, которые считаются пустыми. Скорее всего возьму SHA256 благо к ней нет способа подобрать искусственно коллизию.

(0008748) Parasite (administrator) 07-09-2012 03:38	>Они тоже совпадут с вероятностью равной произведению вероятностей отдельных хэшфункций. Да, но при этом "длинный" хэш получается не путем весьма громоздких вычислений одним алгоритмом (экспоненциально увеличивающимся по времени при увеличении длины хэша!), а путем двух относительно "легких" (по сравнению с "длинным") и всё еще стандартных алгоритмов, и простой конкатенцией этих двух выхлопов. Скорострельность всего решения повышается в разы - проверено, а для параноиков можно и еще удлинить строку по той же схеме, что даст еще больше вариантов и отстрочит возможную коллизию в неопределенное светлое социалистическое будущее. >на более новых процах будет ещё раза в два быстрее. Я понятия не имею, что и как у Вас там. Верхние данные были взяты из каноничного и выверенного описания MD5. Да и по себе знаю - достаточно медленная зараза, мне как-то пришлось поподбирать брутфорсом забытые префикс\суффикс MD5 при известном исходнике и известном результате....это было медленно и печально....и в итоге кстати опять-таки решилось через коллизию (первым был найден ответ, НЕ РАВНЫЙ исходному, но дающий тот же результат. То есть, просто набор символов вместо использованного когда-то осмысленного слова). Если не ошибаюсь, это заняло где-то 5мес всего-навсего. А у нас тут годами качают. :) >на точном сравнении с образцами (с предварительной проверкой размера)? Это даже немного быстрее CRC и полностью исключает вероятность ошибок. Как предлагается сравнивать (по какому алгоритму, в смысле)? Побайтово? >В змп и maps.ini у каждой карты будет список размеров и хешей тайлов, которые считаются пустыми Заодно и собственно хэшировщик куда-нибудь приладить бы (например, на правоклик->"Фильтровать этот тайл"). А то лазить по инету в поисках оного никто ж не будет. Но мне кажется, что это не самый удобный метод - просто потому, что по куче хэшей невозможно вспомнить, что же конкретно за тайл зафильтрован, и через неделю это всё забудется, и нет никакой возможности обратной операции (по готовому хэшу узнать - что же за тайл там был, и за что попал в немилость). То есть, придется до кучи [ручками] еще и хранить эти тайлы с пометками, какой у кого хэш и откуда это всё. И не забывать обновлять\дополнять при любых изменениях. Это гимор. Все же предлагаю сделать папку с образцами готовых тайлов - например, ".BAD" в корне кэша конкретной карты. Всё будет наглядно, а ЗМП при этом вообще трогать не придется. Пожалейте ж юзверей! :)

(0008749) bk99 (reporter) 07-09-2012 04:57	Я прошу прощения, что возвращаюсь, но хотелось бы уяснить для себя (в качестве ликбеза). Прошу не воспринимать это как тролинг. >>> Чтоб не ловить даже возможные коллизии - я и предложил пару разнородных хэшей >> Если кто и наткнётся, то, в конце концов, сделает отдельный багрепорт > Во-первых, когда кто-то наткнётся - может быть очень больно по причине некоторого > _неизвестного_ количества кривизны в кэше Насколько я понимаю, при возникновении такой (очень)маловероятной коллизии просто напросто невозможно будет скачать один единственный тайл. Кеш при этом никак не пострадает (ну будет дырка в один тайл и всё). Это так? > Во-вторых, от разработчиков потребуется менять алгоритм проверки, скорее всего > добавить или изменить один из алгоритмов вычисления хэша. Если хранилище хранит > хэш, это потребует крайне неприятной длительной модификации данных в хранилище. Опять же, по моему разумению, в этом случае от разработчиков потребуется просто вставить ещё одну дополнительную проверку на совпадение по второму типу хеша. Это ведь минимальные и несложные изменения, принципиально не затрагивающие алгоритм? Спасибо.

(0008759) Dima2000 (developer) 07-09-2012 16:52	>Я еще раз объясняю как собираюсь делать. В змп и maps.ini у каждой карты будет список размеров и хешей тайлов, которые считаются пустыми. Sorry, не допонял, образцы из левой папочки храниться и фильтроваться не будут, только по хэшам? Это имхо хуже, я хэши предлашал как ДОПОЛНЕНИЕ и ускорение фильтрации по образцам, не как замену. >Как предлагается сравнивать (по какому алгоритму, в смысле)? Побайтово? Да, я предлагал именно побайтово, бинарное содержимое файлов (образца и скачанного). Это гарантирует отсутствие даже теоретической возможности ошибок.

(0008766) Parasite (administrator) 10-09-2012 04:09	>Это имхо хуже, я хэши предлашал как ДОПОЛНЕНИЕ и ускорение фильтрации по образцам, не как замену. +1 При этом сами хэши специально хранить не надо имхо - они будут строиться при запуске САСа точно так же, как сейчас строится инфа о доступных ZMP (ну и динамически докидывается, если хомяк сделал "Фильтровать этот файл" в процессе работы. Тайл при этом должен скопироваться в папку к неугодным, хеш от него - иметься ввиду при этом сеансе работы, а при перезапуске САСа он заново пересчитается уже из папки неугодных). Как-то так. Было бы удобно, да. >Да, я предлагал именно побайтово, бинарное содержимое файлов (образца и скачанного). Это гарантирует отсутствие даже теоретической возможности ошибок. Не проканает. При росте числа тайлов в папке - получаем замедление всей работы САСа в геом.прогрессии, плюс увеличение [совершенно ненужного] числа диск.операций ровно в той же мере. Представьте, при сотне-другой тайлов в той папке - нам придется каждый входящий файл побитово сравнивать сотню-другую раз, прежде чем переходить к следующему... Хеш же (или по два оных. Или по три) можно просто разово строить при запуске САСа как массив, и потом держать в памяти. Много памяти это не займет, а "короткое" сравнение хэшей "память\память" уж куда быстрее, чем полноразмерное побайтовое "память\диск".

(0008767) vdemidov (manager) 10-09-2012 09:10	Ладно. Уговорили, действительно лучше пихать сами тайлы, а хэши считать уже внутри САСа. Тогда не придется заранее завязываться на хэшфункцию и можно взять даже CRC32 и проводить побайтовое сравнение только если совпали хэши.

(0008774) vasketsov (manager) 10-09-2012 11:12 edited on: 10-09-2012 11:13	>просто напросто невозможно будет скачать один единственный тайл Во-первых, никто не гарантирует, что один. Во-вторых, будет неизвестно, где именно он(и) находи(я)тся. >Это ведь минимальные и несложные изменения, принципиально не затрагивающие алгоритм? Там было важное замечание "Если хранилище хранит хэш". Разумеется если хэш не хранится - то это вопрос выхода из цикла проверки наличия коллизии, покуда есть новые всё более труъ хэш-функции - упорно их считаем и сравниваем, продолжаем есть кактус и т.п. >При росте числа тайлов в папке - получаем замедление всей работы САСа Именно по причине невозможности заранее (на этапе выбора решения) предусмотреть максимальную ресурсоёмкость сравнения нового скачанного тайла со всеми "пустышками" (хэшами или вдруг побайтово), их и надо максимально разделять (по карте и версии). Проще говоря - минимизировать число тайлов в папке, которые анализируются в качестве "пустышек" для конкретного сервиса.

(0008786) Dima2000 (developer) 11-09-2012 05:21	>При росте числа тайлов в папке - получаем замедление всей работы САСа в геом.прогрессии Вовсе нет, в линейной. И всё равно сущие копейки. И не всего САС-а, а лишь процесса закачки. Сравнение будет примерно так: function Пустышка?(const tile:string):boolean; begin result := true; len := length(tile); hash := hash(tile); for i := 1 to <кол-во_пустышек> do begin if len <> sizes[i] then continue; if hash <> hashs[i] then continue; if DoCompareByFile(tile, пустышка[i]) then exit; //Точно совпал! end; result := false; end; Проверка на бинарное совпадение (и чтение пустышки с диска) будет лишь если ТОЧНО СОВПАЛ И РАЗМЕР И ХЭШ, для CRC32 это тысячные доли процента от долей процента совпадений размеров тайлов с размерами пустышек. 99.9% тайлов будет проверяться лишь первым if-ом и прокручивать цикл дальше. Ещё 99.9999% из оставшихся отсеются вторым if-ом. А для каждого миллиардного скачанного "хорошего" тайла проверить его на совпадение с файлом с диска - вообще ни разу не проблема. Максимальные затраты времени: а) для каждого скачанного "хорошего" тайла - однократный проход по массиву из сотен-тысяч элементов (намного меньше миллисекунды); б) для каждой скачанной "пустышки" - плюс сравнение с дисковым файлом (а для второй скачанной пустышки его уже кто-то закэширует, или ОС, или сам САС); в) для "хорошего" тайла, совпадающего по размеру И хэшу с несколькими пустышками (ОЧЕНЬ маловероятно) - сравнение с каждой из них с файлом с диска. В любом случае это во много раз меньше затрат на запись тайла на диск! И ничего разделять не надо, всё будет очень быстро. И можно ещё ускорить - считать хэш скачанного тайла лишь при нахождении его совпадения с одной из пустышек, это если применять хэши типа MD5 и более сложные. Но в этом НЕТ НИКАКОЙ реальной необходимости. Если будет тормозить именно сравнение с пустышками (не верю!), то и ещё ускорить: считать ВСЕ пустышки в память в тот же массив при старте САС-а. Или не все, а лишь мелкие, до десятка килобайтов каждая. Расход памяти: 1000 пустышек * 5Кб = всего 5 мегов. А часто пустышки намного мельче, если мы про именно тайлы говорим. Хотя никаких ограничений на фильтрацию чего угодно закачиваемого разумеется нет.

(0008789) Parasite (administrator) 11-09-2012 05:53 edited on: 11-09-2012 06:04	>Проще говоря - минимизировать число тайлов в папке, которые анализируются в качестве "пустышек" для конкретного сервиса. Ну разумеется. А еще лучше - всё же сделать отдельную чистилку кэша постфактум после скачки и не трогать САСа от греха (см.ниже), но тут это уже обсуждалось. >Вовсе нет, в линейной. В геометрической. С базой прогрессии равной числу тайлов в папке, и с числом членов равным очереди на скачку. 1 тайл на скачку и 1 тайл в папке = 1 проверка, 2 тайла на скачку и 2 тайла в папке = 4, 3 х 3 = 9, итд. При десятке-другом миллионов тайлов к скачке и сотне-другой тайлов в папке - получаем весьма длинные циферки числа тырканий головками винта туда\сюда, превышающие максимальный HEAD_SEEK_POS в смарт-таблице. >лишь если ТОЧНО СОВПАЛ И РАЗМЕР И ХЭШ Это меняет дело. Я Вас выше прямо спросил: каков предлагаемый алгоритм проверки? Вы ответили: "побайтово, бинарное содержимое файлов (образца и скачанного)" конец цитаты. Я именно это и обсуждал. А теперь Вы на лету диалога вводите два условия с хэшами выше этого сравнения, хотя выше пытались как раз отойти от коллизий хэша. Не морочьте голову, другими словами - пишите все предлагаемые алгоритмы полностью и по пунктам. >считать ВСЕ пустышки в память в тот же массив при старте САС-а. А если их неск.сотен на каждый используемый слой (которых тоже может быть целая кучка)? >В любом случае это во много раз меньше затрат на запись тайла на диск! А теперь расскажите нам, как это должно работать в базе (в том же Беркли)? Хорошо, если мы качаем с нуля и не меняем папку с плохими тайлами. А если прямо в процессе работы юзер выбрал "Фильтровать этот тайл" - и нам надо пересмотреть весь уже скачанный на этот момент кэш? Полнотекстовый поиск по хэшу (даже если он хранится в базе) - весьма долгая выборка даже с фикс.длиной поля и наличием индекса по нему (и тоже растет в прогрессии при увеличении размера базы), индекс этого поля будет стремиться к размеру собственно поля (ибо хэши как строки - с весьма высокой долей вероятности уникальны, и коллизии нам не нужны) плюс при положительном сравнении надо будет достать с базы блоб с тем тайлом (еще один селект с неск.килобайтным выхлопом) и сравнить уже бинарно...Базовод будет нагружен чуть более чем полностью, и в процессе скачки (увеличении размера базы) это будет только усугубляться.

(0008794) Dima2000 (developer) 11-09-2012 06:50	>Я Вас выше прямо спросил: каков предлагаемый алгоритм проверки? Вы ответили: "побайтово, бинарное содержимое файлов (образца и скачанного)" конец цитаты. Я именно это и обсуждал. Простите, но: >>>на точном сравнении с образцами (с предварительной проверкой размера)? Это даже немного быстрее CRC и полностью исключает вероятность ошибок. >>Как предлагается сравнивать (по какому алгоритму, в смысле)? Побайтово? >Да, я предлагал именно побайтово, бинарное содержимое файлов (образца и скачанного). Это гарантирует отсутствие даже теоретической возможности ошибок. Даже у вас в процитированном моём тексте есть указание на проверку размеров ДО бинарного сравнения. Т.е. дальше я отвечал уже на метод сравнения ПОСЛЕ совпадения размеров. Да, мы друг друга не поняли, извиняюсь. >А теперь расскажите нам, как это должно работать в базе (в том же Беркли)? А причём тут БД? Я уже рассказал только что как это должно (имхо) работать. Один дополнительный цикл проверки тайла (файла) на "хорошесть" после закачки и до сохранения в тайлохранилище. В любое! И БД тоже. Вообще без привязки к типу тайлохранилища. И без всякого дёрганья тайлохранилища для проверки на пустышки. В чём проблема-то? >>Вовсе нет, в линейной. >В геометрической. От количества пустышек - в линейной: O(tn), где t - количество скачанных тайлов (а не тайлов в тайлохранилище!), n - количество пустышек в папке. Оба правы, разное подразумеваем под затратами. >При десятке-другом миллионов тайлов к скачке и сотне-другой тайлов в папке А давайте примерно оценим, чего спорить. Расходы на 20кб (в среднем) тайл: однократно расчёт CRC32 плюс цикл по сотне элементов массива, два условия, проверка физического тайла с вероятностью 10^-9, на старом процессоре (P3). Составит 20кб / 100Мб/с + 100 (10нс + 1c * 10^-9) = 0.202мс. Даже при чтении каждой пустышки целую секунду!! 100Мб/с CRC32 вполне считается на любых доступных компах. А вероятность 10^-9 обеспечивается комбинацией размера и CRC32 (для реальных данных, а не искусственных коллизий!). Расходы на 10млн тайлов = 0.2мс * 10млн = 2000с. При этом получено 20кб * 10млн = 200Гб тайлов. Значит средняя скорость 100Мб/с. Т.е. можно успеть за полностью забитым гигабитным каналом. Нехило у вас запросы однако! Да ещё и на слабом P3. На более быстрых компах скорость возрастёт ещё в несколько раз. И это я ещё прилично занизил скорость обработки на всякий случай... Имхо вопрос о тормозах можно закрыть как несущественный. Или мне приложить сюда утилитку обхода кэша и замера времени обработки ВСЕХ тайлов в кэше? ;-)

(0008796) vasketsov (manager) 11-09-2012 07:13	>надо пересмотреть весь уже скачанный на этот момент кэш? Вот это как раз оффлайновая работа, к скачке отношения не имеет, сложность не настолько критична. >Значит средняя скорость 100Мб/с Ну да, самому-то не смешно?

(0008797) Dima2000 (developer) 11-09-2012 07:27	>>Значит средняя скорость 100Мб/с >Ну да, самому-то не смешно? Неа. Не я же попросил 10млн тайлов и сотню пустышек. А смысл цифры лишь тот, что при скоростях закачки меньших чем эта - тормозить проверка тем более не будет.

(0008798) vasketsov (manager) 11-09-2012 07:40	>при скоростях закачки меньших чем эта Какая "эта"? Ты считаешь реальным выкачать 200Гб тайлов за 2000с на гигабитном канале по http?

(0008799) Parasite (administrator) 11-09-2012 08:12 edited on: 11-09-2012 08:13	>А причём тут БД? Притом, что она УЖЕ есть, она УЖЕ работает, и у юзеров УЖЕ кэш в ней - и ее придется брать во внимание, нравится нам это или нет. Обратная совместимость - это святое. >И без всякого дёрганья тайлохранилища для проверки на пустышки Вы предлагаете НЕ пересматривать уже имеющийся кэш после того, как юзер добавил свежий тайл к плохишам? И если он его увидел глазками в самом-самом конце скачки, и токи честно добавил (то есть - выполнил всё от него требуемое) - то в кэше у него таки БУДУТ эти плохие тайлы, и для вычискти такого говнокэша таки опять придется юзать костыль, что делит всю затею в САСе на ноль? >От количества пустышек - в линейной: O(t*n) Линейность ф-ции не имеет ничего общего с типом прогрессии. Даже в Вашей формуле умножение есть признак ГЕОМ.прогрессии, что не мешает ей оставаться линейной до тех пор пока база у нее - константа (а это в нашем случае не гарантия, ибо хомяк может в любую секунду докинуть новый тайл - и линейность поймает лося). Линейность это вообще качественный показатель в общем и целом, а не количественный. >100Мб/с CRC32 вполне считается на любых доступных компах. ...в лабораторных условиях, и при условии того что они больше ничего не делают, а ось - реального времени или вообще отсутствует. >Т.е. можно успеть за полностью забитым гигабитным каналом. Ну-ну. За ним даже не каждый винт успевает, со всеми своими перепозиционированиями (а тормозящий винт = тормозящая ось = тормозящий САС и все остальное). "Теория говорит, что нет разницы между теорией и практикой...Практика же говорит, что разница между теорией и практикой есть" © >Не я же попросил 10млн тайлов и сотню пустышек. Ну и посчитайте для начала время доступа к каждому из 10млн файлов в отрыве от кэширования ФС (для чистоты момента - ведь у пользователя может быть какая угодно ФС, вот у меня например Рейзер)... Сколько там RANDOM_SEEK у современного винта? Примерно 62 seeks\sec (http://phpsuxx.blogspot.com/2010/02/blog-post_02.html), что дает нам 161 тысячу секунд (или 112 суток) просто для того чтобы узнать - у кого какой хэш (время хэширования и время чтения боди файла для чистоты момента приравняем к нулю). И это примерно так и есть - попробуйте переписать этот кэш на флешку, которая НЕ кэширует ФС для оптимизации быстрого извлечения... Ну а теперь еще сотня проверок на каждый найденный тайл. >выкачать 200Гб тайлов за 2000с на гигабитном канале по http? Да щоб ми так жили...(с) :)

(0008800) Parasite (administrator) 11-09-2012 08:17	>Ладно. Уговорили, действительно лучше пихать сами тайлы, а хэши считать уже внутри САСа. Тогда не придется заранее завязываться на хэшфункцию и можно взять даже CRC32 и проводить побайтовое сравнение только если совпали хэши. Предлагаю на этом и остановиться, и так и реализовать. А то тут можно долго перетирать в свое удовольствие - а тикету и так уже 2 года.

(0008801) Dima2000 (developer) 11-09-2012 08:42	>Ты считаешь реальным выкачать 200Гб тайлов за 2000с на гигабитном канале по http? Скорость - проверки тайлов на "хорошесть". Реально их так быстро выкачать или нет - не обсуждается. >Даже в Вашей формуле умножение есть признак ГЕОМ.прогрессии Нет, изучаем правила выражений O(). Выражение O(t*n) ЛИНЕЙНО от n с коэффициентом t (да, его вообще-то можно и не указывать в скобках). И квадратично от t и n. При увеличении количества пустышек в сто раз количество проверок при скачивании t тайлов увеличится тоже в сто раз, вне зависимости сколько их уже лежит в кэше. Именно поэтому зависимость линейна от количества пустышек. >Вы предлагаете НЕ пересматривать уже имеющийся кэш после того, как юзер добавил свежий тайл к плохишам? Разумеется. И вообще, это как было правильно указано, вопрос отдельный. И должно имхо делаться командой Удалить в операциях с областью (или ещё где), я уже говорил. Уж точно не в момент закачки или добавления "плохого" тайла. >Ну и посчитайте для начала ... 1. 62seek/s значит на сотню пустышек (а читаются с диска только они!! сколько раз повторять, а?) уйдёт 1.6 секунды, а не 112 суток. 2. Флешки вполне себе кэшируют ЧТЕНИЕ, а только оно и нужно для проверок тайлов на совпадение. 3. Или вы собрались хранить 10млн пустышек?! Бредите. Ещё раз повторяю вопрос, где в мной предложенном алгоритме используется любая БД? Или вы пустышки храните в БД? Ну да, тогда я не знаю сколько времени займёт чтение каждой пустышки, но уж не более 1с? А с секундой на каждую пустышку я привёл расчёт. >Предлагаю на этом и остановиться, и так и реализовать. Согласен. Тем более что у нас с вдемидовым решение практически одинаковое получилось.

(0008802) Parasite (administrator) 11-09-2012 08:43 edited on: 11-09-2012 08:52	Кстати, вдогонку - только что на ум пришло: а если в кэш ложить всё что пришло с сервера, а вот при показе - фильтровать тот или иной тайл (и не показывать его на экране, если он в папке с плохими)? Идея не настолько дика как может сперва показаться: 1) В кэше таки хранится всё, что отдал сервер. Без потерь (да, размер будет немного больше). 2) На коллизии можно плевать - подумаешь, где-то тайл не отобразится...в кэше он все равно есть, см.1. Сменив алгоритм в сасе - false positive уйдет, и будет показываться. 3) склейка в файл и карта заполнения - будут без дырок; 4) отфильтрованные тайлы не будут приводить к новым и новым запросам на сервер, как это будет в случае дырок в кэше и малейшем сдвигании экрана; 5) фича "пересмотреть имеющийся кэш после добавления нового тайла хомяком" будет делаться легко и не нарушая производительности - всего-то экран перерисовать на базе новых фильтров 6) если в какой-то момент хомяк освободит папку с отфильтрованными тайлами - перекачивать ничего не придется, оно сразу же все это моментально и покажется из кэша, см.5. Итд итп. Правда, вознимкет вопрос - а зачем, собссно, такой режим "не отображать какие-то тайлы" нужен...ну да это уже не ко мне - тикет не мой, и лично мне вся эта фича вообще не нужна в общем и целом. Пускай тикетстартер отпишется... :)

(0008803) Dima2000 (developer) 11-09-2012 09:03 edited on: 11-09-2012 09:04	>а зачем, собссно, такой режим "не отображать какие-то тайлы" нужен... Угу, мне такое не нужно, мне хочется не писать пустышки на диск. Вообще. Хотя, мысль интересная, но в новый тикет! :) PS. http://gramota.ru/slovari/dic/?word=%EB%EE%E6%E8%F2%FC&all=x - неправильно, http://gramota.ru/slovari/dic/?lop=x&bts=x&zar=x&ag=x&ab=x&sin=x&lv=x&az=x&pe=x&word=%EA%EB%E0%F1%F2%FC - правильно. Sorry. :)

(0008804) vasketsov (manager) 11-09-2012 09:16	>Выражение O(t*n) ЛИНЕЙНО Да. >НЕ пересматривать уже имеющийся кэш после того, как юзер добавил свежий тайл к плохишам? Разумеется не пересматривать. Вычистить пустышки можно в оффлайне ночами.

(0008805) Parasite (administrator) 11-09-2012 09:17	>Именно поэтому зависимость линейна от количества пустышек. 1) Выше (у меня) был разговор за тип прогрессии, а не за линейность ее функции. Смысловые отличия оборотов "тип прогрессии" от слова "линейность функции", и их нетождественность - гуглить самостоятельно. 2) Выше (у меня) были слова "не мешает ей оставаться линейной до тех пор пока база у нее - константа (а это в нашем случае не гарантия)". Смысловую наполненность оборота "в нашем случае не гарантия" (то есть ненулевая возможность компрометации всего утверждения) - гуглить самостоятельно. >>Вы предлагаете НЕ пересматривать уже имеющийся кэш после того, как юзер добавил свежий тайл к плохишам? >Разумеется. Тогда полезность всей этой фичи завязана исключительно на время реакции хомяка на обнаруженный плохой тайл, и точно так же стремится к нулю как и эта реакция - к бесконечности. >И должно имхо делаться командой Удалить в операциях с областью (или ещё где) Зачем нам ДВЕ операции на ОДИН ненужный тайл? Он одинаково не нужен в обоих двух. >а читаются с диска только они!! Не нужно выдирать фразы их контекста - верхний расклад был в свете темы "пересмотреть весь кэш после добавления нового тайла". Вы же упорно гнете свою линию - при следовании которой уже наработанный кэш все еще будет "грязным" и от чего мы, соббсно, и пытаемся тут уйти. >Флешки вполне себе кэшируют ЧТЕНИЕ 1. Флешки сами по себе вообще ничего не кэшируют - им тупо негде и нечем. 2. Чтобы чтение (независимо от носителя) было закэшировано - должен быть факт как минимум однократного доступа к той информации, то есть - репозиционирование на начало + собственно чтение боди. То есть - именно то что я и сказал. >3. Или вы собрались хранить 10млн пустышек?! Бредите. Тю...У меня их намного, на порядки больше. Половина шкафа винтами по 2Тб уложена, как дровами в поленнице... >Или вы пустышки храните в БД? В существующей реализации Беркли тайлы (включая как "пустышки" - но которые таки тайлы, так и 404е ответы) таки да, хранятся в БД. Хотите обрадовать всех юзеров, что структура кэша беркли поменяется? Сходите на форум, обрадуйте... Узнаете много новых слов. :) >А с секундой на каждую пустышку я привёл расчёт. Сколько у Вас помещается тайлов на экране? У меня, грубо говоря - 80 (разрешение 2560\1980). Вы желаете сообщить мне, что при призумливании на непрокачанную область мой экран мне отрисуется в худшем случае (например, я призумился в океан - где все пустышки) за 80сек, при учете того что скачка займет пару секунд? Я правильно Вас понял?

(0008806) Parasite (administrator) 11-09-2012 09:24	>Вычистить пустышки можно в оффлайне ночами. Разумеется можно. Но ЧЕМ (коль скоро мы тут пилим САС, а не комплекты зимних костылей к нему)? Костылями чистить кэш я предлагал еще с самого начала, и даже сорц дал вона, и если костыли применимы и допустимы - то все обсуждение должно было где-то там и закруглиться. САСу-то это не помогает в любом случае.

(0008807) vasketsov (manager) 11-09-2012 09:32	>Но ЧЕМ Стандартной процедурой удаления тайлов из кэша, видоизменённой на предмет нюхания не только размера, но и хэша.

(0008808) Parasite (administrator) 11-09-2012 09:43 edited on: 11-09-2012 09:45	>Стандартной процедурой удаления тайлов из кэша, видоизменённой на предмет нюхания не только размера, но и хэша. Вот! То что я и говорил ранее (а-ля "отдельный пункт в меню"). Уже интереснее. Видоизмененность этой процедуры будем обсуждать в другом тикете, или прямо тут? Вопрос, собссно, один: что нам мешает объединить эти два одинаковых по сути (но разных по загруженности системы) функционала в один процесс? Например, при добавлении нового тайла - иметь его ввиду при скачке, НО при этом еще и тупенько спросить юзера "Вычистить весь кэш от этих тайлов прямо сейчас Д\Н"? И будет всем щасте.

(0008809) vasketsov (manager) 11-09-2012 10:16 edited on: 11-09-2012 10:44	>что нам мешает объединить эти два одинаковых по сути Мешает наличие существующей процедуры удаления тайлов из кэша. Сейчас она крайне тупа, как минимум туда надо и дату пихать, заодно и хэши (и любые другие критерии вычищения). Да и суть разная. Операция разная. Оперируемая сущность разная. Результат операции с точки зрения команды к хранилищу разный. Всё разное. В сад. >Вычистить весь кэш от этих тайлов прямо сейчас Д\Н Ога. И ещё не забыть написать, что дальше скачка пойдёт только после вычищения всего кэша. Ты реально мечтаешь о таком долбо#бизме? Я вполне допускаю чистку кэша от пустышек KMZ в какой-нибудь конторе ночами в течение недели. зы. И надо ещё не давать закрывать сас, покуда кэш не вычистится, а то новые настройки и старый кэш будут не согласованы. И запретить 2-м прогам писать в один кэш. Дабы не сыграла разная настройка резки тайлов при закачке.

(0008810) Parasite (administrator) 11-09-2012 10:44	>Мешает наличие существующей процедуры удаления тайлов из кэша. Сейчас она крайне тупа Ну дак мы же договорились выше, что она будет переделана. Вот и переделывать её по-умному, а не так чтобы через неделю на этом месте был тикет "Рефакторинг: удалялка тайлов". >Да и суть разная. Суть одна: с набора тайлов который как всегда - делать более другой. И там и там. Всё. >Операция разная. Операция одна: взять отдельный тайл, сравнить по кучке правил, по необходимости - в сад его. Разный только источник - кэш либо интернет. >дальше скачка пойдёт только после вычищения всего кэша. Ты реально мечтаешь о таком долбо#бизме? Ну, во-первых - юзер сам себе дурочка, если выберет Y. Не нравится - не нажимает Y и не чистит сразу. Задача САСа - исполнена в обоих случаях раз хомяк так сказал, претензий к сасу нет. Во-вторых, именно по этой причине я и предлагал ранее standalone-тулзу, которая может тормозить как угодно и запускаться в фоне или вообще в параллельной реальности. И это работает даже седня, и не требует переделки САСа. Но предыдущим ораторам приспичило именно в САСе и именно с гуем и именно в процессе скачки, в риалтайме. А завтра приспичит еще и минет от него ежевечерне, и дачу вспахать по весне. Вопрос "А зачем это всё пихать в САС?" - не мой, я только разместил каменты к. >Я вполне допускаю чистку кэша от пустышек KMZ в какой-нибудь конторе ночами в течение недели. Так одно другому ж не мешает. Удалялка-то всё равно уже будет в составе саса, кто не все - те чистят ночами с той же мерой эффективности. Всего вопроса - выход процiдурки "добавление тайла хомяком" черед диалогбокс залинковать на вход процiдурки "Запуск чистилки кэша при ответе Y" с соответствующими параметрами в ней, и на закрытие диалогбокса - при ответе N.

(0008812) Dima2000 (developer) 11-09-2012 11:00	>Я правильно Вас понял? Нет, вы меня поняли совершенно превратно и неправильно. Слова про вероятность 10^-9 вы вобще не заметили? Зря. Вместо 80с будет лишь добавка 80шт * LEN80 / 100МБ/с + N * (10нс + 1с * 10^-9), где LEN - общий размер 80-ти скачанных тайлов, N - количество пустышек в папке, 1с - время чтения (получения из фС или БД) body одной пустышки. При LEN80=2Мб, N=1000, 1с, отрисовка (а вернее скачивание!!) замедлится на 20мс. Не 80с. Разумеется это сильно в среднем, для 80-ми тайлов может и заметно больше быть. Вы приведите цифру сколько тайлов у вас в кэше совпадают по размеру И CRC32 с образцами пустышек, но при этом отличаются содержимым - тогда и посчитаем точно. И сюда приложите реальный пример такой коллизии!! Вопрос с хранением десятков миллионов (и сотен миллиардов) разных пустышек (не хороших тайлов, а именно нафик не нужных хомяку!) - открыт и мною пока не рассматривается вообще. В контексте данного тикета речь идёт о прозрачных тайлах или аналогичных. Их миллионов быть не может и не дОлжно. >что нам мешает объединить эти два одинаковых по сути Они не одинаковы, одно недопущение загрязнения кэша, другое его очистка. Первое к закачке, второе к операциям-удалить. Уже много раз повторили. Тут речь о первом. Ещё раз: РЕЧЬ ЛИШЬ ПРО НЕЗАПИСЬ В КЭШ ПУСТЫШЕК ПРИ ЗАКАЧКЕ. Всё остальное - в другие тикеты. To vdemidov: Не пойму как лучше, молча отбрасывать тайл-пустышку или вместо него сохранять tne? Вроде второе идеологически неправильно, но зато не будет потом повторных запросов сервера если что. Может параметром в ini сделаете и каждый сам решит для себя?

(0008813) Parasite (administrator) 11-09-2012 11:03	>И запретить 2-м прогам писать в один кэш. Дабы не сыграла разная настройка резки тайлов при закачке. Кстати, да. Может, как-то мониторить папку с плохищами автоматом? Так как она в корне кэша - то при добавлении туда тайла в одной из программ - оно автоматически подхватится и в другой, качающей в тот же кэш. Ну а вычистка уже имеющегося будет сделана той прогой, из которой оно было добавлено (а вторая в то же время будет качать уже с обновленными правилами). PS: Какая-то весьма геморройная хотелка получается, да и интересная всего нескольким ораторам за два-то года. :(

(0008814) zOn (reporter) 11-09-2012 11:06	интересна она не нескольким, а многим. просто многие (я в том числе) в вашей дискуссии "как жук в апельсинах" и слова не вставить.

(0008815) Parasite (administrator) 11-09-2012 11:16	>И сюда приложите реальный пример такой коллизии!! Ага, у меня больше дел нет чем все бросить и бежать пересчитывать весь свой кэш на тему CRC32 (который я нигде сроду не юзал как раз ввиду его ообщеизвестной ущербности на эту тему). Математическую вероятность коллизии CRC32 - сказать могу. Она небольшая. Вкупе с размером - вероятность попадания ниже, но не равна нулю разумеется. >Вопрос с хранением десятков миллионов (и сотен миллиардов) разных пустышек (не хороших тайлов, а именно нафик не нужных хомяку!) - открыт и мною пока не рассматривается вообще. В контексте данного тикета речь идёт о прозрачных тайлах или аналогичных. Их миллионов быть не может и не дОлжно. 1. Опять, в который раз - не совсем понятно: имеются ввиду хранение уникальных "пустышек" (которые каждая - сама по себе и не равна соседней), либо "не хороших тайлов, а именно нафик не нужных хомяку" (например море-окиян, чуть менее чем всё покрытое идентичными друг другу пустышками, но их - туева хуча копий)? Я выше говорил про второе. Постоянно приходится переспрашивать из-за разночтений, коллега. Время теряем. :( >>что нам мешает объединить эти два одинаковых по сути >Они не одинаковы, одно недопущение загрязнения кэша, другое его очистка. Смысл оборота "одинаковы по сути" - гуглить самостоятельно. "Суть" в данном случае - это чистый кэш из грязного, а Вы мне тут за тонкости двух конкретных реализаций на пути к этой сути. Да хоть двадцать две их будет - суть вопроса одна: кэш уже чистый с точки зрения одного отдельного хомяка (и ничего делать не надо), или еще нет (и надо что-то делать).

(0008816) vasketsov (manager) 11-09-2012 11:19	>отбрасывать тайл-пустышку или вместо него сохранять tne? Можно писать tn1 или tne2 или аналогичную фигню (только вот при tne2 могут быть проблемы с короткими именами файлов).

(0008817) vdemidov (manager) 11-09-2012 11:19	> PS: Какая-то весьма геморройная хотелка получается, да и интересная всего нескольким ораторам за два-то года. :( Именно геморойная. Поэтому в ближайшее время будет только: 1) проверка по образцам лежащим в zmp 2) считываться эти образцы будут только при старте программы 3) добавляться будут ручками как файлики в zmp 4) если проверка нашла образец, то будет возвращаться такой же результат как и при 404 статусе, только с чуток другим комментарием, а там уже процедура закачки в зависимости от настроек будет или ничего никуда не писать, или писать tne Кому захочется большего милости просим писать код, кто не может писать код пишет хотелки, но я их буду ставить на 2020-й год.

(0008818) Tolik (manager) 11-09-2012 12:02 edited on: 11-09-2012 12:07	^^^ Вполне годится. Интересно не только нескольким, просто не все отметились в этом флуде :) Образцов будет не миллион, а всего 1-2 реальных пустышек, например, абсолютно прозрачный png или картинка с надписью "такого изображения нет". То, чем покрыты акияны - синие квадраты - пустышками считать нельзя. Образцы можно будет и в репозиторий закинуть. Надо только имена им придумать. Чтоб с иконками и всякими легендами не спутать. Кстати, какие сейчас допустимые имена для иконок? 18.bmp, 24.bmp, какие ещё?

(0008819) zOn (reporter) 11-09-2012 12:36	Толик, а чего там придумывать? в каждом zmp будет 1-3 картинки-заглушки 404_1.jpg/png/gif 404_2.jpg/png/gif

(0008820) Dima2000 (developer) 11-09-2012 12:47	>Поэтому в ближайшее время будет только: Спасибо, вполне достаточно, поддерживаю. Потом добавим тикет про удаление тайлов из кэша по образцам (дополнительный вариант/галку в операции - удалить). И тикет добавлять тайл в папочку плохих по ПКМ на нём. Их хоть на 2020г, вдруг кто озадачится. :)

(0008821) zOn (reporter) 11-09-2012 12:56	Если будет >1) проверка по образцам лежащим в zmp то никаких >тайлов в папочку по Пкм вы не дождетесь и тикет сразу прибьют.

(0008822) Dima2000 (developer) 11-09-2012 13:24	Главное чтобы сделали, хоть как-то. А потом если что поправим (место хранения образцов пустышек), поправить пару строк проще написания всего заново. А потом и ПКМ заработает. Не всё сразу. :)

(0008823) Parasite (administrator) 11-09-2012 13:27	>проверка по образцам лежащим в zmp Ну выше ж вроде договорились, что и папка сгодится. Уже переиграл что ли? Имхо, папка в корне кэша соотв.карты - самое удобное (для среднестатистического юзера) решение. А все остальное пускай будет как ты и написал. >кто не может писать код пишет хотелки, но я их буду ставить на 2020-й год. Слава Аллаху - эта хотелка не моя, так что ставь. И эту тоже туда же можешь. :) >просто не все отметились в этом флуде :) Вполне нормальное и развернутое тематическое обсуждение получилось, ящщетаю. У тебя просто извращенное понимание флуда подо всем, что собирает over10 каментов. :) >Образцов будет не миллион, а всего 1-2 реальных пустышек Миллион был указан про число хранимых\найденных пустышек в кэше (они при этом могут быть идентичными между собой), а не про число образцов. Разумеется, миллион уникальных образцов - это, прямо скажем, многовато. Кто бы спорил. >То, чем покрыты акияны - синие квадраты - пустышками считать нельзя. А предыдущий оратор считал, что "не нравится что она записывает в кэш пустые тайлы (и не нулевого размера)". О чем, собссно, и речь после упоминания о том, что понятия пустышки для каждого - разные. Я уж не говорю о том, что "пустой файл ненулевого размера" это взаимоисключающие параграфы сами по себе и поди ж там пойми без наводящих вопросов - уж не до хорошего... :)

(0008824) Parasite (administrator) 11-09-2012 13:33	>Имхо, папка в корне кэша соотв.карты - самое удобное Кстати, никто так ничего вменяемого и не сказал на тему того, чтобы не ставить какую-то .tne-хрень на месте пустышки, а попробовать ставить линк в кэше на этот единственный тайл в папке. Очень многие вопросы снялись бы...

(0008825) Dima2000 (developer) 11-09-2012 13:45	>никто так ничего вменяемого и не сказал на тему того Да потому что весьма специфично от ФС получается и заметно сложнее в реализации. А вопросы как снялись, так и добавились бы новые.

(0008826) Parasite (administrator) 11-09-2012 13:55	>весьма специфично от ФС получается Угу. Но с другой стороны - у нас уже есть вкладка "копирование кэша", которую можно обучить на тему "если пишем на ФС не поддерживающую линковку - то писать туда target-file a не линк". Это имхо заметно проще, чем пляски со всеми этими tne, удалениями и побайтовыми сравнениями. >заметно сложнее в реализации C каких пор программно поставить линк стало заметно сложнее? >А вопросы как снялись, так и добавились бы новые. Огласите весь список, пжалста. Рассмотрим.

(0008828) Tolik (manager) 11-09-2012 14:56 edited on: 11-09-2012 15:00	Нет-нет, все эти вопросы - о линках, папках в корне, очищалках кэша и т.д. - и есть флуд (или офтопик). Есть хотелка: фильтровать мусор во время скачки. Есть предложение: см. пост vdemidov 0000011:0008817. Осталось только его реализовать.

(0008829) vdemidov (manager) 11-09-2012 15:18	Добавил возможность при закачке проверять тайлы на равенство одному из образцов пустого тайла. Образцы хранятся в zmp в подпапке EmptyTiles.

(0008831) vasketsov (manager) 11-09-2012 16:41	>тайлов в папочку по Пкм >вы не дождетесь и тикет сразу прибьют Как только будет изменена концепция и начнём писать в zmp (или как пустышки можно будет хранить не только в zmp) - так сразу. Это исключительно организационный вопрос, с технической точки зрения это ерунда и фигня в одном флаконе, пишется за 5 минут. >"пустой файл ненулевого размера" это взаимоисключающие параграфы сами по себе Пустой с точки зрения саса может быть и пустой KML для wiki - вот кстати заодно и потестим щас )))

Users who viewed this issue
User List	Anonymous (8054x), rass (1x), k-dmitriy (2x), looo (1x)
Total Views	8058
Last View	21-11-2024 12:35

Issue History
Date Modified	Username	Field	Change
06-08-2010 20:08	vdemidov	New Issue
06-08-2010 20:08	vdemidov	Status	new => assigned
06-08-2010 20:08	vdemidov	Assigned To	=> vdemidov
06-08-2010 20:13	vdemidov	Relationship added	child of 0000012
24-08-2010 06:37	DJ VK	Note Added: 0000122
30-08-2010 10:15	vdemidov	Target Version	100830.Alfa => 110311.Alfa
31-08-2010 14:24	gpsMax	Note Added: 0000156
31-08-2010 14:54	vdemidov	Note Added: 0000159
31-08-2010 15:04	gpsMax	Note Added: 0000160
08-11-2010 14:42	gpsMax	Tag Attached: загрузка
09-11-2010 04:51	Parasite	Note Added: 0000434
09-11-2010 08:16	vdemidov	Note Added: 0000439
09-11-2010 16:52	Parasite	Note Added: 0000441
10-11-2010 07:14	vdemidov	Note Added: 0000451
13-11-2010 10:57	gpsMax	Tag Attached: закачка
13-12-2010 11:55	vdemidov	Target Version	110311.Alfa => 24xxxx
06-04-2011 22:28	gpsMax	Relationship added	related to 0000022
09-04-2011 11:22	gpsMax	Tag Attached: пустые тайлы
23-07-2011 10:50	vdemidov	Relationship added	has duplicate 0000681
04-09-2011 11:16	zOn	Note Added: 0003670
04-09-2011 11:18	zOn	Note Edited: 0003670	View Revisions
04-09-2011 12:31	vasketsov	Note Added: 0003674
04-09-2011 12:45	zOn	Note Added: 0003675
06-09-2011 10:28	vdemidov	Note Added: 0003725
06-09-2011 10:30	zOn	Note Added: 0003726
06-09-2011 17:24	vasketsov	Note Added: 0003748
06-09-2011 17:37	zOn	Note Added: 0003751
07-09-2011 15:01	Tolik	Note Added: 0003775
07-09-2011 15:12	zOn	Note Added: 0003776
07-09-2011 15:17	zOn	Note Edited: 0003776	View Revisions
07-09-2011 15:18	Tolik	Note Added: 0003777
07-09-2011 16:57	zOn	Note Added: 0003780
07-09-2011 16:57	zOn	Note Edited: 0003780	View Revisions
07-09-2011 16:58	zOn	Note Edited: 0003780	View Revisions
08-09-2011 05:23	Parasite	Note Added: 0003785
08-09-2011 05:30	zOn	Note Added: 0003786
08-09-2011 05:56	Parasite	Note Added: 0003788
08-09-2011 08:28	Snake	Note Added: 0003795
08-09-2011 17:37	gpsMax	Note Added: 0003801
08-09-2011 17:56	zOn	Note Added: 0003804
09-09-2011 04:32	gpsMax	Note Added: 0003808
09-09-2011 05:13	zOn	Note Added: 0003812
09-09-2011 11:00	vasketsov	Note Added: 0003820
09-09-2011 11:01	vasketsov	Note Edited: 0003820	View Revisions
09-09-2011 11:02	vasketsov	Note Edited: 0003820	View Revisions
09-09-2011 11:09	zOn	Note Added: 0003821
24-07-2012 19:48	vdemidov	Relationship added	has duplicate 0001403
24-07-2012 20:26	vdemidov	Assigned To	vdemidov =>
24-07-2012 20:26	vdemidov	Status	assigned => confirmed
04-09-2012 07:14	Dima2000	Note Added: 0008675
04-09-2012 07:40	Parasite	Note Added: 0008678
04-09-2012 07:41	Parasite	Note Edited: 0008678	View Revisions
04-09-2012 07:44	Dima2000	Note Added: 0008679
04-09-2012 07:48	Dima2000	Note Edited: 0008679	View Revisions
04-09-2012 07:48	Parasite	Note Edited: 0008678	View Revisions
04-09-2012 08:02	Parasite	Note Added: 0008680
04-09-2012 08:24	Dima2000	Note Added: 0008681
04-09-2012 08:25	Dima2000	Note Edited: 0008681	View Revisions
04-09-2012 08:49	Parasite	Note Added: 0008682
04-09-2012 08:51	Parasite	Note Edited: 0008682	View Revisions
04-09-2012 09:13	Dima2000	Note Added: 0008683
04-09-2012 09:52	Parasite	Note Added: 0008684
04-09-2012 10:07	Dima2000	Note Added: 0008685
04-09-2012 10:24	Parasite	Note Added: 0008686
04-09-2012 10:27	Parasite	Note Edited: 0008686	View Revisions
05-09-2012 07:43	vasketsov	Note Added: 0008703
05-09-2012 07:55	vasketsov	Note Edited: 0008703	View Revisions
05-09-2012 07:57	vasketsov	Note Edited: 0008703	View Revisions
05-09-2012 08:32	vdemidov	Note Added: 0008704
05-09-2012 14:00	Dima2000	Note Added: 0008706
05-09-2012 14:20	Parasite	Note Added: 0008707
05-09-2012 14:26	vdemidov	Note Added: 0008708
05-09-2012 14:29	Parasite	Note Added: 0008709
05-09-2012 14:34	vdemidov	Note Added: 0008710
05-09-2012 14:44	Parasite	Note Added: 0008711
05-09-2012 14:47	zOn	Note Added: 0008712
05-09-2012 15:27	bk99	Note Added: 0008713
05-09-2012 16:25	Dima2000	Note Added: 0008715
05-09-2012 18:26	vasketsov	Note Added: 0008716
05-09-2012 19:17	vdemidov	Note Added: 0008718
05-09-2012 19:24	vasketsov	Note Added: 0008719
05-09-2012 19:31	vdemidov	Summary	Добавить детектирование пустых тайлов => Добавить детектирование пустых тайлов во время закачки
06-09-2012 03:52	vdemidov	Note Added: 0008722
06-09-2012 03:53	Parasite	Note Added: 0008723
06-09-2012 03:56	Parasite	Note Edited: 0008723	View Revisions
06-09-2012 04:46	Dima2000	Note Added: 0008724
06-09-2012 05:43	Parasite	Note Added: 0008727
06-09-2012 08:35	vasketsov	Note Added: 0008728
06-09-2012 08:44	vdemidov	Note Added: 0008729
06-09-2012 09:11	Dima2000	Note Added: 0008730
06-09-2012 09:13	Dima2000	Note Edited: 0008730	View Revisions
06-09-2012 09:14	Dima2000	Note Edited: 0008730	View Revisions
06-09-2012 09:14	Dima2000	Note Edited: 0008730	View Revisions
06-09-2012 09:16	Dima2000	Note Edited: 0008730	View Revisions
06-09-2012 09:19	Dima2000	Note Edited: 0008730	View Revisions
06-09-2012 09:27	Dima2000	Note Added: 0008731
06-09-2012 09:31	vdemidov	Note Added: 0008732
06-09-2012 09:33	Parasite	Note Added: 0008733
06-09-2012 09:41	Parasite	Note Added: 0008734
06-09-2012 09:45	vdemidov	Note Added: 0008735
06-09-2012 09:50	Dima2000	Note Added: 0008736
06-09-2012 09:53	Dima2000	Note Edited: 0008736	View Revisions
06-09-2012 09:58	Dima2000	Note Added: 0008737
06-09-2012 10:04	Parasite	Note Added: 0008738
06-09-2012 10:12	Parasite	Note Added: 0008739
06-09-2012 10:15	Parasite	Note Edited: 0008739	View Revisions
06-09-2012 10:17	Parasite	Note Edited: 0008739	View Revisions
06-09-2012 10:45	vdemidov	Note Added: 0008740
06-09-2012 11:14	Parasite	Note Added: 0008741
06-09-2012 11:15	Parasite	Note Edited: 0008741	View Revisions
06-09-2012 14:58	bk99	Note Added: 0008742
06-09-2012 16:39	vasketsov	Note Added: 0008743
06-09-2012 17:41	Dima2000	Note Added: 0008744
06-09-2012 19:03	vdemidov	Note Added: 0008745
07-09-2012 03:38	Parasite	Note Added: 0008748
07-09-2012 04:57	bk99	Note Added: 0008749
07-09-2012 16:52	Dima2000	Note Added: 0008759
10-09-2012 04:09	Parasite	Note Added: 0008766
10-09-2012 09:10	vdemidov	Note Added: 0008767
10-09-2012 11:12	vasketsov	Note Added: 0008774
10-09-2012 11:13	vasketsov	Note Edited: 0008774	View Revisions
11-09-2012 05:21	Dima2000	Note Added: 0008786
11-09-2012 05:53	Parasite	Note Added: 0008789
11-09-2012 06:00	Parasite	Note Edited: 0008789	View Revisions
11-09-2012 06:04	Parasite	Note Edited: 0008789	View Revisions
11-09-2012 06:50	Dima2000	Note Added: 0008794
11-09-2012 07:13	vasketsov	Note Added: 0008796
11-09-2012 07:27	Dima2000	Note Added: 0008797
11-09-2012 07:40	vasketsov	Note Added: 0008798
11-09-2012 08:12	Parasite	Note Added: 0008799
11-09-2012 08:13	Parasite	Note Edited: 0008799	View Revisions
11-09-2012 08:17	Parasite	Note Added: 0008800
11-09-2012 08:42	Dima2000	Note Added: 0008801
11-09-2012 08:43	Parasite	Note Added: 0008802
11-09-2012 08:52	Parasite	Note Edited: 0008802	View Revisions
11-09-2012 09:03	Dima2000	Note Added: 0008803
11-09-2012 09:03	Dima2000	Note Edited: 0008803	View Revisions
11-09-2012 09:04	Dima2000	Note Edited: 0008803	View Revisions
11-09-2012 09:04	Dima2000	Note Edited: 0008803	View Revisions
11-09-2012 09:16	vasketsov	Note Added: 0008804
11-09-2012 09:17	Parasite	Note Added: 0008805
11-09-2012 09:24	Parasite	Note Added: 0008806
11-09-2012 09:32	vasketsov	Note Added: 0008807
11-09-2012 09:43	Parasite	Note Added: 0008808
11-09-2012 09:45	Parasite	Note Edited: 0008808	View Revisions
11-09-2012 09:45	Parasite	Note Edited: 0008808	View Revisions
11-09-2012 10:16	vasketsov	Note Added: 0008809
11-09-2012 10:44	vasketsov	Note Edited: 0008809	View Revisions
11-09-2012 10:44	Parasite	Note Added: 0008810
11-09-2012 11:00	Dima2000	Note Added: 0008812
11-09-2012 11:03	Parasite	Note Added: 0008813
11-09-2012 11:06	zOn	Note Added: 0008814
11-09-2012 11:16	Parasite	Note Added: 0008815
11-09-2012 11:19	vasketsov	Note Added: 0008816
11-09-2012 11:19	vdemidov	Note Added: 0008817
11-09-2012 12:02	Tolik	Note Added: 0008818
11-09-2012 12:05	Tolik	Note Edited: 0008818	View Revisions
11-09-2012 12:07	Tolik	Note Edited: 0008818	View Revisions
11-09-2012 12:07	Tolik	Note Edited: 0008818	View Revisions
11-09-2012 12:36	zOn	Note Added: 0008819
11-09-2012 12:47	Dima2000	Note Added: 0008820
11-09-2012 12:56	zOn	Note Added: 0008821
11-09-2012 13:24	Dima2000	Note Added: 0008822
11-09-2012 13:27	Parasite	Note Added: 0008823
11-09-2012 13:33	Parasite	Note Added: 0008824
11-09-2012 13:45	Dima2000	Note Added: 0008825
11-09-2012 13:55	Parasite	Note Added: 0008826
11-09-2012 14:56	Tolik	Note Added: 0008828
11-09-2012 15:00	Tolik	Note Edited: 0008828	View Revisions
11-09-2012 15:18	vdemidov	Note Added: 0008829
11-09-2012 15:18	vdemidov	Status	confirmed => resolved
11-09-2012 15:18	vdemidov	Fixed in Version	=> 121010
11-09-2012 15:18	vdemidov	Resolution	open => fixed
11-09-2012 15:18	vdemidov	Assigned To	=> vdemidov
11-09-2012 15:22	vdemidov	Target Version	24xxxx => 121010
11-09-2012 16:41	vasketsov	Note Added: 0008831
13-09-2012 13:10	Dima2000	Relationship added	related to 0001562

SASGIS