» GeoCacher

Ну наконецто.Все отлично работает(v.1.1.3).Остались мелочи:

-Нужно правило,или галочка,на загрузку(обновление)файла:dbRoot.v5?hl=ru-RU&gl=ru.Почему-грузит долго с инета(15 сек.в среднем,с мобильным инетом)и нужен он раз в месяц.А также весит 0.1мб.(мне лично дороговато).

-И почемуто галочка на многопоточность,после перезагрузки прокси,слетает.(ну может она мне и ненужна)

А в целом все супер!!!Можно полностъю уберать HC в связке GE+HC+GC=инет.По крайней мере я уже невижу в етом смысла.Все сочтено и учтено в последнем GC прокси сервере.

Juliys, поддерживаю ! Автору проги троекратное ура !!! Молодца !

Цитата:

Автору проги троекратное ура !!! Молодца !

А можно и материально поддержать проект;) Кто чем может.
Я вот мог бы класть денег на указанный автором в мыло 2934@rambler.ru телефон. (Если реально сделать это из РФ). Или ещё как.

В процессе эксплуатации захотелось следующих навесных деталей:
- горячую кнопку отключения загрузки из кеша GC (нужно когда переходишь к скачиванию какой-либо области на анлимите. Сейчас приходится выходить из GE, отключать прокси в IE, загружать GE по-новой. В таком варианте теряется кеширование GC сопутствующей инфы, в частности Panoramio. Неудобно)
- хоть примитивной, но возможности управлять проиндексированными кешами от GE (Когда их больше десятка, начинаются проблемы с дежавю, типа "кажется я это уже индексировал". А также - возможность выбирать в GC между наборами проиндексированных кешей, желательно на-лету. Ибо при разрастании "архива" кешей GE задача по поиску в них тайлов становится сравнимой с Гугловским сервером. А зачем? Если можно комфортно переключаться между наборами "любимых" кешей. Хотя бы иметь возможность переименовывать (и подключать) файлы GCindex.db3)

Цитата:

- горячую кнопку отключения загрузки из кеша GC (нужно когда переходишь к скачиванию какой-либо области на анлимите. Сейчас приходится выходить из GE, отключать прокси в IE, загружать GE по-новой. В таком варианте теряется кеширование GC сопутствующей инфы, в частности Panoramio. Неудобно)

мне тоже нужно

А вот и первый глюк связки GC_GE )
Кто скажет как прикрепить изображение?
В районе острова Бахрейн (Персидский залив) вылезли не те тайлы. Высота 975 км и меньше. довольно обширная площадь. Границы и дороги - в порядке.

Цитата:

Кто скажет как прикрепить изображение?

Заливаете не сторонний картино-обменник, а сюда ссылку с превью.


Цитата:

В районе острова Бахрейн (Персидский залив) вылезли не те тайлы.

Отдача шла из кэша GE?

ZEDXXX-прозьба!!! Зделать правило,или галочку на загрузку(обновление)файла:dbRoot.v5?hl=ru-RU&gl=ru.Почему?-грузит долго с инета(15 сек.в среднем,с мобильным инетом)и нужен он раз в месяц.А также весит 0.1мб.(мне лично дороговато).
Я в програмировании дуб дерево.Напишите здесь,в форуме,правило.Вам же ето легко.Так сказать"на лету".А я страдаю-привык к мгновенному старту гугла.Он брал все начальные файлы с HC.Но щас полностью перешел на ваш прокси.
Или может кто-то напишет правило...

Juliys,
в следующей версии сделаю такое, а пока, если это вас сильно напрягает - используйте связку с HandyCache.

GeoCacher 1.2.0 - версия для тестов. Добавлено:
- свой тип кэша одним файлом;
- возможность выбора из какого кэша читать и в какой писать;
- пунктик Не обновлять dbRoot.

Если у кого-то есть возможность: погоняйте GC в разных режимах. Особенно интересует работа с новым кэшем, и будут ли проблемы при его размере в 2Гб и более.

Вроде работает..
Только галочки по прежнему не сохраняютса..слетают после перезагрузки проги,на умолчание(такое впечатление что они забронированы автором).И даже многопотоковый режим стал работать(ну по крайней мере галка стоит).Ну а остальные настройки изменяемы.
Текущий баг гугла(Google Earth 5.0.11337.1968 (beta))-по нескольку раз шлет одни и теже запросы,и прокси паралельно качает по нескольку одинаковых файлов.Замечаетса в картинках jpg и kmz файлах.Можно ли ето устранить?.Пробовал последний гугл,в нем много багов.И с моим интернетом работет очень медленно(всего в 2 потока(Google_Earth_Pro_Final_With_license_Key_4.3.7191.6508)).

Прошу прощения за может быть глупость (полный ZERO в прокси), но как Планету отлучить ввобще от инета? т.е. Инета нет на том компе на котором хочу получать тайлы из GC. При отсутствии инета Планета не хочет тянуть из GC может я чет не то делаю? Помогите пожалуйста..

Цитата:

При отсутствии инета Планета не хочет тянуть из GC может я чет не то делаю?

Всё так. Вы внимательно читали описание GeoCacher-a?

Цитата:

...предназначенный для эффективного он-лайн кэширования запросов GoogleEarth

Цитата:

как Планету отлучить ввобще от инета?

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

Вот, мне задавали похожий вопрос:

Цитата:

Цитата: Вопрос такого плана: нельзя ли как-нибудь сэмулировать сервер Планеты, чтобы
прога думала что в интернете и качала всю возможную инфу из ранее
распакованного кэша...

Если коротко, то нет. На данный момент полная эмуляция сервера
невозможна. Однако возможна 99 процентная эмуляция. Дело в том, что
гугл, перед тем как начать работу с сервером, проверяет действительно
ли это сервер гугла, отправляя короткий запрос авторизации (методом POST, размер
запроса менее 50 байт), на этот запрос сервер выдаёт ответ (размер
ответа тоже мизерный - менее 150 байт). И только если ответ сервера
правильный, гугл начинает выдавать запросы в инет и работу с сервером.
Подобная проверка сервера (обмен запросами) происходит и во время работы
гугла, с периодичностью 5-10 минут. Т.е. вся загвоздка в
формировании правильного ответа на запрос гугла. Как это сделать и по
каким алгоритмам он формируется я без понятия, и инфы такой нигде не
встречал.

Это был тоже я

JHellraiser
Цитата:

как Планету отлучить ввобще от инета?

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

Шлялся по Черноморскому побережью, инет в горах есть, но не везде и GPRS. Cменилась версия баз google, остался без карты почти на день. Новую версию GC скачал только по возвращении. Как бы мне пригодилась функция "не обновлять DBROOT"! Попутно вопрос: в папке ..\!!!_TILES_CACHE_!!!\Earth\dbRoot.v5\ лежит у меня файл hl=ru-RU&gl=ru.193, где расширение есть номер версии. Это GC его так поименовал или я руками переименовывал (не помню)?, но убрав расширение и скормив его GE - мигом восстановил "родные места".
Отсюда Предложение:
- сохранять файлы версий в формате hl=ru-RU&gl=ru.NNN (NNN-номер версии)
- галку "не обновлять DBRoot" трансформировать в выпадающее меню с номерами доступных версий (в идеале GC мог бы вообще брать файлы hl=ru-RU&gl=ru из проиндексированных кешей, тогда станут доступны все когда-либо скачанные версии, что гууд), ну и индицировать где-нить можно, что качается "не родная" текущая версия. Красным.
В целом GC1.2- подозрительно хорош для первоапрельской версии
Омрачает:
- несохранение галок,
- невозможность настройки путей (имён) файлов DefCache.dbx, GCindex.db3
Настораживает:
- жесткий диск "стучит головой", что ли пишет порциями
-
Просится:
- встроенная или отдельная утилита по переводу тайлового кеша в файловый (и наоборот) с функцией отсекания лишнего
- какая-нить визуальная индикация в мониторе gc о текущих настройках кеша GC (откуда берёт/куда пишет/какую версию качает), а то уже есть где запутаться
К сведению:
- дважды вылезло окно про регистрацию компонента

Доберусь до анлимита, попробую заполнить DefCache.dbx. Видимо, сразу можно думать о способах объединения этих файлов.

Цитата:

- сохранять файлы версий в формате hl=ru-RU&gl=ru.NNN (NNN-номер версии)

Текущий dbRoot идёт без версии, а старые автоматом будут так подписываться (при обновлении текущего)

Цитата:

в идеале GC мог бы вообще брать файлы hl=ru-RU&gl=ru из проиндексированных кешей

В этом нет необходимости - версия этого файла записана в 7-ом байте файла, т.е. гуглу можно скормить любой dbRoot записав в него какую угодно версию.

Цитата:

Доберусь до анлимита, попробую заполнить DefCache.dbx

В текущей версии все данные записанные в DefCache.dbx сверх 2-х Гб будут недоступны (идут неправильные записи в индекс), в следующей версии это уже исправлено. Сами данные в порядке, т.е. в след. версии к GC можно будет подключить DefCache.dbx от предыдущей версии.

А вот, собственно, и новая тестовая версия: http://narod.ru/disk/7707880000/GC_20090414.RAR.html
- исправлены ошибки (основные, но ещё не все);
- для файлового кэша доступна сортировка по координатам и типам файлов, работают регулярные выражения (см. FileCacheRE.ini);
- отдельное кэширование url сервиса VirtualEarth: регэкспы вынесены в файл VirtualEarth.ini. Кэширование настроено для совместимости сохраняемого кэша при просмотре снимков VE в браузере с кэшем SAS.Планета (кэш GoogleMV). Для просмотра VE в браузере, рекомендую сайт: http://www.flashearth.com/

Кэш нужно переиндексировать. Индексация файлового кэша, к сожалению, пока ещё не готова.

Инструмент для просмотра/редактирования индекса: SQLite Expert Professional (Portable)

Цитата:

в идеале GC мог бы вообще брать файлы hl=ru-RU&gl=ru из проиндексированных кешей     

В этом нет необходимости - версия этого файла записана в 7-ом байте файла, т.е. гуглу можно скормить любой dbRoot записав в него какую угодно версию.

Вот я и думаю, что неплохо было бы делать это не руками а средствами GC.
И ещё - размер этих файлов изменяется от версии к версии, там точно ничего лишнего кроме номера не добавляют?

Добавляют конечно. В основном, там идёт список доступных слоёв (типа дороги, погода и т.д.), может и ещё что-то есть.


Цитата:

Первый файл, что попадает в кэш - это всегда dbRoot.v5 (которому в качестве параметра может передаваться строка вида: hl=ru-RU&gl=by). И вот, что интересно: к началу данного файла прикреплён ключ, длиной ровно 1024 байта. Данным ключом зашифрованы все данные, что передаются от сервера клиенту, он, так же, пригоден и для того, чтобы данные могли быть дешифрированы клиентом GE. В ключе же, в седьмом байте, записана и текущая версия баз на сервере. Алгоритм дешифровки составлен таким образом, что изменения седьмого байта никак не влияют на сам процесс дешифровки и получение незашифрованных данных. В кэше ключ и сам файл dbRoot.v5 хранятся склееными (в том виде, что пришли от сервера). После дешифровки и разархивации dbRoot.v5 представляет собой xml-файл с кучей данных. Вот, для любопытствующих: dbRoot.v5.zip (расшифрован и в обычном, не гугловском, архиве).

Цитата:

гугл, перед тем как начать работу с сервером, проверяет действительно ли это сервер гугла,

Чушь какая.


Цитата:

Подобная проверка сервера (обмен запросами) происходит и во время работы
гугла, с периодичностью 5-10 минут.

Дважды чушь. С периодичностью в 300 секунд идет перезапрос сессии с сервера, коя сессия используется при утягивании тайлов.


Цитата:

Т.е. вся загвоздка в формировании правильного ответа на запрос гугла.

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

Уважаемый, parasss, Вы не правы!
Для того, чтобы начать работу с сервером, клиент инициирует авторизацию на сервере (это и есть проверка сервера, т.к. никто другой, правильго ответа на запрос не даст). Называть это чушью я бы не стал.
Затем, с непостоянной периодичностью, эти запросы повторяются (обычно 5 минут с хвостиком). 300 секунд - 5 минут

Цитата:

"Правильный ответ на запрос гугла" неизменен во времени для каждой версии клиента, и банально ловится сниффером.

Так словите, и увидите, что ответы разные. Могу прислать вам пачку ответов, если самому лень...
Смысл в том, что в теле ответа сервера записаны coocie, которые уже потом клиент выдаёт в заголовках запросов.

Цитата:

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

Как на счёт практической реализации? Раз вы говорите можно, то попробуйте сделать?

Цитата:

Для того, чтобы начать работу с сервером, клиент инициирует авторизацию на сервере

Верно.


Цитата:

это и есть проверка сервера

Не существует никакой "проверки сервера".


Цитата:

т.к. никто другой, правильго ответа на запрос не даст.

Это банальная авторизация по сессиям. Нет ничего сложного ввести и запросить сессию на локальном HTTP-сервере - никакого отношения к "проверке гуглесервера" это не имеет, отдавать сессии можно и через локального Апача специально написанным скриптиком (да, это работает, и клиент проходит авторизацию - но практического смысла никакого не несет).


Цитата:

Называть это чушью я бы не стал.

Достаточно и того, что так ее уже назвал я.


Цитата:

Затем, с непостоянной периодичностью, эти запросы повторяются (обычно 5 минут с хвостиком).

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


Цитата:

300 секунд - 5 минут

Я умею считать, спасибо.


Цитата:

Так словите, и увидите, что ответы разные.

Разные имена выдаваемых сервером сессий, не более того. Так и должно быть.
Передаваемый же клиентом на сервер запрос (до получения сессии) - неизменен.


Цитата:

в теле ответа сервера записаны coocie, которые уже потом клиент выдаёт в заголовках запросов.

Верно.
Только где тут "проверка, действительно ли это сервер гугла"?


Цитата:

Как на счёт практической реализации? Раз вы говорите можно, то попробуйте сделать?

Реализация есть, работает у меня уже несколько лет. Мы это уже обсуждали с Вами на форуме САСпланеты пару месяцев назад.

Цитата:

Цитата: в теле ответа сервера записаны coocie, которые уже потом клиент выдаёт в заголовках запросов.

Верно.
Только где тут "проверка, действительно ли это сервер гугла"?

Цитата:

А проверка в том, что "левый" ответ клиент не принимает.

Прекрасно принимает (версия 3.0.0.616).


Цитата:

Потому я и удивлён вашим постом "не в тему", вы же сами писали, что это нереально:

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

Сейчас же я пишу об отсутствии "проверки гуглесервера", и эмулировании функции "LOGIN" (которая есть далеко не самая технически сложная в функционале сервера ГЕ).
Это немного разные темы, Вы не находите?

Цитата:

Прекрасно принимает (версия 3.0.0.616).

А как насчёт более свежих версий клиента, скажем 5.0? С такой древней версией я не общался, моё знакомство с гуглом началось с версии 4.х. Может тогда действительно, эмулировать авторизацию было элементарно...
Вы готовы описать алгоритм и выложить скрипты от апача или squid-а, чтобы я мог повторить это в GeoCacher-е?

А как насчёт более свежих версий клиента, скажем 5.0?
А зачем, если все работает?
PS: только что проверил работу вышеуказанной версии. Периодически еррорит при парсинге свежеполученного dbroot (нет списка свежепоявившихся с того времени слоев) при запуске напрямую. При забанивании УРЛа проверки апдейтов, подсовывании старого dbroot от 2005го года через проксик - прекрасно проходит авторизацию на гугле и столь же прекрасно тянет текущие гуглетайлы.
Ничего-то там не изменилось со времен Кейхола.....

Вы готовы описать алгоритм и выложить скрипты
Помнится, Вы это уже спрашивали меня через САС. Предлагаю переместиться опять туда, чтобы не утомлять тутошних окружающих.

PS: прошу больше не выкладывать детали личной переписки в паблик без предварительного на то согласия. Спасибо.

ОК, переместились в САС. Будем разводить секреты там, в ЛС

Добавлено:
QQMATS,

Цитата:

Настораживает:
- жесткий диск "стучит головой", что ли пишет порциями

В новой версии GC помимо чтения из индекса, производится ещё и запись в него. Причём запись идёт напрямую для каждого тайла, без какой-либо буферизации. Чтобы поберечь веник от излишней загрузки, я решил пока использовать RAM диск, чего и вам советую. (Есть ещё отличное решение: RamDisk Plus 9, но он платный, и нужно искать ключики.) И по-идее, скорость поиска/запись в индекс должна увеличиться.
Из достоинств именно этого решения RAM диска я заметил:

Цитата:

- Возможность загрузки сохранённого образа диска и заполнения содержимого RAM-диска в момент инициализации драйвера (скорость загрузки - около 30 секунд на 1 ГБ при условии, что образ сохранён на жёстком диске с режимом 4 IDE ATA при процессоре с частотой 1,2 ГГц).
- Возможность сохранения содержимого в образ диска при завершении работы, а также через регулярные интервалы или в заданные моменты времени.

Т.е. один раз настроил сохранение/загрузку RAM диска из образа, и всё работает.
Единственное, в следующей версии GC надо будет добавить возможность произвольного места расположения файлов индекса и DefCache.
Ну и понятно, что размер RAM диска должен быть больше чем размер индексного файла, и на этот же размер у нас уменьшится оперативка. Если возможности железа позволяют, то по-моему это идеальное решение (в плане быстродействия).

Zedxxx, то что говорил parasss, это набор букв, или он действительно может помочь в решении проблемы эмуляции googlevskogo сервера?

Может и может, но не факт, что захочет. Посмотрим, что он ответит в ЛС.