Предварительные размышления
Опубликовано сб, 21/11/2009 - 13:19 пользователем Morthan
Поскольку вялотекущая дискуссия в комментариях к посту «Прощай, Альдебаран!» не прекращается, вынесу-ка я тему бессерверных сетей в отдельный пост. Предлагаю дальнейшую дискуссию перенести сюда. :-) Набросок описания сети Сеть может быть реализована двумя вариантами, которые условно назовём P2P и F2F. Независимо от варианта реализации она позволяет обмениваться файлами FB2 и поддерживает некоторое подобие поиска без поисковых серверов. Поиск основан на следующих предположениях:
Структура, позволяющая решить такую задачу, реализуется DHT-подобным методом. Вариант P2P Клиент включается в общую сеть, находя адреса других узлов с помощью DHT. Вопрос инициализации DHT будет обсуждаться отдельно. Для поиска данных и получения нужных файлов клиент соединяется с другими узлами напрямую. Преимуществом этого варианта является довольно высокая скорость. Недостаток же в том, что любой узел, зная название требуемого произведения, может получить IP тех пользователей, у которых эти файлы есть. Вариант F2F Анонимная сеть с шифрованием трафика. У каждого пользователя есть уникальный ID. Каждый пользователь раздаёт своим друзьям инвайты, тем самым разрешая им подключаться к своему узлу, и обменивается с ними открытыми ключами. Соответственно, каждый пользователь знает адреса только тех, кто непосредственно к нему подключен. После поискового запроса пользователь получает ID тех узлов, у которых есть нужные файлы. В запросе на получение файла пользователь передаёт следующую информацию:
Запрос передаётся адресату по цепочке узлов. Ответ шифруется открытым ключом и по той же цепочке передаётся обратно. Ни один узел цепочки не может прочесть результат запроса (кроме того, чьим ключом он зашифрован). Ни один узел цепочки не может восстановить IP всех членов цепочки. Преимуществом этого варианта является анонимность. Недостаток — низкая скорость обмена информацией. Для файлов FB2, в связи с их сравнительно небольшими размерами, это ещё может сработать. Для PDF или DjVu всё будет гораздо печальнее. Угрозы Пока были перечислены следующие угрозы: Письма провайдерам, с которых выходят в инет наиболее крупные узлы. В случае F2F сложно определить IP чужих узлов. В случае с P2P такое может сработать. Фальшивые "обновленные версии" книг и клиентского софта. Фальшивые "новинки". Мне порекомендовали в качестве способа борьбы рейтингование. Можно ещё попробовать фидошные "эхо-бомбы" (зазипленные многогигабайтные файлы с нулями внутри) - это в случае, если на узлах происходит перепаковка книг. Перепаковки на узлах не происходит, угроза не актуальна. А даже и без перепаковки: пара гиг пробелов в description'е - и привет демону-каталогизатору. :( Можно при получении книги проверять её размер в распакованном виде и, если что, бить тревогу. Опять же, рейтингование. Disclaimer Автору известно о том, что уже есть торренты, DC, FreeNet, Gnutella, etc. и ещё одна сеть не нужна. Известно, что всё заглохнет на этапе теоретических обсуждений. Не вызывает сомнения, что реализация натолкнётся на непреодолимые технические трудности и будет прекращена. Бесспорно, что энтузиазм разработчиков мгновенно иссякнет и они перестанут работать. И, разумеется, даже если всё получится, эта штука будет жутко неудобной и ею никто не будет пользоваться. Поэтому будем считать, что мы тут просто обсуждаем теоретическую возможность создания такой сети. Чтобы потом, через тыщу лет, кто-то нашёл готовую инфу и сэкономил себе время. :-)
|
|
Комментарии
Отв: Предварительные размышления
ок, можно и на ты
Ну, защита, это требование, которое стоит по умолчанию. Удобство - тем более. Ни одна из существующих сетей не является достаточно удобной для книг. Человек хочет получить доступ к библиотеке книг. Его действия: скачать клиент, зарегистрироваться в сети, дальше он хочет получить, например, конкретную книгу. Без проблем. Набирает запрос, и узел к которому он подключился (это может быть и сервер, тк сеть гибридная) выполняет поиск по названию книги. Клиент в своей базе, а сервер в чужой. Если книга найдена - она скачивается. Если нет, то программа предложит скачать базу из другого места. Для одного файла можно послать поисковый запрос в сеть. И есть вероятность, что файл будет найден. Если брать по-максимуму, это инструмент поиска, чтения, скачивания, добавления, обсуждения, оценивания и т.п. книг.
Размер книги в fb2 - небольшой. Даже по модему 0,2 - 5 Мб выкачивается менее 30 минут. Так что, реально все будет зависеть только от доступности файла в сети, и от желания пользователей загрузить свой канал отдачей файлов. если поиск по уже закачанной базе, то все зависит от базы и локальной машины. По сети - есть варианты. Они пока обсуждаются. Но в целом, поиск одного файла не так долог.
На эту тему сейчас можно долго спорить. Поживем-увидим. Можно ведь и незаконно запретить. А предлагаемую сеть, чтобы полностью прикрыть, потребуется отрубить большинству пользователей доступ в интернет.
Да, база у всех одинаковая. В том смысле, что стурктура базы одинаковая на каждой машине (программа-то для работы с ней у нас одна и та же везде). И в том смысле, что, при должном упорстве, каждый может получить почти такую же версию базы(наполнения), как и у другого участника. Для добавления книги, ее нужно будет положить в расшаренную (наподобие как у eMule) папку программы, и произвести некие манипуляции в программе. Книгу сможет добавить любой клиент, также, как и скачать.
Синхронизация - это действительно проблема. 100% синхронизации достичь почти нереально. Сверять каждый раз при подключении гигабайты данных - тоже нереально. Соотвественно, предлагается следующее. База обновляется в двух случаях: если в сети появилась новая книга, то инфа о ней расходится по клиентам, и они добавляют ее в базу. Проблемы возникают, когда клиент отключается от сети. Сохранять все обновления никто не будет, их может оказаться слишком много. Поэтому, при следующем входе программа предложит пользователю обновить базу. Ну и по его команде база "обновится". То есть, "синхронизируется" с кем-либо по выбору программы, сервера или самого пользователя. Синхронизация будет заключаться в том, что программа сверит с чужой свою базу и узнает, были ли новые поступления. Для этого предлагается к поступившей инфе о файле добавлять дату поступления. Далее, нужно будет сверять хеши файла и метаинформации, чтобы исключить дублирование. Удаленные файлы - тут все хитрее. Теоретически, в такой сети невозможно удалить файл. Его можно удалить только из собственной базы и с собственной машины. Если он куда-то ушел, то уже все, назад его уже не вернуть)) Но если он недоступен поиском достаточно долго, то можно считать, что он "пропал". Вот, вроде, более-менее понятно взаимодействие.
Ну, например, у нас есть две базы. Структуры абсолютно одинаковы. В одной есть данные, другая пуста. Пример данных: список книг в жанрах "фантастика" и "фэнтези" пары десятков авторов. Один автор может писать в 2-х жанрах. Итак, нам нужно: перенести все книги по жанру "фантастика" из одной базы в другую, затем перенести все книги автора, пишущего в обоих жанрах, а затем, все книги по жанру "фантастика". И в конце получить абсолютную копию исходной базы, за исключением, разве что, времени добавления каждой записи... То есть, возможность переноса базы по частям без потери изначальной структуры данных. Вот такая задачка. Вроде даже не слишком сложная.
Гм, создается новый файл fb2. Вычисляется его хэш. Дальше файл добавлется в базу и вытаскивается метаинформация. Вычисляется и ее хэш. Оба хэша также добавляются в базу. Между ними однозначное соответствие: если у метаданных другой хэш, значит и хэш файла другим окажется - они же из него взяты. И тогда это разные версии файла . А вот если хэш файла одинаковый, а метаданные разные, значит одна из записей "левая". Тогда имеет смысл восстановить метаданные из самого файла. И инфа о невалидном файле, должна, наверное, каким-то образом по сети распространиться.
Вот насчет аннотаций стоит подумать, мне кажется... Некоторые их даже читают!)) Но объем - ограничить. Обложки - вряд ли. Красиво, конечно, но картинки весят многовато...
Ну, у тебя уже есть БД, где как-то что-то складируется. Соответственно, можно использовать БД и часть написанных программ. Что-то в них изменить под вышеизложенные задачи. Как-то так. Например, если удастся копировать БД по частям на локальной машине, то и по сети это будет не намного сложнее.
Что конкретно делать, я сейчас тебе не скажу)) Нужно узнать, что Morthan по этому поводу думает, во-первых, ну и потом разобраться, кто, что и на чем делать может/будет. Может какая другая идея появиться или еще что-то...
Отв: Предварительные размышления
Если у всех база будет одинакова, то есть большая вероятность, что она будет лучше приспособлена для какой-то определенной категории юзеров а для остальных - нет. Это в лучшем случае, а в худшем - плохая для всех, потому как найти компромисс очень сложно. Например, моя база хороша для библиотекаря, потому как она позволяет добавить что угодно. Но вот работать обычному юзеру с ней очень тяжко. Понятно, что если будет приложение которое будет делать все само, то оно и по барабану как база устроена, но есть большая вероятность, что из-за сложных выборок оно будет тормозить. А другая крайность - простейшая статичная база сразу тянет другие проблемы, типа, чего-то поменять в процессе функционирования, с учетом распределенной системы, будет нереально. А я сомневаюсь что изначально получится все предусмотреть. Я, например, так не смог.
Отв: Предварительные размышления
1) наличие сервера - он выступает посредником, если пользователь хочет закрыться от всех других и доверяет лишь серверу,
2) f2f-сеть - ip-адрес используется только при контакте с "друзьями". Это если он доверяет кому-то другому, а серверу и всем остальным не доверяет.
Можно использовать или один механизм или оба сразу.
Механизмы принуждения есть разные. Можно рейтинговать пользователей и использовать рейтинг для определения приоритетности его заявок и скорости скачивания. Мне этот способ не нравится. Есть вариант скачивания книг в базу, чтобы нельзя было из нее их удалить, и использовать ее для отдачи. Можно: только в базу, или и в базу и в файл. Можно ограничить базу по объему и др. Этот вопрос пока не обсуждался. То есть, варианты есть, но ничего конкретного еще не обсуждалось.
Ключевые слова "будет приложение" и "изначально все предусмотреть". Приложение как раз и будет взаимодействовать с базой и с сетью. Функциональность должна устроить как тех, так и других. Собственно, я считаю, что нужно отталкиваться от функциональности либрусека. Она большинство устраивает. По поводу торможения - это как реализовать взаимодействие. берем простейшую мультипоточность, и в отдельном потоке работа с базой, основное окно приложения другом. И пока идет выборка, в основном окне надпись, вроде "Идет выборка из базы данных, пожалуйста, подождите". Изначально придется предусмотреть максимальное количество всего. Это распространенная проблема. Предусмотреть все нельзя. Но можно предусмотреть необходимое. По поводу обновления - тут придется обновлять программу. Пользователь будет выкачивать новую версию. А потом новая версия программы будет выкачивать контент из старой базы в новую. Здесь я большой проблемы не вижу.
Это уже издержки. С этим либо придется смириться, либо, например, назначать модераторов/библиотекарей, с правом удалять файлы из сети, а не только со своей машины. Через сервер это возможно. Но нужно ли - это вопрос.
Если удалить файл из списка локальной базы, то не нужно. Клиенту приходят только сообщения о вновь добавленных файлах. Либо он скачивает обновления из чужой базы. Этот файл вряд ли окажется в обновлениях. Если же ты имеешь в виду, что некто, получив файл другим способом выкинул его обратно в сеть, и он в таком случае разошелся как новый - в теории это возможно. Но часто ли так будет? И опять же, можно на сервере сделать блек-лист хешей файлов и сверяться с ним при добавлении.
ну, у нас изначально все затачивается под несколько конкретных форматов. Правда, я подумываю о том, чтобы расширить программу легко можно было и для других типов файлов, но серьезно я пока это не рассматриваю.
берем форматы fb2, pdf, djvu за основные, в уме держим: fb3, rtf, doc.
Соответственно, выборку из базы производить нужно по тегам фб2, имени файла и по информации, которую можно вытащить из файлов других типов. Мне представляется, что информацию о файлах каждого типа нужно хранить в базе в отдельных таблицах, и чтобы база предоставляла возможность выборки из каждой из таблиц только по хранящейся в них инофрмации. А откуда выбирать, решал клиент. Если поиск по имени файла - из всех таблиц. А если поиск, напрммер, по ISBN - только из таблицы с fb2. Возможно, естественно, этот вопрос решить и иначе. Я все же не эксперт по БД, хотя и знаком с ними относительно неплохо, так что могу где-то что-то неправильное сказать. Вроде я примерно описал, что хочется получить.
Имитация модели макета чучела миража формализации протокола обмена на локальной машине.
-Пусть есть 2 БД А и Б с одинаковой структурой. И есть некая программа П, которая умеет читать из этих баз по команде пользователя.
1) П посылает А запрос на выборку информации по какому-то из тегов (теги заранее строго определены форматами файлов, в базе предусмотрена возможность выборки по ним).
2) А производит выборку и выдает ответ.
3) П обрабатывает ответ и приводит(возможно и не придется, это можно учесть при формировании ответа от базы А) к виду, удобному для передачи и однозначному (чтобы эти данные в базу можно было внести единственным способом).
4) П передает данные Б.
5) Б записывает данные тем самым единственным способом, чтобы они расположились точно так же/похоже на то, как в исходной базе. И сохраняет также инфу о том, запрос по какому тегу повлек за собой получение этой информации.
6) П снова формирует запрос для А с другим тегом. Для этого он запрашивает у Б, какая часть базы уже скачана.
7) Б возвращает ему тег, по которому был предыдущий запрос (в общем случае "теги" и "были", но вряд ли имеет смысл все. наверное, только наиболее общие, вроде жанра).
8)И П добавляет к запросу "выбрать" "кроме"+тег.
9) И передает А
10) А обрабатывает запрос и передает выборку П.
11) П обрабатывает и передает Б.
12) Далее, П снова хочет получить информацию по первому тегу.
13) Он запрашивает Б, та говорит, что все выкачано по этому тегу и отдает ему дату последней добавленной записи.
14) П формирует запрос к А - выбрать все, кроме более раннего, чем дата.
15) А выбирает и возвращает П,
16) П передает Б.
17) Б сохраняет.
Грубо вот как-то так это выглядеть должно.
Автоматическая рассылка о добавлении - поскольку добавление происходит не руками, а программой, то за это ответственна программа. В данном протоколе это будет выглядеть, как:
1) П добавил в А информацию.
2) П узнал о том, что он добавил новый файл
Все это никак не влияет на запросы к БД, тк все происходит внутри П.
3) П запросил у А информацию о нем,
4) затем передал Б.
Это уже соответствует описанному выше.
В сетевом же варианте вместо П будет 2 программы, которые будут обмениваться информацией между собой.
Пример: "П2 просит П1 сделать выборку из А. П1 выбирает и передает П2. П2 заносит в Б."
Отв: Предварительные размышления
Marked, я запутался. Ты пишешь о сервере а потом о распределенной системе. Это ж принципиально разные подходы. В случае сервера, где есть эталонная база, снимаются все проблемы синхронизации баз. Точнее, эта задача вырождается в задачу синхронизации локальной базы с центральным сервером. А в случае распределенной системы это - ключевая проблема - ИМХО, ессно. Все что ты пишешь о синхронизации баз, касается только пары баз - это не проблема. С моей точки зрения, проблема есть в синхронизации баз в масштабах всей сети в целом. Ну вот, например, вышла новая книга Луки, и ее моментально вбросили в сеть в 100 разных местах, причем, они представляют собой, допустим, 5 разных файлов - форматы там, из разных первичных источников и т.п. Ну и первоначально это все - уникальные объекты, потому как в каждой точке они попадают впервые. По-моему, синхронизация состоит в том, чтобы через определенное время все эти 100 экземпляров "схлопнулись" в один объект "книга", привязанный к одному объекту "автор Лука" и у них связь с 5-ю экземплярами разных файлов. Как это сделается и должен обеспечить вот тот протокол. Ну а если есть сервер, то все это не надо, надо о другом думать - как защитить сервер от 1. наездов со стороны и 2. приватизации изнутри.
Ну и в таком же разрезе можно посмотреть и на остальное, например, на структуру базы. ДОпустим, все делается как ты сказал. Т.е.
По поводу защиты, то так и надо говорить - "основана на доверии пользователей между собой". Тоже вариант.
где-то вверху мелькали слова насчет комбинированной схемы, это когда база данных централизованная, а вот сами книги передаются по сети между пользователями, я правильно понял? то может на этом и остановиться?
Отв: Предварительные размышления
Это не совсем принципиально разные подходы. В данном случае подразумевается, что система может работать и без сервера. С сервером — быстрее и удобнее, но ежели враги сервер выбьют, то она продолжит функционирование и без оного. Просто с ухудшением качества работы: допустим, книги качаются в два раза медленнее и поиск книг можно вести только по автору или названию (а не по всем полям FB2).
К синхронизации базы с центральным сервером я отношусь достаточно скептически. Во-первых, когда первая тысяча узлов начнёт синхронизировать базу с сервером, загрузка серверного канала будет весьма ощутимой. Хотя, можно с сервера сбрасывать файлы обновления БД, подписанные сертификатом сервера и гарантирующие, что их создал именно сервер. А дальше уже эти блоки расходятся между узлами сети. Надо это обдумать.
Но есть ещё и во-вторых. Если мы сильно завязываемся на центральный сервер, то при его исчезновении работоспособность сети падает почти до нуля. Этого хотелось бы избежать.
Вчера я закончил описание примерного протокола подключения узла к сети. Согласно ему каждый узел при подключении к сети синхронизирует базу с узлами своей группы в обязательном порядке. В группе может быть максимум 256 узлов, передаются только отличия от существующей групповой БД, так что можно надеяться на небольшой трафик. Ну и с большой вероятностью обновляться будут все онлайновые узлы. А оффлайновые обновятся при переходе в онлайн.
В некотором роде, да. Есть два варианта пересылки данных с узла А на узел Б. Первый — по цепочке узлов А-В-Г-Д-Е-Б. В данном случае узел А знает адрес только узла В, а узел Б — адрес узла Е. Второй способ — используя сервер в качестве посредника. Узел А передаёт на сервер запрос, куда он хочет послать данные, и получает адрес любого промежуточного звена в цепочке (пусть это будет Д). Т.о. узел А знает адрес Д, но не знает, что это именно Д. Далее данные идут по цепочке А-Д-Е-Б. То есть, немного быстрее. Ну и сопоставить адреса с ID узлов нельзя.
Отв: Предварительные размышления
Честно говоря, не вижу больших препятствий к поиску по всем полям, кроме как ограничение трафика в сети))
Вот у меня была идея, чтобы сервер по запросу клиента мог искать в сети последние обновления базы и соединять клиента именно с нужным узлом. Но я не уверен, что это будет хорошо работать. Возможно введение должности "библиотекарей", которые будут собирать у себя на машине наиболее полную текущую базу, а сервер будет соединять клиента с одним из них. Про сертификаты подумать стоит, в том числе и про "знак качества" для файла...
С таким подходом я не соглашусь :-) На мой взгляд, скачивать базу нужно по желанию пользователя и по частям. Например, если ему нужно скачать всего одну книгу, то ну и фиг с ним, пусть поставит клиент, запустит сетевой поиск и выкачает файл. Просто такой поиск не позволит искать группы файлов по жанрам или еще какие ограничения. Не даст гарантии в том, что файл будет найден при отсутствии онлайн всех его владельцев. Про обязательный порядок - не нужно, никто не помешает ему воспользоваться старой базой, многие файлы останутся на своих местах. А если не останутся - сам виноват, что базу не синхронизировал.
Опять же, лучше по желанию пользователя и по частям. А то, может он в армию служить ушел, через год вернулся, а ему там 10Гб обновлений выкачивать надо.
Отв: Предварительные размышления
Отв: Предварительные размышления
Если память мне не изменяет, то магнитные линки на торренте как бы позволяют обойтись без сервера. Сервер (трекер) на торренте занимается исключительно координацией усилий скачивающих и раздающих, сообщает им оптимальные варианты, какой кусок кому и у кого качать. Без трекера скачивание не будет оптимальным, но будет всё равно.
Надо посчитать. Мне кажется, что всё не так страшно, как может показаться на первый взгляд. Ведь в большинстве случаев будут передаваться совсем небольшие объёмы информации. Допустим, при условии, что ничего не изменилось, будет передано 8*N байтов, где N — количество авторов в базе данных. Опять же, это в случае недоступности сервера.
Ну, как бы да. Существующие P2P-технологии не очень хорошо приспособлены к книгообмену. Если бы можно было обойтись существующими методами!
Отв: Предварительные размышления
Отв: Предварительные размышления
Если использовать предложенный мной метод, то в случае, если ничего не изменилось, будет передано сообщение, что ничего не изменилось. При условии, что в базу добавили 100 файлов, будет передан список с информацией о 100 файлах. При условии, что пользователь решил обновить только часть базы, например, по тегу "фэнтези", то ему придет только список из тех новых книг, которые имеют в дескрипшне соответствующий тег. А проверять, новые или нет - сохраняя в каждой базе дату добавления книги. Так что перекачка базы будет нужна только, если пользователь качает ее с нуля. Либо налицо явное несоответствие с текущей базой и он хочет ее всю заменить. Да и то, всю качать необязательно, можно по частям.
Отв: Предварительные размышления
Сейчас главная идея сети в чем: есть узлы и есть сервер. Сервер управляет сетью, улучшая доступность узлов и скорость передачи. Но он ничего не хранит, кроме списка узлов (ip+id ну и еще что-нибудь, примерно, как сервер ICQ).
Собственно, таким образом он защищается от наездов со стороны - он ничего не хранит, даже списка книг. Соответственно, и спросить с владельцев никак. Он только позволяет всем пользователям сети достаточно быстро соединяться между собой и предоставляет относительную анонимность.
Мы как раз хотим сделать децентрализованную базу. Это и есть защита от приватизации изнутри. В нашем варианте сети, даже если сервер убрать, сеть сможет функционировать. Правда, работать будет чуть хуже.
Проблемы фактически нет. На самом деле, они уже не уникальны. Хэш файла уникален только для разных файлов. Мы передаем хэш файла вместе с метаинформацией. Соответственно, в любой базе, даже если в нее передастся инфа о всех 100 файлах, в списке появятся только пять. По автору они не "схлопнутся" в один объект, внутри каждой базы будут храниться список всех 5. Это - издержки. На либрусеке от хранения нескольких версий тоже не избавились. Зато выборка из базы по автору выдаст все 5 файлов. Поиском в сети также можно будет найти все 5 файлов. То есть, просто напросто нужно сравнение хэша файла при добавлении в базу. Работает примерно так: когда в сеть вбросили 100 файлов, кто-то делает поиск по сети и находит всего 5 :-) файлов, которые можно скачать из 100 разных источников.
Это уже тот, кто будет сетью "руководить" должен решать, стоит ли обновлять или нет. Если из 100 узлов обновили только 20, то другие не смогут синхронизировать базы и получат сообщение, что нужно обновление до более новой версии программы. Делать это слишком часто нельзя, это будет неудобно для пользователей. Поэтому, разработчики, то есть мы, не должны каждый месяц создавать мелкие обновления, а обновлять программу только в необходимых случаях, например, когда новый формат файла стал популярен, или нашли в ней серьезную уязвимость. Собственно, объем программа+база без наполнения нужно минимизировать, чтобы скачать можно было быстро.
Отв: Предварительные размышления
Отв: Предварительные размышления
Ну так там же поиск был, по базе, которая на сервере! Список файлов с описанием.. А у нас на сервере - список пользователей. И все. Мы только предоставляем им возможность общаться между собой. Как ICQ почти. Там тоже можно файлы передавать. Собственно, мы с друзьями через нее несколько гигов мп3 перекачали в последнее время... И не только мы. А сервер как есть, так и остался.
ну так, кто-то другой поднимет сервер, и вся сеть пойдет к нему. А наполнение в сети как было так и останется. Она даже работу не прекратит.
К сожалению, от этого вряд ли удастся избавиться. Но, учитывая распределенность данных, эта проблема чуть менее актуальна. Пока я не вижу способа сделать вменяемое слияние книг автоматическим.
Нейронные сети, разве что.Так что, остаются библиотекари/модераторы и рассылка по всей сети сервисных сообщений, удаляющих "плохие, лишние" книги...Отв: Предварительные размышления
Пока форматы можно разделить на три: FB2, не-FB2 текстовые и не-FB2 бинарные. С первыми вроде ясно, со вторыми и третьими можно использовать FBD, хэшировать бинарные можно непосредственно, текстовые как-то преобразовывать (чтобы не было разночтений от переформатирования текстов, разбиения-слияния строк и т.д.).
Отв: Предварительные размышления
Первоначально я планировал обмен только FB2. Причина: в сетях F2F низкая скорость обмена информацией. Средний размер FB2-файла из моей коллекции около 1.5 мегабайт. Это терпимо. Но я с трудом представляю себе скачивание через F2F 20-мегабайтного djvu/pdf. Конечно, расставить точки над i может только опыт, но...
Отв: Предварительные размышления
С другой стороны, эти форматы сравнительно компактны, следствием чего есть то, что либу вполне можно раздавать полностью а потом обновления, как Траум делает. Да, здесь в жертву приносится оперативность доступа к новинкам, ну дык когда на либрусеке ввели месячный "отстой", то народ побухтел, но не помер. Потому как это все же лучше, чем ничего.
А вот для емких файлов типа пдф или джву создать одно хранилище, где есть все, невозможно. Например, в либгене объем уже достиг ТБ, и усе, больше на винт не влезет физически, теперь коллекцию надо как минимум делить на два хранилища на разных не просто серверах, а хостингах.
Отв: Предварительные размышления
Ну, на мой взгляд, сеть должна поддерживать популярные форматы. С того же осла и десяток Гб скачать можно в приемлемые сроки - пару недель - если скорость подключения нормальная и раздающих много. Так что ради 20 Мб pdf или 50 Мб djvu - можно и подождать пару-тройку часов. К тому же, для сканирующих и вычитывающих обмен этими форматами может быть достаточно важен.
Отв: Предварительные размышления
Да фанаты-то найдутся. Тут, скорее, вопрос, каким образом безопасно для сети предоставлять им такие возможности...
Я имел в виду, скорее, что сервер будет отвечать за их валидность, возможно и формировать их.
Отв: Предварительные размышления
Если не поможет - отключать газ. :-) Не позволять скачивать книги и опять же предупреждать текстом - за что именно.
Конечно, появятся личер-моды клиентского ПО - с выкушенными предупреждалками, подделкой счётчиков отдачи и т.д. Но с ними тоже можно бороться, опыт можно перенять у ослосети.
Отв: Предварительные размышления
Поправка: если клиенту долгое время недоступен файл, то имеет смысл объявить его "в розыск" - пусть все живые узлы опрашивают свежеподключившихся. Если это не даёт результата больше нескольких cуток - тогда тревожить библиотекарей, чтобы искали руками (в вебе, на болванках с архивами, ...), может быть, даже придётся пересканить заново. Во всяком случае, список "пропавших без вести" файлов должен быть.
Отв: Предварительные размышления
С этим согласен.
С этим не согласен. Хэш должен считаться именно из конечного файла. Это нужно для того, чтобы файл можно было скачивать одновременно с нескольких источников. Так eMule работает, кстати.
Написал "наверное, каким-то образом" потому, что этот вопрос еще не обсуждался, в особенности, конкретная его реализация.
Тут я вижу проблему в основном в выдирании картинок из файлов. Занимаемое thumbnail'ами место - тут считать надо. Отдельно картинки передавать - это вряд ли, они к книге должны быть привязаны.
Отв: Предварительные размышления
Кстати, кроме поддержки версий книг и обмена отзывами, ещё одна функция, которую неплохо бы, чтобы распределённая библиотека представляла - это контекстный поиск по всей библиотеке ("поиск цитаты"). Гугля тут, ясен перец, вряд ли поможет (вернее, я попросту не представляю - как именно), зато каждая из машин, входящих в РБ, может устроить обыск только по небольшой части контента, что ИМХО есть гуд. :)
Отв: Предварительные размышления
Имеется в виду поиск цитаты внутри текстов книг? Боюсь, что это будет нереально в предложенные системы встроить...
Отв: Предварительные размышления
Системы полнотекстового поиска — это вещь совсем особенного свойства. Я когда-то в них углублённо ковырялся и могу с уверенностью сказать: думать об этом пока рано. Просматривать при каждом запросе весь контент нереально. Индексатор же штука очень сложная.
Отложим это требование на перспективу.
Кстати, почему Гугль здесь не поможет? Пока на Либрусеке есть возможность читать книги онлайн, там вполне можно найти цитату через расширенный поиск Гугля.
Отв: Предварительные размышления
Отв: Предварительные размышления
Да, про спейслиб прочитал, штука интересная. Там, правда, есть некоторые особенности. В частности, не предусмотрен тот факт, что у одной книги может быть несколько версий.
А полнотекстовый поиск, как я понимаю, там реализуется через внешнюю прогу — Архивариус 300? Если так, то на свою скачанную локальную копию можно натравить любую поисковую систему, хоть от того же Гугля.
Отв: Предварительные размышления
Отв: Предварительные размышления
Отв: Предварительные размышления
вот такой еще есть подход
http://spacelib.narod.ru/news.html
Отв: Предварительные размышления
Кстати, вполне возможна и другая парадигма. На основе разделения системы на несколько практически независимых подсистем.
Например, насчет рецензий\отзывов это вполне может быть самый обычный сайт, где есть только это - для тех книг что есть в базе. И гонять через сеть уже на надо. И в то же время, это стимулирует юзера искать обновление базы, потому как новые книги он сначала находит на сайте. Можно подумать насчет использования уже имеющихся проектов, типа ИМХОНЕт.
Организационные вопросы обмена - это совсем другое, разные технические аспекты, подключения там и т.п. могут решаться в каком-то уже имеющемся форуме в отдельной теме, или в социальной сети, да где угодно, там просто знакомятся и вырабатывают вот те самые "отношения доверия".
База данных - это за библиотекарями, вот здесь надо думать как им синхронизировать базу между собой. А юзер устанавливает прогу и для него все заканчивается - считывается база и книги сами валятся ему на комп - ессно в рамках подписки по темам\авторам и т.п. Если юзер дозрел до того, чтоб самому выкладывать книги, то есть два пути - связывайся с одним из имеющихся библиотекарей, а не хочется в помощниках ходить - то изучай как настроить ПО чтоб самому стать библиотекарем.
Да, такая система работать будет по другому, нежели веб, например, здесь нету моментальной связи, типа, рецензия (поисковый запрос)- ссылка - книга на компе. Вполне может быть что это растянется на неделю-две. Но, с другой стороны, если в сети будет много юзеров и источников, то пока юзер соберется идти на сайт искать рецензии, эти книги давно уже приехали. С третьей стороны, здесь передача по сети тоже упрощается - отпадает необходимость в поисках, главное, организовать доставку до места назначения - юзера. Тоже можно воспользоваться существующими механизмами, например, IRC, или делается плагин к торрент-клиенту, что базу понимает. Можно и свою сеть, с адресованием, узлами и т.п. - по принципу, например, старого Фидо, ессно, как надстройку над TCP/IP.
Отв: Предварительные размышления
Есть вероятность, что такой сайт прикроют. Разве что, давать на нем линки на интернет-магазины, маскируясь под обычный каталог. Но контент - только наличествующий в сети...
Собственно, то, как синхронизация видится мне, я уже объяснял. Здесь отличие только в том, что полная синхронизация не для всех доступна.
Ну, зазвать пользователей в сеть можно откуда угодно))
Вот это и обсуждается.
Собственно, отличие от того что предлагаем я и Morthan, здесь, в основном, в том, что мы хотели бы увидеть все функции совмещенными в одной программе, а ты предлагаешь разбить их между разными системами и сильно разделить пользователей в правах.
Отв: Предварительные размышления
-чтоб сразу все в одном - это веб и есть. Придумать лучше не получится.
-пользователи и так сильно разделены. Не мной, а сами, исходя из того, что они хотят получить от системы. И такое разделение у вас тоже есть, пока ты сам сказал о 2-х категориях - те, кто управляет сетью и все остальные. Ну и от идеи библиотекарей вы пока не отказались, токо их место пока четко не определено.
-трудоемкость разработки. Считаю что реализовать несколько сравнительно небольших проектов, пусть и взаимосвязанных проще, чем один большой, где все внутри.
Мало того, я предлагаю отделить сам обмен от ведения распределенной базы. И реализацию начать именно с базы, потому как она лежит в основе всего.
Отв: Предварительные размышления
Идея насчёт вынесения части функциональности здравая и мне очень нравится. Потому что реализовать чисто DHT-шный поиск/рецензирование/обсуждение будет сложно и ненужно. Я планирую сделать в бессерверном варианте только самый базовый поиск: из списка выбрать автора, из списка его произведений выбрать книгу, из списка файлов, лежащих у разных пользователей выбрать нужный. Вот это должно работать всегда — независимо от сервера.
А всё прочее, в частности, расширенный поиск по жанрам, рецензии на книги, обсуждения на форуме — можно легко вынести на внешний сервер. Самое смешное, что его прикрывать не за что. На нём нет ни единой ссылки. Только указание точного названия книги и точного имени автора. По этой информации нужную книгу можно достать из сети самостоятельно. :-)
Страницы