CC BY
81
УДК 004.72, 004.772
Д.С. Садаков, С.Э. Сараджишвили
рекомендательный протокол децентрализованной файлообменной сети
Человечеству стали доступны ранее немыслимые объёмы цифровой информации. В год создаётся больше одного эксабайта (1018 байт) информации и прослеживается экспоненциальный рост [11]. Справиться с таким информационным взрывом помогают информационно-поисковые системы (ИПС) и рекомендательные системы. Из всей доступной информации они выбирают наиболее релевантную по запросу с ключевыми словами и по заранее известным предпочтениям пользователя. Эти системы предполагают единый пункт со всей информацией о доступных ресурсах, например, в кластерных центрах Google, Yandex, и Amazon. Но на сегодняшний день по количеству передаваемых данных доминируют децентрализованные файлообменные сети, лишённые центрального пункта с информацией о ресурсах сети, и без налаженных поисковых и рекомендательных систем.
Исследования по улучшению качества поиска в децентрализованных сетях остаются достаточно ограниченными по сравнению с аналогичными
трудами для централизованных сетей, но активно продолжаются в работе над пятым поколением Р2Р-сетей.
Компьютерные сети, основанные на равноправии участников (Р2Р - реег4о-реег), стали самым популярным транспортным средством для обмена файлами в сети Интернет [1]. В отличие от неравноправных сетей (например, архитектура клиент-сервер), в децентрализованных сетях каждый узел является как клиентом, так и сервером, что позволяет сохранять работоспособность сети при любом количестве и любом сочетании доступных узлов. Информация передаётся напрямую от узла к узлу, что делает сеть более масштабируемой, устойчивой и эффективной.
Как показали исследования мирового трафика IPOQUE за 2009 г. [2], почти три четверти всей передаваемой информации в мире передаётся по протоколам Р2Р (69 %). Затем следуют веб-протоколы 16 % и потоковые протоколы (7 %). Исследования в области улучшения качества и возможностей Р2Р-сетей, в т. ч. и децентрализо-
Source: CacheLogic (2006)
Рис. 1. Эволюция протоколов по передачи информации в сети Интернет с 1993-го по 2006-й г
ванных рекомендательных протоколов, является актуальной исследовательской задачей.
На рис. 1 виден рост процента трафика P2P-сетей [1].
В данной статье описаны текущие рекомендательные протоколы для децентрализованных сетей (ДС), выявлены требования и предложен улучшенный протокол для создания современной и компетентной децентрализованной рекомендательной системы ДС.
Существующие децентрализованные рекомендательные протоколы. Протокол BitTorrent перевернул область передачи крупных файлов из-за грамотной архитектуры протокола: масштабируемого, эффективного и надёжного протокола P2P [1]. Восемьдесят процентов всего передаваемого Р2Р-трафика протекает по протоколу BitTorrent [2]. В основе протокола лежит взаимовыгодный обмен файлами на принципе эффективности по Парето. Однако протокол не включает в себя механизмы поиска, ранжирования, оценивания или передачу метаданных о файлах.
Без этих компонентов протокол можно использовать только для передачи файлов вслепую, не зная ничего о содержимом. На практике пользователи обходят эту проблему централизованными сайтами раздачи .torrent-файлов, необходимыми для начала передачи файлов, а исследователи активно изучают улучшения к протоколу.
В истории возникновении Р2Р-сетей можно выделить пять их поколений [12], чётко проследить развитие поисковых возможностей и понять, почему рекомендательные протоколы являются наилучшим потенциальным расширением P2P-сетей.
В первом поколении Р2Р-сети имели один централизованный сервер, где хранилась информация об узлах сети и доступных файлах. Примером Р2Р-сети первого поколения является Napster. Несмотря на одноранговость всех пользователей сети, которые занимаются файловым обменом, сеть зависит от одного центрального сервера. В случае остановки центрального сервера становится невозможным поиск файлов внутри сети, она распадается. Так произошло с сетью Napster в 2001 г., когда закрытие центрального сервера привело к разрушению сети из миллионов узлов.
Второе поколение Р2Р-сетей, примером которой служит Gnutella, потомок Napster, является полностью децентрализованным, с принципиальным отсутствием центрального сервера. Ин-
формация об имеющихся в сети файлах хранится распределённо на её узлах, поиск производится по технологии gPulp, где запросы на поиск выполняются по собственной схеме маршрутизации GBFS с ограничением по глубине поиска и количеству возвращаемых результатов. Но сеть плохо защищена от поддельных узлов и файлов, что привело в конечном итоге к сомнительной приемлемости результатов поиска.
Третье поколение P2P - это компромисс между централизованными и децентрализованными подходами, примером является eDonkey2000. Вместо централизованных серверов используются узлы самой сети, т. н. серверные узлы, предназначенные для поиска и индексации файлов, которые могут обмениваться этой информацией между собой. На практике это работало с ограниченным успехом, т. к. при отключении серверных узлов возникает сегментация сети.
Четвёртое поколение Р2Р-сетей получило наибольшее распространение в виде самого распространенного сегодня протокола BitTorrent, созданного Брэмом Коэном [5]. Основано на сегментировании Р2Р-сети. Сеть BitTorrent представляет собой набор обособленных сегментов, каждый из которых повторяет во многом сети первого поколения и состоит из одного или многих серверов. За счёт грамотной архитектуры узлов протокол поддерживает высокие скорости обмена между ними. Но сильная зависимость от центральных серверов является недостатком: отключение центрального сервера приводит к остановке работы сегмента сети. Протокол не имеет механизмов поиска и индексации файлов, он предназначен только для эффективной передачи файлов между узлами сети.
В пятом поколении Р2Р-сетей для устранения недостатков в сетях третьего и четвёртого поколения были внедрены вспомогательные, так называемые «оверлейные сети». Оверлейная сеть -это новая виртуальная децентрализованная сеть, созданная поверх существующей Р2Р-сети. Внутри оверлейной сети узлы получают адреса, не связанные с географическим или топологическим расположением узлов в рамках несущей сети. Примерами являются BitTorrent DHT, Kademlia и BuddyCast. Последний из них находится в активной разработке и открыт для изменений (open source).
Информационный поиск в Г2?-сетях.
Свойства децентрализованных файлообменных
сетей усложняют применение опыта в реализации информационных поисковых систем и рекомендательных систем, ориентированных на централизованные сети. В рекомендательных системах используются алгоритмы коллаборативной фильтрации (CF - collaborative filtering) для анализа различных мнений и пожеланий пользователей и для выработки персональных рекомендаций. Особенности децентрализованных компьютерных файлообменных сетей также мешает перенос разработанных алгоритмов CF. Всё это ведёт к ухудшению качества поиска и рекомендаций в децентрализованных сетях. Для переноса существующих ИПС и рекомендательных систем в децентрализованные сети необходимо преодолеть следующие несоответствия между ними:
Бинарные файлы. Традиционные ИПС ориентированы на текстовые файлы. Поисковые системы могут использовать векторы ключевых слов и семантические онтологии, чтобы найти нужный файл по содержащемуся в нём тексту на естественном языке. Децентрализованные сети чаще всего содержат в себе бинарные файлы, где содержимое описывает аудио- и видеопотоки, изображения. Определять содержимое файла можно по метаданным и по дескриптору файла (по названию и директории), которые чаще всего короткие и неточные. Чаще всего Р2Р-клиенты передают видео-
информацию и фильмы (70 %), ПО и игры (15 %,) и аудиозаписи (15 %) (см. рис. 2).
Отсутствие центрального индекса. Традиционные ИПС зависят от центрального индекса. Используя индекс, документ можно квалифицировать и идентифицировать, а затем ранжировать по релевантности к запросу пользователя. В децентрализованных сетях отсутствует такой индекс. Индивидуальные узлы имеют только малую долю файлов, что осложняет процессы идентификации нужных файлов и их ранжирование по релевантности.
Взвешивание терминов запроса. В традиционных системах часто применяются алгоритмы взвешивания терминов запроса, что улучшает поиск и релевантность результата. С отсутствием центрального индекса сложно определить уникальность и ценность термина в запросе.
Размер передаваемых файлов. По исследованиям [1] больше 50 % файлов, передаваемых в Р2Р-сетях, больше 1 Гб, в Азии - больше 2,5 Гб. Это резко отличается от традиционных ИПС, в которых конечный результат поиска - страница с подробной информацией.
Клиент ТпЫег реализует оверлейную сеть для рекомендаций и поиска, где для обмена внутри сети используется рекомендательный протокол BuddyCast, работающий следующим образом.
Porn
Рис. 2. Тип передаваемой информации в 2009 г. [2] ■ Video 72 %; ■ Softvare 24 %; ■ Audio 4 %
Каждый клиент сети хранит два списка: список N клиентов сети с наиболее схожими вкусами (по формуле 1) с их историей скачиваний, и список случайных клиентов сети без их истории скачиваний. Периодически клиент соединяется с клиентом либо из первого списка для обмена информацией о социальных связях и для получения обновлённой истории скачивания, либо из второго списка, со случайным клиентом, для изучения потенциальных более выгодных связей. Выполняя периодические обновления и исследования, клиент всегда осведомлён о схожих по вкусам клиентах, даже если они новые в сети.
Протокол BuddyCast помимо передачи значения SHA1 от передаваемых файлов в истории скачивания, будет передавать и ключевые слова, по которым найден .torrent-файл, позиция в результатах поиска и полное имя .torrent-файла, также будет передаваться свежая информация о количестве пользователей в раздаче. В итоге протокол позволит собрать и выявить список самых интересных узлов сети по нескольким метрикам: схожесть по вкусам, расстояние по сети, скорость отдачи данных, склонность раздавать файлы (альтруизм), социальное расстояние, надёжность и накопленная история совместной передачи файлов.
Предлагаемый рекомендательный протокол для ?2?-сетей. Рекомендательный протокол для клиента Tribler предлагается расширить следующим образом:
1. Сделать привязку PermID к набору идентификаторов из внешних социальных сетей пользователя. Это позволит рекомендовать файлы по социальному графу этих сетей, что повысит качество рекомендаций.
2. Сохранять информацию об объёме раздачи и рекомендовать краткосрочные раздачи первыми.
3. Использовать стандарт APML для описания и обмена интересов.
4. Позволить пользователю вручную выставлять рекомендации в истории скачивания.
Привязка PermID к идентификаторам из внешних социальных сетей. Социальные сети Facebook (320 млн), MySpace (130 млн), vkontakte (65 млн), Twitter (75 млн), Google, Microsoft Live ID (120 млн) и др. содержат миллионы пользователей. Социальные иерархии этих сетей предоставлены протоколами FaceBook Connect, Google Friends Connect и др. Многие социальные сети реализуют протокол авторизации OAuth и OpenId идентификации, предоставляют специализиро-
ванные API для получения информации о социальном графе конкретного пользователя.
Идентификатор клиента, используемый в протоколе BuddyCast, называется PermID и содержит публичной ключ, полученный алгоритмом из семейства эллиптической криптографии. Клиенты, зная публичные ключи по идентификатору PermID, авторизуются по стандартному протоколу ISO/IEC 9798-3 (challenge/response). В такой схеме идентификатор PermID привязан только к одному адресу IP и порту, что ограничивает оверлейную социальную сеть.
Предлагается реализовать связку PermID ко многим социальным идентификаторам внешних социальных сетей. В качестве идентификаторов социальной сети можно выбрать один из распространённых протоколов децентрализованной авторизации. Достаточную популярность приобрёл протокол децентрализованной авторизации OpenID, разработанный Брэдом Фицпатриком. Позднее он предложил другой, более проработанный и расширяемый протокол получения социальных идентификаторов в социальных сетях по адресу электронной почты, WebFinger, в одном XML файле в формате XRD. Многие сервисы предлагают социальный граф в формате FOAF для автоматического построения социального графа децентрализованным клиентом.
Используя эти протоколы и привязку PermID к идентификатору человека во внешних социальных сетях можно (1) автоматически получить социальные идентификаторы его друзей в реальном мире, (2) автоматически найти их внутри социальной сети по протоколам DHT и Kademlia и (3) сгенерировать более релевантные выборки файлов РП по интересам пользователей. Как показывает опыт исследователей социальных оверлейных сетей [10], клиенты ведут себя более щедро, раздавая файлы своим знакомым и друзьям. Также чётко прослеживается тенденция, что схожие по интересам люди находятся ближе в социальном графе и имеют больше общих социальных связей. Люди тяготеют друг к другу либо по социальному графу из социальных сетей, либо по схожести файлов из истории скачивания. Чем ближе клиенты находятся по социальному графу, тем больше вероятности построить взаимовыгодные социальные контакты для P2P^to.
В итоге протокол BuddyCast будет поддерживать не только схожесть по файлам, но и автоматическую выдачу рекомендации по социаль-
Рис. 3. Экспоненциальный спад скорости P2P BitTorrent
ной иерархии из внешних социальных сетей. Для этого необходимо расширить вызов SOCIAL_ OVERLAP (ID 239), передавая не только имя пользователя и его картинку, но и набор строковых идентификаторов внешних социальных сетей в формате XRD.
Экспоненциальный спад раздач. Временные распределения файлов внутри Р2Р-сетей являются другой проблемой, с которой сталкиваются децентрализованные рекомендательные системы. Исследования показывают [8], что скорость раздачи файлов внутри Р2Р-сетей экспоненциально уменьшается со временем. Это видно на рис. 3.
Экспоненциальный спад скорости более характерен для некоторых типов раздач, таких как телевизионные трансляции телешоу, обновлений ПО и др. Для улучшения качества рекомендательной системы предлагается создать метрику, по которой можно определять раздачи более характерные для падения скорости и отделить их в результатах от более стабильных, размеренных раздач. Это можно сделать, дополнив запись в списке истории скачивания количеством раздающих узлов в разное время, как в таблице, что даст достаточно информации для определения инертности раздачи в результатах рекомендательной системы.
Для предоставления этой исторической информации предлагается расширить вызовы BUDDYCAST (ID 249) и GET_METADATA
(ID 248), в которых передаётся список истории скачивания. Для каждого элемента в списке нужно хранить не только имя файла, поисковые термины, но и количество раздающих файл узлов сети в разные моменты времени.
Стандартизированный формат интересов пользователя APML. Также предлагается стандартизировать формат обмена интересами, используя известные и принятые микроформаты, например «язык разметки профилирования внимания» APML (APML - Attention Profiling Markup Language), в котором собираются характеристики пользователя и его иерархия интересов в формате XML. Информацию об интересах пользователя можно собрать из истории скачивания, так же как и со списка запросов в поисковой системе. Эту информацию предлагается сохранить в формат APML с вычисленными коэффициентами для каждого интереса. Например, имея список файлов и поисковых запросов можно семантически определить расположенность пользователя к телешоу и выставить высокий коэффициент интереса в файле APML.
Сжатый APML файл можно передавать по сообщению BUDDYCAST (ID 249), либо, что предпочтительнее, в отдельном вызове GET_APML, что делается только для новых или при обновлении старых узлов из списка.
Результирующий рекомендательный протокол. При выполнении указанных выше требо-
Предлагаемый механизм сохранения истории популярности раздачи файла
Время начала раздачи Т, ч +00 +2 +4 +8 +16 +32 +64
# раздающих 123 2345 3456 3452 500 200 100
ваний рекомендательный протокол будет годен для рекомендательной системы, в которой будут поддерживаться:
рекомендации файлов от известных человеку людей из внешних социальных сетей;
фильтрация дублирующихся рекомендаций от похожих узлов, но с одинаковыми социальными идентификаторами из внешних социальных сетей;
ранжирование результирующего списка рекомендованных файлов по скорости убывания числа узлов на раздаче;
более стандартизированный обмен данными (APML), что позволит в будущем встраивать другие рекомендательные системы в один протокол, не заменяя протокол общения между узлами.
Таким образом, предложен протокол, на основе которого можно создать современную децентрализованную рекомендательную систему ДС поверх существующих Р2Р-сетей ТпЫег и BitTorrent DHT.
В статье выделены текущие проблемы в рекомендательных протоколах децентрализованных сетей. Описан набор необходимых свойств нового рекомендательного протокола для ДФС, вклю-
чающий необходимые элементы для улучшения качества рекомендательной системы. Рассмотрены механизмы интеграции социальных сетей и децентрализованной социальной оверлейной сети и места расширений протокола BuddyCast, для реализации требуемого РП. Описанный протокол позволит получать более релевантную выборку рекомендации при сохранении свойств автоматического создания Р2Р-сети.
Для получения количественных оценок об улучшении рекомендаций необходимо провести лабораторные испытания с прототипом, основанным на клиенте Р2Р ТпЫег в сети с большим количеством узлов (больше 100 000 узлов). К недостаткам можно отнести возрастание количества передаваемой информации протоколом, что может негативно повлиять на скорость сети.
Перспективными направлениями исследований рекомендательных протоколов для ДФС являются также: выявление ограничений и возможностей языка описания интересов APML в ранжировании для рекомендательных систем и выявление метрик для определения наиболее вероятных поисковых запросов из истории запросов других пользователей ДФС.
СПИСОК ЛИТЕРАТУРЫ
1. Parker A. Cache Logic Research «P2P in 2005», 2006 P2P Media Summit. URL: http://www.dcia.info/ activities/p2pmswdc2006/ferguson.pdf
2. Исследовательская группа IPOQUE, Internet Study 2008/2009, 2009. URL: http://portal.ipoque.com/ downloads/index/study
3. Nguyen L., Jia D., Yee W.G., and Frieder O. Analysis of Query Logs in Gnutella Peer-to-Peer Network / ACM, 30-я конф. исследований и разработок в информ. поиске (SIGIR). Амстердам, Голландия, июль 2007.
4. Rahman R., Hales D., Meulpolder M. et al. Robust vote sampling in a P2P media distribution system / IEEE Intern. Symp. on Parallel&Distributed Processing, 2009, P. 1-8.
5. Cohen B. Incentives build robustness in BitTorrent. In Workshop on Economics of Peer-to-Peer Systems. Berkley, USA, May 2003. URL: http://citeseerx.ist.psu. edu/viewdoc/download?doi=10.1.1.14.1911&rep=rep1&t ype=pdf
6. Wong B., Vigfusson Y. and Sirer E.G. Hyperspaces for Object Clustering and Ap-proximate Matching in Peer-
to-Peer Overlays. In HotOS Workshop, 2007. URL: http:// www.cs.cornell.edu/People/egs/papers/hyperspaces.pdf
7. Wong B., Vigfusson Y. and Sirer E.G. Approximate Matching for Peer-to-Peer Over-lays with Cubit. Cornell University, 2008. URL: http://www.cs.cornell.edu/~bwong/ cubit/tr-cubit.pdf
8. Izal M., Urvoy-Keller G., Biersack E.W. et al. Dissecting BitTorrent: Five Months in a Torrent's Lifetime. In PAM, 2004. URL: http://citeseerx.ist.psu.edu/viewdoc/ download?doi=10.1.1.76.7615 &rep=rep1&type=pdf
9. Garbacki P., Iosup A., Doumen J. et al. TRIBLER PROTOCOL SPECIFICATION http://svn.tribler.org/bt2-design/proto-spec-unified/trunk/proto-spec-current.pdf
10. Koolen S.D. Creating and Maintaining Relationships in Social Peer-to-Peer Networks. Delft University of Technology, 2007.
11. Prete C.D., McArthur J.T., Villars R.L. et al. Industry developments and models / Disruptive Innovation in Enterprise Computing: storage. IDC, Feb. 2003.
12. Сеппель Е. История и развитие пиринговых сетей. СПбГУ, ММФ, 2008.
