[image]

Мысли вслух по поводу распределённой социальной системы

 
1 2 3
+
-
edit
 

Balancer

администратор
★★★★★
Ввиду какого-то непонимания или эпического фэйла старта Диаспоры тыц1 и тыц2 пришла в голову мысль.

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

А вот в пересечении всех этих тенденций появилась идея - а не подумать ли на счёт создания реально распределённой социальной социальной сети?

Формализация мыслей:
- Использование OpenID для авторизации, дабы можно было писать на любом сервере системы без новой регистрации. Также, каждый сервер может быть провайдером OpenID, дабы можно было соединять уже имеющиеся базы пользователей. Скажем, чтобы не нужно было регистрироваться тем же пользователям Авиабазы
- Использование для авторизации XMPP-аккаунтов. Для быстрого начала работы пользователей XMPP.
- На каждом сервере есть возможность создать некую потоковую сущность записей с комментариями - блоги/аспекты/ленты - название можно ещё придумать или выбрать из устоявшихся. Ну, пусть для определённости будет блог.
- Пользователь может писать в блог, если блог ему это позволяет. Пользователь любого сервера системы пишет на любой другой сервер системы. Точнее, он не думает о серверах, он просто пишет в блог.
- Пользователь может подписаться на имеющийся блог или на сообщения другого пользователя. С опциональной фильтрацией по тэгам.
- Пользователь может централизованно, на своём сервере читать все свои подписки.
- Система должна обеспечивать все эти связи. Если пользователь подписывается на блог, на сервере блога остаётся запись об этом. Если подписывается на записи другого пользователя, то подписка остаётся на его (пишущего) сервере. При добавлении записи в блог сервер пользователя-автора рассылает нотификации на сервера подписчиков. Сервер блога делает то же самое с подписчиками блогов.
- Необходима широкая интеграция с уже имеющимися блогами и социальными сетями. Вопрос авторизации через них выше уже озвучивался. Также нужны утягивание записей из других социальных сетей, как через API, так и через простые RSS и опциональный кросспостинг в них.
- Можно в будущем также будет продумать систему нотификации о наличии комментариев в кросспостингах других социальных сетей, как это задумано на Авиабазе в отношении Livejournal.
- Взаимодействие серверов между собой, наверное, нужно делать не на XMPP, как подумалось вначале, а на обычном REST. XMPP же останется просто для удобного взаимодействия пользователя со своим сервером.
   3.6.123.6.12
+
-
edit
 

Balancer

администратор
★★★★★
Первая сложность, пришедшая на ум.

Сегодняшние OpenID дают очень мало реально полезной информации. Даже аватар - и то не всегда.

Понятно, что расширенную информацию можно хранить на сервере пользователя. И вот тут возникает проблема.

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

Значит вижу два варианта:

1. Отказ от OpenID-авторизации на сайтах системы. Вместо этого использовать системную авторизацию (те же user@server).

2. Ведение распределённой базы пользователей, чтобы каждый сервер системы, получив OpenID мог бы найти сервер, которому принадлежит этот пользователь.

Вариант 1 прост в реализации, но неудобен пользователям и не даёт реального ощущения распределённости. Вариант 2 удобен для пользователя, но сильно усложняет систему.

Вот это нужно обдумывать серьёзно...
   3.6.123.6.12
RU Balancer #24.11.2010 15:08  @Balancer#24.11.2010 15:02
+
-
edit
 

Balancer

администратор
★★★★★
Balancer> 2. Ведение распределённой базы пользователей

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

Вот только объём данных о миллионах пользователей (чего уж там мелочиться ;)) будет очень велик для произвольной репликации. И нужно хорошо подумать на счёт секьюрности таких данных. Гипотетически к таким данным сможет получить доступ любой человек.

Проблема...
   3.6.123.6.12

Tico

модератор
★★☆
3. Завести центральную базу специально для OpenID, с которой будут знакомы все сервера системы. Вроде бы удар по распределённости, но это всё же не священная корова.
4. Использовать p2p для передачи и хранения расширенной информации... Но тогда идентификаторы пользователей должны быть уникальными.
   8.08.0
+
-
edit
 

Kuznets

Клерк-старожил
★☆
Balancer>> 2. Ведение распределённой базы пользователей
Balancer> Однако, такой вариант может обеспечить неплохую защищённость системы от падения отдельных узлов. Блоги соответствующего сервера станут недоступны, а вот пользователь сможет работать (читая доступные блоги) с другого, работающего сервера.

читал?


===
Современный интернет похож на пруд. То, что легко увидеть, заглянув в эти камыши, — это гуси (сайты). Они плавают на поверхности, они всем видны. Но есть еще караси (посетители), их несравненно больше, чем гусей, но их не видно — караси под водой. Мы лишь иногда видим круги на воде, и по ним можем догадываться, что караси здесь невидимо ходят.
Ситуация эта не менялась много лет, но браузеры развивались, и теперь браузер пользователя — это некий агрегат, который управляется скриптами, способен сам бегать по разным сайтам, собирая информацию для страницы, и — что особо интересно! — эту информацию хранить. Потому что есть html5, браузерные хранилища, есть кое-где SQLite, есть флэш-хранилища наконец. И все это может хранить информацию чуть ли не до 5 мегабайт и больше. Есть отдельный вопрос, доступна ли эта информация только сайту, который ее туда положил на хранение или можно ее сделать общедоступной. Этим вопросом я пока не интересовался, но и не суть важно. Кроме того, компьютер посетителя — это не терминал, а самостоятельная штука большой вычислительной мощности (иногда — больше, чем сервер).
Теперь смотрим сюда:
.....
Что это было?! Этого всего на моем сайте нет и никогда не было. Я тут ни при чем вообще. Эти блоки сам собрал на вашем экране ваш браузер, пока собирал эту страницу. Он побегал по разным сайтам и собрал. А сайты, между прочим, его отметили как посетителя, записали в статистику, провернули счтчик посещаемости и т.п. Но я и мой сайт тут ни при чем — я только дал вашему браузеру, грубо говоря, что-то вроде такого (владельцы движка поймут):
{_IMBLOAD: Error _}
{_IMBLOAD: Леонид Каганов: 2010/11/13 Биноник: сделали сервер публичного проекта _}
{_IMBLOAD: http://vasya_pupkin.dyndns.org/blog/2010/11/12.html _}
{_IMBLOAD: Ошибка 404: файл не существует _}
Это работает, причем уже полгода как (только обновиться бы, я там подправил чуть :). Работает это, правда, только с сайтами на движке, которые поддерживают мой протокол IMBLOAD. Я пока не интересовался вопросом, может можно какой-то JSON употребить, не изобретая велосипедов. Для чего это нужно? Во-первых, таким способом можно читать, например, френд-ленту. Не на одном сайте, и не специальными клиентами, а вот так вот — браузер сам пробежался, куда надо было, и собрал. Кроме того, необязательно копировать себе понравившийся пост Васи Пупкина — пусть он грузится с родного сайта, вдруг Вася написал дополнение или исправил опечатки?
Следите за мыслью дальше. Обратим внимание, блок номер три от Васи Пупкина — «не загрузился». На самом деле, такого сайта и нет, это я для примера. Почему сайт не отвечает? Да не важно. Быть может, блог Васи Пупкина находится на его домашнем компьютере, и он сейчас выключен, а Вася на неделю уехал в деревню.
И вот дальше начинается самое интересное. Предположим, браузер видит, что сайт недоступен. Нет гуся на пруду, в нашей терминологии. Но есть караси. Которые, быть может, хорошо знают этого гуся, быть может, были у него на сайте совсем недавно и у них в кэше (который, как мы помним, много мегабайт) могла сохраниться его страница. Дело за малым: найти карася, у которого остался кэш. Конечно, браузеры между собой общаться не могут. Но они могут послать сигнал на ближайший сайт системы о том, что такой-то узел не отвечает, нет ли кэша? Кэша, понятное дело, у сайта нет. Но зато он теперь будет спрашивать всех проходящих мимо браузеров, не сохранилось ли у них этого материала. И если сохранилось — то пришлите на сайт, чтобы его снова раздавать.
Мораль: нет ничего невозможного в том, чтобы создать технологию и сеть движков, которая бы стирала разницу между гусями и карасями. В результате мы получаем надежную отказоустойчивую самовосстанавливающуюся систему. И как только я закончу строить на binoniq.net традиционную «гусиную» составляющую (блогохостинг с классическими пользовтаелями), я наверно начну эксперименты по работе с «карасями», потому что я думаю, что за этим будущее. По крайней мере — одна из важных составляющих информационного будущего.
===
   3.6.123.6.12

Balancer

администратор
★★★★★
Tico> 3. Завести центральную базу специально для OpenID, с которой будут знакомы все сервера системы.

Да, я уже склоняюсь к этой мысли. Вопросы безопасности, всё же, не позволят как угодно раскидывать данные пользователей. Так что нужно иметь базу привязок OpenID и серверов пользователей (централизованную или унифицированную - уже другой вопрос). А все данные пользователя хранить уже на его собственном сервере.

Tico> 4. Использовать p2p для передачи и хранения расширенной информации...

Не катит. Это же потребует особых клиентов. У нас же у пользователей простые браузеры. Или XMPP-клиент.
   3.6.123.6.12

Tico

модератор
★★☆
Чтобы стереть разницу окончательно, нужно ввести распределённое хранение данных уже в больших обьёмах на компьютерах у юзеров. Мегабайтами тут не обойдёшься. А секьюрный распределённый storage уже есть - это Freenet.
   8.08.0
+
-
edit
 

Balancer

администратор
★★★★★
Kuznets> читал?

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

Если так важна доступность серверных данных, то проще на серверах дублирование организовать :)

Хотя - да. Мысль о дублировании информации весьма интересна и полезна.
   3.6.123.6.12

Tico

модератор
★★☆
Balancer> Так что нужно иметь базу привязок OpenID и серверов пользователей (централизованную или унифицированную - уже другой вопрос).

Ну да. Собственно примерно как ed2k.

Balancer> Не катит. Это же потребует особых клиентов. У нас же у пользователей простые браузеры. Или XMPP-клиент.

Сегодня нет простых браузеров :) Плагин?
   8.08.0

Balancer

администратор
★★★★★
Tico> Сегодня нет простых браузеров :) Плагин?

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

...

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

Tico

модератор
★★☆
Кстати у того же Freenet есть и болталка и типа форумы и борды.
А собственно чем так хороша идея распределённости социальной сети? Т.е. чего ты пытаешься добиться, малоуязвимости, привата, или перформанса?
   8.08.0

Tico

модератор
★★☆
Balancer> Нет, использование простых браузеров должно быть явно одним из принципов системы.

Ага. Кстати, p2p для обмена данными пользователя можно использовать только между серверами. Клиент передаёт ID на ближайший сервер, тот уже дальше тягает остальную с пиров. Но явный минус такой системы в её тормознутости. Тут идея центральной базы заруливает идею чистого p2p.
   8.08.0

Balancer

администратор
★★★★★
Tico> Кстати у того же Freenet есть и болталка и типа форумы и борды.

Уже года полтора они перманентно мертвы :) Старые варианты оказались сильно уязвимы к спаму и DDoS, новые так и не сделали. В общем, мне так и не удалось в них ни разу пообщаться :)

Tico> А собственно чем так хороша идея распределённости социальной сети?

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

Вот понравился мне чей-то блог на Фейсбуке. Но я не читаю Фейсбук, я хочу читать этот блог в своей ленте на Авиабазе. С имеющимися системами такого не реализовать.

Tico> Т.е. чего ты пытаешься добиться, малоуязвимости, привата, или перформанса?

Удобства и унификации :)

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

Так почему бы не сделать ещё один шаг и, раз уж мы уже работает с внешними ресурсами (те же трансляции и кросспостинги) не сделать такую же распределённую систему? А уж если она ещё и сможет обеспечить резервирование при падении одного из серверов - это вообще будет прекрасно :)
   3.6.123.6.12

Balancer

администратор
★★★★★
Tico> Ага. Кстати, p2p для обмена данными пользователя можно использовать только между серверами.

Это уже s2s называется и используется во многих протоколах, в том же XMPP :)
   3.6.123.6.12

Tico

модератор
★★☆
Balancer> Вот понравился мне чей-то блог на Фейсбуке. Но я не читаю Фейсбук, я хочу читать этот блог в своей ленте на Авиабазе. С имеющимися системами такого не реализовать.

А разве RSS не призван заниматься как раз этим?

Balancer> Так почему бы не сделать ещё один шаг

Т.е. это в общем навороченный кросспостинг на едином протоколе?
   8.08.0

Tico

модератор
★★☆
Balancer> Это уже s2s называется и используется во многих протоколах, в том же XMPP :)

Ну и чудненько - осталось посадить обмен персональными данными на неё. Но всё равно тормозить будет, это неизбежно, увы :(
   8.08.0

Balancer

администратор
★★★★★
Tico> А разве RSS не призван заниматься как раз этим?

RSS тебе не позволит комментировать сообщения в ленте :)

Tico> Т.е. это в общем навороченный кросспостинг на едином протоколе?

По сути, где-то так :)
   3.6.123.6.12

Balancer

администратор
★★★★★
Tico> Ну и чудненько - осталось посадить обмен персональными данными на неё. Но всё равно тормозить будет, это неизбежно, увы :(

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

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

Tico

модератор
★★☆
Balancer> RSS тебе не позволит комментировать сообщения в ленте :)

А и не надо. Его можно использовать только для переотражения ленты на твоём сайте. А отправку сделать как ты уже сказал, отдельным потоком.

Balancer> Тут подразумевается, что вся реальная нагрузка будет идти на сервер пользователя от его пользователей.

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

Balancer

администратор
★★★★★
Tico> Я имел ввиду другой юз кейз - при авторизации пользователя пройдёт время, пока вся персональная информация становится доступной на том сервере через который пользователь зашел.

В современном Интернете - это ничтожно :) Всё за миллисекунды решится.

Tico> Если авторизация может проходить быстро, то подгрузка инфы через p2p может занять время

А там и не нужно много информации. Тем более, что сегодня такая система итак массово иже используется, когда ты на стороннем сайте авторизуешься через facebook или gmail :)
   3.6.123.6.12

Tico

модератор
★★☆
Balancer> Тем более, что сегодня такая система итак массово иже используется, когда ты на стороннем сайте авторизуешься через facebook или gmail :)

Убедил :)

PS: Увы, работать надо :(
   8.08.0

+
+1
-
edit
 

Balancer

администратор
★★★★★
Не прошло и пяти лет. В процессе экспериментов с Авиабаза распределённая пришёл к таким выводам.

1. Принцип хранения данных в конкретном случае не должен влиять на систему в целом. То есть, не важно, хранилище данных локальное на одной машине или распределено по p2p. Важно, что по запросу клиента оно может отдать весь контент или изменения. Пока, для старта, ориентируюсь на взаимодействие по git, в т.ч. буду играть с gittorrent

2. Внутренняя структура данных в конкретном репозитории не несёт глобальной информации. Хранится как удобно. Кому-то разбивать по датам, кому-то — по темам. Вся структурирующая информация хранится внутри документа.

3. Каждый узел сети подписывается на произвольное число других узлов. Каждый проект сам может состоять из нескольких собственных узлов (как Авиабаза состоит из Авиации, Флота, Политики...)

4. В связи с 1 и 2 становится не важно, какая временнАя гранулярность у репозитория. По годам там разбито или по неделям. Раздел Кино на Авиабазе может быть одним за всю историю, а Флот разбиваться по неделям или месяцам.

5. Каждый документ имеет уникальный UUID в рамках всей системы. Вполне возможно, человекочитаемый. Скажем, что-то типа ru.airbase.tanzpol.20150617010500012. Или lor.11683089.

6. Каждый документ имеет одного или несколько авторов, идентифицируемых по e-mail (лучший вариант) или по usergate (хуже, но решается вопрос анонимности. Например,  Meskiukas <30728@airbase.ru>).

7. Есть произвольное число серверов, индивидуально оценивающих качество, репутацию, степень доверия и т.п. других узлов и пользователей. Т.е. Авиабаза выбирает, скажем, собственную систему учёта репутации и пользуется ею для фильтрации материалов. Ну и, конечно, решает, на какие из внешних узлов подписываться. В R/O на всех желающих, с возможность писать в другие узлы — по их желанию. Точнее, это будет зависеть от их собственной подписки на Авиабазу.

По документам. Скорее всего, варианты хранения будут возможны произвольные, но я на старте предпочитаю задействовать Markdown + JSON. Это позволит писать материалы вручную. Или легко анализировать. Каждый документ характеризуется следующими полями (тут надо будет особенно много думать, полагаю, что все, кроме UUID и Type — не обязательные):
  • UUID: Уникальный идентификатор документа. Его должно быть достаточно для поиска документа как в локальном архиве, так и на искомом узле.
  • Node: Идентификатор узла. Важен для фильтрации ненужных узлов при заборе материалов с транзитных узлов и т.п.
  • Title: Заголовок материала
  • Description: Краткое описание/анонс
  • Author: Автор материала в e-mail формате Имя <user@host>
  • Date: Дата в любом однозначно идентифицируемом формате. Лучше зафиксировать, например, YYYY-MM-DD hh:mm:ss +TZ.
  • Type: Типа материала. News|Blog|Article|... — Новости|Блог|Статья и так далее. Типов может быть много, попробую расписать их варианты, как я их вижу, далее в теме.
  • Markup: формат разметки документа. markdown|html|xbb|lcml|...
  • AnswerTo: Если документ является ответом на другой/другие, то тут будут UUID документов, на которые отвечает данный.
  • LinkedTo: UUID'ы связанных материалов
  • License: Копирайт материала. Он может быть не указан и тогда что с материалом делать будет решать конкретный узел. Может быть указано авторство материала с лицензией CC, Public и т.п. Может быть прямо указано, что материал может нарушать чей-то копирайт.
  • Lang: Исходный язык материала. Нужно для автоматического перевода и т.п. Нужно будет подумать, пока неясно, как решать вопрос мультиязычных документов. Когда документ доступен сразу на нескольких языках. Например, можно попробовать вариант на каждом языке хранить отдельным документом и указывать связь таких документов между собой.
  • AuthorGeo: «флажок». Позиция размещения материала или место жительства автора.
  • Category: Классификация материала автором. Возможна иерархия. Возможна множественность категорий. Например, Politics/Ukraine. Или Флот/Авианосцы и Авиация/Авианосцы.
  • Tags: Теги. Тут Всё понятно.
  • Alpha: сортировочное имя. Если материал нужно выводить в алфавитных списках или размещать по алфавиту.
  • Image: логотип. Также возможно размещать логотип автоматически рядом с документом или внутри него в Base64.
  • Auto: true|false — флаг, автоматически созданный материал или нет. Например, кто-то закидывает ссылку в новостной топик форума. Материал классифицируется как новость, но сделано это автоматически. Для учёта приоритета ручной классификации и т.п.
  • Text: Собственно, контент материала. В случае Markdown+JSON — это тело документа.


Далее попробую разобрать типы материалов.
   43.0.2357.12443.0.2357.124
+
-
edit
 

Balancer

администратор
★★★★★
Типы материалов.

Типично форумные:

Topic. Это первое сообщение в топике форума. Несёт также все данные топика.

Comment. Комментарий. Это может быть ответ в топик или на другой комментарий. Может применяться к любым объектам. Наверное, в случае, когда комментарий даётся на другой комментарий, нужно также сохранять UUID исходного документа в вершине цепочки. Для упрощения классификации. Т.е. аналог topic_id

News. Новость. Практически то же самое, что Topic, но содержит новость.

Article. Статья. Развёрнутый материал по какой-то теме.

Blog: Аналогично News или Article, но содержит какую-то частную информацию от автора.

Link: Одиночная ссылка (опционально с описанием).

Quote: Одиночная цитата.

Retweet: Повторное размещение какого-то материала, как внутрисистемного, так и внешнего.

Image: Одиночное изображение

Album: Фотоальбом. Серия изображений.

Object: С названием надо подумать. Карточка какого-то объекта. Например, страница с описанием самолёта или корабля. Может, обозвать как Wiki?

Person: То же самое, что Object, но несёт информацию о конкретном человеке. Хотя, может, не имеет смысл выделять, а просто ввести подтипы для "Object?"
   43.0.2357.12443.0.2357.124
+
-
edit
 

Balancer

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

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

Возможны «R/O-прокси-гейты» на публичные ресурсы, не поддерживающие нашу систему. Читаем внешний сайт, парсим результаты, складываем в отдельный узел.

Система единообразно обрабатывает:
— Форумы
— Блоги
— Wiki
— Персональные сайты
— Сайты-каталоги (типа Авиабазы)
— Новости
— ... да практически что угодно ещё, было бы соглашение на формат
   43.0.2357.12443.0.2357.124
+
-
edit
 

Balancer

администратор
★★★★★
Ознакомился тут с относительно популярными в наше время готовыми решениями. Diaspora, Identica, GNU Social.

Основная проблема, не дающая им (ИМХО) нормально стартовать — отсутствие гейтов к имеющимся данным классических систем что сразу снижает интерес и малая польза от распределённости. Пользователь всё равно остаётся привязан к собственной ноде. Пусть даже в некоторых реализациях и возможен ручной перенос данных на другие ноды. Нет прямого обмена контентом между нодами. Только по подписке пользователей.

Думаю, более востребованная система, в отличие нынешних, должна предоставлять:

— Гейт-доступ к имеющимся материалам классических форумов и блогов. Тут понятно и без комментариев. Есть информация — есть пользователи.

— Автоматический обмен контентом не по подписке пользователя, а в рамках категории. Сейчас пользователь, ищущий что-то интересное, должен предварительно обыскивать остальные ноды сам. И только найдя нужное, может подписаться на потоки. Нужно, чтобы всё актуальное можно было найти на одной текущей ноде.

— Обмен пользовательскими данными. Пользователь должен уметь размножать свой идентификатор на более чем одну ноду. Чтобы при потере одной из нод из сети, он мог продолжить работу через другие ноды не перерегистрируясь и не перенося данные.

...

— Кстати, замечание — основной контент обязан быть публичным. Чтобы гости имели возможность читать статьи и обсуждения без предварительной регистрации.
   43.0.2357.12443.0.2357.124
1 2 3

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru