Многопотоковая закачка в SAS

[zed]

Ага, осталось только все эти выкладки реализовать в коде... где бы найти добровольцев?

[vdemidov]

Так как каждый из этих источников является наследником абстрактного класса, то и сделать их конкретные реализации можно в разных вариантах:

• С доступом к кешу СасПланеты новго типа (в файловой системе).
• С доступом к кешу в беркли.
• С доступом к кешу в mysql.
• С доступом к кешу на локальном http-сервере.
• С доступом к кешу в форматах посторонних прог.
• ftp кеш.

Сто процентов согласен. С небольшим замечанием, что простейший вариант с хранением в файловой системе нужно для начала реализовывать просто как отдельный класс без всяких dll, а еще лучше как интерфейс. Потом можно будет уже прикрутить плагины которые будут создавать интерфейсы такого типа реализующие нужный способ хранения.
Еще одно. Эти интерфейсы сами потоков плодить не должны, но должны быть тред-сейф. А вот многопоточность нужно делать в самой планете.
Собственно говоря у меня уже есть написанные класы реализовывающие 3 существующих способа хранения в файловой системе. Осталось их встроить.

PS: Я все таки считаю, что формирование слоя заполнения это дело самих модулей хранения тайлов. Просто желательно запрашивать не по одному тайлу наличие, а что бы возвращался целиком тайл с картой заполнения более низкого слоя. Тоесть для тайла слоя X запрашиваем карту заполнения тайлами слоя X+k, где k=1..8 например, а модуль уже возвращает готовый тайл с прозрачностями. По крайней мере я это так реализовал. Осталось только заменить в планете существующий код вызовами этих классов.

[svp]

С небольшим замечанием, что простейший вариант с хранением в файловой системе нужно для начала реализовывать просто как отдельный класс без всяких dll, а еще лучше как интерфейс.

Согласен. Причём надо действительно делать на интерфейсах, ибо объект реально создаётся в одном месте, а юзается в другом.
Насчёт того, где будет реализован класс базового (встроенного) простейшего источника -- это уже совершенно не важно.
Главное, чтобы все источники регистрировались в едином планетовском пуле источников. А откуда каждый конкретный источник будет попадать в этот пул -- уже не важно. Первый базовый простейший попадёт туда прямо при создании пула. Остальные можно регистрить из dll.

Эти интерфейсы сами потоков плодить не должны, но должны быть тред-сейф. А вот многопоточность нужно делать в самой планете.

Воистину. В потоке должна висеть отдельная задача, которая будет юзать тот или иной источник. А источник должен давать возможность юзать себя из нескольких потоков разом.

все таки считаю, что формирование слоя заполнения это дело самих модулей хранения тайлов.

Не согласен. Я сейчас пишу пирамидальный индексатор для тайлового кеша. Упор ведётся на то,что индексная структура будет занимать минимальный объём (как памяти, так и места на диске). То есть будет оптимизирована для обмена по сети. Будут реализованы методы слияния, пересечения, вычитания индексов. Это значит, что на серверы-обменники и просто соратникам можно будет отправлять компактный индекс своего кеша или заявку на обмен тайлами. И эти индексы тоже хотелось бы отображать в виде карты заполнения. Так получится универсальнее.

Тоесть для тайла слоя X запрашиваем карту заполнения тайлами слоя X+k, где k=1..8 например, а модуль уже возвращает готовый тайл с прозрачностями.

Да. Но такую заявку лучше делать не к хранилищу, а к индексатору. Хранилище не всегда оптимально быстрым способом может сообщать об элементах, имеющихся в нём. Например хранилище в файловой системе вынуждено перебирать файлы, а это медленно. К тому же индексная структура теоретически может храниться и использоваться также отдельно и никак не связанно с хранилищем. Зачем терять такую возможность? Положим Кто-то кому-то хочет отправить свою карту (индексную структуру) заполнения Крыма или Европы. Уверяю, пирамидальная индексная структура будет очень компактной и её размер не будет зависеть от количества включённых или отсутствующих в ней тайлов. Если интересно, могу подробнее рассказать в другой теме или в личку.

[vdemidov]

А как ваш индексатор будет работать не зная ничего об хранилище тайлов? Нет. Лучше со временем реализовать в обычном тайловом хранилище дополнительно хранение и обновление индексов, зато в некоторых других способах хранения ваш индексатор вообще не понадобиться. В томт то и дело, что лучше пусть об этом думет разработчик хранилища тайлов, в крайнем случае можно прикрутить ваш индексатор в нужных местах, чем нагружать этим Планету.
PS: По поводу пирамидальной индексной структуры нужно списаться в личке. Похоже мы паралельно одно и то же делаем. Может объединим усилия?

[zed]

Немного не в тему, но обьясните, зачем вы изобретаете "индексную структуру", чем MySQL/SQLite не устраивает? Я где-то приводил результаты теста - получение списка тайлов (координат) для заданного региона - БД такой запрос за доли/единицы секунды выполняет... и SAS лишним кодом особо не надо нагружать.

[svp]

Немного не в тему, но обьясните, зачем вы изобретаете "индексную структуру", чем MySQL/SQLite не устраивает? Я где-то приводил результаты теста - получение списка тайлов (координат) для заданного региона - БД такой запрос за доли/единицы секунды выполняет... и SAS лишним кодом особо не надо нагружать.

САС по-любому лишним кодом загружать не будем. Всё будет в оьдельных модулях.
MySQL базу пересылать как карту неудобно.
Скорость поиска и размер индекса в MYSQL зависят от заполнения кеша. Пирамидальная структура индекса не зависит от степени заполнения. Только от качества. А специфика тайловых кешей такова, что качество как правило предопределено и для данного механизма оптимально.