Это новая идея в Р2Р системах, где мобильные приложения могут использовать информацию о физическом положении пользователя по отношению к другим людям и устройствам. Этот подход используется в таких системах, как Cricket [3] и WebSign [4]. Эти сервисы для мобильных устройств могут быть расширены с помощью Р2Р систем. API RockyRoad — первый интерфейс, предлагающий подобные функции разработчикам Р2Р приложений.

Основной задачей этой группы сервисов является поиск нужных peers или ресурсов в сети,  их индексация и построение иерархии участников  и ресурсов на основе персональной информации от каждого участника сети. P2P системы условно можно разделить на два типа: peer-ориентированные и ресурсоориентированные системы.

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

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

В системах такого типа не имеет большого значения удобство доступа к peer. Самым важным является сам peer — поскольку его информация является уникальной. Задача оптимизации возникает только при выборе оптимального маршрута обмена сообщениями между этими двумя peers.

В качестве примера систем второго уровня можно рассматривать системы разделения файлов (Gnutella, FreeNet, Napster, Free Haven, ...). Для пользователей этого типа систем не важно кто является хозяином этой системы, а важно, какими ресурсами обладает на данный момент тот или иной peer.

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

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

Особым интересом для команды RockyRoad обладает сервис обнаружения peer, использующий очень быстрый алгоритм, называемый “beaconing” (от англ. beacon — маяк). Он основан на триангуляции. Подробности алгоритма выходят за рамки этой статьи, для справки смотрите ссылку в конце текста.

Этот раздел описывает подход RockyRoad к проблеме безопасного и аутентифицированного обмена сообщениями в распределенной системе со многими участниками (peers).

Рассмотрим процесс взаимодействия между peers в сети. Данная сеть считается «небезопасной». Атакующая сторона (на рисунке 2 скрытая в облаке) обладает следующими возможностями:

1) Перехватывать любые сообщения (попытки соединения) между данным peer(А) и любым peer В, а также ответные сообщения В к А.

2) Просматривать содержимое перехваченного сообщения и совершать одно из следующих действий:

a. Переслать неизмененное сообщение оригинальному адресату;

b. Удалить сообщение;

c. Переслать измененное любым образом сообщение оригинальному адресату.

3) Разговаривать с peer В, притворяясь peer А, и наоборот (у атакующей стороны есть возможность не только модифицировать существующие сообщения, но и создавать новые).

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

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

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

Типичный PalmOS PDA имеет от 4 до 8 МВ энергонезависимой памяти для программ и данных, модемное подключение к Интернет со скоростью от 9600 до 14400 бит/с и не имеет внешних устройств хранения данных. Большинство клиент-серверных приложений требуют быстрой и надежной связи для потоковой передачи данных. Кроме того, хранение данных на клиентском устройстве затруднено из-за ограниченного объема памяти.

Одно из возможных решений — интеллектуальное кэширование данных на стороне клиента. Этот сервис использует асинхронный протокол для обмена сообщениями между сервером и клиентом. «Интеллектуальность» относится к способности минимизировать количество сообщений, посылаемых для синхронизации данных. Создается иллюзия, что клиентское приложение работает с полной базой данных независимо от состояния соединения. На самом же деле клиент хранит только наиболее часто используемые данные, а неиспользованные порции постепенно стираются (с сохранением целостности на уровне ссылок).

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

Gateway
Gateway обеспечивают взаимодействие между peers, находящимися в разных сетях (IP, GSM и т.д.) В RockyRoad есть некоторые встроенные шлюзы. Они также необходимы для общения с peers, не поддерживающими протокол RockyRoad, но использующими протокол другого производителя (Jabber, Gnutella, Freenet и т.д.)

http://www.jrra.org/bin/view/Main/Services

Мы считаем, что RockyRoad — первый API, полностью поддерживающий динамическое привязывание к сервисам на основе политики пользователя. Динамическое привязывание — простая концепция, для использования которой разработчик должен использовать RockyRoad с опцией блока политики. Блок политики позволяет разработчику предоставить конечному пользователю механизм указания политики и передать эти данные протоколу RockyRoad. Протокол динамически транслирует политику, чтобы найти наиболее подходящий сетевой транспорт или сервисный механизм. Термин «динамическое привязывание» позаимствован из языков программирования типа С++, где позднее связывание — одна из особенностей языка. Термин «динамическое» требует пояснения. Почему так назван простой механизм трансляции политики? Ответ заключается в том факте, что, когда RockyRoad используется с опцией flexiblenetworking, в нем запускается активный поток, который ищет транспортные, сетевые или сервисные механизмы, соответствующие предпочтениям пользователя. Другими словами, RockyRoad может динамически находить подходящие механизмы в зависимости от среды, в которой находится пользователь. Конечно, успешность динамического привязывания зависит от способности четко описывать политику и наличия простого механизма трансляции политики в желаемый сетевой механизм. Это может быть удобно реализовано с использованием XML.