?

Log in

No account? Create an account
 
 
15 December 2009 @ 10:59 am
Распределённый поисковик, IM и социальная сеть в одном флаконе  
Подумалось мне, что было бы очень полезно создать распределённый поисковик или распределённую же социальную сеть как альтернативу Google.

Для начала - что именно хотелось бы сделать? Я вижу такие цели:

  • поисковая система (много направлений - поиск файлов, поиск по иерархиям, по релевантности);
  • среда общения: IM (включая аудио и видео), социальная сеть; в том числе - общение людей за nat/proxy; проблема спама;
  • группы по интересам (по аналогии с форумами, коммьюнити или ньюсгруппами);
  • блоги, хостинг, wiki;
  • безопасность, аутентификация, криптование;
  • веб-интерфейс, нет необходимости ставить специализированный софт у пользователя.

Есть несколько вариантов распределённых систем.

  • как STP или механизм DR/BDR в OSPF. Фактически централизация с автоматически выбираемым центром.
  • как usenet или bgp. Каждый держит собственную копию, которые в нормальной ситуации должны совпадать, быть синхронизироваными.
  • как DNS. Иерархия, на вершине находится несколько фиксированных серверов, но далеко не все запросы проходят через вершину.
  • как jabber или email. Пользователь привязан к конкретному серверу, который указывается в адресе пользователя.
  • как фидо. В адресе указывается роутинг до определённой детализации (сети), а подробнее - решается на месте.
Мне кажется, что было бы хорошо исключить, во-первых, централизацию и иерархичность (потому что это сильно снижает масштабируемость, при увеличении числа узлов в 100 раз нагрузка на центральный узел тоже возрастает как минимум в 100 раз), кроме того, это делает систему более уязвимой. Во-вторых, построение связей должно быть автоматическим - компьютеры с подобными задачами справляются лучше, чем люди (хотя тут возможны варианты). В-третьих, пользователь не должен быть привязан к одному-единственному серверу. Сеть должна быть link-based, как usenet или bgp, а не как jabber или email. Линки нужны для поиска и построения ассоциативных связей, после нахождения нужного пользователя или запрошенной информации узлы, к которым подключены пользователи, передают информацию напрямую, независимо от того, построен ли между ними линк для взаимодействия по протоколу межузлового обмена.

В таких условиях сразу возникают вопросы:
1. Как обеспечить связность системы? То есть, что делать, если линки между двумя частями системы оборвались, и эти части перестали быть связаны между собой? Думаю, что в этом случае части должны быть вполне жизнеспособны и без целого, но должны "слиться" при возможности. Думаю, что тут разумно будет использование anycast, а также построение "дальних" линков, т.е. линков к наиболее удалённым узлам графа (удалённым не географически, а топологически), т.е. граф должен быть уравновешен, не плоский.
2. Как защититься от компрометации информации, т.е. когда кто-то создаёт миллион виртуальных серверов, выдающих нужный ему рейтинг?

С одной стороны, имя пользователя должно быть уникальным, с другой - имена вроде Serg78243 выглядят криво, лучше уж просто цифровые логины, как в ICQ. Доменная иерархия (как в email) привязывает к серверам и фактически себя не оправдывает - всё равно получается одна плоская зона .com, ну или несколько плоских, всё равно проблема уникальности имён не решается. Ничего удобнее, чем ICQ, мне в голову не приходит: не уникальный ник плюс автовыдаваемый уникальный цифровой uin. Только цифровой uin должен быть достаточно большим и случайным, чтобы исключить коллизии - мы ведь хотим, чтобы две части такой сети могли существовать отдельно друг от друга, а потом слиться вместе.
Где и как хранится информация о пользователе (его пароль, список контактов, ластриды, блог и прочее)? Очевидно, на нескольких узлах, а что это за узлы, должно определяться при логине пользователя - либо по его uin (какой-нибудь hash), либо по кукам. То есть, если в куках этой информации нет (например, пользователь зашёл из нового места), по crc16(uin) определям группу узлов, которые знают информацию про всех пользователей с таким hash, в смысле, знают, какие узлы за каких пользователей отвечают. Каждый узел может присоединиться к той или иной группе, и все узлы знают этот верхний уровень иерархии (65536 групп) и получают апдейты про изменения на этом уровне. Разумеется, число 65536 взято с потолка, количество уровней иерархии и степень разветвлённости может меняться и должно это делать автоматически, исходя из общего количества узлов в сети, требуемых ресурсов и надёжности. Пользователь не знает, на каких узлах хранится информация о нём, она кочует между узлами и находится абстрактно "в сети". При отправке сообщения пользователю, который offline, оно ждёт на узле отправителя. Таким образом, пользователь знает, что, пока его любимый сервер работает хорошо, никакие его сообщения молча не потеряются.

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

Спам. Тут, как мне кажется, всё просто. Я хочу получать сообщения от тех, кто как-то со мной связан, как-то на меня вышел, как-то меня нашёл. Либо через общих знакомых, либо по общности интересов, либо ещё через какие-то связи. Тогда это не спам. Если же тот, кто мне отправил сообщение, никак со мной не связан - это спам. Разумеется, спам - не бинарное понятие, сообщение может быть спамом в большей или меньшей степени. Чем больше интересов у человека, нем меньше его заинтересованность в каждом из них. Чем длиннее цепочка знакомых, тем меньше доверия к сообщению. А ещё лучше при отправке первого сообщения (или запроса на построение связи) явно указывать путь нахождения. Например, если я написал утилиту и даю свой uin для связи по вопросам этой утилиты, я регистрирую сообщество (интерес) по этой утилите, соответственно, человек для связи со мной должен для начала указать свой интерес к этой утилите, а потом связаться со мной, указав этот наш общий интерес, тогда будет понятно, что это не спам, и откуда человек получил мой контакт. При этом информация о том, какие интересы у человека, не должна быть публично доступна. Что значит "хранится в открытой распределённой системе и не быть публично доступной" - очень просто, она должна быть зашифрована пользовательским паролем и раскрываться только после его предъявления.

Как бороться со злоумышленниками, т.е. с узлами, которые встраиваются в сеть и работают по несколько другому алгоритму, фальсифицируя результаты поиска (накручивая рейтинг), используя в своих целях конфиденциальную информацию о пользователях (в т.ч. их пароли)? При условии случайного распределения пользователей между узлами злоумышленник не может заранее знать, каких пользователей он будет обслуживать. Запросит слишком много, не сможет всех вовремя обслужить - его будут меньше запрашивать из-за перегруженности. Если он будет давать не ту информацию, что дают параллельные узлы (специализирующиеся на тех же пользователях и тех же темах) - доверие к нему упадёт. А использовать пароли случайных пользователей вряд ли интересно. К тому же, если не замыкаться на http, можно использовать dsa-авторизацию (или иную keypair), так что, даже авторизуя пользователя, можно не иметь возможности получить его пароль и что-либо сделать от его имени. В общем, если оценивать репутацию серверов, получится, что "накрутить" рейтинг, не потеряв репутацию, будет не проще, чем создать в том же livejournal волну постингов от псевдоюзеров, раскручивающих или дискредитирующих определённые сайты или фирмы. (Я не говорю, что это невозможно).

Разумеется, клиентский интерфейс может быть разный на разных узлах. Где-то web, с ajax или без него, где-то свой плагин, где-то совсем свой клиент... Пользователь может выбирать то, что ему больше нравится, из соображений удобства и надёжности. Отсюда здоровая конкуренция.

Какие есть мысли по этому поводу? У меня явно недостаточно знаний о теории нейросетей. Буду благодарен за замечания и советы.
 
 
 
bormalbormal on December 15th, 2009 09:24 am (UTC)
Если эту идею хорошо разработать, можно ее неплохо продать Гуглю :)
Pavel Gulchouck: gulgul_kiev on December 15th, 2009 09:38 am (UTC)
:-)))
Зайнудда-апаl2tp on December 15th, 2009 09:36 am (UTC)
С одной стороны, имя пользователя должно быть уникальным, с другой - имена вроде Serg78243 выглядят криво, лучше уж просто цифровые логины, как в ICQ. Доменная иерархия (как в email) привязывает к серверам и фактически себя не оправдывает - всё равно получается одна плоская зона .com, ну или несколько плоских, всё равно проблема уникальности имён не решается. Ничего удобнее, чем ICQ, мне в голову не приходит: не уникальный ник плюс автовыдаваемый уникальный цифровой uin. Только цифровой uin должен быть достаточно большим и случайным, чтобы исключить коллизии - мы ведь хотим, чтобы две части такой сети могли существовать отдельно друг от друга, а потом слиться вместе.


Мне кажется неудобным использование именно UIN в качестве идентификатора пользователя. Тогда мы вынуждены или использовать централизованный сервис, который будет следить за использованием ресурса, чтобы избежать коллизий (как тот же RIPE следит за выдачей диапазонов IP или AOL-овский сервер - за выдачей ICQ UIN), или разрешить каждому узлу неограниченную выдачу идентификаторов внутри своей зоны, причем зона является частью идентификатора (e-mail, jabber). Второе, как я понимаю, Вам не нравится.

Pavel Gulchouck: gulgul_kiev on December 15th, 2009 09:48 am (UTC)
Поэтому я и говорю о том, что UIN должны быть достаточно большими и случайными, не менее, чем 64-битными (а лучше ещё больше), чтобы выдавать UIN можно было на месте, и при этом сделать вероятность коллизий пренебрежимо малой.
Большие числа - нестрашно, человек будет их видеть и набирать крайне редко, в нормальной ситуации контакты ищутся ассоциативно, через общий интерес или общего знакомого, по нику. Ник не уникален в масштабах всей сети, но обычно достаточно уникален для того, чтобы опознать человека в выбранном сообществе. UINы не нужно запоминать. Разве что, собственный, да и то - если ник уникален в пределах любимого узла, можно и логиниться по нику.
Зайнудда-апаl2tp on December 15th, 2009 09:51 am (UTC)
UIN будет генерироваться при регистрации или выбираться пользователем?
Pavel Gulchouck: gulgul_kiev on December 15th, 2009 09:55 am (UTC)
Ник - выбирается пользователем, уникальность не обязательна;
UIN - цифровой, генерируется при регистрации.
Зайнудда-апаl2tp on December 15th, 2009 10:03 am (UTC)
А как мы решим вопрос с поиском "по интересам", если список интересов хранится в криптованном виде?

Т.е. модель "Я тебя сделаю другом, потому что мы оба состоим в сообществе X и мне нравятся твои идеи там" я понимаю и принимаю (ко мне почему-то новые френды чаще всего приходят после очередного выступления или в ru_root или еще где в тематических местах).

А вот если я решила сделать поиск по интересам "+bgp +cisco" к примеру? В ЖЖ, скажем, реализован вариант поиска хотя бы по одному интересу, указанному в профайле.
Pavel Gulchouck: gulgul_kiev on December 15th, 2009 10:18 am (UTC)
Я это вижу примерно так: если я выступил в каком-то сообществе, меня там заметили - могут построить связи и начать общение уже лично. А посмотреть список всех людей, состоящих в выбранном сообществе - зачем? Писать им лично? Можно ведь написать в сообщество.

Впрочем, возможно, посмотреть список интересов человека иногда было бы полезно, и для спамеров это не такое уж большое препятствие, ведь если спамер узнал UIN, он его узнал каким-то путём (например, из сообщения в какое-то сообщество), и может этот путь запомнить вместе с UIN-ом. Так что, может, и не нужно держать в тайне интересы человека или список членов сообщества (всё равно это удержать в тайне трудно). Или пусть пользователь решает, делать эту информацию публичной или нет.
Зайнудда-апаl2tp on December 15th, 2009 11:19 am (UTC)
Я бы сделала в первую очередь непубличными именно личные данные - реальные имя-фамилию, контактные телефоны-адреса, место жительства-работы, если таковые были заполнены в профайле.

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

И еще один момент. Разрешение коллизий, если таковые возникнут. Хоть это и маловероятное событие при длине цифрового поля байт в 12-16, но все же возможное.
Pavel Gulchouck: gulgul_kiev on December 15th, 2009 12:20 pm (UTC)
> Я бы сделала в первую очередь непубличными именно личные данные - реальные имя-фамилию, контактные телефоны-адреса, место жительства-работы, если таковые были заполнены в профайле.

Почему?
То есть, я не считаю, что их обязательно нужно делать публичными, но этот вопрос для меня неочевиден, открыт. У анонимизации (или виртуализации) есть как положительные, так и отрицательные следствия, я не знаю, какие перевешивают. Другое дело, что требовать realname (развиртуализации) глупо, но надо ли целенаправленно скрывать контактные данные пользователя, если он их указал реальными?
Конечно, делать возможными запросы типа "дайте список адресов людей, проживающих в Москве, получающих более млн $ в год, планирующих следующую неделю быть за городом и использующих охранную систему такой-то фирмы" нельзя. :) С другой стороны, найти Васю Иванова, проживающего в Питере, отдыхавшего в 1998-м году в Сочи и играющего в преферанс - почему нет? Тут тоже нужно ещё подумать, какие критерии можно делать открытыми для поиска, а какие лучше закрыть.

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

Тут, пожалуй, не соглашусь. Бывают взаимные отношения, бывают однонаправленные. Есть популярные личности, которых знают миллионы, для которых уже трудно отличить отношение к человеку или интерес как к явлению. Есть промежуточные варианты - профессора знают и уважают все студенты, а профессор всех помнить не может.
Вопрос в том, что следует из однонаправленной связи. То, что сообщение от человека, односторонне включившего меня в свой круг, не является спамом - разумеется, не следует. То, что он может отслеживать сообщения в моём блоге - почему бы нет? То есть, отношения ЖЖ мне кажутся вполне удачными, если только не называть их "дружба" и делать отдельные списки "кого хочу читать" и "кому показывать мои подзамочные посты".

> И еще один момент. Разрешение коллизий, если таковые возникнут. Хоть это и маловероятное событие при длине цифрового поля байт в 12-16, но все же возможное.

Да, я немного думал над этим. В принципе, тут ничего сложного нет (не сложнее, чем паспортному столу разобраться с полными тёзками). Можно предложить им обоим изменить uin-ы, можно различать по никам, можно по другим данным - по идее ведь, их будут обслуживать одни и те же узлы, поэтому как-то различить, видимо, смогут. На что тут нужно будет обратить особое внимание - на целенаправленные атаки, когда какой-то узел начинает генерировать одинаковых агентов Смитов в больших количествах.
Зайнудда-апаl2tp on December 15th, 2009 12:37 pm (UTC)
Как насчет выборочной развиртуализации? По желанию пользователя? Кто-то пожелает, чтобы любой желающий мог сразу увидеть имя-фамилию и прочее, кто-то откроет только избранным. С разбивкой по группам данных: всем покажу имя-фамилию, а вот личный телефон - только избранным.
Pavel Gulchouck: gulgul_kiev on December 15th, 2009 12:59 pm (UTC)
Да, наверное, это разумно.
Единственный недостаток, который я тут вижу - пользователь должен понимать, что и почему лучше скрывать или показывать, чтобы эти его действия были осознанными. Если он будет кликать от фонаря, лучше уж за него решить.
Но это, наверное, лишь вопрос продуманных умолчаний, не более того.
Зайнудда-апаl2tp on December 15th, 2009 01:31 pm (UTC)
...пользователь должен понимать, что и почему лучше скрывать или показывать...


А вот с этого места мы выходим на скользкую дорожку общей культуры пользователя. Мне вон в комментариях уже доказывал один товарищ много интересного на тему приватности и скрытия личных данных. А общая культура пользователя у нас неуклонно падает с ростом доступности интернета конечному пользователю. Увы.
Pavel Gulchouck: gulgul_kiev on December 15th, 2009 10:50 am (UTC)
Я торможу - конечно, список участников сообщества нужно видеть, чтобы можно было найти нужного человека.
rootikrootik on December 15th, 2009 12:50 pm (UTC)
Мне кажется, вы сейчас IPv6 изобретёте ))
Pavel Gulchouck: gulgul_kiev on December 15th, 2009 01:11 pm (UTC)
Хм...
Я бы понял, если бы Вы говорили про vkontakte, livejournal, jabber или другие сети, из которых взяты некоторые подходы.
Но IPv6? Что с ним общего? "64-битный или более UIN" проассоциировался со 128-битным адресом в IPv6, или есть другие аналогии? Тут ведь совсем разные уровни рассматриваются, IPv6 - это L3, а я говорю про уровни 6-7.
Можно ещё вспомнить про ASN32 - тоже модное слово. :)
Зайнудда-апаl2tp on December 15th, 2009 01:22 pm (UTC)
Кстати, а статистика есть по ASN32 по Украине? И сколько у нас нынче магистральных операторов умеют с ней работать без трансляции в 23456
Pavel Gulchouck: gulgul_kiev on December 15th, 2009 01:45 pm (UTC)
Я не исследовал. Хотя, действительно, было бы интересно.
Когда-то dbg пробовал исследовать, но похоже, что не полностью удачно, хотя его результаты всё равно интересны.
Как будет время и настроение, попробую поковыряться в этом направлении.
rootikrootik on December 15th, 2009 01:42 pm (UTC)
Я образно говорил, на самом деле ))
Pavel Gulchouck: gulgul_kiev on December 15th, 2009 02:03 pm (UTC)
А - в смысле, велосипед?
Ну, может быть. А какие есть похожие проекты? Netsukuku - интересно, но не совсем то.

Кстати, недавно нашёл своё описание распределённой системы интернет-сообщений, замену ICQ, менее функциональное, чем то, что описано тут (там было только IM и ничего более), более детально проработано, не реализовано, но, что интересно, за 2001-й год, когда ещё не было ни скайпа, ни джаббера. И, в отличие от джаббера, без привязки пользователя к серверу, с сохранением за пользователем его адреса при переключении с одного сервера на другой. Прикольно. :)