Распределённый поисковик, IM и социальная сеть в одном флаконе
Подумалось мне, что было бы очень полезно создать распределённый поисковик или распределённую же социальную сеть как альтернативу Google.
Для начала - что именно хотелось бы сделать? Я вижу такие цели:
Есть несколько вариантов распределённых систем.
В таких условиях сразу возникают вопросы:
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 или без него, где-то свой плагин, где-то совсем свой клиент... Пользователь может выбирать то, что ему больше нравится, из соображений удобства и надёжности. Отсюда здоровая конкуренция.
Какие есть мысли по этому поводу? У меня явно недостаточно знаний о теории нейросетей. Буду благодарен за замечания и советы.
Для начала - что именно хотелось бы сделать? Я вижу такие цели:
- поисковая система (много направлений - поиск файлов, поиск по иерархиям, по релевантности);
- среда общения: IM (включая аудио и видео), социальная сеть; в том числе - общение людей за nat/proxy; проблема спама;
- группы по интересам (по аналогии с форумами, коммьюнити или ньюсгруппами);
- блоги, хостинг, wiki;
- безопасность, аутентификация, криптование;
- веб-интерфейс, нет необходимости ставить специализированный софт у пользователя.
Есть несколько вариантов распределённых систем.
- как STP или механизм DR/BDR в OSPF. Фактически централизация с автоматически выбираемым центром.
- как usenet или bgp. Каждый держит собственную копию, которые в нормальной ситуации должны совпадать, быть синхронизироваными.
- как DNS. Иерархия, на вершине находится несколько фиксированных серверов, но далеко не все запросы проходят через вершину.
- как 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 или без него, где-то свой плагин, где-то совсем свой клиент... Пользователь может выбирать то, что ему больше нравится, из соображений удобства и надёжности. Отсюда здоровая конкуренция.
Какие есть мысли по этому поводу? У меня явно недостаточно знаний о теории нейросетей. Буду благодарен за замечания и советы.