Одноранговая p2p библиотека

Опубликовано ср, 22/07/2009 - 06:07 пользователем UPSTM

Давно, ещё с год назад родилась идея сделать нормальный (библиотечный, работающий с fb2) интерфейс для KAD подобной сети. К слову, сейчас я пользуюсь RetroShare. Например, можно было бы взять уже готовый, надо сказать, прекрасно сделанный интерфейс MyHomeLib и добавить в него библиотечку kademlia. Но такое решение вопроса свободного распространения книг открывает проблему с вандалами. Например, никто не сможет в данном случае говноресовцам добавлять документы с теми же тегами заглавия и автора, а весь текст забивать чем то типа "Покупайте книги по этому адресу.".

Значит, надо разработать свой протокол, но работающий по принципу kademlia, но, уже не одноранговый. Я немного пофантазирую на эту тему, если кто увидит этот пост - пусть меня поправит, если я в чём-то заблуждаюсь.

Уровни доступа
- Гость Скачивает книги.

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

- Модератор Пользователь + удаляет книги, запрещает участие пользователей в сети, модерирует комментарии и системные форумы.

- Администратор Модератор + Назначение модераторов и администраторов.

Авторизация
1. При регистрации в сети пользователь получает два PGP ключа. Открытый и закрытый.
2. Для авторизации ему посылается с случайного количества случайных клиентов сети опять же случайный набор буков и цифер, зашифрованный его открытым ключём.
3. Получив зашифрованные сообщения он их расшифровывает и отправляет обратно в расшифрованном виде.
4. Если успех, то сообщение об авторизации пользователя рассылается по всем клиентам сети.

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

Пересылка файлов
Если пересылать файлы в незашифрованном виде, то могут возникнуть проблемы. По этому, есть два варианта.
1. Шифровать файл открытым PGP ключём.
2. Архивировать в запароленный архив WinRAR или WinUHA.

После чего передавать одним из трёх способов:
1. По частям, каждую из частей разным случайным маршрутом.
2. Целиком, случайным маршрутом.
3. Напрямую.

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

Хранение данных пользователей.
Данные о всех клиентах хранятся у всех клиентов сети. Если подпись XML файла со списком пользователей на совпадает с подписью файла другого (одного или нескольких пользователей), они сравниваются по объёму и дате с несколькими пользователями и загружается новый. Чтобы исключить подлог, в первую очередь подписи сравниваются с клиентами с наибольшим рейтингом доверия.

Метод организации конференций.
Личные форумы пользователей хранятся лично у пользователей :) Они могут открыть XML файл блокнотом и поправить его так как им захочется. Обсуждение книг хранится у клиентов с наибольшим рейтингом доверия, модераторов, администраторов а так же тех, кто эти книги качал. При обновлении уведомляются все.

Организация поиска.
При поиске книги сначала производится поиск в общем списке книг библиотеки, который есть у каждого пользователя и обновляется часто. Затем, по всей сети рассылается сообщение со списком идентификаторов требуемых книг. Далее, от всех у кого книги с такими идентификаторами присутствуют получается ответ. В него входит размер книги, версия и т.д. Далее пользователь просто ставит галочки напротив нужных ему произведений и происходит процедура описанная выше.

Я извиняюсь, что немного сумбурно написал, не спал уже почти сутки. А теперь самое главное. Зачем я это всё калякал. Как лучше поступить?

1. Остановиться на ретрошаре и КАД.
2. Доделать таки то, что я тут написал (надо сказать раз пять или шесть садился, но через пару дней руки опускались :( ).
3. Оставить всё как есть.
4. Линчевать меня за попытку нарушения авторских прав.

Комментарии

Опубликовано ср, 22/07/2009 - 07:42 пользователем Jolly Roger

Если вы это можете сделать - делайте. Ибо пора и сильно поддержит всех...

Однако то, что вы описали, мне кажется вещью сложной. Я такого разработанного пиринга - с модераторами и т.п. - не встречал. Даже не слышал...

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

На самом деле для книжного пиринга нужно две программы - для решения двух разных задач: поиск по фондам и раздача новинок.
Думая по сему поводу, я нашел - умозрительно - лишь одно решение: возродить файл-эхи Фидо на новом уровне. :)
Книги "весят" немного и хранить их все на компе - вполне реально. Раздачи онлайн они тоже не требуют в силу небольшого размера. Поэтому было бы интересно построить систему mail2mail - спецом зарегеный гугло-ящик, подписка у раздающих нод на всё, либо по авторам/жанрам, шифрованные письма с аттачментом (у каждого свой ключ). По такой системе новинки будут разливаться, как по сети каналов. А уж пропущенное можно искать с помощью пиринговых программ и неспешно...

Но я не программист. Вымыслить можно всё, но кто сделает?... Если не вы - некому.

Опубликовано ср, 22/07/2009 - 09:20 пользователем sergicus

интересная идея

Опубликовано ср, 22/07/2009 - 09:31 пользователем gloom

сами файлы можно хранить традиционно в каде например в в зипе блоками по 100 или сколько-то метров а вот с распределённой базой данных и правами доступа вся проблема
хранилище + база сделать по приринговой технологии можно и раздельно
в качестве хранилища например amuled
интерфейс можно написать на чем угодно python php c c++ java

вообще такой проект должен быть максимально кросплатформеный
и делать его лучше с нуля

http://hadoop.apache.org/common/docs/r0.17.0/hdfs_design.html
http://www.hypertable.org/
по крайней мере линух всегда можно запустить в виртуалке или colinux...

Опубликовано ср, 22/07/2009 - 10:06 пользователем Xardas

Не вижу смысла в этом предложении. Если ты будешь физически хранить книги у себя на сервере, то чем ты отличаешься от Либрусека? Неудобным методом закачки? Все копирайт проблемы остаютья с тобой.
Если хранить не будешь, то ты сам описал проблемы и это далеко не все, а только начало. Маленькие файлы для открытия которых необходимы архиваторы удивительно удобны для доставки любой дряни в комп потребителя. Тебе постоянно придеться стоять на раздаче и прочая прочая прочая.

Опубликовано ср, 22/07/2009 - 10:55 пользователем gloom

Можно ханить десяток книжек и их раздавать
Удобным в етом вся суть Копирайтные проблемы всегда тудут но прирингопую систему непросто задосить
будет интерфейс вроде как у хомелиб разве вручную волится архивами удобней?
при определенном количестве пользователей любой файл всегда будет на раздаче

Опубликовано ср, 22/07/2009 - 13:04 пользователем mstorm

Правильно ли я понимаю: поиск в подобной децентрализованной сети происходит по хешам файлов (в нашем случае книг). Что бы запросить какой-то файл, нужно послать запрос в эту сеть с его хешем, каждое звено цепи хранит хеши своих файлов и адреса узлов с близкими по значению хешами. Так вот, при присоединении к сети, ты должен представить какие файлы у тебя есть в наличии, а точнее отослать кому-то хеш каждой книжки, правильно? Представь, хранится у тебя на компьютере 50 тысяч книг, занимают они гигов 20, небольшой объем... и теперь нужно отослать хеш каждой книжки, которая есть в наличии... сколько трафика затратся на все эти реверансы? А ведь нужно еще пропускать через себя поисковые запросы других пользователей и чем больше файлов ты хранишь, тем больше запросов через тебя будет проходить? Я не силен в технических аспектах работы подобных сетей, но вот что-то подсказывает мне, что подобная сеть годится только для более массивных файлов, которые хранятся на компьютерах в несколько меньшем количестве.
Извиняюсь, если накосячил в описании технологии.

Опубликовано ср, 22/07/2009 - 13:13 пользователем Xardas

Задосить может и не просто, но засечь твой ИП и взять тебя в суд элементарно. Вся идея П2П как раз в том чтобы сказать, а я тут причем.
На муле и торренте так или иначе лежит вся англоязычная литература. Почти все популярные книги появляются в течении нескольких часов с момента выхода.
Я Мартна и Роулинг иногда скачивал за несколько часов до первого появления книг в магазине.

Опубликовано ср, 22/07/2009 - 13:13 пользователем mstorm

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

Опубликовано ср, 22/07/2009 - 14:55 пользователем Ajaja

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

Опубликовано ср, 22/07/2009 - 15:13 пользователем UPSTM

Цитата:
Представь, хранится у тебя на компьютере 50 тысяч книг, занимают они гигов 20, небольшой объем... и теперь нужно отослать хеш каждой книжки, которая есть в наличии...

Пример. Считаем хеш трёх файлов. Фильма, маленькой статьи и скрипта.
E:/2008 - Repo. The Genetic Opera\Repo. The Genetic Opera.avi 699 Mb 96e6fccf4a0b0f2d89ed13b0795f64df
D:\BOOKZ\Рус\Ш\Шеповалов Даня\Оргазм Робокопа.htm 10 kb 590504b6fe593978ffd8df53347882a4
C:\home\localhost\www\avapanel\index.php 3.91 kb da9cb9e64d96d6814377c67d27df565e
Выполнение заняло 20 секунд.

На получение хеша первого файла требуется 19-20 секунд, соответственно, создание хеша мелочи занимает менее 1 секунды. Значит, если книги немног опобольше, то берём 3 секунды на обработку одной книги (посчитаем сюда же препарирование из XML в базу данных библиотеки названия, описания, автора, жанра и т.д).

Соответственно, на моей старушке это займёт около 41 часа единовременно. :)

Пример верен для AMD Sempron 2500 (1200 Mhz) 256 Mb DDR, Windows XP sp3, функция md5_file php 5.0.1

Цитата:
интерфейс можно написать на чем угодно python php c c++ java

Если говорить о кросс-платформенности, то можно попробовать PHPw.

Цитата:
Книги "весят" немного и хранить их все на компе - вполне реально. Раздачи онлайн они тоже не требуют в силу небольшого размера. Поэтому было бы интересно построить систему mail2mail - спецом зарегеный гугло-ящик, подписка у раздающих нод на всё, либо по авторам/жанрам, шифрованные письма с аттачментом (у каждого свой ключ). По такой системе новинки будут разливаться, как по сети каналов.

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

Цитата:
Тебе постоянно придеться стоять на раздаче и прочая прочая прочая.

C каждой скачаной книгой у первого раздающего будут всё меньше и меньше качать. Так что потом, можно вообще прекратить раздачу :) Все книги будут распределены по пользователям и неуловимы.

Цитата:
Маленькие файлы для открытия которых необходимы архиваторы удивительно удобны для доставки любой дряни в комп потребителя.

Факт. Но кто сидит без антивируса в наше нескучное время - тот сам себе злобный буратино.

Цитата:
А ведь нужно еще пропускать через себя поисковые запросы других пользователей и чем больше файлов ты хранишь, тем больше запросов через тебя будет проходить?

В принципе, и верно и нет. В сети есть 10 машин. Ты - машина 1, на машине 10 хранится нужный тебе файл. Ты отсылаешь запрос на файл на 2 и 7 машины. Они каждая отсылают ещё на две, пока нужный файл не будет найден и таким же способом не будет отправлено обратное уведомление.

Цитата:
Задосить может и не просто, но засечь твой ИП и взять тебя в суд элементарно. Вся идея П2П как раз в том чтобы сказать, а я тут причем.

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

Цитата:
Например хочется видеть на сайте книжки в формате pdf, djvu, в которых хранится много сканированной технической документации.

Я вообще-то думал только о FB форматах, как наиболее удобных для добавления, передачи и препарирования.

Пожалуйста, кому интересно, присоединяйтесь: http://code.google.com/p/libp2p/
Сейчас надо создать технический лист и дальше по нему работать.

Среда разработки: http://exvision.net/

Опубликовано ср, 22/07/2009 - 15:36 пользователем Ajaja

UPSTM Думаю, замечание mstorm было не о скорости вычисления хэша, а о его размере при большом количестве книг. Допустим, пользователь раздает 100000 книг, размер хэша 32 байта - в итоге ему надо передать на сервер минимум 3Мб хэшей. А теперь представим, что таких пользователей несколько десятков тысяч, и бедному серверу надо будет парсить такое количество хэшей при каждом подключении/отключении юзеров. IMHO, нереально. Точно скажу, что ни один бы торрент-сервер не выдержал такой сумасшедшей нагрузки, если бы у каждого сидера было бы не по десяток-другой, а десяток-другой тысяч раздач.

Опубликовано ср, 22/07/2009 - 15:57 пользователем UPSTM

Ajaja какому серверу? :) Сеть бессерверная. Может быть я вас где-то не понимаю... Но у меня на работе сейчас стояла база в 5Gb, в ней постоянно проводился полнотекстовый поиск от более чем тысячи клиентов. Прошу обратить внимание на слова полнотекстовый поиск, 5 гб и 1000 пользователей.

Далее. Так как хеши и список книг не хранится на сервере, он хранится у КАЖДОГО пользователя. И не изменяется, а только пополняется. Я так наверное на вскидку не скажу сколько будет весить архивированный файл с базой, но сейчас напишу софтинку. Итак, хаш таблица в XML содержащая информацию о 1000000 конкретно, название, автора, описание, хеш. Имеет размер 590 Мб. Много :) А в архиве имеет размер около 3,5 мб. И учтите, что этот файл скачивается всего один раз. Потом он только пополняется. Кроме того, для удобного и быстрого поиска книг, было бы правильно ставить на машину пользователя Firebird или MySQL. Тогда всё будет проще, быстрее, удобнее :).

Опубликовано ср, 22/07/2009 - 17:02 пользователем Ajaja

UPSTM Не понятно как в безсерверной сети можно все это организовать (уровни доступа, авторизацию, модерирование и т.д.) Но все-равно, даже такой организации проблема никуда не денется. Большое количество небольших файлов на каждом узле, много хэшей, огромный трафик при обмене хэшами, затрудненный поиск. Библиотека без полноценного поиска по авторам/названиям/сериям/ и т.д. бесполезна. В KAD поиск идет просто по ключевым словам из имени файла. Как искать книгу в KAD-подобной сети? Тут схема "название, автор, описание, хеш" не помогут. Надо вычислять отдельно хэши для автора, названия , серии, причем для каждого ключевого слова из этого набора. Книг и так десятки и сотни тысяч, а тут количество хешей в такой схеме возрастает еще в разы. В общем, утопия все это.

Опубликовано ср, 22/07/2009 - 16:49 пользователем Shimuuar

Давайте ка и я выскажусь.

1. Модерация. Собственно я не очень понимаю как возможна модерация в одноранговой сети. Одноранговость означает что все участники равны. Модерация означает, что модератор имеет больше прав чем остальные участники. Ну и кроме технических проблем, мне кажется до добра это не доведёт, а породит огромное количество конфликтов.

В одноранговой сети возможна сеть доверия (web of trust) то есть. Я доверяю этим людям. (Список ключей приводится). Доверие может быть транзитивным. Т.е. я доверяю людям, которым доверяет Алиса.

2. Не надо тащить в протокол обмен сообщениями. Для этого есть e-mail, jabber, личная встреча, наконец. «Делай одну вещь и делай её хорошо» /программистская истина/.

3. Что делать с многочисленными ревизиями книг. Книги вычитывают, исправляют. Надо как-то работать с кучей версий, выбирать самую правильную. И правильная версия не обязана быть единственной.

Опубликовано ср, 22/07/2009 - 17:20 пользователем gloom

все просто делаем одноранговое хранилище где имена файлов md5 хеш и только пополняем его
и делаем версионную распределенную базу данных
и например вебинтерфейс их тоже может быть сколько угодно

берем
http://gen.lib.rus.ec/
выкладываем в кад
и вместо скачки с веба пишем прослойку для загрузки с када
не устраивает поиск можно добавить поля в базу пропарсиd например тоже fb2
а вот что делать с базой я не знаю...
и еще кад протокол неторопривый

Опубликовано ср, 22/07/2009 - 17:53 пользователем UPSTM

Как организуется авторизация я уже описал. С помощью открытых ключей PGP. Уровни доступа, так же, как и имена пользователей хранятся на ВСЕХ машинах сети. Совершить подлог на 1-10-20 машинах возможно. На всех - нет. В особенности, подлог прав маловероятен при наличии общесетевых доверенных узлов.

Цитата:
много хэшей, огромный трафик при обмене хэшами

Хеш один на каждую книгу. Хеш автора не нужен, так как база данных продублирована на каждом узле сети.

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

Объясните пожалуйста зачем? :)

Цитата:
Ну и кроме технических проблем, мне кажется до добра это не доведёт, а породит огромное количество конфликтов.

Не задумывался над этим. В чём вы видите конфликты?

Цитата:
Что делать с многочисленными ревизиями книг. Книги вычитывают, исправляют.

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

Цитата:
и еще кад протокол неторопривый

Факт. Все бессерверные сети крайне медленны. Но это не такой большой недостаток. Их медленность относительна. В 1995 году у меня были в офисе интернеты, откуда-то из Китая, я сейчас уже точно не помню. Вот ЭТО было медленно. Потом РОЛ диалап. ЭТО - тоже было медленно. Так что бессерверная сеть - не такая уж и медленная штука.

Опубликовано ср, 22/07/2009 - 18:17 пользователем gloom

Цитата:
Решить вопрос с шифрованием передаваемых файлов pgp/rar

рар не надо в качестве основного формата для него кодировщик закрытый под линух нету толком 64 разрядной версии(
есть zip tar.gz tar.bz2 7zip

Опубликовано ср, 22/07/2009 - 18:23 пользователем UPSTM

храниться то они будут в zip, fb2.zip - это уже стандарт :). Другой вопрос, как их передавать так, чтобы прочитать содержимое было возможно только тем, кто файл этот заказал. Пароль на зип архив ломается за 1 секунду :) По крайней мере раньше так было, и этим я не интересовался года три. Пароль же на рар невозможно взломать, только подобрать. Следовательно, если рар не подходит, использовать PGP.

Опубликовано ср, 22/07/2009 - 18:38 пользователем gloom

шифровать нужно сетевой трафик
проверять на целосность штуки 3 разных хешей

а шифровать содержимое слишком избыточно и ресурсоемко

Опубликовано ср, 22/07/2009 - 19:13 пользователем Xardas

C каждой скачаной книгой у первого раздающего будут всё меньше и меньше качать. Так что потом, можно вообще прекратить раздачу :) Все книги будут распределены по пользователям и неуловимы.

Ошибочное мнение. Фаил книги весит 1-2 мега скачиветься моментально и 99% юзеров немедленно переносят его в другую папку для безопастности. Фильм весит в среднем 700 мегов и время закачки колеблется от нескольких часов до нескольких суток, как результат если на закачке стоят 100 человек с недокачанным фильмом то шансы за то что 101й может собрать у них куски даже в том случае если оригинальный релизер ушел с раздачи. С книгами не получиться. Такой маленький файл всегда будет качаться от одного человека. Найти которого не будет представлять никакой проблемы, а если за пиратство возьмутся серьезно то именно раздача полного файла будет представлять проблему.
Теперь еще вопрос, ну Пехова или Панова качать будут тысячи, а вот что делать с непопулярными, но иногда нужными книгами. Я уверен что есть масса книг на Либрусеке которые скачивают 2-3 раза в месяц или в год. На п2п они просто не выживут.

Опубликовано ср, 22/07/2009 - 20:20 пользователем UPSTM

Цитата:
Фаил книги весит 1-2 мега скачиветься моментально и 99% юзеров немедленно переносят его в другую папку для безопастности.

Скажите пожалуйста, пользуясь myHomeLib вы тоже сразу переносите "для безопасности" скачанный файл в другую папку? :)

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

Вы ошибаетесь. Файл книги не скачивается напрямую с компьютера пользователя. Отправляется заказ на получение файла. И потом файл в зашифрованном виде (напишу так, пока не изучил другие возможности) передаётся через случайные узлы сети. Кто именно отдал этот файл - установить нереально. Кому он будет передан однако же известно.

Цитата:
Теперь еще вопрос, ну Пехова или Панова качать будут тысячи, а вот что делать с непопулярными, но иногда нужными книгами. Я уверен что есть масса книг на Либрусеке которые скачивают 2-3 раза в месяц или в год. На п2п они просто не выживут.

Резонный вопрос. Если вы помните, в советском союзе, когда покупали, например, семена в соответствующих магазинах давали товар в нагрузку. Например, мне (а я живу на урале) как-то достались семена сладкой дыни. Так же предлагаю поступить и тут. Предложить пользователям выделять определённое место на своём жёстком диске под редкозапрашиваемые книги. От 10 до Xn Mb. Напряжно это ни для кого не будет, а книги будут таким образом распределены. Другой вопрос, что, наверное, будут появляться люди, которые будут заходить из разных мест, или с разных машин. Или просто удалять старый аккаунт после каждого входа в систему. По этому, книги можно будет распределять только по членам сети, присутствующим в ней как минимум месяц, или имеющим повышенный уровень доверия.

Опубликовано ср, 22/07/2009 - 22:36 пользователем Xardas

Поясню перенос в другую папку. Живу я в Америке и пару лет назад начали приходить письма от моего провайдера, коему в свою очередь были посланны письма от Сони и Уорнер Бразерс.
Провайдер мне угрожал закрытием счета, а в письмах были перечисленны все фильмы этих кинокомпаний лежащие у меня целиком на раздаче. И на муле и на торренте. То есть, пока я качаю сам или раздаю частичный файл ко мне нет претензий, но как только я раздаю целиком готовый файл претензии появляются. С этих пор любой готовый файл я немедленно убираю из раздачи. Некрасиво, но здоровье дороже.
Поверьте мне, нет еще возможности закрыться полностью от желающих найти откуда раздается файл. Захотят найти, найдут. Ни прокси не поможет, ни кодировка. Так что живем спокойно пока ясных законов нет, а потом переходим на сервера стран где законы благоприятствуют.
Если ваша идея удастся буду рад, но сомневаюсь в реальной необходимости реализации этого проекта.

Опубликовано чт, 23/07/2009 - 12:31 пользователем ktulho

автор, почитай про японские p2p сети share и perfectdark. p2p в японии официально запрещен, но выкрутились ведь!

Опубликовано чт, 23/07/2009 - 14:55 пользователем kv

нельзя зацикливаться на любом формате, в том числе на фб2, просто в силу того, что книг и так мало - по сравнению с музыкой например, а в фб2 - это капля в море.

Ну и надо посмотреть кто и что наработал.
Вот, например
http://rulib.narod.ru/index.html
http://spacelib.narod.ru/news.html

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

Опубликовано пт, 24/07/2009 - 15:42 пользователем UPSTM

Цитата:
по сравнению с музыкой например, а в фб2 - это капля в море.

Ну, моё личное мнение, что разность форматов - это очень плохо. И надо всё таки идти к какому-то одному, или двум форматам. Например, пдф для нераспознанных или частично распознанных вещей и фб2 (фб3) для текстов. DJView - для научных текстов например. Иначе получится как с автомобилями, когда к одному не подходят запчасти от другого. Поэтому, было бы здорово, если бы кто-нибудь написал конверторы.

Теперь о http://spacelib.narod.ru.
Я посеитл только что сей сайт и немного почитал. Поразила программа Ssearch. Не представляю, как можно было достичь такой эффективности без субд. Программе не хватает юзер-френдли интерфейса. конечно :)

Опубликовано сб, 25/07/2009 - 00:41 пользователем kv

UPSTM написал:
Цитата:
по сравнению с музыкой например, а в фб2 - это капля в море.

Ну, моё личное мнение, что разность форматов - это очень плохо. И надо всё таки идти к какому-то одному, или двум форматам. Например, пдф для нераспознанных или частично распознанных вещей и фб2 (фб3) для текстов. DJView - для научных текстов например. Иначе получится как с автомобилями, когда к одному не подходят запчасти от другого. Поэтому, было бы здорово, если бы кто-нибудь написал конверторы.
Плохо, но так есть. И надо научиться жить с этим а не строить воздушных замков про один формат. Потому как все равно нереализуемо. А насчет конвертеров, то полно их, проблема в том, что конвертить - это ручной труд, он требует много времени - кто это будет делать? а потом, исходные файлы все равно останутся в сети. Почитай на форуме Либгена - там собрано много полезного софта - http://gen.lib.rus.ec/forum/index.php
UPSTM написал:

Теперь о http://spacelib.narod.ru.
Я посеитл только что сей сайт и немного почитал. Поразила программа Ssearch. Не представляю, как можно было достичь такой эффективности без субд. Программе не хватает юзер-френдли интерфейса. конечно :)
там еще findISBN полезная прога, вот здесь http://gen.lib.rus.ec/forum/viewtopic.php?f=3&t=132 делали парсер библиографии, вот бы соединить это все в единое целое, чтоб получилось нечто по типу http://www.movienizer.com/ru/ но только для книг. Это был бы прорыв.

Опубликовано пт, 24/07/2009 - 21:15 пользователем MkIV

Вот тут мы долго этот вопрос обсуждали, но особо ни к чему не пришли.
http://www.the-ebook.org/forum/viewtopic.php?t=5279&highlight=

Имхо - нужны рейтинги отдельных файлов - архивов книг, по контрольным суммам. Чтобы рейтинги тоже бегали по сети. И не отдельный клиент, а просто возможность работы с emule, shareaza, etc.

Опубликовано сб, 25/07/2009 - 00:49 пользователем kv

MkIV написал:
Вот тут мы долго этот вопрос обсуждали, но особо ни к чему не пришли.
http://www.the-ebook.org/forum/viewtopic.php?t=5279&highlight=
Не сказал бы что ничем не закончилось. Универсальную базу я все-таки сваял:) Правда, для работы с ней пока что есть только одна прога и сама работа по упорядочению инфы требует много времени.

MkIV написал:
Имхо - нужны рейтинги отдельных файлов - архивов книг, по контрольным суммам. Чтобы рейтинги тоже бегали по сети. И не отдельный клиент, а просто возможность работы с emule, shareaza, etc.
да, я тоже думал о плагине к shareaza, который понимает мою универсальную базу. Вот только где бы найти разработчика чтоб это сделал...

Опубликовано сб, 25/07/2009 - 15:06 пользователем eskander

собственно интересная тема
но вот хотелоь бы что бы была возможность у запущеного клиента постоянно выкачивать все новинки и без моего участия (собственно и раздавать тут же) не такой уж и большой обьём а сервак и так почти постоянно включён
список новинок брать примеру у модератора , в случае если какаято книга обновилась в следствии её вычитки , модератор просто присваивал какойнибудь статус ей и она заменялась на новую в автомате
ну и что касаемо авторских прав то ведь не только раздавать можно в зашифрованом виде но наверное и хранить можно так же , а самому иметь доступ по паролю (ключу )

Опубликовано сб, 25/07/2009 - 16:55 пользователем mstorm

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