parasss Junior Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: гугл, перед тем как начать работу с сервером, проверяет действительно ли это сервер гугла, Чушь какая.   Цитата: Подобная проверка сервера (обмен запросами) происходит и во время работы гугла, с периодичностью 5-10 минут.   Дважды чушь. С периодичностью в 300 секунд идет перезапрос сессии с сервера, коя сессия используется при утягивании тайлов.   Цитата: Т.е. вся загвоздка в формировании правильного ответа на запрос гугла. "Правильный ответ на запрос гугла" неизменен во времени для каждой версии клиента, и банально ловится сниффером. Ничего не мешает сдампить байты и выдавать этот ответ уже эмулятором. При конечном числе версий клиента - будет всегда конечное число возможных выдаваемых ответов, выдавать кои можно и без глубокого понимания процесса авторизации Keyhole.     Всего записей: 159 | Зарегистр. 21-05-2007 | Отправлено: 08:10 16-04-2009

zedxxx Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Уважаемый, parasss, Вы не правы! Для того, чтобы начать работу с сервером, клиент инициирует авторизацию на сервере (это и есть проверка сервера, т.к. никто другой, правильго ответа на запрос не даст). Называть это чушью я бы не стал. Затем, с непостоянной периодичностью, эти запросы повторяются (обычно 5 минут с хвостиком). 300 секунд - 5 минут Цитата: "Правильный ответ на запрос гугла" неизменен во времени для каждой версии клиента, и банально ловится сниффером. Так словите, и увидите, что ответы разные. Могу прислать вам пачку ответов, если самому лень... Смысл в том, что в теле ответа сервера записаны coocie, которые уже потом клиент выдаёт в заголовках запросов.   Цитата: выдавать кои можно и без глубокого понимания процесса авторизации Keyhole. Как на счёт практической реализации? Раз вы говорите можно, то попробуйте сделать? Всего записей: 1535 | Зарегистр. 14-07-2008 | Отправлено: 11:30 16-04-2009

parasss Junior Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Для того, чтобы начать работу с сервером, клиент инициирует авторизацию на сервере   Верно.   Цитата: это и есть проверка сервера Не существует никакой "проверки сервера".   Цитата: т.к. никто другой, правильго ответа на запрос не даст.   Это банальная авторизация по сессиям. Нет ничего сложного ввести и запросить сессию на локальном HTTP-сервере - никакого отношения к "проверке гуглесервера" это не имеет, отдавать сессии можно и через локального Апача специально написанным скриптиком (да, это работает, и клиент проходит авторизацию - но практического смысла никакого не несет).   Цитата: Называть это чушью я бы не стал.   Достаточно и того, что так ее уже назвал я.   Цитата: Затем, с непостоянной периодичностью, эти запросы повторяются (обычно 5 минут с хвостиком).   TTL выданной сессии передается клиенту в составе того же ответа, что и имя сессии. По дефолту это - 300 секунд. Непостоянство же обьясняется еще проще: так как сессии нужны только для обмена с сервером, то при отсутствии необходимости обмена (например тайл берется из кэша) - они и не перезапрашиваются, либо перезапрашиваются автоматически в "щадящем режиме" с той или иной долей рандомности - это уже зависит от версии клиента. На механизм работы это никак не влияет - главное отдавать имя текущей сессии гуглю в течении TTL оной, по истечении - запросить свежую.     Цитата: 300 секунд - 5 минут   Я умею считать, спасибо.     Цитата: Так словите, и увидите, что ответы разные.   Разные имена выдаваемых сервером сессий, не более того. Так и должно быть.   Передаваемый же клиентом на сервер запрос (до получения сессии) - неизменен.   Цитата: в теле ответа сервера записаны coocie, которые уже потом клиент выдаёт в заголовках запросов.   Верно.   Только где тут "проверка, действительно ли это сервер гугла"?     Цитата: Как на счёт практической реализации? Раз вы говорите можно, то попробуйте сделать?   Реализация есть, работает у меня уже несколько лет. Мы это уже обсуждали с Вами на форуме САСпланеты пару месяцев назад. Всего записей: 159 | Зарегистр. 21-05-2007 | Отправлено: 12:48 16-04-2009

parasss Junior Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: А проверка в том, что "левый" ответ клиент не принимает.   Прекрасно принимает (версия 3.0.0.616).   Цитата: Потому я и удивлён вашим постом "не в тему", вы же сами писали, что это нереально: Вообще-то ТОГДА я писал о полном функциональном копировании функций гуглесервера к себе (что далеко выходит за рамки действия "подсунуть клиенту ранее запрошенный блок данных", что умеет даже Сквид - кой успешно и юзается). Полное же копирование функций ГЕ сервера практически нереально, имхо.     Сейчас же я пишу об отсутствии "проверки гуглесервера", и эмулировании функции "LOGIN" (которая есть далеко не самая технически сложная в функционале сервера ГЕ).   Это немного разные темы, Вы не находите?     Всего записей: 159 | Зарегистр. 21-05-2007 | Отправлено: 13:52 16-04-2009

parasss Junior Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору А как насчёт более свежих версий клиента, скажем 5.0? А зачем, если все работает?   PS: только что проверил работу вышеуказанной версии. Периодически еррорит при парсинге свежеполученного dbroot (нет списка свежепоявившихся с того времени слоев) при запуске напрямую. При забанивании УРЛа проверки апдейтов, подсовывании старого dbroot от 2005го года через проксик - прекрасно проходит авторизацию на гугле и столь же прекрасно тянет текущие гуглетайлы. Ничего-то там не изменилось со времен Кейхола.....     Вы готовы описать алгоритм и выложить скрипты Помнится, Вы это уже спрашивали меня через САС. Предлагаю переместиться опять туда, чтобы не утомлять тутошних окружающих.   PS: прошу больше не выкладывать детали личной переписки в паблик без предварительного на то согласия. Спасибо. Всего записей: 159 | Зарегистр. 21-05-2007 | Отправлено: 14:35 16-04-2009 | Исправлено: parasss, 14:44 16-04-2009

zedxxx Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору ОК, переместились в САС. Будем разводить секреты там, в ЛС   Добавлено: QQMATS, Цитата: Настораживает:   - жесткий диск "стучит головой", что ли пишет порциями В новой версии GC помимо чтения из индекса, производится ещё и запись в него. Причём запись идёт напрямую для каждого тайла, без какой-либо буферизации. Чтобы поберечь веник от излишней загрузки, я решил пока использовать RAM диск, чего и вам советую. (Есть ещё отличное решение: RamDisk Plus 9, но он платный, и нужно искать ключики.) И по-идее, скорость поиска/запись в индекс должна увеличиться. Из достоинств именно этого решения RAM диска я заметил: Цитата: - Возможность загрузки сохранённого образа диска и заполнения содержимого RAM-диска в момент инициализации драйвера (скорость загрузки - около 30 секунд на 1 ГБ при условии, что образ сохранён на жёстком диске с режимом 4 IDE ATA при процессоре с частотой 1,2 ГГц). - Возможность сохранения содержимого в образ диска при завершении работы, а также через регулярные интервалы или в заданные моменты времени.   Т.е. один раз настроил сохранение/загрузку RAM диска из образа, и всё работает.   Единственное, в следующей версии GC надо будет добавить возможность произвольного места расположения файлов индекса и DefCache.   Ну и понятно, что размер RAM диска должен быть больше чем размер индексного файла, и на этот же размер у нас уменьшится оперативка. Если возможности железа позволяют, то по-моему это идеальное решение (в плане быстродействия). Всего записей: 1535 | Зарегистр. 14-07-2008 | Отправлено: 15:04 16-04-2009 | Исправлено: zedxxx, 20:38 17-04-2009

parasss Junior Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Zedxxx, то что говорил  parasss, это набор букв Нет, это хокку вежливого содержания - прости мя, Господи......... Всего записей: 159 | Зарегистр. 21-05-2007 | Отправлено: 17:34 21-04-2009

zedxxx Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору GeoCacher 1.2.3: - статистика использования кэша, для отображения в мониторе   Теперь, для каждого GE url-а можно получить информацию о том, из какого кэша тайл взят, и в какой загружен (с полными путями). Приняты обозначения: G - тайл взят из кэша GE F - тайл взят из файлового кэша GC T - тайл взят из тайлового кэша GC I - тайл загружен из интернета   В колонку монитора Источники, заносится инфа об источниках, загруженных тайлов. Например, запись F5:44 - означает, что тайл взят из файлового кэша №5, и из этого кэша уже взято 44 тайла. Номер кэша берётся из индекса (GCIndex.db3) - колонка CacheID. Нумерация кэшей сквозная, т.е. если есть кэш F5, то кэша G5 уже быть не может. Источники кэша T и I номера не имеют, а только число тайлов. В колонке монитора URL, во всплывающей подсказке прописаны пути сохранения/загрузки тайла. Пример записи из подсказки: Код: http://khmdb.google.com/flatfile?db=tm&f1-020300031202333311-i.6-fa8bf+f1-020300031202333312-i.6-fa8bf&v=1 f1-020300031202333311-i.6-fa8bf <-- E:\GC_CachePath\!!!_TILES_CACHE_!!!\History\Images\18\f1-020300031202333311-i.6-fa8bf f1-020300031202333312-i.6-fa8bf --> E:\GC_CachePath\!!!_FILES_CACHE_!!!\History\Images\Images_fa8bf.dbx   При помощи стрелочек указано направление тайла:   --> запись в кэш; <-- чтение из кэша   В строке состояния, заносится общая статистика использования источников кэша.   Вот скриншот:     Данную функцию можно отключить чекбоксом Вести статистику использования кэша на вкладке Кэш. Всего записей: 1535 | Зарегистр. 14-07-2008 | Отправлено: 15:22 22-04-2009 | Исправлено: zedxxx, 16:50 22-04-2009

QQMATS Newbie Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Чтой-то я  за Вами не успеваю Про относительный путь:   - работает с перевыполнением. Попытка прописать относительные пути в окнах  настройки GC приводит к созданию кучи каталогов с именами, генерируемыми после каждого нажатия клавиши на клавиатуре типа таких -   GC\П GC\ПС GC\ПС_ GC\_ GC\С_ GC\_П GC\_ПС GC\_G GC\_GC GC\_GC_ GC\_GC_C GC\_GC_Ca GC\_GC_Cah GC\_GC_Cahe GC\_GC_Cache GC\_GC_Caсhe  --------  отследились даже  срабатывания PuntoSwitcher (автомат перевода раскладки) последний каталог создался дважды. Как ему это удалось?   в C:\Temp\Earth появились  файлы   Images.dbx Index_196.dbx Terrain_188.dbx Terrain_192.dbx Terrain_196.dbx Попробовал указать другой путь к файловому кешу, туда прописался DefCache.dbx и растёт, остальные *.dbx-сы никакой реакции  не проявили. Это типа  черновики? И что тогда кеш?   попытка вернуть "пустые пути" провалилась - GC возвращает ранее прописанныые папки.   Растут панические настроения Всего записей: 31 | Зарегистр. 24-03-2008 | Отправлено: 21:06 22-04-2009

zedxxx Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Попытка прописать относительные пути в окнах  настройки GC приводит к созданию кучи каталогов с именами, генерируемыми после каждого нажатия клавиши на клавиатуре Да, есть такое. Путь лучше либо вставлять сразу, либо использовать диалог, ну или предварительно прописать в ini (тем более, что для того, чтобы индекс стал храниться по новому пути, программу нужно перезапустить).   Цитата: Это типа  черновики?   И что тогда кеш? По поводу файлового кэша наверное нужно прояснить: 1. Количество файлов кэша *.dbx может быть сколь угодно много, либо всего один (ну, или ни одного, если этот тип кэша отключён). 2. Размер одного файла *.dbx не ограничен. 3. По-умолчанию файловый кэш подлежит сортировке, подобно тайловому кэшу. Т.е. если для тайлового кэша было настроено, что картинки 10-го зума будут сохраняться в папку с:\images\10\ то для файлового кэша может быть аналогичная настройка, с той лишь разницей, что вместо целевой папки, будет указан файл: с:\images\10.dbx. Вся сортировка файлового кэша построена по-аналогии с тайловым. Правила, по которым выполняется сортировка - в файле FileCacheRE.ini. 4. Если сортировка настроена неправильно, или файла FileCacheRE.ini нет в положенном месте, и при всём при том, включена опция сохранения в файловый кэш - все данные будут сохраняться в один файл - DefCache.dbx. В этот же файл будут писаться все тайлы, не попавшие под правила в FileCacheRE.ini. Но по-умолчанию, сделано так, что в DefCache.dbx ничего писаться не должно - всё должно сортироваться, аналогично тайловому кэшу, в папку !!!_FILE_CACHE_!!!, которая создаётся в директории по-умолчанию для файлового кэша. 5. FileCacheRE.ini определяет сортировку файлового кэша для записи. Любой, уже заполненный, dbx файл, можно подключить в режиме только чтение - достаточно расположить его вне пути по-умолчанию, или переименовать оригинально (главное чтобы в FileCacheRE.ini небыло правила на аналогичный файл) и проиндексировать его анологично, как это было с кэшем GE. 6. Помимо этого, для файлового кэша введена возможность сортировки по координатам, загружаемых тайлов. Т.е. можно сделать так, чтобы один город/регион сохранялся в один файл, другой - в другой, а всё остальное, что не относится к этим городам - в третий. Координаты регионов (фильтры) определяются в Filtr.ini. А уже определённые фильтры иcпользуются в FileCacheRE.ini. (В шапках всех ini файлов написаны небольшие пояснения, которые помогут разобраться что к чему).   7. Внутренняя структура файла *.dbx практически 1 в 1 идентична структуре файлов кэша GE.   Вот такой вот файловый кэш. По-моему, очень гибкий (мне, по крайней мере, нравиться и я полностью отказался от тайлового кэша - в пользу dbx). Цитата: попытка вернуть "пустые пути" провалилась - GC возвращает ранее прописанныые папки Верно, GC не может писать в пустоту - в этом случае вновь введённый путь игнорируется, а используется прошлый, и так до тех пор, пока не будет указан путь, по которому будет возможно что-то записать.   Чё у вас такие проблемы с путями? Закройте GC, пропишите в ini файл пути (можно всюду .\), сохранитесь, и запускайте GC. Так должно сработать железно. Цитата: Растут панические настроения Панические настроения отставить! Всё работает как часы Пробуйте, настраивайте. Всего записей: 1535 | Зарегистр. 14-07-2008 | Отправлено: 09:50 23-04-2009 | Исправлено: zedxxx, 10:04 23-04-2009

QQMATS Newbie Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Панические настроения отставить! Есть отставить! Разобрался. Но вопросы есть 1. Что бывает, если GE не получает от сервера запрошенный файл? И если ничего страшного, то можно ли сократить время ожидания до нуля? Это к тому, что если на медленном интернете пропускать только авторизацию, а на остальные запросы возвращать ошибку типа "файл не найден". Убрав таким образом узкое место, когда связка GE-GC зависает в ожидании файлов из инет. Изображение будет неполным, но в ряде случаев это неважно, так как "нужные места" есть в кеше в высоком разрешении, а вся система начинает тормозить "на подлёте", пытаясь подкачать, более грубые слои. Типа опции "медленный инет"   2. Почти все иконки  в GE заменились одной и той же (Wiki), даже в левой панели "слои". Нашел массу  иконок в кеше и рабочих папках GE, пытался их заменять/удалять ноль эффекта. Откуда GE подкачивает свои иконки? Может это быть связано с работой GC? Всего записей: 31 | Зарегистр. 24-03-2008 | Отправлено: 23:08 28-04-2009

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

Компьютерный форум Ru.Board » Компьютеры » Программы » GeoCacher

Переход по форумам  Закладки   » Компьютеры Цифровое изображение Программы Microsoft Windows UNIX Другие OS Hardware В помощь сисадмину Прикладное программирование Игры Форумные игры   » Интернет Web-программирование В помощь вебмастеру Графика Хостинг Зацените-ка!   » Тематические Ikonboard v.2 Ikonboard v.3 Invision Board Другие форумы PHP-Nuke и другие порталы Мобила   » Общие Спорт Флейм Темы по региональным встречам Музыка и Кино Юмор Литература и Живопись   » Ru.Board Новости Помощь по форуму   » Андеграунд eBookz Варезник Раздачи и акции Мобильный варезник Андеграунд Игры и фильмы   » Специальные Тестирование