Предварительные размышления
Опубликовано сб, 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. и ещё одна сеть не нужна. Известно, что всё заглохнет на этапе теоретических обсуждений. Не вызывает сомнения, что реализация натолкнётся на непреодолимые технические трудности и будет прекращена. Бесспорно, что энтузиазм разработчиков мгновенно иссякнет и они перестанут работать. И, разумеется, даже если всё получится, эта штука будет жутко неудобной и ею никто не будет пользоваться. Поэтому будем считать, что мы тут просто обсуждаем теоретическую возможность создания такой сети. Чтобы потом, через тыщу лет, кто-то нашёл готовую инфу и сэкономил себе время. :-)
|
|
Комментарии
Отв: Предварительные размышления
Я всё думаю =)
Мысли приходят в голову, если честно, какие-то совсем уже фантастические. Например, сделать сеть не просто каналом передачи данных, а привить ей свойства ИИ, так что каждый узел сети будет чем-то вроде нейрона в нейронной сетке. Такая сеть, в частности, должна быть способна обучаться, кроме того, возможно задействовать автоматическое доказательство генерируемых теорем.
Нахрена это надо? Чтобы, хотя бы частично, задачи по выработке противодействия угрозам и поддержания доступности информации решала сама сеть. Для этого ещё и код самомодифицированный сделать. :)
Например, впрыск в эту сеть каждой новой книжки, такая сеть должна воспринимать как поступление новой информации, содержащей в книге, которую она может переработать. Вброс фейков - как мусор от которого надо избавляться. Ещё и сама сможет, задействуя мощности узлов, проводить распознавание книг.
Короче, даёшь Скайнет для борьбы с копирастией!
Отв: Предварительные размышления
Этому больше не наливать ;)
Отв: Предварительные размышления
Вообще, идея хороша. В случае реализации тянет на нобелевку за создание полноценного ИИ. :-)
Если серьёзно, на современном этапе развития вычислительной техники это будет опять же, рейтингование. Поскольку рецепторами сети, определяющими фейк или не фейк, будут читатели.
Отв: Предварительные размышления
Если совсем серьёзно, основная мысль, что такая библиотечная сеть будет обладать и серьёзными вычислительными ресурсами, которые можно как-нибудь полезным образом для её же функционирования использовать. А полноценный ИИ - это мечта к которой надо стремиться в данном случае :)
Отв: Предварительные размышления
Не поможет. Ибо книг не просто дофига, а слишком дофига. Даже в сегодняшнем Либрусеке больше 100 000, причем большая часть не прочитана и не отрецензирована.
Или выйдет допустим новая книга какого-нибудь столпа вроде Пелевина, и все хором будут добавлять ее в сеть. Что будет? Правильно, ничего хорошего - будут гулять по сети десятки, если не сотни вариантов, различающихся на пару символов может быть. Поэтому, как ни вертись, а без "головы" сеть не получится, точнее будет неким аморфным "болотом", в котором опять-таки каждому придется самостоятельно отделять зерна от плевел. Мой вариант я вижу наиболее приемлемым. Это, если кто не прочитал, пародия на aniDB.net - центральный сайт с описаниями, хешами, названиями книг и авторов и всяческими комментариями с форумами (общаться-то ведь тоже надо будет), но сам контент лежит в ed2k. На случай, если сайт упадет, есть клиент, который скачивает с сайта всю его DB и действует как оффлайновая версия сайта. И не надо изобретать велосипед, ослосеть вполне справится с задачей, тем более что в ней, в отличие от торрентов, можно "зашарить" одним кликом сразу сотни тысяч файлов безо всяких перегрузок.
Отв: Предварительные размышления
Итак, если я правильно понимаю, предлагается воспользоваться готовым решением? Т.е., берём готовую сеть ed2k, пишем клиента для поиска по БД, сооружаем центральный сайт, пару недель/месяцев на раскачку и PROFIT! Если так, то это удобный, легко реализуемый запасной вариант, который вполне можно оставить на тот случай, если ничего нового изобретено не будет.
Однако же следует предусмотреть возможные угрозы для сети в этом варианте. Бывают случаи, когда представители правообладателей пишут провайдерам всякие мерзкие письма, насчёт пользователей, которые качают нелицензионный контент. Бывают провайдеры, которые, недолго думая, отключают данным пользователям инет. Это те случаи, про которые я могу вспомнить, не особо напрягаясь.
Ну и, опять же, центральный сервер является уязвимой точкой. Помню времена, когда Либрусек месяц нельзя было открыть. :-( Для нас это не смертельно, но неприятно. Новинок уже не почитаешь, только то, что было в локальной базе на момент отруба сервера.
Отв: Предварительные размышления
Нужно-нужно. На войне - как на войне, однако....
Отв: Предварительные размышления
Отв: Предварительные размышления
Либо реморализация, либо вопросник вида "введите 18е слово на 127 странице книги"
Отв: Предварительные размышления
Дырку в голове и кабель оптоволоконный туда. А подсоединить сама сеть должна.
Отв: Предварительные размышления
Некоторое время назад, когда менялся протокол ICQ, обсуждали с приятелем создание безсерверной аськи... Результаты обсуждения были, как в описанном способе F2F, плюс выявили следующее: цепочки друзей не бесконечны. Сеть получится разделенной на фрагменты. Подключение к такой сети может оказаться весьма проблематичным. Нельзя забывать о том, что злоумышляющий может включиться в цепочку, разрешить всем подключаться к себе и насобирать IP-адреса и сведения о имеющихся у них файлах. При отключении одного из пользователей для других может исчезать ощутимая часть сети. Это я так, навскидку вспомнил. Если я в чем-то неправ - поправьте.
Мне приходят в голову следующие решения проблемы:
Вариант 1: каждый доступен каждому - то есть, если один раз удалось подключиться к какому-либо клиенту, то в следующий раз при поиске подключение к нему происходит напрямую. Проблема - нужна будет некая оптимизация поиска при большом количестве IP в списке. Ну и, соответственно, открытые IP. Вообще, это вроде и есть предлагаемый вариант P2P, если я все правильно понял.
Вариант 2, на мой взгляд, самый вменяемый:
клиент-серверная модель. Имеется сервер. На нем регистрируются пользователи. Сервер знает их айпи адреса. огромная такая база соответствия ip и id. id хоть текстовые, хоть цифровые, как в ICQ. Кроме-того, сервер умеет принимать/отдавать файлы. Как выглядит система в работе: пользователь регистрируется на сервере. далее он может: начать поиск файла. Сервер по команде клиента опросит всех известных ему пользователей и выдаст информацию. Недостаток - долго. Оптимизируем клиент: первый раз долго, но зато нашли список id узлов и сохранили его. Второй раз по похожему запросу начнем поиск с них, возможно, найдем уже быстрее. Файл найден, нужно скачать. по команде клиента сервер запрашивает у найденного узла передачу файла. тот передает файл маленькими (относительно) частями, в архиве. название архива также меняется на что нибудь, пусть на md5 реального названия. Соответсвенно, на сервере всегда будет тока набор нулей и единиц, а реальной информации не будет.
Один из пользователей не узнает ip адрес другого. Хотя, возможность прямой передачи следует в
программе предусмотреть. то есть идея такая: "мы даем пользователям возможность обмениваться файлами, что и как они передают не наше дело." Эту же прогу можно и для общения использовать, вместо аськи)) С распаковкой тут есть недостаток, конечно. Ну, автоматическую разархивацию встраивать не нужно. переложить разархивацию на пользователя.
Рейтингование - это правильно. Можно также добавить оценки пользователей и тп.
По поводу нейронных сетей - честно, не осознал, как их можно сюда прикрутить.
ЗЫ: если сделать OpenSource проект, я готов поучаствовать, как программист.
Отв: Предварительные размышления
Ага, в моей реализации бессерверной аськи они называются «группами». :-)
Тут всё зависит от способа получения адреса по ID. Если использовать центральный сервер, который будет получать ID и возвращать пользователю соответствующий адрес (если ID входит в число друзей пользователя), то с подключением проблем быть не должно.
Это да, при условии что количество друзей не ограничено. Но в сети Netsukuku, откуда я невозбранно позаимствовал процедуру трассировки для варианта F2F, количество узлов в группе ограничено (где-то около сотни). Если продумать ограничения, то скомпрометировать всех (или даже только одну группу) не получится.
При условии, что эта часть сети подключена только через этого пользователя — да. Это нужно учитывать при разработке топологии и, по возможности, избегать таких вещей.
Отв: Предварительные размышления
Собственно, тогда получается, что в поиске будет участвовать только одна группа, и другим пользователям сети их файлы будут недоступны. На мой взгляд это не есть хорошо. Ну а зачем тогда сеть? Друзья и так друг другу файлы скинут. То есть, добавляться в друзья все равно будут "левые" личности, для расширения "группы". Так что я пока не увидел абсолютные преимущества такого подхода в плане защиты. Да, вероятность, что Ваши файлы "увидят" "копирасты" меньше. Но она все равно остается. Даже если это самое ограничение на количество "друзей" ввести. И при этом теряется целостность сети.
Ну, тогда это не совсем бессерверная сеть... Ну, допустим, такой механизм вполне приемлем. Но, например, пользователь хочет подключиться к сети, а друзей там у него нет. Как в таком случае поступать? Коннектиться к этому самому серверу и перебирать все id, до тех пор, пока кто-нибудь не "добавит" его в друзья?
Отв: Предварительные размышления
Нет. Группы объединяются между собой и в поиске участвуют все группы. Просто запросы внутри своей группы имеют приоритет и быстрее выполняются.
Это общая проблема сетей F2F. Равно как и сайтов, наподобие хабра. Система инвайтов имеет как плюсы, так и минусы. :(
Отв: Предварительные размышления
При полном отсутствии сервера я как-то не представляю себе механизм их объединения.
При наличии сервера с базой узлов это, конечно, вполне понятно и логично.
Отв: Предварительные размышления
Скажем так — объединение групп принципиально возможно. Друзья у узла могут быть не только среди своей группы. А вот как убрать отсюда слова «могут быть» и добавить «обязательно есть», над этим надо подумать. В Netsukuku есть термин «пограничный узел», обозначающий узел, у которого есть связи не только со своей, но и с чужой группой/группами. Такие узлы кроме таблицы маршрутизации внутри своей группы хранят аналогичную таблицу маршрутизации между группами.
Соответственно, для передачи пакета в чужую группу нужно найти свой пограничный узел, у которого в таблице маршрутов прописан путь к этой группе, и швырнуть ему пакет с обратным адресом.
Отв: Предварительные размышления
Мы немного о разных вещах говорим)) Собственно, я исходил из предположения, что "группа" - это некий сегмент сети, где каждый пользователь может тем или иным путем "соединиться" с другим. То есть, грубо говоря, если есть узел А и у него десяток узлов-друзей, один из которых, допустим, узел Б, и есть узел В, у которого 2 десятка узлов-друзей , среди которых узел Б также есть, то узлы А и В могут "соединиться" посредством узла Б. Следовательно, они входят в одну группу. При этом если есть некий узел Г, у которого 40 друзей, но ни один из них или ни один из друзей друзей и т.п., не имеет никакой связи с узлом А, то это разные группы. То есть, имеется, как бы "физическое" (не знаю, как это иначе назвать) разделение. Фактически, это 2 несвязанных сети. Вами же, видимо предполагается, что "группа" - это некая логически выделенная часть сети.
Я, собственно, хочу избежать случая, когда будет куча таких несвязанных сетей с малым количеством контента. Вместо этого будет сеть с сервером, который позволит любой такой сети-группе или любому новому пользователю достаточно легко влиться в общий обмен. При этом, естественно, возможно и появление других серверов. А в случае комбинированной схемы - появление отдельных "кусков" сети без сервера. В случае отключения сервера, кстати, существующая сеть не развалится, а будет работать как f2f и ждать создания нового сервера...
Отв: Предварительные размышления
Нетрезвая идея - ARP
Отв: Предварительные размышления
Идея настолько нетрезвая, что мне даже непонятна. :-)
Желаю подробностей!
Отв: Предварительные размышления
Как работает ARP ? Надо найти нужный IP (у нас - нужный ресурс). Отправляется датаграмма, содержащая искомый IP в качестве параметра, кто первый встал - того и тапочки. В нашем случае не прокатит потому, что нижний по сравнению с IP уровень не маршрутизируется, мысль не только нетрезвая, но и неудачная. Пошел копаться в распределенных хранилищах и cloud computing. :(
Отв: Предварительные размышления
Отв: Предварительные размышления
Хм... Пошел изучать IGMP.
Отв: Предварительные размышления
Кстати, к идее логически выделенных групп в книжной f2f сети, да и в сети с сервером тоже. Можно разрешить пользователю создавать группы по интересам - то есть, если он выкачивает, допустим, фэнтези, с каких-то определенных узлов, значит, пусть создаст группу по интересам и эти узлы при поиске будут тогда задействованы первыми. В автоматическом режиме можно создавать группы по количеству закачек с разных узлов. Это также позволит пользователю быстрее находить нужные ему файлы... Тут есть о чем подумать, но это уже к архитектуре сети прямого отношения не имеет. Такое разделение на группы можно в большинство сетей вписать.
Отв: Предварительные размышления
Да, это он. В данный момент такой схемой пользуются торренты и ed2k. DHT позволяет легко получить IP по указанному ID (хешу) узла. Посредников нет, качаем напрямую. Всё быстро (хорошо) и открыто (не очень).
В предварительных проработках варианта F2F такое предусматривалось. Единственное — сервер не выдаёт информацию кому попало, у него есть ещё база кто кому друг.
В проработках варианта F2F кое-что похожее есть. Но там сервер для поиска не используется. Поисковый запрос расходится по группам, анализируется внутри каждой группы, после чего ответ возвращается по той же цепочке. Спрашивающий получает от каждой группы список ID тех, у кого есть запрошенный файл.
Ну, скорее, на сервере не будет полной копии файла, а не реальной информации. И то не факт, что при закачке популярных книг там не наберётся полный файл. К тому же, появляется возможность сказать: «а я скачал всего Лукьяненко с (подставить IP сервера), закройте этот пиратский сайт!».
Кроме того, при передаче файлов через сервер всплывает проблема трафика. Допустим, десять тысяч пользователей запрашивают двухмегабайтный файл. В этом случае сервер должен получить десять гиг и десять же отдать. И всё это в разумное время. :-(
Можно предусмотреть комбинированную схему, но это уже не будет настоящим F2F.
Да. Желательно ещё продумать, как сделать рейтингование работающим независимо от центрального сервера. С сервером-то оно всяко работать будет, а вот без оного...
Аналогично. :-)
Если до чего-то договоримся, то бум иметь в виду.
Отв: Предварительные размышления
В том, варианте, который я предложил - никто никому не друг. Сеть заранее в каждом подозревает врага)) IP есть только у сервера, и все общение происходит через него, если, конечно пользователь не выбрал вариант передачи файлов напрямую.
Ну, тут я вижу как плюсы, так и минусы. Плюс в том, что сервер не нагружается. Минус в том, что при таком подходе находятся не все файлы в сети, а только в отдельной ее части.
Ну, часть зашифрованного архива трудно назвать реальной информацией. А если разделять архив на части не с постоянным размером а со случайным, то вероятность того, что на сервере окажется полный файл ничтожно мала. Вот по поводу "закройте этот пиратский сайт" - такой вариант исключать действительно нельзя. Хотя, по большому счету, на данный момент это можно обойти. Например, эквадорский домен и хостинг наподобие либрусековского. А "пиратского" в этом сервере будет намного меньше. Ведь информацию-то он не хранит. Фактически, это всего лишь система безопасной передачи данных по сети. "Пиратским" можно назвать только возможность поиска, разве что.
Можно сделать, кроме наличия сервера, и систему наподобие f2f. То есть, пытаться скачать сразу и с группы друзей и через сервер. По возможности, вообще сделать так, чтобы один и тот же файл можно было выкачивать одновременно. Кто хочет полной безопасности - тот ждет, кто согласен на создание группы друзей - ждет меньше.
На мой взгляд, она пока и выглядит наиболее приемлемой. Причем так, чтобы и при отсутствии сервера сеть работала, разбитой на группы. И при отсутствии группы друзей у пользователя он имел доступ к сети. Ну или и то и другое вместе.
Вот тут не знаю(( Есть идея переложить рейтингование на пользователей. Типа как оценки. Только не текста, а файла. И/или на клиент. Но как защититься от накручивания рейтинга в таком случае - без понятия.
Отв: Предварительные размышления
Почему только в отдельной её части? Группы связаны друг с другом. Просто вместо того, чтобы отправлять поисковый запрос всем узлам сети, мы отправляем его одному узлу в каждой группе. Он ретранслирует запрос внутри группы, накапливает информацию и возвращает нам ответный пакет.
Хм. Над этим стоит подумать. Меня посетила идея насчёт комбинированной схемы. Приду завтра на работу, подискутирую с товарищами...
Отв: Предварительные размышления
Собственно, как я уже написал выше:
Отв: Предварительные размышления
Короче, ты предлагаешь еще один Tor.
Ребята, давайте не будем лезть в навороты. Вы все-таки обсуждаете сеть для обмена обычными художественными книгами, а не VPN для координации операций Аль-Каеды.
Отв: Предварительные размышления
Есть ненулевая вероятность того, что через некоторое время обмен обычными художественными книгами будет юридически приравниваться к операциям Аль-Каеды. Ergo, потребуется соответствующий VPN.
Это не совсем шутка. Если я правильно понял комменты к одной недавней публикации на хабре, то по существующим законам Украины установка нелицензионного ПО является особо тяжким преступлением, как и убийство. И наказывается соответственно.
Отв: Предварительные размышления
по существующим законам Украины установка нелицензионного ПО является особо тяжким преступлением, как и убийство
--------
Звучит как бред сумасшедшего.
Им так придётся всю страну посадить.
Спрошу у знакомого в Хозляндии.
Отв: Предварительные размышления
Если интересуют подробности, то вот ссылка:
Вопрос лицензионности ПО на предприятии
Там также приводятся цитаты из статьи 176 УК Украины.
Отв: Предварительные размышления
Ладно шутки шутками, но ничего более сложного чем torrent tracker по моему не нужно, единственное что он должен уметь работать с книгами (ну типа поиск там по авторам, названиям, ISBN и пр) ну и протокол оптимизирован под мелкие файлы.
Отв: Предварительные размышления
Тогда уж ed2k. Для торрента нужен торрент-файл, а плодить лишние сущности нежелательно.
Поиск по ISBN. Часто ли им пользуются?
Отв: Предварительные размышления
В российском сегменте сети почти нет, из за бардака созданного FB2 который с одной стороны для текстов а с другой стороны вроде как для книг и не там и не там не хорошо. А вот "на западе" вовсю.
Отв: Предварительные размышления
Ошибаетесь, Роман. Забыли PirateBay? Торренты - не решение, им нужен сервер, который на практике очень легко достать. Излагаю свои любительские соображения.
У бессерверных, децентрализованных моделей (либо с сервером только для регистрации, в дальнейшем обмене не участвующем) действительно, скорее всего, будет такой недостаток, как низкая скорость поиска. Однако, этот недостаток не так уж серьезен. Использование id кажется мне хорошей идеей. Лучше всего бы найти способ скрыть ip пользователей, дабы обезопасить их... Ну или как можно меньше светить его. Поэтому напрямую информацию передавать не стоит - нужны прокси (только как бы он не загнулся при больших нагрузках)... Ну или пусть эту функцию несет комп того, кто выдал инвайт - в соответствующей модели.
Запрос информации в децентрализованной сети организовать по принципу "эха". Также необходимо контролировать контент, т.е. необходимы модераторы, которые должны проверять выкладываемые файлы на предмет соответствия, а также разбираться с версиями файлов. Для облегчения этого процесса действительно лучше всего использовать рейтинги.
Отв: Предварительные размышления
В какой то мере буду сам себе противоречить но книги все же не торренты. То есть сервер нужен именно для поиска, то что творится в ослике все же не вариант. А сидеть там могут хоть магнет-линки (собственно те же хэши). Просто надо место где книги и авторы индексировались и "находить" их (точнее их хэши) можно было однозначно.
Такой сервер закрыть будет намного сложнее, примерно как гугля.
"Идея" в том чтоб не была еще одна файлопомойка как в осле, а в остальном да и на ослика с ослолинковскими сайтами похоже.
К тому же у Кадемилы и подобных протоколов есть огромный недостаток - возникает сегментация "сети" это раз, а во вторых искать не по именам файлов а по какой то метадате у клиентов - это серьёзно нагружать сеть лишними поисками, да и клиентские компютеры запросами то же. С таким лучше справился бы "сервер" , "трэкер" или как хотите назовите но кто то централизующий.
Отв: Предварительные размышления
По поводу поиска не соглашусь: сервер, где будут храниться названия книг и тп - в теории могут прикрыть. Так что, хоть это и быстрее - не факт, что лучше.
Из всего этого в любом случае сильно торчат уши "осла". До чего бы мы тут ни договорились. Главное, найти правильный баланс между сложностью, защищенностью и удобством.
Отв: Предварительные размышления
Отв: Предварительные размышления - реплики по ходу
Под эту сеть уже всё практически готово - есть прога RetroShare - бессерверный аналог DC++, с подключением по инвайтам.
Нужен первоначальный узел 24/7, который бы раздавал инвайты всем-всем-всем, а потом подсоединившиеся будут соединяться между собою, обмениваясь инвайтами, создавая перекрёстные связи.
Только не знаю, как она работает с большой номенклатурой файлов. А так - уже можно запускать хоть сейчас.
Эта сеть более уязвима, хотя и более притягательна. Есть одна прога - Perfect Dark, в которой уязвимости вроде бы преодолены при сохранении положительных сторон. Вот подробное описание и мануал по установке. Исходников нет, но устойчивость бешеная - в Японии с ней ничего сделать не могут.
Но и здесь основная проблема будет в том, как она справится с сотней тысяч книг.
...Попытка сделать библиотеку в еМуле предпринималась пять лет тому назад - сервер, поднятый на поддомене у Мошкова, падал при попытке принять клиентский список уже в 10 тысяч книгофайлов.
Отв: Предварительные размышления - реплики по ходу
Скачал, посмотрю что это такое.
Хм. Если я правильно понимаю, это улучшенный аналог FreeNet. Штука, конечно, интересная, но требования меня смущают. Лично я пока не готов выделить на машине 40 Гб непонятно под что. Будем думать.
Печально... Однако, я так понимаю, там софт не был оптимизирован именно под кучу мелких файлов?
Отв: Предварительные размышления - реплики по ходу
Назвать можно по разному, но сервер так сервером и останется.
Ну, довольно много программ можно уже запускать. Но под книги вроде ни одна не заточена. Они обычно заточены под файлы, поиск по метаинформации невозможен. А так, грубо говоря - можно папку с книгами расшарить для eMule - вот и готово, контент в сети.
Аналогично, да и места требует немеряно...
Ну, им не повезло. Может, не так настроили ПО, сетевое оборудование не подходило, сервер работал медленно, памяти не хватало, ну или какие другие мистические проблемы... Нормальный сервер падать не должен. Хотя, задуматься может. Или просто список не принять. Теоретически, это должно быть программой предусмотрено. Чтобы, например, такие списки по частям отправлялись. Я в осла обычно добавляю папку с 12000 мп3, и серверы, вроде, нормально кушают.
Отв: Предварительные размышления
К идее программы: есть вариант вообще отказаться от поиска по сети. Вместо этого каждому пользователю хранить локальную базу файлов. В том числе, для каждого файла должно присутствовать в ней id нескольких клиентов, с которых можно будет файл этот скачать. Правда, размер ее будет нехилый. если есть 100 000 файлов и к каждому информация хотя бы по 1Кб занимает - уже 100 Мб. Потому надо предусмотреть возможность скачивания базы по частям. Например, по жанрам, по авторам, еще по каким-то критериям. Тут надо правильно БД спроектировать.
База обновляется не автоматически, а по желанию пользователя. Либо, при добавлении книги, всем, кто есть в сети, расходится сообщение о добавление некоего файла и он добавляется автоматически. База скачивается не с сервера, а с одного из клиентов, у кого она самая новая. Либо сделать "клиентов-библиотекарей", которые будут ловить все обновления и иметь "эталонную" базу. В случае сети без сервера - с того из "друзей" (но не дальше) у которого она самая новая. Соответственно, гибридный вариант опять имеет преимущество - через сервер проще найти эталонную/самую новую базу.
Идея рейтингования - рейтинг хранится с инфой о файле, в зашифрованном виде. Добавление "оценки" осуществляется следующим образом: файл отправляется на сервер или случайному другу с просьбой добавить оценку. И только чужая машина оценку добавляет и посылает обратно.
(Посмотрел на все мной написанное и ужаснулся. Это ж кодить несколько лет...)
Отв: Предварительные размышления
Ну, в общих чертах я уже заканчиваю продумывать схему. Получается довольно интересная гибридная сема, которую со следующего года уже можно начинать реализовывать. Если, конечно, найдём энтузиастов, окромя себя. :-)
Кстати, самиздатовский e-mail ещё жив? Дабы не засорять эту тему ненужными техническими подробностями, пошлю-ка я многоуважаемому товарищу Marked письмецо...
Отв: Предварительные размышления
Угу. В смысле - скорее всего, найдете ;)
Отв: Предварительные размышления
Вот сюда загляните - http://vitus-wagner.livejournal.com/416683.html - в середине треда, начиная с "файловая система fuse для архива книг" обдумывается что-то аналогичное. И энтузиастов, соответственно, можно поискать.
Отв: Предварительные размышления
Ага, посмотрел. Думаю. Они там, конечно, каталогизацию обсуждают, но идея интересная. Правда под Windows нету FUSE. Есть Dokan, но я его ещё не смотрел.
Отв: Предварительные размышления
http://fuse4win.4host.ru/ - порт fuse под windows
Отв: Предварительные размышления
И кое-что умею. На сейчас есть
-универсальная база данных - есть структура и наполнение, сейчас около 240 тыс книг (либрусека там нету, все ждал что коллекцию до ума доведут, не дождался). Универсальная база в том смысле, в нее можно запихнуть любую другую. Платформа - мускул.
-средства конвертации данных между базами различной структуры в виде простенького языка, на котором описывается соответствие структур и генератора SQL скриптов на основе этого описания и csv файлов из исходной базы. Результат - скрипты по обработке данных в базе другой структуры. Есть две проги - интерпретатор на Паскале и транслятор на Питоне
-есть несколько поделок по работе с той универсальной базой. Типа, парсинга фб2 для заполнение базы и т.п.
-есть прога-сравнивалка метаинформации из базы с последующие обработкий результатов, типа слияния/разделения разных объектов и т.п.
-продумывал механизм синхронизации содержимого нескольких локальных баз между собой на основе хэширования метаинформации. К сожалению, пока не реализовано.
Думаю, для здешнего проекта это будет полезно хотя бы со стороны того, чего ожидать при работе с различными типами баз данных и какой объем они занимают - не умозрительно, а на реальном примере. Например, у меня база сейчас около гига.
Отв: Предварительные размышления
Цель - написать программу, защищенную от копирастов, защищенную от хакеров, позволяющую удобно обмениваться книгами. Форматы fb2 (основной), и, видимо, pdf и djvu... С БД возиться юзерам не нужно, за них это должна делать программа.
Под "удобным обменом" я лично подразумеваю возможность найти книгу не по названию файла, а по метаинформации, и скачать ее в течение короткого времени (максимум 30 мин, на мой взгляд). При этом с минимумом телодвижений.
Под защитой подразумевается невозможность законно запретить действие этой программы. Естественно также защитить/скрыть данные, передаваемые по сети, максимально скрыть личные данные пользователей (ip-адрес в основном имеется виду). В предлагаемом мной варианте вся ответственность перед копирастами возлагается на пользователей, т.к. вся информация хранится у них. Адреса скрываются от других сервером, либо видны только "друзьям". Но все это не окончательный вариант пока что.
Лично мне бы еще хотелось, кроме всего прочего, иметь возможность оценивать, комментировать и обсуждать книги. С метаинформацией получать также и аннотацию книги. Чтение книги без сохранения на диск - тоже может быть полезно. Часть из этого вполне можно реализовать.
По БД: моя идея в том, чтобы у каждого пользователя была собственная база (не файлов, а список файлов и метаинформация), но "согласованная" со всеми остальными. По реализации: вместе с программой-клиентом, на машину устанавливается БД. Без информации, но с уже созданной структурой. Далее пользователю предлагается обновить БД. Но не только полностью, тот же гиг качать, особенно через сервер - это весьма долго. Например, есть кнопка "фэнтези". Соответственно, посылается запрос к клиенту на другой машине (неважно, через сервер или напрямую), сформировать и выслать только "часть" базы, со списком книг в жанре фэнтези. Ну, и она в ответ посылается. И заносится в базу в том же виде, что и было. То есть, структура везде одинакова, и в идеале на каждой машине должны быть абсолютно одинаковые БД,
Плюсы подхода - поиск файлов осуществляется в локальной базе, быстро, и можно искать по любым тегам, которые предусмотрены программой. Сеть не нагружается постоянными поисковыми запросами. Можно искать не 1 файл, а большие группы файлов. В случае поиска по сети, например, по тегу "фэнтези", все время передавалась бы сводная таблица. А так, скачивать придется гораздо меньше. И не со всех узлов по таблице, а 1 таблица с нескольких, либо через сервер.
Минусы - размер базы, и сложность ее проектирования/взаимодействия с ней.
Собственно, можно поиграться с "переливанием" контента из одной локальной базы в другую. По разным "тегам", от наименований жанров до выборки по авторам и сериям, найти наиболее удобную и быструю структуру базы для такого рода операций.
Мне представлялось взять хэш файла и сделать его основным критерием сравнения. Хотя, метаинформацию тоже ведь надо защитить от изменения, т.к. она в данном случае отдельно от файла существует... Синхронизация мне представляется в виде скачивания текущей базы/ее части по желанию пользователя. Далее, идет сравнение по названию файлов, затем хэшей файлов; и новые добавляются. Автоматически, разве что, прием обновлений в виде сообщений от других клиентов о добавлении новых файлов/удалении старых. Пока пользователь онлайн, такой вариант вполне возможен.
~ по 4 Кб метаинформации на файл? Это вся инфа о книге из fb2 вытаскивается, или только часть ее?
Собственно, раз у Вас есть немалые наработки по БД, и Вы готовы участвовать, то, наверное, нам есть смысл задуматься об описанном мной варианте.
Эта моя фраза
относилась к написанию всего механизма с нуля. За такое я бы сейчас не взялся)))
Отв: Предварительные размышления
-"обмен=поиск+скачать за 30 минут" позволяет реализовать только веб-сервер+броузер. Ну дык все это уже есть:)
-насчет защиты - тоже непонятно, потому как Либрусек, например, никто законно и не запрещает:)
ну и т.д.
Вывод - все это вместе и есть веб. Придумывать еще один вариант, чтоб позволял то же что и он и был лишен его недостатков, ИМХО, нереально. Посему предлагаю урезать требования.
-юзеры все разные, например, те, которые собираются только скачивать книги(таких 90%) - у них такая же база как у тех, кто собирается заливать книги?
-основная проблема - синхронизация баз. Как это планируется.
p.s.Если хочешь, сбрось мыло в личку, отправлю доки что есть, могу дамп базы сбросить.
Страницы