Пиринг чем не новый вариант сетевой библиотеки?

А откуда идея, что распределенная библиотека должна оптимизироваться на работу под управлением чего то типа палма? Это бред. Я такое проектировать не буду. Я проектирую узел сети, основное назначение которой - поддержка пиринговой глобальной библиотеки. И приоритет соответственно - снижение трафика, оптимизация хранения. Ибо и так будеи и заметный трафик и изрядное место на диске. Вариант для КПК - штука экзотическая, потребует достаточно сильного железа. На палм пилот точно не влезет. А на любом современном КПК 4М под словарь выделить не проблема.

Однако, проблемы, кроме тона, не вижу. Но это не мои проблемы Smile

Расширим протокол, пусть точка выбирает способ сжатия, zip или bz2.

Если я пишу "кажется", это означает что это мне неизвестно и требуется уточнение Smile

предполагается, что такое использование слова "кажется" также общеизвестно.

Ну по размеру библиотеки как раз проблем не вижу - пара десятков гигобайт по нынешним временам вообще не проблема, харды к терабайту подходят. Это же не видео. Для наладонника это пока много, но на нем можно всю библиотеку и не хранить. Вернее хранить базу, но не книги, а это гораздо меньше.

Компрессия - не думаю все же что тут bz2 так уж идеален. Даже если он в общем случае и лучший, то вряд ли он лучший именно для базы в xml формате, где очень много повторяющихся тэгов.
Наверно лучше у специалистов на compression.ru спросить. Хотелось бы все-таки чтоб по возможности было не такое требовательное к ресурсам ПРИ РАСПАКОВКЕ. Ну и опенсорсное естественно.
Вдруг все-таки нормальные аппаратные ебуки с сетевым интерфейсом пойдут в массы, надежда есть. В идеале оно и там должно работать прямо 'на борту', пусть только в режиме запросов.
А Алан всегда так общается, типа фидо-стиль, ничего личного Smile

Обмениваться случайной выборкой периодически мысль может и неплохая, но как-то логичнее в первую очередь обмениваться новыми и обновленными книгами, наверно? В базе ведь наверняка есть время последнего обновления.
И гонять по сети каждый раз весь description из fb2 как-то нелогично, раз он все равно в чем то избыточен, а в чем-то недостаточен. Лучше наверно что-то близкое к записям базы данных библиотеки, экспортированным в сжатый xml.

Сорри я наверное невнятно и не вполне корректно выражаюсь, буду исправляться Smile

Идея использовать сильное сжатие предполагалась для уменьшения трафика узла, он все еще довольно дорогой. Скажем, когда передается обновление каталого - куча xml тегов... Я бы вообще отказался от XML по этой причине, да как то устоялся он...

Насчет использовать для информационного пакета только то, что хранится в базе, а не всю ветку FB2/description - так и сделаем. Не могу понять, почему мне одно время хотелось рассылать всю ветку Smile

Идея разрешить произвольный формат объекта здравая, давайте так и поступим. То есть, есть файл с некоей публикацией, есть к ней описание - оно лежит в базе, оно и передается. Что за файл библиотекарю до некоторой степени все равно, если он его не знает (то есть, нет плагина для доступа к содержимому, как в google desktop), значит некоторые дополнительные функции типа поиска текста для него будут недоступны, и все. Но передавать и хранить он его будет.

description сжимать вопрос тонкий. Там должно быть все, чего клиент может захотеть найти. А это может быть и имя переводчика, и имя оригинала и т.д. К тому набору данных, что публиковался раньше, пока что добавляется версия документа и тип: NULL будет fb2.zip.

Насчет объема информационного пакета.

Я сделал тест на своем импорте (некая случайная выборка, 554 книги), брал целиком FB2/description в utf8 (!), а потом полный массив сжимал зипом и бз2. Результаты такие:

Desciption stats: zip: 392.25/book, bz2: 245.61/book.

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

Насчет случайной выборки при обновлении: стормозил. Во первых, конечно, по сети будут рассылаться новинки. Счас поправим.

Уровни

Уровень 1 слабый, отказываемся.

Уровень 2 модифицируем так:

Прем обновлений.

Новые поступления (новые книги, обновленные и ротация). Если квота не исчерпана, то все поступает в локальную базу. Если квота исчерпана, то прнимаются только книги с низким индексом хранения, для которых высвобождается место (ниже). Можно также предусмотреть отдельно квоту и/или флаг новинок, если их не будет спасать индекс хранения.

Превышение квоты.

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

Рассылка обновлений.

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

Прием запросов.

Оставляем как есть. Место для хранения выбирается вышеописанным алгоритмом.

Рассылка каталога хранения.

Очень интересный вопрос - как рассчитать индекс хранения, если у нас нет сервера статистики. С сервером то все красиво...

Как вариант: циркуляраня рассылка. Каталог ходит непрерывно, и каждая точка инкрементирует индекс тех книг, которые хранит, и декрементирует для тех, которые отсутствуют.

Однако при этом эти каталоги будут размножаться. Пока не придумал изящного решения. Ваши идеи?

Уровень 3 - пока отложим.

Так может все-таки не стоит увлекаться изобретением велосипедов, а взять готовое отлаженное P2P ядро, например JXTA. В нем все эти проблемы вроде решены... Только настроить.

К сведению:
После обработки приблизительно 10000 книг, и занесения в текстовый файл вот такого типа информации:

Kv
Вы все правильно пишите, но чем больше телодвижений, тем меньше пользователей и соответственно меньше информации в общей базе и меньше резервируемость. Sad

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

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

Сеть пиринговая, но инициатором запроса может быть не только пользователь, но и собственно прога-библиотекарь. Все время, пока ее не закрыли (в том числе и как демон), она обрабатывает сетевые запросы и поддерживает фонд в рамках квот на трафик и диск, которые у нее есть.

Не понял каким это образом можно обойтись без квот. Имхо никак невозможно Smile

Квота нужна библиотекарю (который мы проектируем), чтобы поддерживать некую часть общего фонда. Заметьте, этот общий фонд не имеет НИКАКОГО отношения к личной библиотеке пользователя. Ну кроме того, что из него быстрее всего импортировать в личную библиотеку. Естественно, файлы на диске при этом не размножаются, просто в записи в базе ставится флажок, что эта книга принадлежит и к личной библиотеке и в ротации не участвует.

Циркулярная рассылка передает только каталог хранения. В этом каталоге на одну единицу хранения (сиречь книгу) будет где то 16 байт. То есть, полтора метра на сто тысяч книг. Правда, оно не будет сжиматься Smile

Однако, если довести до ума уровень 3, обмен будет на уровне апдейтов с неокторой линамической сеткой выделенных серверов a la POP3, которые собственно книги пересылать никогда не будут, а будут использоваться только для минимизации трафика и сбора совершенно абстрактной бинарной инфы. Думаю, я смогу это сформулировать так, что даже американцы не сумеют его прикрыть Smile

Но неважно, сделаем и без этого.

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

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

Насчет отношения UL/DL, то здесь мы скорее сделаем так. Юзер указывает квоту на хранение и квоту на трафик. Это автоматически ограничивает размер его личной библиотеки и личного трафика (запросы на новинки или поиск) до такой же величины, как и указанные им квоты для общего пользования. Скажем, если квота на трафик позволяет лопатить до 100 книг в день, то по его запросу он будет получать до 100 книг в день. хакать клиента бесполезно - линки просто не отдадут Smile

И плз хватит скатываться к модели торрент+локальный библиотекарь. это не то, на что стоит тратить время Smile

У нас уже получается нечто изящное и умное, чему аналогов я пока не вижу Smile

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

Добавлено спустя 23 минуты 9 секунд:

Еще о распределенном поиске.

Рассмотрим маргинальную ситуацию: пользователь ищет фрагмент текста по всем книгам, возможно с некоторым фильтром. Точка (обработав свою часть фонда) берет каталог хранения, чистит оттуда то, что просмотрела сама, и отправляет запрос и оставшуюся часть каталога по линкам. Каждый линк обрабатывает такой запрос по своей части фонда, удаляя соответственно часть каталога из запроса, и если каталог не пуст, а запрос не удовлетворен, отправляет дальше. Таким образом, можно учинить поиск по всей распределенной библиотеке. Отработает он небыстро, но отработает же Smile

Интересно, что такой подход позволяет решить проблему как с объемом хранения, так и с объемом вычислений. Если в мире найдется хотя бы 10к активных точек, с квотой хранения в 1Гб, то общий фонд такой библиотеки будет эффективно хранить не менее 1Тб данных, не слишком обременяя участников. И поиск в такой чудовищной базе тоже будет распределенным, что, согласитесь, приятно Smile

Прям нечто из какой то фантастики, читал я что то такое...

Добавлено спустя 37 минут 21 секунду:

Индекс хранения

Есть простая схема: циркуляр принимается точкой от своих линков, суммируется в общий, туда добавляется информация о хранимых локально документах, нормируется (чтобы не разрастался), после чего такой исправленный файл выдается обратно линкам, причем с заранее определенной частотой (например, один раз в сутки).

Состав циркуляра: (document_id, store_index) [,(document_id, store_index)...]

document_id: уникальный id единицы хранения. Скажем, 6 байтовый серийник, если есть сервер, раздающий серийники, или 16-байтовый гуид.

store_index: беззнаковое целое, 4 байта, означает обощенное число точек, где документ хранится.

Суммирование: store_index складывается для всех циркуляров.

Нормировка: из всех store_index вычитается минимальный (приводится к нулю), чтобы избежать переполнения.

Цель работы библиотекаря таким образом - получение как можно меньшей дисперсии параметра store_index Smile

Значительно эффективнее схема будет работать, если мы создадим Id-server, у которого будет ровно 4 команды:

CreateId
UpdateStorageIndex(Id, +-1)
GetMinStorageIndex(howManyToGet)
GetStorageIndexes()

Это резко уменьшит трафик в системе, улучшит равномерность коирования и позволит использовать короткие, 6 байтовые идентификаторы, вместо громоздких гуидов. И прикрыть легально такой сервер очень непросто.

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

Нагрузка на сервер крошечная, могу у себя захостить. Если потом раскрутимся, перенесем на какойнить более мощный хостинг.

Хорошо, тогда тупой вопрос. Допустим задаю квоту хранения 50 гиг, и пожелание хранить книги таких-то жанров и не хранить таких-то. Образуется у меня через некоторое время локальная библиотека этих жанров с автопополнением раз в сутки-двое? Если все книги этих жанров укладываются в файловую квоту.
Понятно что оно и на внешние запросы будет отвечать, в пределах сетевой квоты, но интересующие меня книги хотелось бы по возможности брать сразу из локальной, без запросов в сеть. Просто локальные запросы все равно на несколько порядков быстрее будут обрабатываться. Да и мало ли, сеть отпала, америкосы новую подлянку придумали.. Так оно как-то спокойнее.

И второй вопрос - какая будет система разрешения коллизий. Допустим некую книгу одновременно добавили несколько человек в разных местах сети, не такая уж невероятная ситуация для горячих новинок. Сможет система отследить что они побайтово совпадают и свести к одной, или это дело модераторов?

Kv
От Вас лично НИКТО и НИЧЕГО не требует. Устанавливать/не устанавливать - Ваше личное дело.