Научная статья на тему 'Двухуровневая организация проблемно-ориентированной одноранговой сети'

Двухуровневая организация проблемно-ориентированной одноранговой сети Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
385
158
i Надоели баннеры? Вы всегда можете отключить рекламу.
Ключевые слова
ОДНОРАНГОВАЯ СЕТЬ / ДУБЛИНСКОЕ ЯДРО / PEER TO PEER NETWORKING / DUBLIN CORE

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Суворова Зоя Викторовна

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

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Суворова Зоя Викторовна

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

TWO-LEVEL PROBLEM-ORIENTED PEER TO PEER NETWORKING

This paper presents the principle of building distributed information network which consists of mobile nodes. It is based on a two-level network architecture. Resources of the network described in accordance with the specification Dublin Core, which allows the semantic search within the network.

Текст научной работы на тему «Двухуровневая организация проблемно-ориентированной одноранговой сети»

УДК 004.7

З.В. Суворова

ДВУХУРОВНЕВАЯ ОРГАНИЗАЦИЯ ПРОБЛЕМНО-ОРИЕНТИРОВАННОЙ ОДНОРАНГОВОЙ СЕТИ

Аннотация

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

Ключевые слова:

одноранговая сеть, дублинское ядро.

Z.V.Suvorova TWO-LEVEL PROBLEM-ORIENTED PEER TO PEER NETWORKING

Abstract

This paper presents the principle of building distributed information network which consists of mobile nodes. It is based on a two-level network architecture. Resources of the network described in accordance with the specification Dublin Core, which allows the semantic search within the network.

Keywords:

peer to peer networking, Dublin core

1. Введение

Одними из наиболее перспективных сетевых технологий в области обеспечения отказоустойчивости и обмена большими объёмами данных являются технологии одноранговых (или пиринговых, peer-to-peer, p2p) сетей, которые объединяют десятки миллионов компьютеров по всему миру и находят широкое применение в таких областях как: трансляция потокового мультимедиа (Skype), обмен файлами (BitTorrent), распределённые вычисления и др.

Технологии, на базе которых строятся пиринговые сети, весьма разнообразны. Обычно принято делить их на два больших класса -централизованные (BitTorrent, eDonkey2000) и децентрализованные (Skype, OpenDC++). При этом децентрализованные сети, по крайней мере, теоретически, превосходят централизованные практически по всем характеристикам, однако имеют существенный недостаток - большой объём генерируемого служебного трафика (поисковые пакеты, пакеты синхронизации данных и пр.).

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

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

Основные параметры узлов при организации децентрализованной пиринговой сети:

• все узлы равноправны;

• каждый узел хранит информацию, которая структурирована в рамках единого для всей системы классификатора;

• узел предоставляет возможность поиска информации как локально, так и по всей системе.

При такой архитектуре сети поиск информации может осуществляться следующими способами:

1. При получении запроса на поиск узел инициирует поиск у себя локально и опрашивает все остальные узлы сети. Затем по мере поступления информации формирует отчет на запрос пользователя и предъявляет этот отчет. Такой тип поиска условно можно назвать рекурсивным.

2. Предположим, что каждый узел имеет полный список всех ресурсов всех узлов сети, возможно ограниченный для поиска информации только с определенными характеристиками. Этот список реплицируется на все узлы сети. Узел инициирует поиск строго в рамках своей локальной копии полного списка и формирует ответ пользователю. Такой поиск можно обозначить как локальный.

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

Вторая модель является лучше масштабируемой и более надежной. Продолжительность поиска на конкретном узле напрямую зависит от его производительности. Однако очевидным недостатком такой архитектуры является то, что полный список всех ресурсов сети должен быть реплицирован на все хосты в сети, что порождает огромный служебный трафик внутри сети (момент первоначального распространения списка + периодическая синхронизация в случае изменения перечня хранимых ресурсов хотя бы на одном узле). Кроме того, необходимость хранения списка на всех хостах предъявляет дополнительные требования к узлам сети в плане организации дискового пространства, вычислительных ресурсов и мобильности [3].

Очевидно, что ни одна из этих архитектур в полной мере не удовлетворяет требованиям доступности и высокой надежности.

Анализ децентрализованных пиринговых сетей показал, что лишь 25% узлов находятся в сети более 24 часов, а около 40% - менее 4 часов. Кроме того, служебный трафик (так называемые запросы «ping-pong», используемые для определения доступности узлов, т.е. поддержания непрерывного сетевого взаимодействия) составляет более 50% всего трафика сети, а объем «полезного» трафика (пользовательские запросы) - около 10% [1]. Таким образом, чтобы существенно сократить объем вспомогательного трафика, следует, прежде всего, добиться сокращения количества запросов «ping-pong». В предлагаемой архитектуре количество таких запросов сокращается за счет того, что они распространяются не между всеми хостами сети (что и перегружает сеть), а среди некоторых групп узлов.

С учетом указанных выше статистических данных - мобильности большинства узлов - можно построить классификацию узлов по признаку постоянства нахождения узла в составе сети.

В результате такой классификации образуется двухуровневая организация узлов, входящих в сеть:

1-й уровень: узлы, которые обладают высокой доступностью и участвуют в процессе приема и отдачи данных, находясь в составе сети практически постоянно;

2-й уровень: узлы, обладающие высокой мобильностью, которые

преимущественно получают информацию и хранят небольшие объемы данных. Роль таких узлов исполняют преимущественно мобильные (подвижные) узлы.

Такое разделение узлов потенциально позволит снизить объем вспомогательного трафика за счет «перекладывания» некоторых функций на хосты первого уровня; при этом снижается нагрузка на мобильные узлы второго уровня.

Хосты, выделенные в верхний уровень, назовем мастер-хостами, или концентраторами, остальные хосты остаются обычными узлами. Мастер-хосты должны обрабатывать основной поток трафика и отвечать на запросы поиска, доступности, а также отслеживать появление мобильных узлов сети, т.е. обладать достаточными вычислительными ресурсами и способностью поддерживать множественные соединения, которые поступают от других хостов (в том числе и от тех, которые располагаются на уровне ниже). К мобильным узлам предъявляемые требования значительно ниже с точки зрения вычислительных возможностей, в роли обычных узлов могут выступать мобильные устройства. Функциональность таких узлов сравнительно ниже, но не является «тонкой» архитектурой с точки зрения задач поиска, хранения и индексирования данных.

Взаимодействия между хостами организованы в виде следующих задач:

• При первичном подключении к сети на клиентском приложении каждого хоста имеется список адресов мастер-хостов. Делая свой первый запрос какому-либо из мастер-хостов из списка, узел подключается к сети.

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

• Мастер-хосты взаимодействуют с другими мастер-хостами посредством широковещательной передачи.

• Опрос доступности узла. Каждый узел должен регулярно опрашивать узлы из своего списка на предмет доступности. Это реализуется запросами Ping-Pong: отправляя запрос Ping какому-либо узлу, получатель запроса в ответ формирует запрос Pong, который означает присутствие в сети в данный момент. Список узлов-«соседей» строится в соответствии с алгоритмом, описанным ниже.

• Поисковые запросы. Узлы первоначально взаимодействуют с узлами из своего списка. В случае, если на них отсутствует необходимая информация, запрос перенаправляется мастер-хосту.

4. Описание ресурса с помощью дублинского ядра (метаданные ресурсов)

Поскольку в описываемой архитектуре предлагается каждому хосту поставить в соответствие определенную область интересов, зависящую от тематики хранимых ресурсов, необходимо определить структуру, которая бы описывала данные, хранящиеся на узлах. Метаданные, описывающие разделяемые ресурсы, должны быть представлены структурой с определенным набором полей, которая хранит информацию о наиболее важных параметрах описываемых данных. Например, музыкальный файл может описываться именем исполнителя, названием, альбомом, годом записи и другими параметрами. В качестве стандарта для описания данных можно взять действующий в РФ ГОСТ Р 7.0.10-2010 (ИСО 15836:2003) "Национальный стандарт российской федерации”. Система стандартов по информации, библиотечному и издательскому делу. Набор элементов метаданных "Дублинское ядро".

Дублинское ядро (Dublin Core, DC) можно понимать как компактный язык для разработки формализованных утверждений определенных типов, описывающих ресурсы.

1) Simple Dublin Core - простой уровень, который еще называется неквалифицированным;

2) Qualified Dublin Core - квалифицированный уровень.

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

Каждый элемент DC является опциональным (необязательным) и может повторяться в метаописании сколько угодно раз. Кроме того, порядок элементов в метаописании также никак не регулируется. Порядок, в котором несколько экземпляров одного и того же элемента (например, Creator - создатель) входят в метаописание, может иметь значение в некоторых системах. Однако не гарантируется, что этот порядок будет сохраняться в других реализациях. Упорядочение зависит от синтаксиса, в котором реализуется дублинское ядро.

Простой набор элементов метаданных Дублинского ядра (Dublin Core Metadata Element Set; DCMES):

1. Title — название;

2. Creator — создатель;

3. Subject — тема;

4. Description — описание;

5. Publisher — издатель;

6. Contributor — внёсший вклад;

7. Date — дата;

8. Type — тип;

9. Format — формат документа;

10. Identifier — идентификатор;

11. Source — источник;

12. Language — язык;

13. Relation — отношения;

14. Coverage — покрытие;

15. Rights — авторские права.

Квалифицированный (компетентный) набор элементов метаданных Дублинского ядра, помимо 15 вышеперечисленных, может включать:

• Audience — аудитория (зрители);

• Provenance — происхождение;

• RightsHolder — правообладатель. [5]

Основываясь на метаданных, полученных с помощью «Дублинского ядра», далее предлагается классифицировать ресурсы по семантике и организовать тематический поиск данных.

5. Реализация поискового запроса

Каждый узел после подключения к одноранговой сети производит построение списка данных, которые он содержит. Каждому ресурсу при этом поставлен в соответствие файл, содержащий описание этого конкретного ресурса в виде дублинского ядра. Такие файлы с описаниями формируются при выставлении этого ресурса в общий доступ (в клиентском приложении заполняются соответствующие поля), причем для дальнейшей организации и корректной работы семантического поиска обязательно задаются понятия, связанные с тематикой этого ресурса, или ключевые слова. Затем сформированный список всех ресурсов хоста с их описаниями в виде дублинского ядра отсылаются на мастер-хост. Концентраторы, таким образом, получают информацию обо всех данных, хранящихся на всех хостах. Используя эту информацию, мастер-хосты могут выделить в отдельные кластеры хосты, объединенные общей областью интересов, которая задается пользователем самостоятельно как его область интересов либо определяется по процентному соотношению хранимых данных по конкретной тематике к общему объему хранимых данных (т.е. если большая часть хранимых данных данного хоста имеет в поле Subject в DC заголовок «кулинария», то этот хост прикрепляется к группе хостов, имеющих большинство информации на эту же тему). Сами мастер-хосты также определяют собственные области интересов и участвуют в поиске наравне с обычными узлами.

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

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

Поиск в такой сети возможен как по ключевым словам, автору, названию, так и по любому полю, представленному в дублинском ядре.

6. Заключение

Данная архитектура разработана с учетом требования к мобильности узлов, а также с целью снижения «накладных расходов» одноранговой сети и добавления возможности семантического поиска. Практически в любой сети существуют узлы, которые являются доступными большую часть времени. При этом многие другие узлы подключаются к сети время от времени и не обладают высокой ресурсоемкостью (как объем хранимой информации, так и вычислительные мощности). Такими узлами, прежде всего, являются подвижные, мобильные узлы. В связи с этим естественным будет разделение узлов по этому принципу на функционально более отягощенные и более облегченные узлы; при этом снижается объем служебных запросов за счет «сужения» областей передачи служебных данных.

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

Использование в качестве описания ресурса общепринятого стандарта «дублинское ядро» задает общий классификатор для тематического разделения ресурсов.

Литература

1. Matei, Ripeanu. Mapping the Gnutella Network: Properties of Large-Scale Peer-to-Peer Systems and Implications for System Design / Matei Ripeanu, Ian Foster, Adriana Iamnitchi// IEEE Internet Computing. - 2002. -Vol. 6, Issue 1. -рр. 50-57.

2. Алексеев, И.В. Разработка протокола уровня приложений для огранизации мобильной файлообменной пиринговой сети / И.В. Алексеев, А.В. Лукьянов // Информатизация образования и науки. -2009. - №4. - С.75-88.

3. Манцивода, А.В. Объектные модели и распределенные системы знаний /А.В. Манцивода, Н.О. Стукушин // Известия Иркутского государственного университета. -2010. -Т.3, №4. -С.65-79.

4. Рожков, М.М. Разработка моделей поиска структурированной информации в пиринговой сети / М.М. Рожков //Дистанционное и виртуальное обучение. - 2009. -№12. - С.65-72.

5. Dublin Core Metadata Initiative. - Режим доступа: http ://dublincore. org/

Сведения об авторах

Суворова Зоя Викторовна

стажер-исследователь. Учреждение Российской академии наук Институт информатики и математического моделирования технологических процессов Кольского научного центра РАН. Россия, 184209, г. Апатиты Мурманской обл., ул. Ферсмана, д. 24A. e-mail: shirokova@iimm.kolasc.net.ru

Zoya V. Suvorova

probationer-researcher. Institution of Russian Academy of Sciences, Institute for Informatics and Mathematical Modeling of Technological Processes, Kola Science Center оf RAS.

Russia, 184209, Apatity Murmansk region, Fersman St. 24А.

i Надоели баннеры? Вы всегда можете отключить рекламу.