Уровень техники
Область техники, к которой относится изобретение
Группа изобретений относится, в общем, к области компьютерных сетей. Более конкретно, группа изобретений относится к усовершенствованным аппарату и способу для создания и использования резервных каналов связи для мобильных устройств.
Описание уровня техники, предшествующего изобретению
А. Преобразование сетевых адресов ("NAT - преобразование")
Большие сети общего пользования, такие как сеть Интернет, часто имеют соединения с меньшими частными сетями, такими как сети, эксплуатируемые корпорацией, провайдерами услуг сети "Интернет" или даже индивидуальными домашними хозяйствами. По самой своей природе, сети общего пользования должны иметь распределение сетевых адресов, по которому имеется общее соглашение, то есть публичные адреса. По различным причинам лица, эксплуатирующие частные сети, часто выбирают для частных сетей использование частных сетевых адресов, которые не являются частью распределения, по которому имеется общее соглашение. Таким образом, для того чтобы сетевой трафик из частной сети был способен проходить сеть общего пользования, требуется некоторая форма преобразования сетевых адресов из частных в публичные ("NAT - преобразования").
Устройство, выполняющее операции NAT - преобразования, изменяет пакеты данных, отправляемые из частной сети, таким образом, чтобы они удовлетворяли схеме адресации сети общего пользования. В частности, транслятор сетевых адресов заменяет исходный частный адрес и номер порта пакета своим собственным публичным адресом и назначенным номером порта. Транслятор сетевых адресов также изменяет пакеты данных, принимаемые для компьютеров частной сети, таким образом, чтобы заменять публичный адрес пункта назначения и номер порта правильным частным адресом и номером порта подразумеваемого адресата. Термин "адрес", в том значении, в котором он здесь используется, должен толковаться таким образом, чтобы включать в себя как адрес, так и номер порта, если это уместно по контексту, что должно быть понятно специалисту обычного уровня квалификации в данной области техники.
При обработке данных в современных сетях NAT - преобразование становится все более распространенным. Одно из преимуществ NAT - преобразования заключается в том, что оно замедляет истощение адресного пространства сети общего пользования. Например, адресация по протоколу TCP/IP (протоколу управления передачей/ межсетевому протоколу), которая используется в сети "Интернет", содержит четыре последовательности из трех разрядов каждая, обеспечивая, таким образом, конечное адресное пространство. В дополнение к этому, определенные участки этого адресного пространства зарезервированы для особых вариантов использования или пользователей, еще более истощая фактически располагаемое количество адресов. Однако при использовании NAT - преобразования частная сеть или подсеть могут использовать произвольное количество адресов и все-таки представлять для внешнего мира один единственный, стандартизированный публичный адрес. Это делает количество располагаемых адресов фактически безграничным, потому что каждая частная сеть могла бы, теоретически, использовать в точности одинаковые частные адреса.
Одно из преимуществ, предоставляемых NAT - преобразованием, заключается в повышении безопасности, являющемся результатом того факта, что абоненты сети общего пользования не могут определить фактический (то есть частный) сетевой адрес компьютера в частной сети. Причина этого заключается в том, что в сети общего пользования транслятором сетевых адресов предоставляется только публичный адрес. В дополнение к этому, этот публичный адрес может соответствовать любому количеству компьютеров в частной сети.
Различные типы NAT - преобразования используют различные уровни защиты. Например, в случае "полного конического NAT - преобразования", когда внутренний адрес (iAddr:iPort) отображается на внешний адрес (eAddr:ePort), любое внешнее хост -устройство может отправлять пакеты для iAddr:iPort, отправляя пакеты по адресу iAddr:ePort. В случае "ограниченного конического NAT - преобразования" внешнее хост - устройство с адресом hAddr может отправлять пакеты для iAddr:iPort, отправляя пакеты по адресу iAddr:ePort, только в том случае, если iAddr:iPort предварительно отправил пакет по адресу hAddr. Порт внешнего хост - устройства в данном случае не важен. В случае, когда имеет место "Ограниченное по порту коническое NAT - преобразование" внешнее хост - устройство, имеющее адрес/порт hAddr:hPort может отправлять пакеты для iAddr:iPort, отправляя пакеты по адресу iAddr:ePort, только в том случае, если iAddr:iPort предварительно отправлял пакет по адресу iAddr:hPort. Наконец, в случае Симметричного NAT - преобразования каждый запрос с одного и того же адреса iAddr:iPort в некоторый конкретный IP - адрес и порт пункта назначения соответствует уникальному eAdd:ePort. Если одно и то же внутреннее хост - устройство отправляет пакет в различные пункты назначения, то используются различное отображение внешнего адреса и порта. Только то внешнее хост - устройство, которое принимает пакет от внутреннего хост - устройства, может отправить пакет в обратном направлении этому внутреннему хост - устройству.
В. Проблемы NAT - преобразования в случае одноранговых сетей
Термин "одноранговая (Р2Р) обработка данных" относится к распределенной сетевой архитектуре, состоящей из вычислительных узлов, которые делают часть своих ресурсов напрямую доступными для других участников сети. Одноранговые узлы в одноранговой сети устанавливают прямые каналы связи друг с другом и действуют в качестве как клиентов, так и серверов, в отличие от традиционной модели "клиент - сервер", при которой серверы предоставляют ресурсы, а клиенты потребляют ресурсы.
Описанные выше операции NAT - преобразования создают множественные проблемы для одноранговых соединений. Например, установление прямого соединения между двумя одноранговыми узлами становится все более трудным в том случае, если один или оба из одноранговых узлов располагаются позади системы NAT - преобразования одного или более типов, описанных выше. Эта проблема усиливается тем фактом, что мобильные устройства, такие как Apple iPod Touch®, Apple iPhone®, Apple iPad® и различные другие устройства (например, устройства RIM Blackberry®, устройства Palm Pre® и так далее) часто перемещаются между сетями, имеющими различные варианты реализации NAT - преобразования. Например, устройство Apple iPhone™ способно поддерживать связь по сетям Wi-Fi (например, по сетям стандартов 802.11b, г, n); по 3G - сетям (сетям третьего поколения, например, сетям Универсальной системы мобильной связи ("UMTS - сетям"), по высокоскоростным спутниковым сетям пакетного доступа ("HSUPA - сетям") и так далее); и по сетям Bluetooth (известным как персональные сети ("PAN - сети")). Будущие мобильные устройства будут способны поддерживать связь по дополнительным каналам связи, таким как, например, сеть WiMAX Усовершенствованная сеть международной мобильной телекоммуникации ("IMT") и Усовершенствованная сеть долгосрочного развития ("LTE").
Раскрытие изобретения
Описываются устройство, способ и машиночитаемый носитель информации для создания, поддержания и использования резервных каналов в одноранговой ("Р2Р") сети. Например, в одном варианте реализации изобретения каждое мобильное устройство может устанавливать первичный канал одноранговой связи с одним или более другими мобильными устройствами. Как только первичный канал установлен, каждое мобильное устройство может использовать этот первичный канал для обмена данными для соединения по вторичному каналу и может вслед за этим открыть один или более вторичных каналов одноранговой связи с этими другими мобильными устройствами. При обнаружении того, что первичный канал одноранговой связи нарушен или ухудшился ниже некоторого указанного порога (например, порогового значения ширины полосы пропускания или скорости передачи битов), один из вторичных каналов одноранговой связи может быть автоматически сделан первичным каналом одноранговой связи.
Краткое описание чертежей
Лучше понять настоящее изобретение можно из нижеследующего детализированного описания в сочетании с нижеследующими чертежами, на которых:
На Фиг.1 проиллюстрирована сетевая архитектура, в которой группа мобильных устройств и сервисов поддерживают связь по сети.
На Фиг.2а-с проиллюстрированы транзакции между одним вариантом реализации сервиса обмена соединительными данными (CDX - сервиса), сервисом формирователя сочетания и/или сервисом приглашения.
На Фиг.3 проиллюстрирован один вариант реализации структуры данных билета.
На Фиг.4 проиллюстрирован один вариант реализации способа, воплощаемого CDX - сервисом.
На Фиг.5 проиллюстрирован один вариант реализации способа, воплощаемого мобильным устройством.
На Фиг.6 проиллюстрирована группа мобильных устройств, соединенных посредством первичного и вторичного каналов связи.
На Фиг.7 проиллюстрирован один вариант реализации мобильного устройства для выбора среди первичного и вторичных каналов связи.
На Фиг.8а-b проиллюстрирована группа мобильных устройств, соединенных посредством первичного и вторичных каналов связи, и получающаяся в результате этого топология сети.
На Фиг.9 проиллюстрирован один вариант реализации воплощаемого компьютером способа для выбора между первичным и вторичными каналами связи.
На Фиг.10 проиллюстрирована сетевая архитектура, в которой по сети поддерживают связь группа мобильных устройств и сервисов, включающих в себя сервис каталога и сервис "проталкиваемых" уведомлений.
На Фиг.11 проиллюстрированы транзакции между одним вариантом реализации сервиса приглашения, сервисом "проталкиваемых" уведомлений и сервисом обмена соединительными данными (CDX - сервисом).
На Фиг.12 проиллюстрированы транзакции между одним вариантом реализации сервиса приглашения, сервисом "проталкиваемых" уведомлений и сервисом ретрансляции.
На Фиг.13 проиллюстрирован один вариант реализации сервиса ретрансляции для установления ретрансляционного соединения между двумя или больше мобильными устройствами.
На Фиг.14 проиллюстрирован один вариант реализации таблицы совместимости NAT - преобразования (преобразования сетевых адресов), предназначенной для определения совместимости NAT - преобразования.
На Фиг.15 проиллюстрирован один вариант реализации сервиса формирователя сочетания для сочетания между собой мобильных устройств для онлайновых приложений.
На Фиг.16 проиллюстрирован один вариант реализации способа для сочетания между собой пользователей/устройств.
На Фиг.17a-d проиллюстрирована приводимая в качестве примера последовательность обновлений таблиц, выполняемых для сочетания пользователей/устройств.
На Фиг.18 проиллюстрирован способ для сочетания пользователей/устройств с использованием различных переменных "соответствия" сочетания.
На Фиг.19 проиллюстрирован каркас, предоставляющий интерфейс прикладного программирования (API - интерфейс) для приложений и интерфейс прикладного программирования для сервисов, предназначенный для поддержания связи с набором сервисов.
На Фиг.20 проиллюстрирован один вариант реализации каркаса игр, имеющий API - интерфейс для приложений, игрового "демона" и модуль игровых сервисов для поддержания связи с сервисами.
На Фиг.21 проиллюстрирован один вариант осуществления программного компонента реализации API - интерфейса и программного компонента вызова API - интерфейса.
На Фиг.22 проиллюстрирован один вариант реализации изобретения, в котором между операционными системами, сервисами, и приложениями производятся вызовы API - интерфейса.
На Фиг.23 проиллюстрирован один вариант реализации архитектуры приводимой в качестве примера компьютерной системы.
На Фиг.24 проиллюстрирован другой вариант реализации архитектуры приводимой в качестве примера компьютерной системы.
Подробное описание предпочтительных вариантов реализации изобретения
Ниже описаны варианты реализации аппарата, способа и машиночитаемого носителя информации для создания, поддержания и использования первичных и/или резервных одноранговых каналов связи в сети. Также описаны сервис приглашения и сервис формирователя сочетания, предназначенные, соответственно, для приглашения пользователей и формирования сочетаний пользователей для сеансов одноранговой связи. В дополнение к этому, описывается сервис ретрансляции, позволяющий пользователям при определенных указанных условиях устанавливать соединения ретрансляции. Наконец, описываются каркас приложений и связанный с ним интерфейс прикладного программирования (API - интерфейс), позволяющие разработчикам приложений разрабатывать приложения, которые используют преимущество разнообразных описанных здесь онлайновых функциональных возможностей.
Повсюду в описании, в целях объяснения, сформулированы многочисленные конкретные подробности, дающие полное понимание настоящего изобретения. Однако специалисту в данной области техники будет очевидно, что настоящее изобретение может быть осуществлено без некоторых из этих конкретных подробностей. В других случаях, хорошо известные конструкции и устройства не показаны или показаны в форме структурной схемы для того, чтобы избежать затруднения понимания основных принципов настоящего изобретения.
Устройство и способ для эффективного и безопасного обмена соединительными данными
Как проиллюстрировано на Фиг.1, общая топология сети, воплощенная в одном варианте реализации изобретения может включать в себя группу "клиентских" или "одноранговых" мобильных вычислительных устройств: А-D 120-123, соответственно, поддерживающих связь друг с другом и с одним или более сервисами 110-112 по сети 120. Хотя на Фигуре 1 "сеть" 120 проиллюстрирована как единое сетевое облако, она может включать в себя разнообразие различных компонентов, включающих в себя, например, сети общего пользования, такие как сеть "Интернет", и частные сети, такие как локальные сети Wi-Fi (например, бытовые беспроводные сети стандарта 802.11 n или точки беспроводного доступа), локальные сети Ethernet, сотовые сети передачи данных (например, 3G (сети третьего поколения), Edge (сети с технологией повышенных скоростей передачи данных для развития системы GSM и так далее), и сети WiMAX. Например, мобильное устройство А 120 может быть соединено с бытовой сетью Wi-Fi, представленной сетевой линией 125, мобильное устройство В 121 может быть соединено с сетью 3G (например, с сетью Универсальной мобильной системы связи ("UMTS - сетью"), с высокоскоростной спутниковой сетью пакетного доступа ("HSUPA - сетью") и так далее), мобильное устройство С 122 может быть соединено с сетью WiMAX, представленной сетевой линией 127, а мобильное устройство 123 может быть соединено с сетью Wi-Fi общего пользования, представленной сетевой линией 128. Каждая из линий 125-128 локальной сети, по которой соединены мобильные устройства 120-123, может быть подсоединена к сети общего пользования, такой как сеть "Интернет", через шлюз и/или NAT - устройство (устройство преобразования сетевых адресов) (не показанное на Фигуре 1), таким образом, делая возможной связь между различными мобильными устройствами 120-123 по сети общего пользования. Однако если два мобильных устройства находятся в одной и той же локальной или частной сети (например, в одной и той же сети Wi-Fi), то эти два устройства могут поддерживать связь напрямую по этой локальной/частной сети, обходя сеть общего пользования. Конечно же, следует отметить, что принципы, лежащие в основе изобретения, не ограничены никаким конкретным набором типов сетей или топологий сети.
Каждое из мобильных устройств 120-123, проиллюстрированных на Фиг.1, может поддерживать связь с сервисом (110) обмена соединительными данными (CDX - сервисом), сервисом 111 формирователя сочетания и сервисом 112 приглашения. В одном варианте реализации изобретения сервисы 110-112 могут быть воплощены как программное обеспечение, исполняемое на одном или более физических вычислительных устройствах, таких как серверы. Как показано на Фигуре 1, в одном варианте реализации изобретения сервисы 110-112 могут быть воплощены в рамках контекста более крупного сервиса 100 данных, управляемого одним и тем же объектом (например, одним и тем же поставщиком сервиса данных) и доступного для каждого из мобильных устройств 120-123 через сеть 120. Сервис 100 данных может включать в себя локальную сеть (например, локальную сеть на основе Ethernet), соединяющую различные типы серверов и баз данных. Сервис 100 данных может также включать в себя одну или более сетей устройств хранения данных ("SAN - сетей") для хранения данные. В одном варианте реализации изобретения эти базы данных сохраняют и управляют данными, относящимися к каждому из мобильных устройств 120-123, и пользователей этих устройств (например, данными учетных записей пользователей, данными учетных записей устройств, данными о пользовательских приложениях, … и так далее).
В одном варианте реализации изобретения сервис 111 формирователя сочетания может, основываясь на некотором указанном наборе условий, формировать сочетание двух или более мобильных устройств для совместного сеанса одноранговой связи. Например, пользователи двух или больше мобильных устройств могут быть заинтересованы в проведении некоторой конкретной игры для нескольких игроков. В таком случае, сервис 111 формирователя сочетания может идентифицировать группу мобильных устройств для участия в игре, основываясь на таких переменных, как уровень мастерства каждого пользователя, возраст каждого из пользователей, время поступления запросов сочетания, конкретная игра, для которой запрашивается сочетание, и разнообразные переменные, специфические для игры. В порядке примера, а не ограничения, отметим, что сервис 111 формирователя сочетания может, при проведении некоторой конкретной игры, попытаться сочетать пользователей со сходными уровнями мастерства. В дополнение к этому, взрослые могут сочетаться с другими взрослыми, а дети могут сочетаться с другими детьми. Кроме того, сервис 111 формирователя сочетания может располагать по приоритетам пользовательские запросы, основываясь на порядке, в котором принимаются эти запросы. Принципы, лежащие в основе изобретения, не ограничены никаким конкретным набором критериев сочетания или никаким конкретным типом однорангового приложения.
Как подробно описывается ниже, в ответ на запрос сочетания сервис 111 формирователя сочетания может осуществлять с CDX - сервисом (110) согласование с целью обеспечения того, чтобы все сочетаемые участники получили соединительные данные, необходимые для организации сеансов одноранговой связи эффективным и безопасным образом.
В одном варианте реализации изобретения сервис (112) приглашения также идентифицирует мобильные устройства для участия в совместных сеансах одноранговой связи. Однако в случае сервиса (112) приглашения, по меньшей мере, один из участников специально идентифицируется другим участником. Например, пользователь мобильного устройства А 120 может специально запросить совместный сеанс связи с пользователем мобильного устройства В 121 (например, идентифицируя мобильное устройство В посредством идентификатора или телефонного номера пользователя). Как и в случае сервиса 111 формирователя сочетания, в ответ на запрос приглашения, сервис 112 приглашения может идентифицировать набор участников и осуществлять с CDX - сервисом ПО согласование с целью обеспечения того, чтобы все сочетаемые участники получили соединительные данные, необходимые для организации сеансов одноранговой связи эффективным и безопасным образом.
Как было упомянуто выше, в одном варианте реализации изобретения CDX - сервис ПО функционирует в качестве некоторой центральной точки обмена данными в отношении соединительных данных, требующихся для организации сеансов одноранговой связи между двумя или больше мобильными устройствами. В частности, один вариант реализации CDX - сервиса генерирует, в ответ на запросы мобильных устройств, данные прохождения NAT - преобразования (иногда именуемые как данные "проделывания прохода") для того, чтобы позволить внешним сервисам и клиентам поддерживать связь через NAT - систему каждого мобильного устройства (то есть "проделать проход" через NAT - систему, чтобы добраться до устройства). Например, в одном варианте реализации изобретения, CDX - сервис определяет внешний IP-адрес и порт, необходимые для поддержания связи с мобильным устройством, и предоставляет эту информацию мобильному устройству. В одном варианте реализации изобретения CDX - сервис также принимает и обрабатывает списки мобильных устройств, генерируемые сервисом 111 формирователя сочетания и сервисом 112 приглашения и эффективно и надежно подает соединительные данные каждому из мобильных устройств, включенных в состав этих списков (как подробно описывается ниже).
В одном варианте реализации изобретения связь между мобильными устройствами и CDX - сервисом ПО устанавливается с использованием относительно легковесного сетевого протокола, такого как сокеты Протокола пользовательских дейтаграмм ("UDP - протокола"). Как известно специалистам в данной области техники, соединения сокетов UDP - протокола не требуют диалогов квитирования связи для обеспечения надежность передачи пакета, упорядоченности или целостности данных и, следовательно, не поглощают такого большого количества служебных данных для обработки пакетов как соединения сокетов TCP - протокола. Следовательно, легковесная и не требующая запоминания состояний природа UDP - протокола полезна для серверов, которые отвечают на небольшие запросы от обширного количества клиентов. Кроме того, в отличие от TCP - протокола, UDP - протокол совместим с вещательной передачей пакетов (при которой пакеты отправляются всем устройствам в локальной сети) и с групповым вещанием (при котором пакеты отправляются некоторому подмножеству устройств в локальной сети). Как описывается ниже, даже при том, что может использоваться UDP - протокол, безопасность в CDX - сервисе ПО можно поддерживать, шифруя данных прохождения NAT - преобразования, используя ключи сеанса связи.
В противоположность имеющему малое количество служебных данных, легковесному сетевому протоколу, используемому CDX - сервисом 110, в одном варианте реализации изобретения связь между мобильными устройствами 120-123 и сервисом 111 формирователя сочетания и/или сервисом 112 приглашения устанавливается посредством внутренне защищенного сетевого протокола, такого как Протокол защищенной передачи гипертекстов ("HTTPS - протокол"), который полагается на соединения Протокола защищенных сокетов ("SSL - протокола") или Протокола защиты транспортного уровня ("TLS - протокола"). Подробности, связанные с этими протоколами, хорошо известны специалистам в данной области техники.
На Фиг.2 а проиллюстрирована приводимая в качестве примера последовательность транзакций, которые могут быть осуществлены CDX - сервером (сервером обмена соединительными данными). При описании функционирования одного варианта реализации CDX - сервиса нижеследующие термины имеют следующие значения.
Соединительные данные - это информация, которой потенциальные одноранговые пользователи должны обменяться друг с другом для организации Сеанса одноранговой связи. Ниже описаны варианты реализации механизма для того, чтобы можно было обмениваться этой информацией.
CDX - сервер (Сервер обмена соединительными данными) - CDX - сервер в одном варианте реализации изобретения представляет собой аутентифицированный отражатель группового вещания, который позволяет уполномоченным объектам обмениваться произвольными данными. Эти данные именуются как Полезные данные.
CDX - сеанс (Сеанс связи с обменом соединительными данными) - Термин "CDX - сеанс связи" относится к группе клиентских устройств, которые могут поддерживать связь друг с другом через CDX - сервер. Каждому клиентскому устройству, которое является участником этого сеанса связи, выдается CDX - билет (Билет на обмен соединительными данными). Каждый сеанс связи имеет уникальный идентификатор CDX - сеанса связи, который является большим целым числом, которое можно использовать для идентификации отдельного сеанса связи или ссылки на этот сеанс связи.
CDX - Запрос (Запрос обмена соединительными данными) - Запрос, который посылается из клиентского устройства на CDX - сервер. Запрос обычно состоит из двух частей: CDX - билета и Полезных данных. В этом варианте реализации изобретения полезные данные представляют собой Соединительные данные, зашифрованные посредством Ключа сеанса связи.
CDX - ответ - CDX - ответ представляет собой то, что "отражается" назад другим устройствам в ходе CDX - сеанса связи, когда CDX - сервер принимает CDX - запрос от участника CDX - сеанса связи. Он строится путем присоединения Полезных данных к Корешку CDX - билета от CDX - Билета, использованного в данном CDX - запросе.
CDX - билет - CDX - билет сообщает CDX - серверу о том, как отправить Полезные данные участникам CDX - сеанса связи. В одном варианте реализации изобретения этот билет "подписывается" Ключом CDX - билета для того, чтобы предотвратить подделку или фальсификацию. Как проиллюстрировано на Фиг.3, в одном варианте реализации изобретения, CDX - билет содержит нижеследующую информацию:
Идентификатор 301 сеанса связи, который в одном варианте реализации изобретения не является зашифрованным или скрытым.
Количество 302 участников сеанса связи, которое в одном варианте реализации изобретения не является зашифрованным или скрытым.
Индекс 303 того участника сеанса связи, к которому относится этот билет (не зашифрован или не скрыт в одном варианте реализации изобретения).
Время/дата 304 истечения срока действия, после которого билет считается недействительным (не зашифрованные или не скрытые в одном варианте реализации изобретения).
Данные 305-306 "проделывания прохода" через CDX - систему для каждого участника сеанса связи, зашифрованные, в одном варианте реализации изобретения, с использованием Ключа CDX - билета.
Код 307 аутентификации сообщения, использующий Ключ CDX - билета, который действует в качестве "Цифровой подписи" для гарантии того, что билет подлинный.
Корешок CDX - билета - Первая часть CDX - билета минус Данные "проделывания прохода" через CDX - систему и Код аутентификации сообщения.
Полезные данные - это вторая часть CDX - запроса и CDX - ответа. Полезные данные представляют собой данные, которые клиентское устройство желает сообщить другим устройствам в ходе CDX - сеанса связи. В этом варианте реализации изобретения полезные данные представляют собой Соединительные данные, зашифрованные посредством Ключа сеанса связи. В одном варианте реализации изобретения CDX- сервер не дешифрует полезные данные, он просто передает их дальше в неизменном виде.
Ключ сеанса связи - это ключ, используемый клиентами, для шифрования Соединительных данных. В одном варианте реализации изобретения этот ключ не известен CDX - серверу. В этом варианте реализации изобретения Ключ сеанса связи генерируется сервисом формирования сочетания и передается клиентам вместе с их индивидуальными CDX- билетами.
Ключ CDX - билета - Это - ключ, используемый для создания и "подписания" CDX - билетов. Ключ CDX - билета известен только CDX - серверу и сервису, который генерирует CDX - билеты - который, как было описано ниже, мог бы представлять собой сервис формирования сочетания и/или сервис приглашения.
Запрос на "проделывание прохода" через CDX - систему - специальный тип CDX запроса, который используется для того, чтобы получать от CDX - сервера Данные "проделывания прохода" через CDX - систему.
Данные "проделывания прохода" через CDX - систему - это непрозрачный "блоб" данных, который описывает то, как CDX - сервер может отправить информацию клиенту, который изначально ее запросил. Их получают, отправив CDX - серверу Запрос на "проделывание прохода" через CDX - систему. Данные "проделывания прохода" через CDX - систему должны быть собраны с каждого клиентского устройства в ходе CDX - сеанса связи прежде, чем могут быть сгенерированы CDX - билеты. Данные "проделывания прохода" через CDX - систему (иногда именуемые как "данные прохождения NAT - преобразования") могут включать в себя публичный IP - адрес и порт запрашивающего устройства.
Обратимся теперь к Фиг.2а, на которой в одном варианте реализации изобретения мобильное устройство А 120 и мобильное устройство В 121 могут исполнять некоторое совместно используемое приложение, такое как игра для нескольких игроков или совместный сеанс "чата" (диалога в реальном масштабе времени), которое требует однорангового соединения с одним или более другими вычислительными устройствами. На этапе 201а мобильное устройство 120 передает CDX - серверу 110 Запрос "проделывания прохода" через CDX - систему. После этого, на этапе 202a, CDX - сервер 110 отвечает, передавая Данные "проделывания прохода" через CDX - систему. В одном варианте реализации изобретения эти данные "проделывания прохода" включают в себя публичный IP - адрес и порт мобильного устройства (А) и/или любые другие данные, необходимые для "проделывания прохода" через NAT - систему мобильного устройства (A) (например, данные о типе NAT - преобразования, определяющие тип NAT - преобразования для мобильного устройства (А)). Аналогичные транзакции выполняются для мобильного устройства (В), соответственно, на этапах 201b и 202b.
После этого, на этапах 203а и 203b мобильные устройства (А) и (В) отправляют сервису формирования сочетания запросы сочетания, включающие в себя Данные "проделывание прохода" через CDX - систему, вместе с любыми дополнительными критериями сочетания (описываемыми ниже). На этой стадии мобильные устройства (А) и (B) могут начать создавать Соединительные данные, необходимые для установления одноранговой связи. Это может быть достигнуто, например, с использованием такой транзакции, как стандартная транзакция по установлению соединения в сети "Интернет" ("ICE - транзакция") (например, посредством сервиса прохождения NAT - преобразования). Однако, принципы, лежащие в основе изобретения, не ограничены никаким конкретным механизмом для определения соединительных данных.
В одном варианте реализации изобретения после того, как сервис 111 формирования сочетания определил набор клиентских устройств с критериями сочетания, он может сгенерировать уникальный Идентификатор CDX - сеанса связи, уникальный CDX- билет для каждого участника CDX - сеанса связи и уникальный Ключ сеанса связи. В одном варианте реализации изобретения сервис 111 формирования сочетания, может зашифровать Данные "проделывания прохода" через CDX - систему для CDX - билета, используя уникальный ключ - CDX билета. После этого, на этапах 204а и 204b, сервис формирования сочетания может затем отправить каждому из мобильных устройств (А) и (В) их CDX - билет и Ключ сеанса связи.
Мобильное устройство (А) принимает CDX - билет и Ключ сеанса связи и зашифровывает свои предварительно определенные Соединительные данные, используя этот Ключ сеанса связи, создавая Полезные данные. В одном варианте реализации изобретения мобильное устройство (А), присоединяя созданные Полезные данные к CDX - билету, составляет CDX - запрос. На этапе 205а мобильное устройство (А) отправляет CDX - серверу ПО CDX - запрос. Мобильное устройство (В) на этапе 205b также могло бы выполнить такие же операции и передать запрос CDX - серверу.
На этапе 206a CDX - сервер (ПО) принимает CDX - запрос, исследует билет дл того, чтобы убедиться, что он действительный и аутентичный (например, основываясь на коде 307 аутентификации сообщения). Если CDX - билет недействителен, то запрос удаляется. В одном варианте реализации изобретения CDX - сервер после этого, используя ключ CDX - билета, который содержится в CDX - билете, дешифрует набор Данных "проделывания прохода" через CDX систему. В одном варианте реализации изобретения ключ CDX - билета может включать в себя время/дату истечения срока действия, которые также могут быть переданы с билетами. CDX - сервис 110 и сервис 111 формирователя сочетания могут хранить два (или больше) различных ключей CDX - билета для шифрования/дешифрования: первый, который активен в текущее время, и второй, который станет активным после достижения времени/даты истечения срока действия первого ключа. После приема билета CDX - сервис 110 может прочитать время/дату истечения срока действия, определяя то, какой ключ билета, использовать. Когда срок действия ключа CDX - билета истек, как CDX - сервис (110), так и сервис 111 формирователя сочетания могут каждый сгенерировать новый ключ билета (который будет следующим ключом, подлежащим использованию после истечения срока действия текущего ключа билета). В одном варианте реализации изобретения CDX - сервис 110 и сервис 111 формирователя сочетания исполняют один и тот же алгоритм генерации ключа для того, чтобы гарантировать непротиворечивость между двумя ключами билета. Например, могут быть использованы технологии, такие как те, что используются для хорошо известного аутентификационного механизма RSA SecurlD (безопасной идентификации на основе шифрования методом Ривеста, Шамира и Адлемана), в котором новый аутентификационный код генерируется через постоянные промежутки времени. В одном варианте реализации изобретения новый ключ CDX - билета генерируется на ежедневной основе. Однако принципы, лежащие в основе изобретения, не ограничены никаким конкретным механизмом для генерирования ключей CDX - билета.
Те же самые операции могли бы быть выполнены, как показано на этапе 206b, для мобильного устройства В. CDX - сервер составляет CDX - ответ, исходя из CDX - запроса, и затем использует Данные "проделывания прохода" через CDX - систему для того, чтобы отправить CDX - ответ участникам CDX - сеанса связи (отправка мобильному устройству (В) на этапе 207а и мобильному устройству (А) на этапе 207b).
Мобильное устройство (В) принимает от CDX - сервера CDX - ответ 207 а. Клиентское устройство (В) исследует Корешок CDX - билета для обеспечения того, чтобы Идентификатор сеанса связи соответствовал Идентификатор сеанса связи своего собственного CDX - билета. После этого мобильное устройство (В) может дешифровать Полезные данные, используя Ключ сеанса связи, что дает Соединительные данные, поступившие от Мобильного устройства (А). После этого Мобильное устройство (В) использует Соединительные данные, поступившие от Мобильного устройства (А), для того, чтобы начать процесс организации сеанса одноранговой связи. В одном варианте реализации изобретения это включает в себя стандартные ICE - транзакции (транзакции по установлению соединения в сети "Интернет"). Однако принципы, лежащие в основе изобретения, не ограничены никаким конкретным механизмом для установления одноранговой связи.
Как было упомянуто выше, в одном варианте реализации изобретения мобильные устройства (А) и (В) для того, чтобы поддерживать связь с сервисом (111) формирователя сочетания, организуют сеансы связи по Протоколу защищенной передачи гипертекстов ("HTTPS - протоколу") (например, используя транзакции запроса/ответа по HTTPS - протоколу), а для поддержания связи с CDX - сервисом (110) устанавливают сокеты Протокола пользовательских дейтаграмм ("UDP - протокола"). Запросы 204а, 204b сочетания могут включать в себя тип NAT - преобразования и данные "проделывания прохода" (например, публичный IP - адрес и порт), предварительно определенные для каждого соответствующего мобильного устройства. В варианте реализации изобретения, который включает в себя игру для нескольких игроков, каждый запрос сочетания может идентифицировать игрока на каждом мобильном устройстве (например, используя уникальный идентификационный код игрока), игру, в которую хочет играть каждый пользователь, количество игроков, которое будет участвовать в игре, и/или другие переменные параметры конфигурации игры, связанные с требуемой игрой. В порядке примера, а не ограничения, отметим, что переменные параметры конфигурации игры, связанные с игрой, могут включать в себя уровень трудности (например, простой, нормальный, трудный), возраст пользователя (например, "младше 13"), подобласть игры (например, "уровень 2") и/или уровень мастерства игрока (например, мастер, новичок, промежуточный уровень). Как было подробно описано ниже, эти переменные иногда именуются как игровой "короб" и идентифицируются с использованием уникального "идентификатора короба". Каждая игра может включать в себя различные наборы идентификаторов "коробов" для идентификации различных переменных конфигурации игры.
В одном варианте реализации изобретения мобильное устройство (В) отправляет подтверждение на этапах 208а и 209а. Аналогичным образом на этапе 208b и 209b передается подтверждение мобильного устройства (А). Если подтверждения мобильного устройства (А) или (В) не получены после некоторого указанного промежутка времени, то соединительные данные 207а могут быть снова посланы мобильному устройству В 212. Инициировать повторную попытку может либо CDX - сервис 110 и/или инициировать повторную попытку может мобильное устройство А (120).
На Фиг.2b проиллюстрирован более детализированный пример, в котором три различных мобильных устройства 120-122 осуществляют согласование для одноранговых соединений, используя CDX - сервис и сервис 111 формирователя сочетания. На Фиг.2b также проиллюстрированы два дополнительных сервиса, используемых мобильными устройствами 120-122 для того, чтобы устанавливать связь: сервис 291 прохождения NAT - преобразования (преобразования сетевых адресов) для определения типа NAT - преобразования и сервис 290 прохождения NAT - преобразования для определения полных соединительных данных для каждого мобильного устройства (например, с использованием ICE - транзакции для соединительных данных). Следует, однако, отметить, что не требуется, чтобы отдельные сервисы удовлетворяли принципам, лежащим в основе изобретения. Например, в альтернативном варианте реализации изобретения функции прохождения NAT - преобразования, выполняемые каждым из этих сервисов 290-291, могут быть интегрированы непосредственно в рамках CDX - сервиса (110) и/или сервиса (111) формирователя сочетания. Аналогичным образом, функции, выполняемые обоими сервисами 290-291 прохождения NAT - преобразования, могут быть интегрированы в рамках единого сервиса прохождения NAT - преобразования. Таким образом, конкретное функциональное разделение, показанное на Фиг.2b, не требуется для удовлетворения принципам, лежащим в основе изобретения.
Обратимся теперь к конкретным деталям Фиг.2b, на которой на этапе 220 мобильное устройство (А) передает сервису 291 прохождения NAT - преобразования запрос о типе NAT - преобразования. В ответ на это, сервис 291 прохождения NAT - преобразования, может использовать различные известные технологии, включающие в себя осуществление последовательности транзакций для определения типа NAT - преобразования, используемого мобильным устройством (А). Например, сервис 291 прохождения NAT - преобразования может попытаться открывать различные IP - адреса и порты в NAT - системе мобильного устройства (А) и поддерживать связь с мобильным устройством (А) через эти порты, используя различные комбинации IP - адреса/порта. Таким образом, NAT - преобразование, используемое мобильным устройством (А), может быть классифицировано как один из типов NAT - преобразования, описанных выше (например, полное коническое, ограниченное коническое, ограниченное по порту коническое, симметричное), или альтернативный тип NAT - преобразования. Эта информация, как проиллюстрировано, может затем быть предоставлена мобильному устройству 120.
На этапе 221 мобильное устройство 120 инициирует запрос прохождения NAT - преобразования, адресованный CDX - сервису 110. В ответ на это, CDX - сервис 110 может считать публичный IP - адрес и публичный номер порта, используемые для этого запроса, и передает эту информацию назад мобильному устройству 120. Как было описано выше, если устройство находится позади NAT - системы, то ее публичные порт и IP - адрес будут отличаться от ее частных порта и IP - адреса, соответственно. Таким образом, в зависимости от типа используемого NAT - преобразования публичный IP - адрес и порт могут быть использованы для того, чтобы "проделать проход" через NAT - устройство (устройство преобразования сетевых адресов), чтобы достигнуть мобильного устройства.
На этапе 222 мобильное устройство А 120 передает сервису 111 формирователя сочетания запрос 222 сочетания. Как было описано выше, в одном варианте реализации изобретения мобильное устройство (А) поддерживает связь с сервисом 111 формирователя сочетания, используя сеансы связи по Протоколу защищенной передачи гипертекстов ("HTTPS - протоколу") (например, используя транзакции запроса/ответа по HTTPS - протоколу). Запрос сочетания может включать в себя тип NAT - преобразования (преобразования сетевых адресов) и данные "проделывания прохода" (например, публичный IP - адрес и порт), предварительно определенные для мобильного устройства А 120. В одном варианте реализации изобретения, который включает в себя игру для нескольких игроков, запрос сочетания может идентифицировать игрока на мобильном устройстве (А) (например, используя уникальный идентификационный код игрока), игру, в которую хочет сыграть пользователь, количество игроков, которое должно участвовать в игре, и/или другие переменные параметры конфигурации игры, связанные с требуемой игрой (как это было описано ранее в отношении Фигуры 2 а).
На этапах 223-225 набор транзакций, соответствующих транзакциям 220-222, выполняется для мобильного устройства В 121, а на этапах 226-228 набор транзакций, соответствующий транзакциям 220-222, выполняется для мобильного устройства С 122. Таким образом, после транзакции 228 сервис 111 формирователя сочетания получил запросы сочетания для всех трех мобильных устройств 120-122. В этом конкретном примере запросы сочетания приводят в результате к тому, что образуется сочетание мобильных устройств 120-122 для некоторого конкретного совместного сеанса связи, такого как игра для нескольких игроков (например, пользователи этих мобильных устройств, возможно, выбрали одну и ту же игру с одними и теми же или аналогичными наборами переменных, что в результате приводит к их сочетанию сервисом 111 формирователя сочетания).
Сервис 111 формирователя сочетания использует данные, содержащиеся в каждом из запросов сочетания, для того, чтобы сгенерировать Билет А, который он передает мобильному устройству (А) на этапе 229; Билет В, который он передает мобильному устройству (В) на этапе 230; и Билет С, который он передает мобильному устройству (С) на этапе 231. Хотя это и не показано на Фигуре 2b, сервис 111 формирователя сочетания может использовать сервис "проталкиваемых" (доставляемых посредством активной доставки) уведомлений для "проталкивания" Билетов А, В и С, соответственно, мобильным устройствам А, В и С (например, такой как сервис 1050 "проталкиваемых" уведомлений, проиллюстрированный на Фигурах 11-12). Один вариант реализации структуры данных билета, используемой для билетов А, В и С описан выше в отношении Фигуры 3.
На этапе 232 мобильное устройство А 120 осуществляет связь с сервисом 290 прохождения NAT - преобразования для того, чтобы определить свои собственные соединительные данные. В одном варианте реализации изобретения это может включить в себя стандартную ICE - транзакцию для соединительных данных. Как было упомянуто выше, соединительные данные могут включать в себя публичный/частный IP - адрес, порт и тип NAT - преобразования для мобильного устройства А 120.
Мобильное устройство А 120 присоединяет свои соединительные данные к Билету А и, на этапе 233, передает Билет А с соединительными данными CDX - сервису 110. В одном варианте реализации изобретения CDX - сервис 110 обрабатывает Билет А так, как это было описано выше, и, на этапе 234, передает эти соединительные данные (которые могут быть зашифрованы) мобильному устройству В 121 и мобильному устройству С 122. Для этих транзакций CDX - сервис 110 может использовать данные прохождения NAT - преобразования для мобильных устройств (В) и (С), включенные в состав Билета А.
На этапах 236-238 набор транзакций, соответствующих транзакциям 232-234 выполняется с использованием Билета В, а на этапах 238-240 набор транзакций, соответствующих транзакциям 232-234, выполняется для Билета С. Таким образом, после транзакции 240 между каждым из мобильных устройств 120-122 произошел обмен соединительными данными. С использованием этих соединительных данных, между мобильными устройствами (А) и (В), мобильными устройствами (А) и (С) и мобильными устройствами (А) и (С) организуются сеансы одноранговой связи.
Как проиллюстрировано на Фигуре 2с, сервис (112) приглашения также можно использовать с CDX - сервисом ПО (либо вместо, либо в дополнение к сервису 111 формирователя сочетания). В одном варианте реализации изобретения сервис 112 приглашения обрабатывает запросы приглашений для одноранговых соединений с конкретными мобильными устройствами и/или пользователями. Сервис 112 приглашения может быть реализован как сервис без запоминания состояний (то есть сервис, который не фиксирует текущий уровень транзакций между каждым из устройств беспроводной связи).
Если обратится к этому конкретному примеру, то на этапе 250 мобильное устройство А 120 передает сервису 291 прохождения NAT - преобразования запрос о типе NAT - преобразования (преобразования сетевых адресов). В ответ на это, сервис 291 прохождения NAT - преобразования может использовать различные известные технологии для определения типа NAT - преобразования, используемого мобильным устройством (А), (некоторые из которых были описаны выше). На этапе 251 мобильное устройство А 120 инициирует запрос прохождения NAT - преобразования, подаваемый CDX - сервису 110. В ответ на это, CDX - сервис 110 может считать публичный IP - адрес и публичный номер порта, используемые для этого запроса, и передает эту информацию назад мобильному устройству А 120. Как было описано выше, если устройство находится позади NAT - системы, его публичные номер порта и IP-адрес будут отличаться, соответственно, от его частных номера порта и IP-адреса. Таким образом, в зависимости от типа используемого NAT - преобразования публичный IP-адрес и порт могут быть использованы для того, чтобы "проделать проход" через NAT - устройство (устройство преобразования сетевых адресов), чтобы достигнуть мобильного устройства.
Как и в случае сервиса 111 формирователя сочетания, в одном варианте реализации - изобретения каждое из мобильных устройств поддерживает связь с сервисом 112 приглашения, используя сеансы связи по Протоколу защищенной передачи гипертекстов ("HTTPS - протоколу") (например, используя транзакции запроса/ответа по HTTPS - протоколу).
На этапе 252 мобильное устройство А 120 передает сервису 112 приглашения запрос с приглашением, который включает в себя данные прохождения NAT - преобразования для мобильного устройства (А) (например, тип NAT - преобразования, публичные IP - адрес/порт). В варианте реализации изобретения, который использует сервис "проталкиваемых" уведомлений (описываемый более подробно ниже), запрос с приглашением может также включать в себя маркер "проталкивания" для мобильного устройства (А). Запрос 252 с приглашением может также включать в себя идентификационный код, идентифицирующий одного или более других пользователей/устройств - в данном случае пользователей мобильных устройств В 121 и С 122. Могут быть использованы и различные другие типы идентификационных кодов. Например, в случае игры для нескольких игроков идентификационные коды могут содержать специфические для данной игры идентификационные коды игроков. В случае сеанса аудио/видео "чата" идентификационные коды могут содержать номера телефонов или уникальные идентификационные коды, идентифицирующие одного или более пользователей из списка контактов (контактных лиц) пользователя мобильного устройства (А).
В одном варианте реализации изобретения сервис 112 приглашения, для нахождения каждого из мобильных устройств (В) и (С), считывает идентификационные коды из запроса с приглашением и выполняет поиск в регистрационной базе данных (не показанной на чертеже). В одном конкретном варианте реализации изобретения каждое из мобильных устройств (В) и (С) были перед этим зарегистрированы в сервисе "проталкивания" (активной доставки) для того, чтобы получать "проталкиваемые" уведомления от сервиса 112 приглашения. Также, в этом варианте реализации изобретения сервис 112 приглашения использует сервис "проталкиваемых" уведомлений для того, чтобы "проталкивать" запросы с приглашением мобильному устройству В 121 и мобильному устройству С 122, соответственно, на этапах 253 и 254. Дополнительные подробности, относящиеся к сервису "проталкиваемых" уведомлений, описаны ниже (смотри, например, Фигуры 11-12 и связанный с ними текст), и в Заявке о "проталкиваемых" уведомлениях, ссылка на которую приводится выше.
В одном варианте реализации изобретения запросы 253 и 254 с приглашениями включают в себя структуру данных билета, проиллюстрированную на Фигуре 3, и описанную выше в отношении Фигур 2 а-b. В частности, билет, отправленный мобильному устройству (В), включает в себя зашифрованный список, идентифицирующий мобильные устройства (А) и (В), а билет, отправленный мобильному устройству (С), включает в себя зашифрованный список, идентифицирующий мобильные устройства (А) и (С). В одном варианте реализации изобретения, по причине того, что сервис 112 приглашения может еще не иметь данных прохождения NAT - преобразования для мобильного устройства (В), "билет" на этапе 253 может включать в себя другую информацию, идентифицирующую мобильное устройство (В). Например, как излагается ниже в отношении вариантов реализации изобретения, которые используют сервис ретрансляции и сервис "проталкиваемых" уведомлений (смотри, например, Фигуры 11-12), "билет" на этапе 253 может включать в себя данные прохождения NAT - преобразования для мобильного устройства (А), идентификационный код устройства (А), маркер "проталкивания" для устройства (А), идентификационный код устройства (В) и маркер "проталкивания" для мобильного устройства (В). Те же самые типы информации могут быть предоставлены на этапе 254 для мобильных устройств (А) и (С).
На этапе 255 мобильное устройство (В) может поддерживать связь с сервисом 291 прохождения NAT - преобразования для определения его типа NAT - преобразования, а на этапе 256 мобильное устройство (В) может поддерживать связь с CDX - сервисом 110 для определения своих данных прохождения NAT - преобразования (например, публичных IP - адреса/порта). На этапе 257 мобильное устройство (В) передает сервису 112 приглашения ответ на приглашение, содержащий идентификационный код мобильного устройства (А) и мобильного устройства (В), данные прохождения NAT - преобразования и, если используется сервис "проталкиваемых" уведомлений, то маркеры "проталкивания" для мобильных устройств (А) и (В). На этапе 258 мобильное устройство (В) может извлекать свои текущие соединительные данные, поддерживая связь с сервисом 290 прохождения NAT - преобразования. На этапе 259 мобильное устройство (В) передает свой билет (Билет В) со своими текущими соединительными данными CDX - сервису 110. В ответ на это, CDX - сервис 110 обрабатывает этот билет так, как это было описано выше, и пересылает эти соединительные данные мобильному устройству А 120.
После получения ответа на приглашение, поступившего от мобильного устройства (В), сервис 112 приглашения может сгенерировать зашифрованный билет для мобильного устройства (А) и на этапе 260 передать этот билет мобильному устройству. В одном варианте реализации изобретения этот билет включает в себя данные прохождения NAT - преобразования, тип NAT - преобразования и маркер "проталкивания" (в том, случае, если используется сервис "проталкиваемых" уведомлений) для мобильных устройств (А) и (В). "Билеты", описанные в отношении Фигуры 2с, могут быть теми же самыми или отличными от структур данных для "билетов", описанных в отношении сервиса 111 формирователя сочетания. Например, вместо того, чтобы генерировать зашифрованный "билет", как это было описано выше, сервис 112 приглашения может просто сгенерировать уникальный идентификатор сеанса связи, предназначенный для идентификации сеанса связи приглашения с каждым из мобильных устройств.
На этапе 261 мобильное устройство (А) извлекает свои текущие соединительные данные, поддерживая связь с сервисом 290 прохождения NAT - преобразования. После этого мобильное устройство (А) может присоединить свои соединительные данные к билету и, на этапе 262, передать билет со своими соединительными данными CDX - сервису 110. CDX - сервис ПО обрабатывает билет так, как это было описано выше, и пересылает соединительные данные мобильного устройства (А) мобильному устройству (В). Наконец, на этапе 263, мобильные устройства (А) и (В) используют соединительные данные, которыми они обменялись, для открытия прямого однорангового соединения. Как было описано ниже, в случаях, при которых типы NAT - преобразования мобильного устройства (А) и (В) несовместимы, для того, чтобы сделать возможным связь между мобильными устройствами (А) и (В), можно использовать сервис ретрансляции.
На этапах 264-272 мобильное устройство С 122 и мобильное устройство (А) могут исполнить ряд транзакций для установления однорангового соединения так, как это было описано на этапах 255-263 для мобильных устройств (В) и (А). В частности, на этапе 624, мобильное устройство С 122 поддерживает связь с сервисом 291 прохождения NAT - преобразования для определения его типа NAT - преобразования и на этапе 265 поддерживает связь с CDX - сервисом ПО для определения своих данных прохождения NAT - преобразования (например, публичных IP - адреса/порта). На этапе 266 мобильное устройство (С) передает ответ на приглашение, содержащее тип NAT - преобразования для мобильного устройства (С) и мобильного устройства (А), данные прохождения NAT - преобразования и маркер "проталкивания" (в случае, если используется сервис "проталкиваемых" уведомлений). На этапе 267 мобильное устройство (С) извлекает свои текущие соединительные данные через одноранговый сервис 290 прохождения NAT - преобразования, и на этапе 268 мобильное устройство (С) присоединяет свои соединительные данные к Билету С и передает Билет С CDX - сервису 110. CDX - сервис 110 обрабатывает этот билет так, как это было описано выше, и пересылает соединительные данные мобильного устройства (С) мобильному устройству 120.
На этапе 269 мобильное устройство 120 принимает от сервиса 112 приглашения ответ на приглашение, поступивший от мобильного устройства (С), который включает в себя тип NAT - преобразования для обоих мобильных устройств (А) и (С), данные прохождения NAT - преобразования и маркер "проталкивания" (в случае, если используется сервис "проталкивания"). На этапе 270 мобильное устройство (А) извлекает свои текущие соединительные данные из сервиса 290 прохождения NAT - преобразования, присоединяет свои текущие соединительные данные к Билету А и на этапе 271 передает Билет A CDX - сервису 110. В качестве альтернативы, транзакция 270 может не требоваться, потому что мобильное устройство определило свои соединительные данные в ходе транзакции 261. CDX - сервис ПО обрабатывает Билет А так, как это было описано выше, и пересылает соединительные данные мобильного устройства (А) мобильному устройству (С). Наконец, на этапе 272 мобильные устройства А и С используют соединительные данные, которыми они обменялись, для установления прямого однорангового соединения 272.
В одном варианте реализации изобретения сервис 112 приглашения и сервис 111 формирователя сочетания могут для "проталкивания" данных полагаться на сервис "проталкиваемых" уведомлений (не показанный на чертеже). Например, на Фигуре 2с запросы 253 и 254с приглашениями могут "проталкиваться" к мобильным устройствам В 121 и С 122 через сервис "проталкиваемых" уведомлений. Аналогичным образом, на Фигуре 2а билеты А и В могут "проталкиваться" к мобильным устройствам А 120 и В 121. В одном варианте реализации изобретения, когда мобильное устройство активируется в сети, оно регистрирует свой маркер "проталкивания" в центральном регистрационном каталоге, к которому имеет доступ сервис "проталкиваемых" уведомлений. В одном варианте реализации изобретения этот регистрационный каталог ассоциативно связывает с маркером "проталкивания" защищенный паролем пользовательский идентификатор или номер телефона. Если маркер "проталкивания" может быть идентифицирован в каталоге, то сервис "проталкиваемых" уведомлений может использовать этот маркер "проталкивания" для передачи мобильному устройству "проталкиваемых" уведомлений. В одном варианте реализации изобретения сервис "проталкиваемых" уведомлений представляет собой Сервис "проталкиваемых" уведомлений, принадлежащий Apple ("APNS - сервис"), разработанный правообладателем по данной заявке и описанный, например, в Заявке о "проталкиваемых" уведомлениях, упомянутой выше. Следует, однако, отметить, что сервис "проталкиваемых" уведомлений не является обязательным требованием в вариантах реализации изобретения, показанных на Фигурах 2а - с. Например, проталкиваемые уведомления не требуются для CDX сервиса НО, чтобы он выполнял свои операции, как здесь описано.
На Фигуре 4 проиллюстрирован способ, который может быть осуществлен CDX - сервисом 110 для обмена соединительными данным, а на Фигуре 5 проиллюстрирован способ, который может быть осуществлен мобильным устройством для обмена соединительными данными и установления однорангового соединения. Некоторые аспекты этих способов были уже описаны выше в отношении Фигур 1-2с. В частности, эти способы могут быть осуществлены в рамках контекста сетевой архитектуры, показанной на Фигурах 1-2с, но они не ограничены такого рода архитектурой. В одном варианте реализации изобретения эти способы воплощены в коде программы, который при исполнении его процессором, заставляет выполняться операции этих способов. Код программы, будучи исполняемый процессором, может храниться на машиночитаемом носителе информации, таком как оперативное запоминающее устройство ("ОЗУ"). Процессор может представлять собой универсальный процессор (например, процессор Intel® Core™) или специализированный процессор. Однако эти способы могут быть осуществлены с использованием любой комбинации аппаратного обеспечения, программного обеспечения и программно - аппаратного обеспечения. Кроме того, код программы может храниться на энергонезависимом запоминающем устройстве, таком как накопитель на жестком магнитном диске, оптический диск (например, Цифровой видеодиск или Компакт - диск), или в энергонезависимой памяти, такой как устройство с флэш - памятью.
Обратимся теперь к способу, показанному на Фигуре 4, на которой на этапе 401, для некоторого конкретного мобильного устройства, в этом примере - "мобильного устройства (А)", принимается запрос прохождения NAT - преобразования (преобразования сетевых адресов) (также иногда именуемый как запрос "проделывания прохода"). На этапе 402 генерируется ответ о прохождении NAT - преобразования и передается мобильному устройству (А). В одном варианте реализации изобретения генерирование ответ о прохождении NAT - преобразования может включать в себя определение текущих публичных IP - адреса/порта и/или типа NAT - преобразования для мобильного устройства (А).
Вслед за этим объект, генерирующий билеты, такой как описанные выше сервис 111 формирователя сочетания или сервис 112 приглашения, может сгенерировать и зашифровать билет для мобильного устройства (А). На этапе 403 осуществляется прием билета, сгенерированного для мобильного устройства (А), ("Билет А"), который включает в себя данные прохождения NAT - преобразования (для устройства (А) и одного или более других устройств) и соединительные данные для устройства (А). На этапе 404 осуществляется аутентификация этого билета с использованием кода аутентификации сообщения, и данные "проделывания прохода" дешифруются с использованием того же самого ключа CDX - билета, что и ключ, используемый объектом, генерирующим билеты, для шифрования этого билета. Как было упомянуто выше, в одном варианте реализации изобретения правильный ключ CDX - билета идентифицируется с использованием времени/даты истечения срока действия, связанных с этим ключом CDX - билета.
На этапе 405 извлекаются данные прохождения NAT - преобразования для мобильных устройств. На этапе 406 соединительные данные для мобильного устройства (А) передаются, с использованием данных прохождения NAT - преобразования, каждому из одноранговых устройств. На этапе 407 от каждого из одноранговых устройств принимаются подтверждения. Если на этапе 408 определено, что подтверждения от всех одноранговых устройств приняты не были, то соединительные данные мобильного устройства (А) повторно передаются тем одноранговым устройствам, которые не ответили на этапе 409. Когда на этапе 408 определено, что получены подтверждения по всем соединительным данным, способ завершается.
В одном варианте реализации изобретения способ, показанный на Фигуре 4, может быть выполнен для каждого из одноранговых устройств, вовлеченных в эту одноранговую транзакцию, для обеспечения того, чтобы каждое одноранговое устройство получило соединительные данные, требующиеся для установления однорангового соединения.
На Фигуре 5 проиллюстрирован способ, который может быть выполнен мобильным устройством в соответствии с описанными здесь вариантами реализации изобретения. На этапе 501 передается запрос прохождения NAT - преобразования (преобразования сетевых адресов), а на этапе 502 принимается ответ о прохождение NAT - преобразования. Как было описано ранее, данные прохождение NAT - преобразования, содержащиеся в этом ответе могут включать в себя публичные порт/IP - адрес запрашивающего устройства. На этапе 503 передается запрос сочетания, который содержит данные прохождение NAT - преобразования. Вслед за этим объект, генерирующий билеты, такой как описанные выше сервис 111 формирователя сочетания или сервис 112 приглашения, может сгенерировать и зашифровать билет для мобильного устройства. В качестве альтернативы структуре данных билета, описанной выше, сервис 111 формирователя сочетания и/или сервис 112 приглашения могут просто идентифицировать каждого из участников, используя уникальный идентификатор сеанса связи.
На этапе 504 этот билет может быть принят; на этапе 505 к билету присоединяются соединительные данные для мобильного устройства; и на этапе 506 осуществляется передача билета с соединительными данными. На этапе 507 принимаются соединительные данные, необходимые для установления одноранговых соединений с одним или более другими одноранговыми устройствами. На этапе 508 принимаются подтверждения, указывающие, что одно или более других устройств беспроводной связи приняли соединительные данные, переданные на этапе 506. Если все подтверждения не приняты, то на этапе 510 соединительные данные повторно передаются тем мобильным устройствам, от которых не были получены подтверждения. Если на этапе 509 определено, что все подтверждения приняты, то соединительные данные, принятые на этапе 507, используются для организации сеансов одноранговой связи с другими мобильными устройствами.
Устройство и способ для создания и использования резервных каналов связи Существующие на сегодняшний день мобильные устройства способны поддерживать связь по большому разнообразию различных каналов связи. Например, устройство Apple iPhone™ способно поддерживать связь по сетям Wi-Fi (например, сетям стандартов 802.11 b, r, n); сетям 3G (третьего поколения) (например, сетям Универсальной системы мобильной связи ("UMTS - сетям"), по высокоскоростным спутниковым сетям пакетного доступа ("HSUPA - сетям") и так далее); и по сетям Bluetooth (известным как персональные сети ("PAN - сети")). Будущие мобильные устройства будут способны поддерживать связь по дополнительным каналам связи, таким как, например, сеть WiMAX, Усовершенствованная сеть международной мобильной телекоммуникации ("ГМТ") и Усовершенствованная сеть долгосрочного развития ("LTE"). При работе существующие на сегодняшний день мобильные устройства выбирают из числа набора располагаемых каналов один основной канал связи. Например, мобильные устройства часто сконфигурированы таким образом, чтобы выбирать соединение Wi - Fi, если оно доступно, и выбирать соединение сотовой системы передачи данных (например, соединение UTMS), если Wi - Fi не доступен.
В одном варианте реализации изобретения группа мобильных устройств первоначально создает первичные одноранговые ("Р2Р") каналы связи, используя стандартные обмены соединительными данными по протоколу ICE и/или используя технологии обмена соединительными данными, описанные выше. После этого мобильные устройства могут обменяться соединительными данными по первичным каналам для того, чтобы создать один или более вторичных каналов связи, которые используются в качестве резервных каналов, если какой-либо из первичных каналов неисправен. В одном варианте реализации изобретения вторичные каналы связи поддерживаются открытыми через брандмауэры (межсетевые экраны) NAT - преобразования, периодически передавая по этим каналам пакеты "сердцебиения" (пакеты, подтверждающие работоспособность этих каналов).
Термин "канал связи", в том значении, в котором он здесь используется, относится к полному сетевому пути между двумя мобильными устройствами, а термин "линия" связи относится к одному конкретному соединению, используемому на пути связи. Например, если устройство (А) соединено с сетью "Интернет" с использованием соединения Wi - Fi, а устройство (В) соединено с сетью "Интернет" с использованием 3G - соединения, то "канал" между устройством А и устройством (В) определен как линией Wi - Fi, так и линией 3G; устройство А имеет "линию" связи Wi - Fi; а устройство (В) имеет "линию" связи 3G. По существу, если устройство (А) переключается с линии Wi - Fi на линию 3G, то "канал" между устройством (А) и устройством (В) изменяется, несмотря на тот факт, что линия связи 3G для устройства (В) остается той же самой.
Теперь со ссылкой на Фигуру 6 будут описаны конкретные примеры, в которых мобильные устройства создают первичный и вторичный каналы связи. Следует, однако, отметить, что принципы, лежащие в основе изобретения, не ограничены конкретным набором линий связи и каналов связи, который показан на Фигуре 6.
На Фигуре 6 мобильное устройство А 601 способно соединяться с сетью 610 (например, сетью "Интернет") по линии 605 связи с NAT - устройством (устройством преобразования сетевых адресов) 611, а по линии 606 связи с NAT - устройством 612. Аналогичным образом, устройство С 603 способно соединяться с сетью 610 по линии 609 связи с NAT - устройством 613 и по линии 610 связи с NAT - устройством 613. В порядке примера, а не ограничения, отметим, что линии 605 и 609 связи могут представлять собой линии связи 3G, а линии 606 и 610 связи могут представлять собой линии связи Wi-Fi.
Следовательно, в этом примере имеется четыре различных канала связи, которые могут быть созданы между мобильным устройством (А) и мобильным устройством (В): первый канал, который использует линии 605 и 609 связи; второй канал, который использует линии 605 и 610 связи; третий канал, который использует линии 606 и 609 связи; и третий канал, который использует линии 606 и 610 связи. В одном варианте реализации изобретения мобильные устройства (А) и (В), основываясь на схеме назначения приоритетов, выберут один из этих каналов в качестве первичного канала связи и выберут три оставшиеся канала в качестве резервных каналов связи. Например, одна схема назначения приоритетов может заключаться в том, чтобы выбирать канал с самой большой шириной полосы пропускания в качестве первичного канала и использовать оставшиеся каналы в качестве вторичных каналов. Если два или более канала имеют сопоставимую ширину полосы пропускания, схема назначения приоритетов может включать в себя выбор наименее дорогого канал (предполагая, что пользователь вносит плату за использование этого одного или более каналов). В качестве альтернативы, схема назначения приоритетов может заключаться в том, чтобы выбирать в качестве первичного канала наименее дорогой канал, а, если стоимость каждого канала является одной и той же, то выбирать канал с самой большой шириной полосы пропускания. Могут быть реализованы и различные другие схемы назначения приоритетов, притом чтобы по-прежнему удовлетворялись принципы, лежащие в основе изобретения.
Для создания первичного канала связи мобильные устройства А 601 и С 603 могут использовать технологии, описанные выше (например, обмениваясь соединительными данными через CDX - сервис 110). В качестве альтернативы, для обмена соединительными данными мобильные устройства 601, 603 могут осуществлять стандартные транзакции по установлению соединения в сети "Интернет" ("ICE - транзакции"). Независимо от того, каким образом создан первичный канал, как только он создан, мобильные устройства А 601 и С 603 могут обмениваться соединительными данными для вторичных каналов связи по первичному каналу связи. Например, если первичный канал связи, показанный на Фигуре 6, включает в себя линию 606 связи и линию 609 связи, то это соединение, будучи установленным, может быть использовано для обмена соединительными данным для вторичных каналов связи, которые включают в себя линии 605 и 609 связи. В этом примере соединительные данные, обмен которыми осуществляется по первичному каналу связи, могут включать в себя данные прохождения NAT - преобразования (преобразования сетевых адресов) и данные о типе NAT - преобразования для NAT - устройства 611 и NAT - устройства 613, включающие в себя публичные и частные IP - адреса/порты для каждого из мобильных устройств.
После того как вторичные каналы связи созданы, они поддерживаются открытыми с использованием пакетов "сердцебиения". Например, устройство (А) может периодически передавать небольшой пакет "сердцебиения" на устройство (С), и/или устройство (А) может периодически передавать небольшой пакет "сердцебиения" на устройство (С) для обеспечения того, чтобы порты NAT - устройств, используемые для вторичных каналов, оставались открытыми (NAT - устройства часто закрывают порты по причине бездействия). Пакеты "сердцебиения" могут представлять собой UDP - пакеты (пакеты по Протоколу пользовательских дейтаграмм) без полезных данных, хотя принципы, лежащие в основе изобретения, не ограничены никаким конкретным форматом пакета. Пакеты "сердцебиения" могут представлять собой UDP - пакеты с полем самоидентифицирующегося типа в их заголовке полезных данных, и может содержать необязательную дополнительно отформатированную информацию, включающую в себя значение времени существования канала, но не ограничивающуюся им.
Как проиллюстрировано на Фигуре 7, каждое мобильное устройство 601 хранит и поддерживает структуру 710 данных (например, таблицу, текстовый файл, базу данных и так далее), содержащую список первичных и вторичных каналов связи. Отдельная запись предусматривается для каждого канала связи и включает в себя соединительные данные, необходимые для использования этого канала (например, частный/публичный IP - адрес, тип NAT - преобразования и так далее), и текущий статус этого канала (например, первичный, вторичный 1, вторичный 2 и так далее).
В одном варианте реализации изобретения, для поддержания связи по линии 605 связи и линии 606 связи используются, соответственно, связные интерфейсы 701 и 702. На мобильном устройстве 601 может быть выполнен модуль 705 обнаружения неисправности, предназначенный для обнаружения того, когда некоторый конкретный связной интерфейс/линия связи отказал или ухудшились ниже некоторого указанного порога. В ответ на это, модуль 706 управления линиями связи может считать соединительные данные 710 первичного/вторичного канала с тем, чтобы сделать вторичный канал, имеющий следующий высший приоритет, первичным каналом. Система приоритетов вторичных каналов может быть выполнена с использованием тех же самых принципов как те, что рассмотрены выше для первичных каналов (например, основанных на ширине полосы пропускания, стоимости, надежности и так далее). Как только вторичный канал выбран, модуль 706 управления линиями связи может передать сигнал неисправности линии связи модулям управления линиями связи, имеющимся на других мобильных устройствах, отдавая этим устройствам команду сделать этот вторичный канал связи первичным каналом связи. После этого эти устройства начнут использовать соединительные данные, связанные с выбранным первичным каналом.
В одном варианте реализации изобретения, для понуждения к переключению на один из вторичных каналов связи не требуется полный "отказ" первичного канала связи. Например, в одном варианте реализации изобретения, если первичный канал связи ухудшился в достаточной мере (например, ниже некоторого конкретного порогового значения ширины полосы пропускания, скорости передачи битов или надежности), то может быть реализовано переключение на вторичный канал связи, которое здесь описано. В одном варианте реализации изобретения переключение на вторичный канал выполняется только в том случае, если этот вторичный канал способен поддерживать более хорошую рабочую характеристику (например, ширину полосы пропускания, скорость передачи битов или надежность), чем первичный канал, использовавшийся на текущий момент времени.
На Фигуре 8а проиллюстрирована та же самая конфигурацию сети, как та, что показана на Фигуре 6, с добавлением к ней мобильного устройства В 602, соединенного непосредственно с сетью 610 и соединенное с устройством С 603 через соединение 620 частной сети. Частная сеть 620 может, например, представлять собой соединение Bluetooth частной сети между устройством В 602 и устройством С 603. Из этого примера можно видеть, что, переключая первичный канал на вторичный канал, можено коренным образом изменить топологию сети. Например, как показано на Фигуре 8b, если первичные каналы 801 для мобильных устройств включают в себя линию 609 связи (что в результате приводит к прямым соединениям между устройствами (А), (В) и (С)), а вторичные каналы включают в себя частную сеть 620, то топология сети может измениться так, как это проиллюстрировано на Фигуре 8с, поскольку единственный путь, для того, чтобы устройство (А) и устройство (С) поддерживали связь с использованием этой частной сети, лежит через устройство (В). Хотя это является упрощенным примером только с тремя устройствами, может быть использовано значительно большее количество устройств, что в результате приведет к большому разнообразию различных конфигураций топологии сети при переключении между первичным и вторичным каналами связи.
Один вариант реализации способа для создания и поддержания вторичных каналов проиллюстрирован на Фигуре 8. В одном варианте реализации изобретения этот способ может исполняться модулем 706 управления линиями связи на каждом мобильном устройстве. Однако этот способ не ограничен никакой конкретной конфигурацией устройств.
На этапе 901 выбирается первичный одноранговый канал связи. Как было упомянуто выше, первичный канал может быть выбран на основе некоторой предварительно заданной схеме назначения приоритетов. Например, определенные типы каналов связи могут быть расположены по приоритету выше других типов каналов связи. Каналам могут также быть расположены по приоритету на основе таких переменных, как ширины полосы пропускания, стоимость использования и/или надежность.
На этапе 902 создаются резервные одноранговые каналы связи. В одном варианте реализации изобретения это достигается путем обмена соединительными данными между всеми мобильными устройствами по первичному каналу связи. На этапе 903 поддерживается функционирование резервных каналов. В одном варианте реализации изобретения это включает в себя периодическую передачу данных по вторичным каналам связи (например, в форме периодически передаваемых пакетов "сердцебиения" (пакетов, подтверждающих работоспособность этих каналов)).
На этапе 904, если первичный одноранговый канал выходит из строя (например, по причине того, что линия связи некоторого конкретного мобильного устройства ухудшилась или мобильное устройство переместилось вне зоны досягаемости линии связи), то на этапе 905 мобильные устройства делают резервный канал, имеющий наивысший приоритет, первичным каналом. В одном варианте реализации изобретения это включает в себя то, что мобильное устройство с вышедшей из строя линией связи передает по вторичному каналу уведомление об отказе своей линии связи на другие устройства. Наконец, на этапе 906 резервный канал делают первичным каналом и процесс возвращается на этап 902 (на котором находят какие-либо дополнительные резервные каналы и добавляют их в схему назначения приоритетов).
Устройство и способ для сервиса приглашения для создания одноранговых (Р2Р) каналов связи
Как проиллюстрировано на Фигуре 10, в дополнение к CDX - сервису ПО, сервису 111 формирователя сочетания и сервису 112 приглашения (некоторые варианты реализации которых описаны выше), один вариант реализации изобретения может включать в себя сервис 1052 регистрации/каталога, сервис 1050 "проталкиваемых" уведомлений и сервис 1051 ретрансляции. Как было упомянуто выше, в одном варианте реализации изобретения сервис 112 приглашения и/или сервис 111 формирователя сочетания могут использовать сервис 1052 регистрации/каталога для того, чтобы идентифицировать зарегистрированные мобильные устройства, а сервис 1050 "проталкиваемых" уведомлений - для того, чтобы "проталкивать" данные к мобильным устройствам. В одном варианте реализации изобретения, когда мобильное устройство активируется в сети, оно регистрирует "маркер проталкивания" (иногда именуемый как "идентификатор учетной записи сервиса уведомлений" в Заявке о "проталкиваемых" уведомлениях) в базе данных, поддерживаемой сервисом 1052 регистрации/каталога, ассоциативно связывая маркер "проталкивания" с защищенным паролем пользовательским идентификатором или номером телефона. Если маркер "проталкивания" идентифицирован в регистрационном каталоге (например, при выполнении запроса с пользовательским идентификатором), сервис 1050 "проталкиваемых" уведомлений может использовать этот маркер "проталкивания" для передачи "проталкиваемых" уведомлений мобильному устройству. В одном варианте реализации изобретения сервис "проталкиваемых" уведомлений представляет собой Сервис "проталкиваемых" уведомлений, принадлежащий Apple ("APNS - сервис"), разработанный правообладателем по данной заявке и описанный, например, в Заявке о "проталкиваемых" уведомлениях, упомянутом выше.
На Фигуре 11 проиллюстрирован вариант реализации изобретения, в котором сервис 1051 "проталкиваемых" уведомлений используется для установления прямого однорангового соединения между двумя мобильными устройствами, а на Фигуре 12 проиллюстрирован вариант реализации изобретения, который используется для установления однорангового соединения через сервис 1051 ретрансляции. Как было описано ниже, решение относительно того, использовать ли сервис 1051 ретрансляции для установления однорангового соединения, может основываться на возможности установления между мобильными устройствами прямого однорангового соединения (например, может основываться на вопросах совместимости NAT - преобразования).
Обратимся теперь к Фигуре 11, на которой, на этапе 1101 мобильное устройство А 120 передает приглашение, приглашающее мобильное устройство В 121 к сеансу одноранговой связи (например, к совместной видеоигре, одноранговому видеочату (видеодиалогу) и так далее). В одном варианте реализации изобретения приглашение включает в себя Пользовательский идентификационный код, идентифицирующий мобильное устройство В 121 (и/или пользователя мобильного устройства (В)) в рамках контекста некоторого конкретного онлайнового приложения. Например, пользовательский идентификационный код может представлять собой идентификатор игрока для конкретной одноранговой игры для нескольких игроков и может принимать форму, например, Универсальный уникальный идентификатор (UUID - идентификатор). В качестве альтернативы, в некоторых вариантах реализации изобретения идентификационный код может быть телефонным номером мобильного устройства В 121. Для идентификации игры для нескольких пользователей, к которой мобильное устройство (А) приглашает присоединиться мобильное устройство (В), может быть использован идентификационный код игры. Для идентификации конфигурации параметров для этой игры может быть использован Идентификатор "короба" (как было здесь описано в отношении сервиса формирователя сочетания).
Приглашение 1101 может также включать в себя идентификационный код, идентифицирующий мобильное устройство А 120, и данные прохождения NAT - преобразования/соединительные данные, связанные с мобильным устройством (А), (например, публичные/частные IP - адреса и порты для мобильного устройства (А) и тип NAT - преобразования для NAT - устройства, относящегося устройству (А)). Данные прохождения NAT - преобразования/соединительные данные или данные о типе NAT - преобразования могли быть предварительно определены мобильным устройством (А) перед запросом 1101 с приглашением (например, посредством прохождения NAT - преобразования, транзакций, относящихся к типу NAT - преобразования и соединительным данным, таким как те, что были рассмотрены выше в отношении Фигур 2а - с). Как было упомянуто ранее, запрос 1101 с приглашением может принимать форму HTTPS - запроса (Запроса по Протоколу защищенной передачи гипертекстов). Кроме того, для дополнительной безопасности, запрос 1101 с приглашением может включить в себя сертификат клиента, подписанный предварительно указанным центром сертификации.
Независимо от конкретного типа кода, используемого для идентификации мобильного устройства (В), этот идентификационный код принимается сервисом 112 приглашения, и, на этапе 1102, сервис 112 приглашения может выполнить поиск в сервисе 1052 каталога (не показанном на Фигуре 11) для идентификации идентификатора учетной записи сервиса уведомлений, такого как маркер "проталкивания", используемый для "проталкивания" уведомлений к мобильному устройству (В) ("маркер - В - проталкивания"). В одном варианте реализации изобретения операции поиска могут выполнить несколько проверок, определяющих то, следует ли разрешить это приглашение. Сначала, операция поиска может подтвердить то, что идентификационный код для мобильного устройства (A) ("ID - А") и маркер "проталкивания" для устройства (А) ("маркер - А - проталкивания") представляют собой зарегистрированную ассоциацию в рамках базы данных сервиса каталога. Операция 1102 поиска может также подтвердить то, что пользователю мобильного устройства (А) разрешено приглашать пользователя мобильного устройства (В) (например, пользователь мобильного устройства (В) может указать, что приглашать пользователя (В) могут только те другие пользователи, которые зарегистрированы как друзья пользователя (В); или может указать, что никакие приглашения не разрешаются). В одном варианте реализации изобретения, если какая-либо из этих проверок терпит неудачу, то приглашение аннулируется, и сервис 112 приглашения возвращает мобильному устройству (А) сообщение об ошибке.
Следует отметить, что хотя в этом варианте реализации изобретения описан "маркер проталкивания", принципы, лежащие в основе изобретения, не ограничены использованием "маркера проталкивания" или какой-либо другой конкретной структурой данных для аутентифицикации и "проталкивания" уведомлений мобильным устройствам.
В одном варианте реализации изобретения после того, как маркер "проталкивания" был идентифицирован, сервис 112 приглашения может сгенерировать защищенный одноразовый "маркер сеанса связи", назначаемый этому сеанс связи по приглашению и используемый для идентификации этого сеанса связи во всех последующих транзакциях. После этого копия маркера сеанса связи передается в обратном направлении мобильному устройству А 120 и отправляется мобильному устройству (В) с запросом с приглашением. В одном варианте реализации изобретения маркер сеанса связи используется вместе с описанной выше структурой данных билета, а в другом варианте реализации изобретения используется только маркер сеанса связи.
На этапе 1103 сервис 112 приглашения передает сервису 1050 "проталкиваемых" уведомлений запрос "проталкивания". В одном варианте реализации изобретения запрос "проталкивания" может включать в себя данные прохождения NAT - преобразования для мобильного устройства (А), идентификационный код устройства (А), "маркер - А - проталкивания", идентификационный код устройства (В) и "маркер - В - проталкивания". В одном варианте реализации изобретения эта информация может быть упакована внутри структуры данных "билета" и зашифрована так, как описано выше. В другом варианте реализации изобретения эти данные просто передаются вместе с идентификатором сеанса связи по приглашению.
Поскольку мобильное устройство В 121 в этом примере зарегистрировано в сервисе 1050 "проталкиваемых" уведомлений, то сервис 1050 "проталкиваемых" уведомлений способен на этапе 1104 найти мобильное устройство В 121 и "протолкнуть" к нему запрос с приглашением. "Проталкиваемое" приглашение 1104 может включать в себя маркер сеанса связи, данные прохождения NAT - преобразования/соединительные данные мобильного устройства (А), и идентификационный код мобильного устройства (В). В ответ на запрос с приглашением, мобильное устройство (В) может определить свою информацию подключения сети (например, данные прохождения NAT - преобразования/ соединительные данные, тип NAT - преобразования и так далее), обратившись к сервису прохождения NAT - преобразования или CDX - сервису 110 (сервису обмена соединительными данными), как это было описано выше.
На этапе 1105 мобильное устройство (В) дает согласие на приглашение. Согласие 1105 может принимать форму вызова по HTTPS - протоколу (Протоколу защищенной передачи гипертекстов) в сервис 112 приглашения и может включать в себя сертификат клиента, подписанный предварительно указанным центром сертификации (упомянутым выше в отношении запроса с приглашением). В одном варианте реализации изобретения согласие 1105 может включать в себя идентификационный код для мобильных устройств (А) и данных прохождения NAT - преобразования/соединительные данные и/или тип NAT - преобразования для мобильных устройств (А) и (В). Согласие 1105 может также включать в себя маркеры "проталкивания" для мобильных устройств (А) и (В) и/или маркер сеанса связи. В одном варианте реализации изобретение согласие 1105 может также содержать указание на то, является ли это повторной попыткой после предыдущей неудавшейся попытки прямого соединения. Однако в другом варианте реализации изобретения согласие 1105 не содержит указания на повторную попытку. Наоборот, после обнаружения неудавшейся попытки однорангового соединения, одно из этих двух мобильных устройств может передать сервису 112 приглашения специальное "приглашение к ретрансляции". В ответ, этот сервис может напрямую инициировать последовательность ретрансляционных транзакций, описываемых ниже в отношении Фигуры 12 (начиная с этапа 1201).
На этапе 1106 сервис 112 приглашения может выполнить проверку совместимости для определения того, осуществимо ли прямое одноранговое соединение между мобильными устройствами (А) и (В). Например, в одном варианте реализации изобретения, если согласие 1105, принятое от мобильного устройства (В), указывает, что это - повторная попытка после предыдущей неудавшейся попытки прямого соединения (или после некоторого указанного количества предыдущих неудавшихся попыток прямого соединения), то сервис приглашения может прийти к заключению, что прямое одноранговое соединение неосуществимо. Сервис 112 приглашения может сравнить данные о типе NAT - преобразования для мобильных устройств (А) и (В) для того, чтобы определить, будут ли NAT - устройства (устройства преобразования сетевых адресов) мобильных устройств (А) и (В) поддерживать прямое одноранговое соединение. Некоторые комбинации типов NAT - преобразования, как известно, являются несовместимыми для установления однорангового соединения. Например, полное коническое NAT - преобразование может для установления прямого однорангового соединения использоваться с любым другим типом NAT - преобразования кроме закрытого/имеющего брандмауэр NAT - преобразования. В противоположность этому, симметричное NAT - преобразование может для установления прямого однорангового соединения использоваться только с полным коническим NAT - преобразованием. В одном варианте реализации изобретения возможность сочетания различных типов NAT - преобразования сформулирована в таблице 1400 совместимости типов NAT - преобразования, показанной на Фигуре 14, в которой столбцы представляют собой типы NAT - преобразования одного мобильного устройства (например, мобильного устройства (А)), а строки представляют собой типы NAT - преобразования другого мобильного устройства (например, мобильного устройства (В). Значение "1.0" в клетке указывает на то, что типы NAT - преобразования в связанных с этой клеткой строке и столбце являются совместимыми, а значение "0.0" указывает на то, что эти типы NAT - преобразования являются несовместимыми.
В одном варианте реализации изобретения, если проверкой 1106 совместимости определено, что прямое одноранговое соединение неосуществимо, то сервис 112 приглашения может передать запрос 1201 поиска ретранслятора, как это описывается ниже в отношении Фигуры 12. Если, однако, проверкой 1106 совместимости определено, что прямое одноранговое соединение осуществимо, то сервис 112 приглашения может передать сервису 1050 "проталкиваемых" уведомлений запрос 1107 "проталкивания", содержащий согласие мобильного устройства (В) на приглашение мобильного устройства (А). Запрос 1107 "проталкивания" и последующая "проталкивающая" передача 1108 данных мобильному устройству (А) от сервиса 1050 "проталкиваемых" уведомлений может включать в себя маркер сеанса связи и маркер "проталкивания" как мобильного устройства (А), так и (В), идентификационный код, и/или данные прохождения NAT - преобразования/соединительные данные. В одном варианте реализации изобретения эта информация может быть упакована внутри структуры данных "билета", описанной выше (смотри, например, Фигуры 2а - с и связанный с ними текст), и может быть зашифрована с использованием уникального ключа. В качестве альтернативы, эта информация может просто быть передана с уникальным идентификатором сеанса связи по приглашению. Сервис 1050 приглашения может также уведомить мобильное устройство (В) о том, что будет предпринята попытка прямого соединения.
На этой стадии, мобильные устройства (А) и (В) имеют достаточную информацию для того, чтобы установить прямую одноранговую связь. В одном варианте реализации изобретения это достигается с использованием CDX - сервиса 110, как это было описано выше. Например, мобильное устройство (В) присоединяет свои соединительные данные к Билету В и, на этапе 1109, передает Билет В (с соединительными данными) CDX - сервису. Непосредственно перед этой транзакцией мобильное устройство (В) может осуществить транзакцию, такую как транзакция 235, показанная на Фигуре 2b, для того, чтобы гарантировать то, что его соединительные данные являются действующими. После этого CDX - сервис 110 осуществляет аутентификацию этого билета (например, используя уникальный ключ сеанса связи, как это было описано выше), извлекает соединительные данные мобильного устройства (В), и на этапе 1110 пересылает эти соединительные данные мобильному устройству (А). Аналогичным образом, мобильное устройство (А) присоединяет свои соединительные данные к Билету А и, на этапе 1111, передает Билет А (с соединительными данными) CDX - сервису 110. Непосредственно перед этой транзакцией мобильное устройство (А) может осуществить транзакцию, такую как транзакция 232, показанная на Фигуре 2 b, для того, чтобы гарантировать то, что его соединительные данные являются действующими. После этого CDX - сервис 110 осуществляет аутентификацию этого билета (например, используя уникальный ключ сеанса связи, как это было описано выше), извлекает соединительные данные мобильного устройства (А), и на этапе 1112 пересылает эти соединительные данные мобильному устройству (В). Наконец, на этапе 1113, мобильные устройства (А) и (В), используя соединительные данные, обмен которыми произошел, устанавливают между собой прямое одноранговое соединение.
Обратимся теперь к Фигуре 12, на которой если проверкой 1106 совместимости определено, что прямое одноранговое соединение осуществимо, то сервис 112 приглашения может передать сервису 1051 ретрансляции запрос 1201 поиска ретранслятора для того, чтобы определить ретрансляционное хост - устройство для использования каждым мобильным устройством. Запрос 1201 может содержать информацию подключения к сети для мобильных устройств (А) и (В) (например, данные прохождения NAT - преобразования/соединительные данные, и/или данные о типе NAT - преобразования), которые используются сервисом 1051 ретрансляции для того, чтобы выбрать подходящие ретрансляционные хост - устройства для обоих мобильных устройств. Как проиллюстрировано на Фигуре 13, один вариант реализации сервиса 1051 ретрансляции включает в себя множество ретрансляционных хост - устройств 1302-1303, и базу 1301 данных по ретрансляционным хост - устройствам, содержащую сетевую информацию, относящуюся к каждому из ретрансляционных хост - устройств. Сервис 112 приглашения передает запрос 1201 поиска ретранслятора сервису 1300 поиска ретранслятора, который делает запрос в базу 1301 данных по ретрансляционным хост -устройствам, используя сетевую информацию по мобильным устройствам (А) и (В). После получения результатов из базы данных сервис 1300 поиска ретранслятора предоставляет ответ 1202, идентифицирующий выбранные ретрансляционные хост - устройства 1302-1303.
В одном варианте реализации изобретения ответ 1202 на запрос поиска ретранслятора содержит маркер ретрансляции, сгенерированный сервисом ретрансляции, и сетевые адреса (IP - адреса/порты) ретрансляционных хост - устройств 1302-1303, подлежащих использованию мобильными устройствами (А) и (В) для ретрансляционного соединения. В одном варианте реализации изобретения маркер ретрансляции связан с ретрансляционным сеансом связи и используется ретрансляционными хост - устройствами 1302 - 1303 для аутентификации мобильных устройств (А) и (В) после соединения с сервисом 1051 ретрансляции. Этот маркер может принимать различные формы, включающие в себя, например, уникальный идентификационный код идентификатора ретрансляционного сеанса связи, цифровой сертификат и/или уникальный ключ шифрования, связанный с ретрансляционным сеансом связи.
На этапе 1203 сервис приглашения передает мобильному устройству В 121 ответ 1203 о ретрансляции, содержащий указание на то, что будет выполнено ретрансляционное соединение. В одном варианте реализации изобретения ответ 1203 о ретрансляции может включать в себя маркер ретрансляции и сетевую информацию для ретрансляционного хост - устройства В 1303. В одном варианте реализации изобретения ответ 1203 может быть отправлен напрямую мобильному устройству (В) (в обход сервиса 1050 "проталкиваемых" уведомлений), поскольку его отправляют в ответ на согласие 1105 мобильного устройства (В).
Сервис 112 приглашения передает мобильному устройству (А) ответ 1204 о ретрансляции, который может включить в себя маркер ретрансляции и сетевую информацию для ретрансляционного хост - устройства 1303. В этом случае ответ 1204 "проталкивается" мобильному устройству (А) через сервис 1050 "проталкиваемых" уведомлений в ходе транзакции 1205.
На этапе 1206 мобильное устройство А 120 использует сетевую информацию для ретрансляционного хост - устройства А 1302 для того, чтобы установить связь с сервисом 1051 ретрансляции. Аналогичным образом на этапе 1207 мобильное устройство В 121 для того, чтобы установить связь с сервисом 1051 ретрансляции, использует сетевую информацию для ретрансляционного хост - устройства В 1303. В каждой из этих транзакций, в любых брандмауэрах NAT - преобразования для мобильных устройств (А) и (В) открываются новые проходы, и сервисом 1051 ретрансляции могут быть определены данные прохождения NAT - преобразования/соединительные данные для мобильных устройств (А) и (В) и возвращены, соответственно, мобильным устройствам (А) и (В), (например, посредством определения публичного IP/порта для этих устройств). В одном варианте реализации изобретения сервис 1051 ретрансляции и мобильные устройства (А) и (В) реализуют Протокол прохождения NAT - преобразования с использованием ретрансляции ("TURN - протокол"), который, как понятно специалистам в данной области техники, позволяет элементу, находящемуся позади NAT - системы или брандмауэра принимать данные, поступающие по соединениям, соответствующим TCP - протоколу (Протоколу управления передачей) или UDP - протоколу (Протоколу пользовательских дейтаграмм).
На этапе 1208 мобильное устройство (А) передает сервису 112 приглашения корректировку ретрансляции, которая на этапе 1209 пересылается сервису "проталкиваемых" уведомлений и на этапе 1210 "проталкивается" мобильному устройству (В). Аналогичным образом на этапе 1211 мобильное устройство (В) передает сервису 112 приглашения корректировку ретрансляции, которая на этапе 1212 пересылается сервису "проталкиваемых" уведомлений и на этапе 1213 "проталкивается" мобильному устройству (А). Корректировка ретрансляции, передаваемая мобильным устройством (А), может включать в себя маркер сеанса связи, идентификационный код каждого устройства, и данные прохождения NAT - преобразования/соединительные данные, определенные ретранслятором на этапах 1206 и 1207 (то есть при этом мобильное устройство (А) отправляет свои данные прохождения NAT - преобразования/соединительные данные мобильному устройству (В) и наоборот). В одном варианте реализации изобретения операции корректировки ретрансляции выполняются по причине того, что информация о NAT - преобразовании для каждого мобильного устройства может измениться.
Наконец, на этапах 1214 и 1215 мобильные устройствах (А) и (В), соответственно, устанавливают одноранговое соединение через сервис 1051 ретрансляции. В одном варианте реализации изобретения ретрансляционные соединения могут быть установлены тогда, когда мобильное устройство (А) отправляет сервису 1051 ретрансляции данные прохождения NAT - преобразования/соединительные данные мобильного устройства (В), и наоборот, позволяя, таким образом, сервису 1051 ретрансляции определить правильный путь к ретрансляционному хост - устройству 1302-1303 каждого однорангового пользователя.
Используя технологии, описанные выше, сервис 112 приглашения может быть реализован как сервис без запоминания состояний, который, по существу своему, является масштабируемым и эластичным, даже в крупномасштабной системе с большим количеством мобильных устройств. Например, поскольку сервис 1050 "проталкиваемых" уведомлений, по существу своему, способен к определению местонахождения зарегистрированных мобильных устройств и "проталкиванию" им контента, от сервиса приглашения не требуется, чтобы он отслеживал текущее местонахождение каждого устройства. В дополнение к этому, поскольку устройства могут передавать все данные состояния сеанса связи с каждым запросом и ответом, от сервиса приглашения никогда не требуется, чтобы он сохранял какую-либо информацию о состоянии для каждого соединения, что снижает требования к хранению и обработке данных в сервисе приглашения. Такого рода реализация особенно полезна в крупномасштабной системе.
Система и способ для формирования сочетаний пользователей для онлайновых сеансов связи
Как проиллюстрировано на Фигуре 15, один вариант реализации сервиса 111 формирователя сочетания может включать в себя диспетчера 1501 формирователя сочетания для приема запросов сочетания и "проталкивания" ответов о сочетании мобильным устройствам 120-122; базу 1512 данных для хранения запросов сочетания в таблице 1502 запросов и для хранения данных о наборе сочетаемости в таблице 1503 идентификаторов набора сочетаемости ("MSI - идентификаторов"); и один или более формирователей 1510 сочетания для выборки запросов сочетания из базы 1512 данных, выполнения операций формирования сочетания и сохранения результатов сочетания вновь в базе 1512 данных. Следует, однако, отметить, что принципы, лежащие в основе изобретения, не ограничены конкретной архитектурой, показывают на Фигуре 15.
В одном варианте реализации изобретения диспетчер 1501 формирователя сочетания действует в качестве интерфейса для сервиса 111 формирователя сочетания, принимая запросы от мобильных устройств 120-122, преобразуя эти запросы в команды на сохранение запросов в базе 1512 данных, считывания результатов сочетания из базы 1512 данных и на сообщение этих результатов мобильным устройствам 120-122.
При работе, когда поступает новый запрос сочетания, диспетчер 1501 формирователя сочетания может сохранить этот запрос в строке таблицы 1502 запросов. В одном варианте реализации изобретения диспетчер 1501 присваивает каждому запросу сочетания Идентификационный код запроса ("RID - код"), проиллюстрированный на Фигуре 15 просто как "А", "В" и "С" (в корреспонденции, соответственно, с мобильными устройствами (А), (В) и (С)). Хотя на Фигуре 15 этот код для простоты показан с использованием буквенного обозначения, Идентификационный код запроса может относиться к строковому, целому или любому другому типу переменной, подходящему для отслеживания запросов сочетания в пределах базы данных.
Каждому запросу сочетания может быть присвоено значение идентификатора набора сочетаемости ("MSI - идентификатор"), которое сохраняется в таблице 1502 запросов. В одном варианте реализации изобретения MSI - идентификатор может идентифицировать конкретное приложение, для которого запрашивается сочетание, и/или параметры конфигурации, используемые для этого приложения. Например, значение MSI - идентификатора, составляющее 12:4, может идентифицировать некоторую конкретную игру для нескольких игроков, имеющую идентификатор "12", и может идентифицировать некоторую конкретную конфигурацию для этой игры, имеющую идентификатор "4". Если описать это более конкретно, то идентификационный код 12 может идентифицировать некоторую конкретную гоночную игру для нескольких игроков, а идентификационный код 4 может указывать конкретный гоночный трек, скорость, или уровень мастерства игрока для этой гоночной игры. В одном варианте реализации изобретения разработчикам приложения предоставляется опция для того, чтобы, используя таким образом значения MSI - идентификатора, указывать любые параметры конфигурации приложения. В одном варианте реализации изобретения, вместо того, чтобы указывать MSI - идентификатор напрямую, разработчики приложения указывают идентификатор игры (для идентификации конкретной игры) и идентификатор "короба" (для идентификации конкретной конфигурации игры), и эти значения отображаются на значение MSI - идентификатора диспетчером 1501 формирователя сочетания.
Кроме того, в рамках одного MSI - идентификатора может быть использовано несколько различных значений MSI - идентификатора с целью указания множественных различных параметров конфигурации (например, 12:4:1 мог бы представлять: 12=гоночная игра; 4=трек; и 1=уровень мастерства). Как подробно описывается ниже, в одном варианте реализации изобретения каждый MSI - идентификатор используется формирователем 1510 сочетания для того, чтобы идентифицировать набор запросов сочетания, в котором могут быть выполнены операции по формированию сочетания (например, запросы группируются на основе MSI - идентификатора, и сочетания строятся в пределах группы каждого MSI - идентификатора). В одном варианте реализации изобретения каждый MSI - идентификатор может динамически изменяться/выбираться диспетчером для того, чтобы включить в себя идентификатор раздела, идентифицирующий разделы для различных машин. Например, если некоторый конкретный MSI - идентификатор становится перегруженным, то диспетчер может разделить этот MSI - идентификатор между двумя или более различными серверами и/или разделами памяти (например, используя такие обозначения, как 4:3:1 и 4:3:2, где последние цифры идентифицируют, соответственно, разделы 1 и 2). После этого другой формирователь сочетания может независимо извлекать и обрабатывать запросы из каждого из различных MSI - идентификаторов от каждого из различных серверов.
Как проиллюстрировано на Фигуре 15, данные запроса сочетания могут также быть сохранены по каждому запросу внутри таблицы 1502 запросов. Данные запроса могут включать в себя любые данные, полезные для принятия решения о формировании сочетания, и/или любые данные, необходимые для доступа к мобильному устройству, инициировавшему запрос, по сети. Например, в одном варианте реализации изобретения данные запроса сочетания включают в себя, для каждого запроса, данные о типе NAT - преобразования (преобразования сетевых адресов) и/или данные прохождения NAT - преобразования/соединительные данные для мобильного устройства, инициирующего запрос. Внутри таблицы 1502 запросов могут также быть сохранены и другие типы данных запроса, такие как скорость соединения устройства (100 килобит в секунду, 1 мегабит в секунду и так далее), тип соединения (например, 3G, EDGE, WiFi и так далее), местонахождение устройства (например, определенное посредством технологий геолокации), язык (английский, испанский и так далее) и/или пользовательские предпочтения. Данные запроса могут определяться каждым мобильным устройством 120-122 и передаваться диспетчеру 1501 формирования сочетания с каждым запросом сочетания. Например, каждое мобильное устройство может определять свои соединительные данные, тип соединения, местонахождение устройства и так далее, используя различные технологии, некоторые из которых описаны в этой заявке (например, поддерживая связь с сервером прохождения NAT - преобразования для определения данных прохождения NAT - преобразования/соединительных данных; используя систему GPS (Глобальную систему позиционирования) для определения местонахождения устройства, считывая информацию HTTP - протокола (Протокола передачи гипертекста) для определения языка и так далее).
Как проиллюстрировано на Фигуре 15, в одном варианте реализации изобретения каждому действующему MSI - идентификатору может быть присвоена строка в таблице 1503 MSI - идентификаторов. В одном варианте реализации изобретения, при поступлении нового запроса диспетчер 1501, в дополнение к добавлению запроса в таблицу 1502 запросов, также проверяет таблицу 1503 MSI - идентификаторов для того, чтобы определить, не существует ли уже MSI - идентификатора для этого запроса (то есть, не были ли приняты другие запросы, имеющие тот же самый MSI - идентификатор). Если никакого совпадающего MSI - идентификатора не найдено, то диспетчер 1501 может создать новый вход в таблице 1503 MSI - идентификаторов новую запись для нового запроса. Если Совпадающий MSI - идентификатор найден, то диспетчер может просто добавить новый запрос в таблицу 1502 запросов, как это было описано выше.
После того как таблица 1502 запросов и таблица 1503 MSI - идентификаторов обновлены диспетчером 1501 формирователя сочетания, один экземпляр модуля 1510 формирователя сочетания (в дальнейшем именуемый просто как "формирователь 1510 сочетания") извлекает данные для выполнения операции формирования сочетания. Множественные экземпляры формирователя сочетания могут одновременно исполняться для выполнения множественных запросов формирования сочетаний, и единственный формирователь 1510 сочетания может одновременно проводить множественные операции формирования сочетаний на множественных различных группах MSI - идентификатора.
В одном варианте реализации изобретения, когда формирователь 1510 сочетания становится доступным (например, после завершения операций сочетания для группы MSI - идентификатора или будучи инициализированным), он делает запрос в таблицу 1503 MSI - идентификаторов для идентификации нового MSI - идентификатора для обработки. На Фигуре 15 значение "N/A" ("не доступен") в полях идентификатора формирователя сочетания для MSI - идентификатора 3:1 указывает на то, что ответственность за обработку этого MSI - идентификатора еще не возложена на формирователя сочетания. В одном варианте реализации изобретения каждая запись с MSI - идентификатором снабжена временной меткой и формирователь 1510 сочетания выбирает MSI - идентификатор, имеющий самую старую временную метку.
В одном варианте реализации изобретения, когда формирователь 1510 сочетания принимает ответственность за некоторый конкретный MSI - идентификатор, он обновляет его идентификационный код формирователя сочетания в таблице 1503 MSI - идентификаторов и указывает продолжительность владения для этого MSI - идентификатора (например, 5 секунд). В одном варианте реализации изобретения формирователь 1510 сочетания постоянно обновляет это значение продолжительности владения по мере того, как он обрабатывает сочетания для этого MSI - идентификатора. Значения продолжительности владения могут использоваться для того, чтобы идентифицировать MSI - идентификаторы, которые были назначены потерпевшим неудачу формирователям 1510 сочетания. Например, если значение продолжительности владения истекло, то этот MSI - идентификатор может быть затребован новым формирователем 1510 сочетания, несмотря на тот факт, что таблица 1503 MSI - идентификаторов указывает, что этот MSI - идентификатор уже назначен формирователю сочетания.
После того как формирователь 1510 сочетания принял ответственность за некоторый MSI - идентификатор, он может сделать запрос в таблицу 1502 запросов для того, чтобы считать в память запросы, связанные с этим MSI - идентификатором. После этого формирователь 1510 сочетания может тогда выполнить операции сочетания для того, чтобы сочетать пользователей и мобильные устройства в соответствии с набором критериев сочетания (например, так, как это описывается ниже). Формирователь 1510 сочетания может обновлять таблицу 1502 запросов для указания того, что сочетания мобильных устройств сформированы. Например, формирователь сочетания может удалить значения MSI - идентификатора из столбца MSI - идентификатора в таблице 1512 запросов и ввести некоторое предварительно заданное значение, указывающее, что сочетание завершено. В дополнение к этому, формирователь 1510 сочетания может обновлять поле "данные запроса" для каждого участника для того, чтобы идентифицировать других участников, с которыми было установлено сочетание этого участника (например, записывая данные прохождения NAT преобразования/соединительные данные, необходимые для поддержания связи с другими участниками).
Диспетчер 1501 может делать запрос в таблицу 1502 запросов для того, чтобы идентифицировать завершенные сочетания. В ответ на обнаружение завершенного сочетания диспетчер 1501 может передать "проталкиваемое" уведомление мобильным устройствам, входящим в состав сочетания (например, используя технологии "проталкиваемых" уведомлений, описанные в данной заявке и в одновременно рассматриваемых заявках того же заявителя). В одном варианте реализации изобретения "проталкиваемое" уведомление включает в себя описанную выше структуру данных "билета". Затем эти мобильные устройства могут использовать каждый из своих билетов для обмена соединительными данными через CDX - сервис (сервис обмена соединительными данными) 110, как это было описано выше.
В дополнение к использованию "проталкиваемых" уведомлений, в одном варианте реализации изобретения мобильные устройства 120-122 могут периодически делать запрос диспетчеру 1501 для того, чтобы определить, сформировано ли сочетание. Периодические запросы полезны в том случае, если это не сделало для мобильного устройства "проталкиваемое" уведомление. Однако, поскольку используется "проталкивающая" архитектура, эти периодические запросы могут быть сделаны относительно редкими, что уменьшает нагрузку на сервис 111 формирователя сочетания.
На Фигуре 16 проиллюстрирован приводимый в качестве примера вариант реализации способа, в котором сервисом 111 формирователя сочетания формируется сочетание двух мобильных устройства (А) и (В). На Фигурах 17а - d проиллюстрированы приводимые в качестве примера обновления таблицы 1502 запросов и таблицы 1503 MSI - идентификаторов, которые могут иметь место в процессе осуществления этого способа.
На этапе 1601 принимается запрос сочетания от мобильного устройства (А). Как проиллюстрировано на Фигуре 17а, на этапе 1602 запрос мобильного устройства (А) вводится в таблицу запросов, а в таблицу 1503 MSI - идентификаторов вводится новый MSI - идентификатор (MSI - идентификатор 1:1) (если такой в ней уже не существует). На этапе 1603 принимается запрос сочетания от мобильного устройства (В), а на этапе 1604 запрос сочетания от мобильного устройства (В) также вводится в таблицу запросов, как это проиллюстрировано на Фигуре 17b.
На этапе 1605 некоторый конкретный экземпляр формирователя сочетания (формирователь (# N) сочетания) проверяет таблицу MSI - идентификаторов и обнаруживает, что MSI - идентификатор 1:1 не затребован другим экземпляром формирователя сочетания. В качестве альтернативы, формирователь сочетания может обнаружить вход запись в таблице MSI - идентификаторов с истекшей продолжительностью владения, что указывает на то, что формирователь сочетания, ранее работавший с этим MSI - идентификатором, потерпел неудачу. В одном варианте реализации изобретения записям MSI - идентификаторов с истекшей продолжительностью владения присваивается более высокий приоритет, чем новым записям MSI - идентификаторов (которые еще не были назначены формирователю сочетания). Кроме того, в одном варианте реализации изобретения относительно более старым записям MSI - идентификаторов может присваиваться более высокий приоритет, чем относительно более новым записям MSI - идентификаторов. Независимо от того, каким образом формирователь сочетания выбирает MSI - идентификатор, когда он это делает, он добавляет к нему свой идентификатор и устанавливает новое значение продолжительности владения для этой записи MSI - идентификатора, как это проиллюстрировано на Фигуре 17с (например, используя в проиллюстрированном примере значение продолжительности владения, составляющее 5 секунд). После этого формирователь сочетания может сделать запрос в таблицу запросов и считать записи таблицы запросов с этим MSI - идентификатором в память, так чтобы они могли обрабатываться.
На этапе 1606 формирователь сочетания выполняет последовательность операций сочетания для того, чтобы выбрать подходящее сочетание для каждого из запросов. Некоторые варианты реализации операций сочетания описаны ниже в отношении Фигуры 18. Вкратце, в одном варианте реализации изобретения переменные, которые оцениваются для определения "подходящих" сочетаний, включают в себя тип NAT - преобразования (преобразования сетевых адресов) (например, полное коническое, ограниченное по порту, симметричное и так далее), тип соединения (например, WiFi, 3G, EDGE и так далее), язык, связанный с пользователем (полученный из заголовка принятия языка в запросе по HTTP - протоколу (Протоколу передачи гипертекста)), и "возраста" каждого из запросов сочетания. Вообще говоря, формирователь (1510) сочетания может попытаться сочетать мобильные устройства, имеющие совместимые типы NAT - преобразования (хотя иногда, как описано ниже, может быть использован сервис ретрансляции), одинаковые типы соединения и один и тот же язык. В одном варианте реализации изобретения формирователь 1510 сочетания может быть более либеральным в отношении требований к сочетанию, основываясь на "возрасте" запросов сочетания (то есть чем старше запрос, тем более либерально будут применяться ограничения сочетания).
Возвратимся к Фигуре 16, на которой на этапе 1607, после принятия решения о сочетании, формирователь 1510 сочетания может обновить таблицу запросов для того, чтобы указать, что сочетание завершено, как это показано на Фигуре 17d. Как часть этого обновления, формирователь сочетания может также обновить данные запросов для мобильных устройств (А) и (В). Например, в одном варианте реализации изобретения формирователь 1510 сочетания записывает данные прохождения NAT преобразования/соединительные данные мобильного устройства (В) в столбец данных запроса для мобильного устройства (А) и записывает данные прохождения NAT - преобразования/соединительные данные мобильного устройства (А) в столбец данных запроса для мобильного устройства (В).
На этапе 1608 диспетчер 1501 может прочитывать таблицу запроса для того, чтобы идентифицировать записи запросов, которые образовали сочетания. В одном варианте реализации изобретения, когда он обнаруживает, что мобильные устройства (А) и (В) образовали сочетание, он считывает данные запросов (обновленные формирователем сочетания так, как это было описано выше), и генерирует уведомление для мобильных устройств (А) и (В). В одном варианте реализации изобретения это уведомление представляет собой структуру данных "билета", описанную выше, которая зашифрована и включает в себя данные прохождения NAT - преобразования/соединительные данные для каждого мобильного устройства. Как было описано выше, в одном варианте реализации изобретения для "проталкивания" уведомлений мобильным устройствам (А) и (В) используется сервис 1050 "проталкиваемых" уведомлений. Кроме того, мобильные устройства (А) и (В) могут периодически опрашивать диспетчер 1501 для того, чтобы определить, было ли сформировано сочетание. В этом варианте реализации изобретения технология опроса может быть сделана с относительно низкой частотой для того, чтобы идентифицировать сочетания, данные о которых по некоторым причинам не были успешно "протолкнуты" одному из мобильных устройств. Используя "проталкиваемые" уведомления для управления нагрузкой опрашивающих запросов, значительно снижают нагрузку на сервис 111 формирователя сочетания, который в ином случае был бы загружен опрашивающими запросами от мобильных устройств.
Если на этапе 1608 определено, что в процессе ожидания находятся дополнительные запросы сочетания для того же самого MSI - идентификатора, то формирователь сочетания может продолжить формировать сочетания мобильных устройств/пользователей в рамках этого MSI - идентификатора. На этапе 1610 формирователь сочетания может осуществить сброс значения продолжительности владения, имеющегося в таблице 1503 MSI - идентификаторов. На этапе 1611 выполняются дополнительные сочетания, и таблица запросов обновляется (так, как это было описано выше). На этапе 1612 эти дополнительные сочетания считываются из таблицы запросов, и производится обновление по этим дополнительным мобильным устройствам (так, как это было описано выше). Если же никакие дополнительные запросы сочетания не находятся в процессе ожидания для этого MSI - идентификатора, то на этапе 1609 эта запись MSI - идентификатора удаляется из таблицы MSI - идентификаторов (например, посредством команды удаления, поступающей либо от диспетчера и/либо от формирователя сочетания).
На Фигуре 18 проиллюстрирован один вариант реализации способа для выполнения сочетаний между мобильными устройствами/пользователями (операция 1606 на Фигуре 16). На этапе 1801 все запросы с текущим MSI - идентификатором (например, для конкретной комбинации приложения/" короба" (совокупности параметров конфигурации приложения)) располагаются по парам. На этапе 1802 оценивается соответствие сочетания в каждой паре, и на этапе 1803 пары сортируются в порядке уменьшения соответствия. "Соответствие" оценивается на основе множества различных переменных, включающих в себя тип NAT - преобразования (преобразования сетевых адресов) (например, полное коническое, ограниченное по порту, симметричное и так далее), тип соединения (например, WiFi, 3G, EDGE и так далее), язык, связанный с пользователем (полученный из заголовка принятия языка в запросе по HTTP - протоколу (Протоколу передачи гипертекста), и "возраста" каждого из запросов сочетания, но не ограниченных этими переменными. Другие переменные, которые могут учитываться в качестве факторов при принятии решения по формированию сочетания, включают в себя местонахождение каждого из мобильных устройств (например, при попытке сочетания пользователей в некотором конкретном местонахождении); минимальные и/или максимальные требования к игрокам (например, указанные пользователем и/или приложением); являются ли один или больше пользователей, входящих в этот MSI - идентификатор, "друзьями" или вступили ли они в одноранговое соединение ранее (например, в случае предпочтительности сочетания "друзей" или ранее знакомых); и опыт пользователя с этим приложением (например, в случае игры для нескольких игроков могут учитываться в качестве факторов ранги на табло лидеров, присвоенные каждому из пользователей, при этом предпочтение оказывается сочетанию пользователей, имеющих сходный опыт).
Как показано на Таблице А, приведенной ниже, в одном варианте реализации изобретения оценка "соответствия" представляет собой численное значение между 0,0 и 1,0. Использование значения с плавающей запятой позволяет нормировать оценку соответствия по каждому критерию. Во избежание арифметики с плавающей запятой можно использовать ненормированные целочисленные значения с соответствующей оценкой таким образом, чтобы значения "соответствия" можно было сравнивать.
В одном варианте реализации изобретения все критерии имеют двоичную оценку соответствия, при которой они либо совместимы (имея нормированное значение 1,0) или не совместимы (имея нормированное значение меньше чем 1,0). Их можно считать требуемыми критериями там, где соответствие может изменяться с "возрастом" (как это описывается ниже). Если в качестве переменной добавляется местонахождение, то наилучшим соответствием может являться соответствие с самым ближним игроком, который удовлетворяет требуемым критериям.
Соответствие сочетания - Таблица А
В одном варианте реализации изобретения Соответствие равно Сумме, равной (Нормированный весовой коэффициент * Значение "возрастного" коэффициента) для каждого из вышеупомянутых критериев. Значение "возрастного" коэффициента может начинаться со значения 1 и увеличивается после того, как прошел некоторый предварительно заданный промежуток времени. Он может затем продолжить увеличиваться по мере того, как проходит больше времени (например, периодически увеличиваясь на некоторую указанную величину). В одном варианте реализации изобретения, вместо того, чтобы использовать Значение "возрастного" коэффициента, описанное выше, можно установить пороговые значения "возраста", как этот описано ниже. Нормированные/взвешенные значения определенных переменных, таких как Тип соединения и Язык, могут применяться выше определенных пороговых значений "возраста" (даже если они не сочетаются).
В одном варианте реализации изобретения "соответствие" между парой запросов (А) и (В) является средним значением соответствия А с В и В с А. Кроме того, соответствие А с В для каждого фактора может быть скорректировано на основе "возраста" А (и наоборот). В одном варианте реализации изобретения, для совместимого сочетания может требоваться значение соответствия, составляющее 1,0. Это означает, что А и В сочетаются только в том случае, если сочетаются совместимость NAT - преобразования, Тип соединения и Язык (что в результате дает нормированное значение, составляющее 1,0) или если А и/или В достигли того возраста, что некоторые из вышеупомянутых переменных (например, Типа соединения и Языка) фактически игнорируются (либо используя значение "возрастного" коэффициента, упомянутое выше, либо пороговые значения, рассматриваемые ниже).
Возрасты - Таблица В
Пороговые значения "возраста" могут быть установлены так, как показано в Таблице В, приведенной выше. По мере того как превышается каждое пороговое значение "возраста" (то есть по мере того как запрос становится старше чем указанное пороговое значение), значения "возрастного" коэффициента могут увеличиваться до последовательно более высоких значений (например, 1,5, 2,0 и так далее). В качестве альтернативы, или в дополнение к этому, по мере того как превышаются различные пороговые значения "возраста", в принятие решения о сочетании могут добавляться взвешенные значения для некоторых переменных (например, таких как тип соединения и язык, как это описывается ниже).
В одном варианте реализации изобретения пределы "возраста" запроса, указанные в Таблице В, корректируются в соответствии со скоростью потока сочетаний для данного MSI - индикатора. В одном варианте реализации изобретения эта скорость потока определена как количество сочетаний, выполняемых в некоторую указанную единицу времени (например, каждые 10 секунд, каждую минуту и так далее). Таким образом, скорость потока дает указание на то, насколько занят некоторый конкретный набор MSI - идентификатора. В одном варианте реализации изобретения, чем более занят этот набор, тем ниже может быть установлено каждое из вышеупомянутых пороговых значений в Таблице В, приведенной выше, что повышает вероятность раннего успешного сочетания и снижения нагрузки на формирователь сочетания. Кроме того, нагрузка для данного набора MSI - идентификатора может быть сообщена конечному пользователю (например, в форме значения расчетного времени до формирования сочетания), так, чтобы пользователь аппаратуры мог выбирать, пытаться ли ему вступить в игру для нескольких игроков, которая является особенно занятой. Значение нагрузки может быть сообщено пользователю в форме "проталкиваемого" уведомления.
Обратимся теперь к каждой из переменных из Таблицы А, в одном варианте реализации изобретения совместимость NAT - преобразования определяется по таблице 1400 совместимости NAT - преобразования, показанной на Фигуре 14. Если два типа NAT - преобразования определены на основе этой таблицы как совместимые, то может быть применен весовой коэффициент совместимости NAT - преобразования.
Тип соединения - Таблица С
Тип соединения может быть оценен с использованием таблицы, такой как та, что показана выше как Таблица С. В этом примере, если тип соединения устройств А и В является одинаковым (что обозначается как 1,0 в клетках, в которых встречаются одинаковые типы соединения), то взвешенное значение типа соединения, взятое из Таблицы А, может быть включено в определение "соответствия". Как было упомянуто выше, "возраст" каждого из запросов может использоваться для того, чтобы влиять на определение типа соединения. Например, в одном варианте реализации изобретения значение "соответствия" для типа соединения выбирается с использованием матрицы в Таблице С для "возрастов" пороговых значений 1, 2 и 3. Для "возрастов" порогового значения 4 или выше, тип соединения может быть установлен в 1,0 (даже для несочетающихся типов соединения), и может быть применено соответствующее взвешенное значение для типа соединения. Хотя в некоторых вариантах реализации изобретения используется "тип" соединения, вместе с типом соединения, или вместо него, может быть определена и использоваться скорость соединения. Например, могут рассматриваться "совместимыми" скорости соединения в пределах определенных указанных диапазонов (например, 0-100 килобит в секунду; 100-500 килобит в секунду; 500-1000 килобит в секунду, 1000-1500 килобит в секунду и так далее). Любая из рассмотренных здесь переменных формирования сочетания может также быть применена как весовой коэффициент при вычислении значения "соответствия" сочетания и скорректирована согласно "возрасту" так, как это было описано выше.
В одном варианте реализации изобретения язык игрока может быть получен из заголовка принятия языка в запросе по HTTP - протоколу (Протоколу передачи гипертекста), который может содержать один или более языков с q - фактором (qfactor) предпочтения. Диспетчер может извлечь наиболее предпочтительный язык и передать эту информацию формирователю сочетания. В одном варианте реализации изобретения взвешенное значение по языку из Таблицы А устанавливается равным 1,0 в том случае, если языки одинаковы, или 0,0 в том случае, если они не одинаковы. Однако в одном варианте реализации изобретения взвешенное значение по языку может быть применено, даже в том случае, если языки различаются, если "возраст" (запросов) выше, чем некоторое предварительно указанное пороговое значение (например, если возраст составляет пороговое значение 2 или выше по Таблице В).
В одном варианте реализации изобретения сочетание может быть сформировано из двух пользователей с несовместимыми типами NAT - преобразования (преобразования сетевых адресов). Например, если формирователь сочетания столкнулся с трудностью при формировании сочетания пользователей для некоторого конкретного MSI - идентификатора, то после некоторого указанного промежутка времени он может проложить маршрут соединений связи через сервис 1051 ретрансляции, используя технологии, описанные выше. Таким образом, сервис 1051 ретрансляции действует в качестве своего рода "клапана давления", позволяя сочетаниям по "возрастным" запросам иметь место даже, несмотря на несовместимые типы NAT - преобразования. Сервис 1051 ретрансляции может также использоваться в ответ на обнаружение одной или более неудавшихся попыток сочетания. В этом варианте реализации изобретения каждый запрос сочетания, поданный мобильным устройством, может включать в себя указание на то, были ли ранее предприняты одна или более неудачных попыток сочетания.
Как часть определения "соответствия" сочетания могут быть оценены и снабжены значением весового коэффициента различные дополнительные критерии сочетания, включающие в себя, в порядке примера, но не ограничения, указание на то, является ли любой из пользователей, запрашивающих сочетание, "друзьями". Например, формирователь 1510 сочетания может попытаться сочетать между собой любые запросы пользователей, которые являются "друзьями", применяя при расчете значения "соответствия" сочетания весовой коэффициент "друзья". Аналогичным образом, друзья друзей могут также быть взвешены (например, с 2 или более степенями разделения). В дополнение к этому, игрок может присваивать рейтинги другим игрокам некоторой конкретной игры, и формирователь сочетания может оценивать эти рейтинги при выполнении сочетания (с тенденцией формировать сочетание пользователя с теми игроками, которые имеют относительно более высокие рейтинги, и не формировать сочетание пользователя с игроками, которые имеют низкие рейтинги). Кроме того, может оцениваться время задержки соединения пользователя (например, с использованием простой операции системы PING (Отправителя пакетов Интернета)) и использоваться как часть принятия решения о формировании сочетания.
Еще одной другой переменной, используемой для сочетания игроков, может служить тип устройства. Например, формирователь 1510 сочетания может попытаться сочетать игроков, имеющих аналогичные типы устройств (например, iPads, iPods, iTouches, iPhones, RIM Blackberries и так далее). Дополнительные переменные могут включать в себя ранжирование пользователей на табло лидеров, местонахождение на текущий момент, место жительства в текущий момент, возраст, пол и сходные игровые коллекции могут сходным образом оцениваться для определения сочетания (то есть во многих случаях, имея тенденцию способствовать сочетаниям между теми пользователями, у которых сходные критерии). Наконец, формирователь сочетания может оценивать средства родительского контроля, гарантируя то, чтобы формировались сочетания пользователей только с надлежащими MSI - идентификаторами и с другими пользователями того же самого возраста.
Сервис 111 формирователя сочетания может извлекать любую из вышеупомянутых переменных из одной или более баз данных, которые ведутся в рамках сервиса 100 данных (смотри, например, базу (1920) данных, описываемую ниже в отношении Фигуры 19). Например, доступ к данным "друзей" пользователя может быть осуществлен из базы данных сервиса "друзей", а доступ к другой информации, такой как возраст, пол, игровая коллекция и т.д. каждого пользователя можно получить из одной или более других баз данных (например, профиля пользователя, базы данных с играми, базы данных табло лидеров и так далее). В одном варианте реализации изобретения всем описанным здесь сервисам предоставляется доступ к одной и той же центральной базе данных (или группе баз данных) для хранения всего разнообразия различных типов данных о пользователе/устройстве, используемых для принятия решения о формировании сочетания.
Хотя выше было приведено несколько конкретных примеров, следует понимать, что принципы, лежащие в основе изобретения, не ограничены никаким конкретным набором переменных для определения уровня соответствия для сочетания. В одном варианте реализации изобретения прикладные программисты, проектирующие приложения, подлежащие исполнению в описанных здесь системе и способе, могут указать свой собственный набор критериев для сочетания и/или для группирования запросов с использованием различных критериев MSI - идентификатора.
Обратимся вновь к способу, показанному на Фигуре 18, в котором, после того, как определено "соответствие" сочетания по каждой паре, на этапе 1803 эти пары сортируются в порядке уменьшения значения "соответствия" (например, так, что пары, имеющие самое высокое значение "соответствия", располагаются вверху списка). На этапе 1804 в "наборы сочетания" сеются те пары, которые имеют самые высокие значения "соответствия" вышеуказанного порогового значения. Как было описано выше, "пороговое" значение может быть задано имеющим нормированное значение 1,0, показанное выше в Таблице А. На этапе 1805 в набор сочетания добавляются новые предполагаемые партнеры, которые имеют значения "соответствия" одному или всем текущими членам в наборе сочетания, превышающие некоторое указанное пороговое значение. Например, если набор сочетания был первоначально посеян парами А и В, то С может быть добавлен в этот набору сочетания в том случае, если значение "соответствия" А - С и/или В - С - вышеуказанного порогового значения. В одном варианте реализации изобретения, если хотя бы единственное значение "соответствия" сочетания для предполагаемого участника превышает некоторое пороговое значение, то этот участник может быть добавлен в набор сочетания (то есть, по причине того, что в случае необходимости этот участник будет в состоянии поддерживать связь со всеми участниками через одного участника, с которым он имеет походящее "соответствие" сочетания). После того как в набор сочетания добавлен один или более новых участников, если на этапе 1806 определено, что требования по размеру для этого сочетания удовлетворены, то результаты сочетания сохраняются и сообщаются на этапе 1807 (например, посредством обновления таблицы 1502 запросов и передачи уведомлений так, как это было описано выше). В одном варианте реализации изобретения единственный запрос сочетания может представлять множественных пользователей (например, когда запрос сочетания следует за последовательностью приглашения, как это описывается ниже). В этом случае, требования по размеру оцениваются на основе количества пользователей, представленных каждым запросом сочетания. Если требования по размеру не были удовлетворены, то процесс возвращается на этап 1805, и к набору сочетания добавляется новый участок (то есть участник, имеющий значение "соответствия" сочетания с одним или более текущих членов набора, превышающее некоторое указанное пороговое значение).
На этапе образовавшие сочетание запросы удаляются из текущего набора запросов, обрабатываемых формирователем сочетания. На этапе 1809 выбирается посеянный следующим набор сочетания, и процесс возвращается на этап 1804 для дополнительного сочетания. Хотя на Фигуре 18 процесс проиллюстрирован как последовательный, следует отметить, что посеянные наборы сочетания могут обрабатываться одновременно, по-прежнему удовлетворяя при этом принципам, лежащим в основе изобретения.
Хотя выше они и описываются как отдельные сервисы, сервис 111 формирователя сочетания и сервис 112 приглашения могут для соединения одноранговых пользователей функционировать совместно. Например, в одном варианте реализации изобретения первый пользователь может пригласить одного или более друзей к онлайновому сеансу связи и запросить сочетания с одним или более дополнительными пользователями (например, ПРИГЛАСИТЬ друга "Боб" и сформировать сочетание с 3 дополнительными игроками для многоуровневой компьютерной игры). В таком случае сервис 112 приглашения может первоначально обработать запрос с приглашением от первого пользователя для того, чтобы соединить первого пользователя и друга (друзей) первого пользователя. Результаты запроса с приглашением (например, успешное одноранговое соединение) могут затем быть сообщены в обратном направлении мобильному устройству пользователя. После этого сервис 111 формирования сочетания может принять запрос сочетания от мобильного устройства первого пользователя (или, в одном варианте реализации изобретения, непосредственно от сервиса приглашения или от друзей первого пользователя), запрашивающего дополнительных игроков. В ответ на это сервис 111 формирователя сочетания может осуществить сочетание первого пользователя с одним или более другими запросами сочетания, имеющими тот же самый MSI - идентификатор, что и запрос первого пользователя (как это было описано выше). Запрос сочетания может включать в себя только критерии сочетания с первым пользователем или может включать в себя критерии сочетания с первым пользователем и с "другом" первого пользователя (например, тип NAT - преобразования, тип соединения, язык, местонахождение и так далее). В одном варианте реализации изобретения, если один или больше "друзей" первого пользователя не могут установить прямое одноранговое соединение с другим включенным в сочетание пользователем, соединение этого включенного в сочетание пользователя с "друзьями" первого пользователя может быть установлено через устройство обработки данных первого пользователя (например, с использованием мобильного устройства первого пользователя в качестве посредника для этого соединения), и/или для соединения пользователей может быть использован сервис ретрансляции (как это было описано выше).
В одном варианте реализации изобретения сервисом формирования сочетания можно первоначально сформировать сочетание первого пользователя с одним или более пользователями (как это было описано выше), а затем первый пользователь может пригласить одного или более "друзей" присоединяться к онлайновому сеансу связи с первым пользователем и этими включенными в сочетание пользователями. В этом варианте реализации изобретения обмен как информацией о пользователе, так и информацией о включенных в сочетание пользователях (например, данные о NAT - преобразования/соединительные данные, пользовательские идентификаторы, маркеры проталкивания и так далее) может осуществляться с приглашенными пользователями через сервис приглашения (как это было описано выше). Принципы, лежащие в основе изобретения, остаются теми же самыми независимо от того, происходит ли сначала сочетание, за которым следует приглашение, или имеет ли место сначала приглашение, за которым следует сочетание.
Каркас приложений с интерфейсом прикладного программирования для совместно используемых онлайновых приложений
Как проиллюстрировано на Фигуре 19, один вариант реализации изобретения осуществлен в контексте мобильного устройства 120, имеющего некоторый предварительно заданный каркас (1912) программного обеспечения с интерфейсом прикладного программирования ("API - интерфейсом") 1910 для сопряжения с одним или более приложениями 1911 и интерфейс 1910 прикладного программирования на стороне сервисов для поддержания связи с множеством сетевых сервисов 1901-1903. Как показано на Фигуре 19, сетевые сервисы 1901-1903 могут быть спроектированы и/или управляться тем же самым онлайновым сервисом 100 данных (хотя такая конфигурация не обязательна). Приложения 1911, такие как одноранговые игровые приложения и другие типы совместно используемых онлайновых приложений, могут быть разработаны таким образом, чтобы осуществлять доступ к сетевым сервисам 1901-1903 через API - интерфейс 1910, делая вызовы API - интерфейсу 1910. Разработка приложений 1911 может быть облегчена при использовании набора средств для разработки программного обеспечения ("SDK - набора"), предоставляемого разработчиком каркаса 1912 и сетевых сервисов 1901-1903. Более конкретная реализация каркаса 1912 и API - интерфейсов 1910, 1913 описывается ниже в отношении Фигуры 20.
Как проиллюстрировано, каждому сервису может быть предоставлен доступ к базе данных 1920 для хранения данных, используемых сервисами. Один конкретный пример представляет собой базу 1512 данных, используемую сервисом 111 формирователя сочетания (описанную выше). Другие примеры могут включать в себя базу данных табло лидеров для хранения данных табло лидеров, базу данных для сервиса "друзей", предназначенную для хранения записей состояния "друзей", базу данных профиля для хранения данных профилей пользователей и базу данных игр для хранения данных, относящихся к онлайновым играм. Может быть использован любой тип базы данных (например, MySQL, Microsoft SQL и так далее), но в одном конкретном варианте реализации изобретения может быть использована база данных "ключ/значение", такая как Berkley DB и/или MZBasic DB. Базы данных могут быть распределены по большому количеству массовых запоминающих устройств (например, жестким дискам) в Сеть хранения данных (сеть SAN) или другую конфигурацию хранения данных.
Следовательно, когда некоторый конкретный сервис обрабатывает и/или сохраняет данные, как это было описано выше, эти данные могут сохраняться в базе 1920 данных. Некоторые сервисы, однако, могут не использовать базу данных. Например, как было описано выше, сервис 112 приглашения может быть реализован как сервис без запоминания состояний и, следовательно, может не потребоваться сохранять данные в базе 1920 данных (хотя такого рода реализация все же возможна в соответствии с принципами, лежащими в основе изобретения).
API - интерфейс 1913 может быть разработан таким образом, чтобы поддерживать связь и обмениваться информацией с сетевыми сервисами 1901-1903, используя любой подходящий стек сетевых протоколов, включая, например, TCP/IP (Протокол управления передачей/Межсетевой протокол) или UDP/IP (Протокол пользовательских дейтаграмм/Межсетевой протокол) на сетевом уровне и HTTP - протокол (Протокол передачи гипертекста) на прикладном уровне. Может использоваться протокол, основанный на Вызове удаленной процедуры (RPC), по HTTP - протоколу или HTTPS - протоколу (Протоколе защищенной передачи гипертекстов), такой как SOAP - протокол (простой протокол доступа к объектам), и/или может использоваться Протокол передачи репрезентативного состояния (REST - протокол). Кроме того, сервисы могут быть реализованы на любой вычислительной платформе, включая, в порядке примера, Xserve или аналогичные серверы, эксплуатирующие программные платформы Unix, Linux или Apache. В одном конкретном варианте реализации изобретения эта платформа включает в себя Web - объекты, воплощенные в Linux. Предшествующие примеры были приведены просто в целях иллюстрации. Принципы, лежащие в основе изобретения, не ограничены никаким конкретным механизмом для связывания приложений с сервисами или каким бы то ни было конкретным набором сетевых протоколов.
Фигура 20 иллюстрирует более детализированную архитектуру программного обеспечения, включающую в себя интерфейсы прикладного программирования (API - интерфейсы) 2001 а-b, которые в одном варианте реализации изобретения могут быть реализованы на устройстве 120 беспроводной связи. Хотя этот вариант реализации изобретения описан в контексте каркаса 2000 игр для нескольких игроков, принципы, лежащие в основе изобретения, не ограничены игровым воплощением. Например, архитектура программного обеспечения, которая показана на Фигуре 20, может быть использована для того, чтобы поддерживать различные совместно используемые приложения, которые не являются играми (например, совместный "чат" (диалог в реальном масштабе времени), совместные аудио/видео сеансы с несколькими участниками и так далее).
В архитектуре, показанной на Фигуре 20, предусматривается каркас 2000 игр для поддержания разнообразных описанные здесь многопользовательских свойств и одноранговых свойств. В одном варианте реализации изобретения каркас 2000 игр предназначен для того, чтобы функционировать на операционной системе 2005 мобильного устройства. Например, если мобильное устройство 120 представляет собой iPhone, iPad, или iPod Touch, то операционная система 2005 может представлять собой операционную систему iPhone OS, операционную систему для мобильных устройств, разработанную правообладателем по настоящей заявке.
Каркас 2000 игр может включать в себя публичный интерфейс прикладного программирования (API - интерфейс) 2001 b и частный или "защищенный" API - интерфейс 2001 а. В одном варианте реализации изобретения приложение - игровой центр 2031, предназначенное для того, чтобы предоставлять различные описанные здесь и связанные с игрой функциональные возможности, может направлять вызовы как публичному API - интерфейсу 2001 b, так и частному API - интерфейсу 2001 а, тогда как другим приложениям 2030 (например, приложениям, разработанным третьими лицами) предоставляется только доступ к публичному API - интерфейсу 2001 b. Например, разработчик мобильного устройства 120 может захотеть держать определенные функции API - интерфейса, которые затрагивают потенциально уязвимую информацию, вне публичного API - интерфейса 2001 b для того, чтобы избежать злоупотребления со стороны разработчиков - третьих лиц (например, запросы "друзей", списки "друзей" и так далее). Однако как защищенный API - интерфейс 2001 а, так и публичный API - интерфейс 2001 b может быть объединены в единый API - интерфейс, доступный для всех приложений на мобильном устройстве (то есть разделение API - интерфейса на отдельные публичный и частный компоненты не требуется для соблюдения принципов, лежащих в основе изобретения). Обозначение "API - интерфейс 2001" иногда используется ниже по отношению к операциям, которые можно найти либо в публичном API - интерфейсе 2001 b и/либо в частном API - интерфейсе 2001 а.
Один вариант реализации приложения - игровой центр 2031 описан в одновременно рассматриваемой заявке того же заявителя, озаглавленной "Systems and Methods for Providing a Game Center" ("Системы и способы создания игрового центра"), (номер досье поверенного 4860.P9127USP1), имеющей порядковый номер 61/321,861, поданной 7 апреля 2010 г., имеющей в качестве изобретателей Marcel Van Os and Mike Lampell (в дальнейшем именуемой как "Патентная заявка на игровой центр"), права по который принадлежат правообладателю по данной заявке, и которая включена в данную заявку посредством ссылки. Вкратце, приложение - игровой центр 2031 включает в себя игро-центрический графический пользовательский интерфейс (GUI - интерфейс) для навигации по играм для нескольких игроков; для покупки новых игр; для извлечения информации, относящейся к играм (например, информации табло лидеров, информации о достижениях, информации о "друзьях" и так далее); для контактов с "друзьями" с целью проведения игр; для запроса игровых сочетаний с другими пользователями; и для приглашения конкретных пользователей. Различный другие функции, выполняемые приложением - игровым центром 2031, описаны в Патентной заявке на игровой центр, упомянутой выше. Некоторые из функций игрового центра могут быть предоставлены каркасом 2000 игр и сделаны доступными для других приложений 2030 через публичный API - интерфейс 2001 b.
В одном варианте реализации изобретения API - интерфейс 2001, выставляемый каркасом 2000 игр, упрощает процесс разработки совместных игр для нескольких игроков для мобильного устройства 120. В частности в одном варианте реализации изобретения API - интерфейс 2001 позволяет разработчикам делать простой вызов API - интерфейса, запуская относительно сложный процесс соединения пользователей для одноранговой игровой сессии с несколькими игроками. Например, простой вызов API - интерфейса, такой как INVITE (идентификатор игрока (В), идентификатор "Короба") (то есть ПРИГЛАСТЬ (идентификатор игрока (В), идентификатор "Короба")), может быть сделан с API - интерфейса 2001 для того, чтобы инициировать детализированную последовательность операций приглашения, описанную выше. Аналогичным образом вызов API - интерфейса, такой как MATCH (Идентификатор игрока (А), идентификатор "Короба") (то есть СОЧЕТАНИЕ ДЛЯ (Идентификатор игрока (А), идентификатор "Короба")), может быть сделан с API - интерфейса 2001 для того, чтобы инициировать детализированную последовательность операций формирования сочетания, описанную выше. Функции INVITE (ПРИГЛАШЕНИЕ) и MATCH (СОЧЕТАНИЕ) иногда обобщенно именуются здесь как "Функции однорангового соединения". В одном варианте реализации изобретения каркас 200 игр включает в себя код программы, требующийся для управления операциями приглашения и формирования сочетания в ответ на эти вызовы API - интерфейса (как это более подробно описывается ниже). Следует отметить, что фактические функции API - интерфейса могут иметь несколько отличные форматы данных, чем те, что описаны выше, (хотя они могут приводить в результате к аналогичным операциям, выполняемым каркасом 200 игр). Принципы, лежащие в основе изобретения, не ограничены никаким конкретным форматом для указания функций API -интерфейса.
Каркас 200 игр от имени игрового центра 2031 и других приложений 2030 может также управлять различными другими типами связанных с играми транзакций и информации. Некоторая часть этой информации описана в "Патентная заявка на игровой центр". В порядке примера, а не ограничения, эта информация может включать в себя информацию табло лидеров, относящуюся к тем пользователям, которые достигли максимального количественного результата для каждой игры и информацию о "достижениях", идентифицирующую пользователей, которые достигли определенных специфических для игры достижений. Каждый разработчик приложения может указать свой собственный набор "достижений" для каждого игрового приложения 2030 (например, пройденные уровни 1-3; уровень 1, пройденный за время, менее 5 минут; более 50 убитых, приходящихся на каждый уровень; сброшенные 20 флагов и так далее).
Каркас 2000 игр может также включать в себя код программы для управления данными о "друзьях" пользователя и для интегрирования данных о "друзьях" в рамки контекста игрового центра 2031 и других игровых приложений 2030. Например, когда пользователь выбирает ссылку на некоторую конкретную игру в игровом центре 2031, для этой игры может отобразиться информация, относящаяся к каждому из "друзей" пользователя (например, ранжирование друзей на табло лидеров, достижения "друзей", результаты при игре пользователя в эту игру с каждым из его/ее друзей, и так далее). В одном варианте реализации изобретения API - интерфейс 2001 каркаса 2000 игр включает в себя функции для получения доступа к данным о "друзьях", управляемым сервисом "друзей", таким как тот, что описан в одновременно рассматриваемой заявке того же заявителя, озаглавленной "Apparatus and Method for Efficiently Managing Data in a Social Networking Service" ("Аппарат и способ для эффективного управления данными в сервисе работы в социальных сетях"), (номер досье поверенного 4860.Р9240), имеющей порядковый номер 61/321,848, поданной 7 апреля 2010 г., имеющей в качестве изобретателей Amol Pattekar, Jeremy Werner, Patrick Gates, и Andrew H. Vyrros, (в дальнейшем именуемой как "Патентная заявка на сервис "друзей""), права по который принадлежат правообладателю по данной заявке, и которая включена в данную заявку посредством ссылки.
Как проиллюстрировано на Фигуре 20, в одном варианте реализации изобретения, игровой "демон" 2020 может сопрягать каркас 2000 игр с первым набором 2050, а компонент 2010 игровых сервисов может сопрягать каркас 2000 игр со вторым набором сервисов 2051. В порядке примера, первый набор сервисов 2050 может включать в себя сервис 112 приглашения, сервис 111 формирователя сочетания и сервис 1051 ретрансляции, описанные выше, и сервис "друзей", описанный в вышеупомянутой "Патентной заявке на сервис "друзей"". Другие сервисы, доступ к которым может быть осуществлен через игрового "демона" 2020, включает в себя сервис табло лидеров (предоставляющий данные табло лидеров); сервис игры (предоставляющий статистические и другие данные, относящиеся к каждой из игр и возможности приобрести игру); сервис аутентификации пользователя (для аутентификации пользователя мобильного устройства); и/или сервис профиля пользователя (для хранения данных профиля пользователя, таких как пользовательские предпочтения). Второй набор сервисов 2051, доступ к которому осуществляют через компонент 2010 игровых сервисов, может включать в себя описанные выше сервис 110 обмена соединительными данными (CDX - сервис) и сервисы 290-291 прохождения NAT - преобразования (преобразования сетевых адресов). Хотя в целях иллюстрации на Фигуре 20 они и проиллюстрированы как отдельные компоненты, игровой "демон" 2020 и модуль 2010 игровых сервисов могут на самом деле быть компонентами каркаса 2000 игр. В одном варианте реализации изобретения игровой "демон" 2020 и 2010 поддерживают связь с каждым из сетевых сервисов 2050-2051 через некоторый предварительно заданный API - интерфейс, который, в одном варианте реализации изобретения, является частным API - интерфейсом (то есть, не разглашается разработчикам - третьим лицам).
В одном варианте реализации изобретения игровой "демон" 2020 может поддерживать связь с сервисом 111 формирователя сочетания, сервисом 112 приглашения и другими сервисами 2050, используя HTTPS - протокол (Протокол защищенной передачи гипертекстов), в то время как модуль 2010 игровых сервисов может поддерживать связь с CDX - сервисом (Сервисом обмена соединительными данными) 110 и сервисами 290-291 прохождения NAT - преобразования (преобразования сетевых адресов), используя относительно легковесный протокол, такой как сокеты UDP - протокола (Протокола пользовательских дейтаграмм). Однако, как упоминалось ранее, могут использоваться и различные другие протоколы, что по-прежнему согласуется с принципами, лежащими в основе изобретения.
В дополнение к этому, как проиллюстрировано на Фигуре 20, игровой "демон" 2020 может принимать "проталкиваемые" уведомления 2052, сгенерированные некоторыми сервисами 2052 (например, сервисом приглашения и сервисом формирователя сочетания), в то время как другие типы "проталкиваемых" уведомлений 2053 могут приниматься напрямую игровым центром (например, уведомления сервиса "друзей", такие как запросы новых "друзей"). В одном варианте реализации изобретения эти "проталкиваемые" уведомления 2053 предоставляются непосредственно игровому центру 2031, чтобы гарантировать то, что уязвимые данные пользователя не будут сделаны доступными для приложений 2030, разработанных разработчиками приложений, являющимися третьими лицами.
Возвращаясь к примерам приглашения к игре, приведенным выше на Фигуре 11, отметим, что когда приложение 2030 на мобильном устройстве (А) делает приглашающий вызов в API - интерфейсе 2001 b каркаса 2000 игр для того, чтобы пригласить пользователя мобильного устройства (В) (например, вызов INVITE (идентификатор игрока (В), идентификатор Игры/"Короба")), каркас 2000 игр может передать этот запрос с приглашением игровому "демону" 2020 мобильного устройства (А). После этого игровой "демон" 2020 может осуществить связь с сервисом (112) приглашения для предоставления ему этого запроса с приглашением. После этого сервис 112 приглашения может использовать сервис 1050 "проталкиваемых" уведомлений (как это было описано выше) для "проталкивания" приглашения игровому "демону" 2020 мобильного устройства (В). После этого игровой "демон" 2020 мобильного устройства (В) может осуществить связь с каркасом 2000 игр мобильного устройства для того, чтобы определить, установлена ли игра, приглашение на которую прислано, на мобильном устройстве (В). Если установлена, то каркас 2000 игр может запустить приложение 2030 и/или сгенерировать визуальное уведомление о приглашении. Если приложение не установлено, то каркас 2000 игр может запустить визуальное уведомление о приглашении для пользователя мобильного устройства (В) с предложением приобрести эту игру (например, через графический пользовательский интерфейс игрового центра 2031). В качестве альтернативы, визуальное уведомление может быть сгенерировано "демоном" "проталкиваемых" уведомлений, функционирующим на мобильном устройстве 120 (здесь не показанным). Если пользователь мобильного устройства (В) приобретает эту игру, то после этого приобретения последовательность операций при приглашении может продолжиться. Если пользователь мобильного устройства (В) дает согласие этому запросу с приглашением, то каркас 2000 игр мобильного устройства (В) может передать запрос с приглашения своему игровому "демону" 2020, который затем может ответить сервису 112 приглашения.
Вспомним, что на Фигуре 11 на этапе 1106 проверки совместимости, определяется, что типы NAT - преобразования (преобразования сетевых адресов) мобильных устройств (А) и (В) совместимы. Таким образом, на этапе 1108 игровой "демон" 2020 мобильного устройства (А) может принять согласие мобильного устройства (В) (например, в этом примере - через "проталкиваемое" уведомление) и, в одном варианте реализации изобретения, передает это согласие каркасу 2000 игр. На этой стадии каркас 2000 игр на мобильном устройстве (А) может либо уведомить запрашивающее приложение 2030 о том, что мобильное устройство (В) дало согласие, (через API - интерфейс 2001) или может подождать уведомлять запрашивающее приложение 2030 до тех пор, пока устройства не будут успешно соединены. В любом случае каркас 2000 игр может передать запрос соединения модулю 2010 игровых сервисов, который, в одном варианте реализации изобретения может инициировать обмен соединительными данными с мобильным устройством (В). В частности, модуль игровых сервисов может передать мобильному устройству (В) соединительные данные мобильного устройства (А), используя CDX - сервис (сервис обмена соединительными данными) 110 (смотри, например, транзакции 1111 и 1112 на Фигуре 11). Как было описано выше, эта связь может быть реализована как UDP - соединение (соединение по Протоколу пользовательских дейтаграмм) с использованием защищенной структуры данных "билета".
Вспомним, что на Фигуре 12, если на этапе 1106 проверки совместимости определено, что типы NAT - преобразования мобильных устройств (А) и (В) не совместимы, то для обеспечения соединения между устройствами может быть использован сервис 1051 ретрансляции. Следовательно, игровой "демон" 2020 мобильного устройства (В) может получить от сервиса приглашения ответ 1203 о ретрансляции (показанный на Фигуре 12), а игровой "демон" 2020 мобильного устройства (А) может получить от сервиса приглашения ответ 1205 о ретрансляции (через сервис 1050 "проталкиваемых" уведомлений). Игровые "демоны" 2020 мобильных устройств (А) и (В) могут на этапах 1206 и 1207 осуществлять связь с сервисом ретрансляции для того, чтобы извлечь данные о конфигурации. На этапе 1210 игровой "демон" 2020 мобильного устройства (В) принимает данные корректировки ретрансляции от мобильного устройства (А), а на этапе 1213 игровой "демон" 2020 мобильного устройства (А) принимает данные корректировки ретрансляции от мобильного устройства (В).
Конечным результатом процессов, показанных на Фигурах 11 и 12, является то, что мобильными устройствами (А) и (В) установлено соединение друг с другом (либо прямое одноранговое соединение или ретрансляционное соединение). В одном варианте реализации изобретения после обнаружения успешного соединения каркас 2000 игр может уведомлять приложение 2030, который запросило соединение, используя вызов API - интерфейса (например, CONNECTED (идентификатор игрока (А), идентификатор игрока (В))) (то есть, СОЕДИНЕНЫ (идентификатор игрока (А), идентификатор игрока (В)))). После этого мобильные устройства (А) и (В) могут, используя установленное соединение, играть в указанную игру или использовать другое совместное используемое приложение 2030.
Таким образом, в ответ на относительно простой вызов с API - интерфейса 2001 (например, INVITE (идентификатор игрока (В), идентификатор Игры/"Короба") можно посредством каркаса 2000 игр управлять сложной последовательностью транзакций для установления однорангового или ретрансляционного соединения между мобильными устройствами (А) и (В). В одном варианте реализации изобретения каркас 2000 выполняет последовательность операций по соединению мобильных устройств (А) и (В) и после этого предоставляет результаты запрашивающему приложению 2030, оставляя, таким образом, подробности вызова API - интерфейса прозрачными для разработчика приложения. По существу дела, от разработчика приложения не требуется понимать то, как соединять мобильные устройства (А) и (В) в сети, или выполнять различный другие функции, требующиеся для установления связи между устройствами, что упрощает процесс разработки приложения.
Аналогичным образом, каркас 2000 игр может сформировать сочетание между мобильным устройством (А) и другими участниками, использующими сервис 111 формирователя сочетания, как это было описано выше в отношении Фигуры 2 а - b. В этом примере, приложение 2030 может сделать простой вызов в API - интерфейсе 2001, такой как MATCH (идентификатор игрока (А), идентификатор Игры/"Короба"). В ответ на это каркас 2000 игр может управлять операциями сочетания и обмена соединительными данными. Когда операции сочетания и/или одноранговые соединения завершены, каркас 2000 игр предоставляет результаты в обратном направлении приложению 2030.
Например, на Фигуре 2 b каркас 2000 игр может использовать модуль 2010 игровых сервисов для поддержания связи с сервисом обмена соединительными данными (CDX - сервисом) 110 и сервисами 290 - 291 прохождения NAT - преобразования (преобразования сетевых адресов) и может использовать игрового "демона" для поддержания связи с сервисом 111 формирователя сочетания. Как только сочетание сформировано, игровой "демон" 2020 мобильного устройства (А) принимает на этапе 229 Билет А, и каркас 2000 игр использует эту информацию для того, чтобы осуществить обмен соединительными данными через модуль 2010 игровых сервисов. Например, на этапе 232 он может через сервис 290 прохождения NAT - преобразования запросить свои собственные соединительные данные и после этого может осуществлять обмен своими соединительными данными на этапах 233 - 234 через CDX - сервис 110. На этапах 237 и 240 модуль 2010 игровых сервисов мобильного устройства (А) принимает соединительные данные для мобильных устройств (В) и (С), соответственно. Вслед за этими обменами данных модуль 2010 игровых сервисов устанавливает на этапе 241 одноранговые соединения и каркас 2000 игр, используя API - уведомление (уведомление в API - интерфейсе) (например, MATCH COMPLETE (идентификатор игрока (В), идентификатор игрока (С))) (то есть, СОЧЕТАНИЕ ЗАВЕРШЕНО (идентификатор игрока (В), идентификатор игрока (С))) уведомляет приложение 2030 о том, что процесс соединения завершен. После этого приложение, используя установленное одноранговое соединение, может исполняться.
В некоторых вариантах реализации изобретения пользователю может быть предоставлена опция сыграть в игру с другими "друзьями", которые в настоящее время зарегистрированы как "онлайн". В этом случае уведомление о том, что некоторые "друзья" находятся в режиме "онлайн", может быть предоставлено посредством "проталкиваемых" уведомлений 2052 или "проталкиваемых" уведомлений 2053 (принимаемых непосредственно игровым центром 2031). После этого игровой центр 2031 и/или приложения 2030 могут предоставить эти уведомления пользователю и предоставить пользователю опцию, чтобы сыграть с одним или более выбранными "друзьями", находящимися в режиме "онлайн". Однако следует отметить, что описанная здесь последовательность операций при приглашении будет работать независимо от того, предоставлены ли уведомления об "онлайн". В одном варианте реализации изобретения онлайновое состояние пользователя может контролироваться сервисом, доступ к которому может осуществлять игровой "демон" 2020 (например, упомянутым выше сервисом "друзей" или отдельным сервисом "присутствия").
Один вариант реализации каркаса 2000 игр предусматривает комбинированную операцию приглашения/формирования сочетания, в которой пользователь может пригласить одного или более друзей сыграть в некоторую игру с группой незнакомых сочетаемых с ними участников. Например, если игра требует 4 игроков, и первый пользователь приглашает второго пользователя сыграть в эту игру, то сервис 112 приглашения 112 может сначала соединить первого пользователя и второго пользователя, а сервис 111 формирования сочетания может затем сформировать сочетание первого пользователя и второго пользователя с двумя (или более) другими игроками. В этом варианте реализации изобретения каркас 2000 может сначала выполнить вышеописанные последовательности операций при приглашении для того, чтобы соединить первого пользователя и второго пользователя. В одном варианте реализации изобретения после того, как первый пользователь и второй пользователь были успешно соединены, каркас 2000 игр может осуществить последовательности операций формирования сочетания для того, чтобы идентифицировать других пользователей и соединиться с ними. Как было упомянуто выше, в одном варианте реализации изобретения критерии сочетания, применяемые сервисом формирования сочетания, могут включить в себя как первого, так и второго пользователя (например, типы NAT - преобразования (преобразования сетевых адресов), типы соединения, язык и т.д. как первого, так и второго пользователя). В качестве альтернативы, для принятия решения о сочетании могут оцениваться критерии одного из этих двух пользователей.
После того, как все пользователи соединены между собой, каркас 2000 игр может через API - интерфейс 2001 сообщить о результатах соединения приложению 2030, которое запрашивало соединение. Отметим еще раз, что в ответ на относительно простой вызов API - интерфейса, сделанный приложением 2030, каркас 2000 игр приступает к последовательности сложных транзакций для соединения каждого из устройств. После того, как устройства были успешно соединены, каркас 2000 игр сообщает о результатах в обратном направлении запрашивающему приложению 2030.
Как проиллюстрировано на Фигуре 20, каркас 2000 игр может включать в себя буфер 2003 связи для того, чтобы временно хранить сообщение, передаваемое между пользователем и другими участниками игры. Это передаваемое сообщение может включать в себя, например, текстовое, аудио- и/или видеосообщение. Каркас 2000 игр может создавать буфер 2003, основываясь на требованиях каждого приложения 2030. Например, для аудио-/видеосвязи с медленным сетевым соединением может требоваться относительно более емкий буфер 2003. В одном варианте реализации изобретения каждое приложение 2030 может обратиться через API - интерфейс 2001 с явно выраженным запросом создать буфер связи определенного размера (например, используя команду BUFFER (размер) (то есть, БУФЕР (размер)). В качестве альтернативы, каркас 2000 игр может автоматически создавать буфер, основываясь на требуемом объеме информационного обмена каждого приложения. Например, каркас 2000 игр может выбирать конкретный размер буфера, основываясь на том, требуется ли поддерживать передачу текстовых, аудио- и/или видеоданных.
В одном варианте реализации изобретения буфер 2003 связи может временно хранить потоки сообщений прежде, чем все одноранговые соединения между пользователями будут установлены. Например, после того, как сервис 112 приглашения или сервис 111 формирователя сочетания идентифицировал каждого из пользователей, но перед тем, как CDX - сервис (сервис обмена соединительными данными) ПО завершит операции обмена соединительными данными, каждый пользователь может быть уведомлен о других участниках игры, находящихся в процессе соединения. На этой стадии пользователь мобильного устройства 120 может передавать другим участникам потоки текстовых, аудио- и/или видеосообщений. Каркас 2000 игр сохранит эти потоки сообщений в буфере 2003 связи для тех участников, которые еще не подсоединены. После этого по мере завершения подсоединения для каждого устройства каркас 2000 игр может передавать эти текстовые, аудио- и/или видеоданные из буфера 2003.
В одном варианте реализации изобретения игровой "демон" 2020 включает в себя кэш - память 2021 для кэширования данных, постоянно используемых на каждом сервисе 2050, с целью уменьшения сетевого трафика. Например, как определяется политикой управления кэш - памятью, в кэш - памяти 2021 могут сохраняться список "друзей" пользователя, данные табло лидеров, данные достижений, данные присутствия и данные профиля. В одном варианте реализации изобретения политика управления кэш - памятью формируется каждым индивидуальным сервисом, по которому сохраняются данные. Следовательно, для n различных сервисов к кэш - памяти 2021 может применяться n различных политик управления кэш - памятью. В дополнение к этому, поскольку политика управления кэш - памятью формируется сервисами, то ее можно изменять динамически, основываясь на текущих условиях загрузки сети и/или сервера. Например, в те промежутки времени, когда сервис тяжело загружен (например, Рождество, день выпуска нового изделия и так далее), сервис может в динамическом режиме определить политику управления кэш - памятью с относительно нечастыми обновлениями кэш - памяти (например, обновления каждые 12 часов). В противоположность этому, в те промежутки времени, когда сервис не является тяжело загруженным, сервис может определить политику кэширования с более частыми обновлениями кэш - памяти (например, обновлениями каждые полчаса, час, 2 часа, и так далее).
В одном варианте реализации изобретения политика управления кэш - памятью определяется с использованием значения времени существования (TTL - значения) для определенных записей данных, хранящихся в кэш - памяти 2021. Когда запись данных хранилась в кэш - памяти сверх ее TTL - значения, тогда эти данные рассматриваются как "устаревшие" и напрямую сервису, связанному с этими данными, может быть отправлен локальный запрос по этим данном. В одном варианте реализации изобретения этот запрос включает в себя идентификационный код, идентифицирующий текущую версию этих данных. Если этот идентификационный код совпадает с идентификационным кодом на сервисе, то данные по-прежнему являются действительными и не нуждаются в обновлении. В таком случае от сервиса в обратном направлении может быть отправлен ответ, указывающий, что данные в кэш - памяти являются актуальными, и TTL - значение для этой записи данных может быть возвращено в исходное состояние.
В дополнение к использованию политики управления кэш - памятью, которая описана выше, в одном варианте реализации изобретения обновления кэш - памяти для некоторых типов данных могут "проталкиваться" мобильному устройству с использованием сервиса 1050 "проталкиваемых" уведомлений. Например, на мобильное устройство пользователя 120 в динамическом режиме могут "проталкиваться" изменения в списке "друзей" пользователя или в текущем онлайновом состоянии "друзей" пользователя. Это "проталкиваемое" уведомление может быть принято игровым "демоном" 2020, который после этого может обновить кэш - память 2021 таким образом, чтобы включить в нее соответствующую порцию данных, "проталкиваемых" сервисом (то есть обновление всех данные в кэш - памяти, связанных с этим сервисом может и не потребоваться). В противоположность этому, некоторые "проталкиваемые" уведомления могут отдать игровому "демону" 2020 команду переписать все содержимое кэш - памяти (или, по меньшей мере, участка кэш - памяти, связанного с сервисом, выполняющим "проталкивание").
Те сервисы, которые используют "проталкивание" для обновления кэш - памяти 2021, могут выбрать относительно высокие TTL - значения (и/или, могут не задавать TTL - значения), потому что они способны "проталкивать" уведомления для обновления данных, хранящихся в кэш - памяти 2021. В одном варианте реализации изобретения каждый сервис указывает набор событий, которые могут запустить обновление кэш - памяти "проталкивающими" уведомлениями. Например, события для обновления кэш - памяти могут включать в себя изменение в онлайновом состоянии "друга", запрос нового "друга", согласие на запрос "друга", операцию удаления из "друзей", указание на то, что "друг" играет в некоторую конкретную игру, игровое достижение, достигнутое "другом", изменения десятки лучших на некотором конкретном табло лидеров, или любые другие события, считающиеся достаточно важными для того, чтобы служить основанием для обновления кэш - памяти. Осуществляемое таким образом использование "проталкиваемых" уведомлений для обновления кэш - памяти 2021 может уменьшить нагрузку на сеть и на сервис, потому что в случае "проталкиваемых" обновлений периодический опрос, проводимый между мобильным устройством и сервисом, не требуется.
Один вариант реализации каркаса 2000 игр уникальным образом форматирует данные, представляемые конечному пользователю, на основе страны и/или географического местонахождения пользователя. Например, такие значения, как текущая дата, время и денежные значения могут быть представлены по-разному для пользователей в разных странах и местах расположения. В порядке примера, в Соединенных Штатах формат даты может представлять собой [месяц день, год] (например, апрель 25, 2010), тогда как в других странах, формат даты может представлять собой [день месяц, год] (например, 25 апреля 2010). Аналогичным образом, при представлении времени в США и некоторых других странах может быть использовано обозначение АМ/РМ (ДО ПОЛУДНЯ/ПОСЛЕ ПОЛУДНЯ), и между часами и минутами может использоваться двоеточие (например, 3:00 РМ). В противоположность этому, много других стран не используют обозначение АМ/РМ и/или не используют запятую между часами и минутами (например, 15,00). В качестве другого примера, много частей мира используют метрическую систему, в то время как некоторые части мира ее не используют (например, Соединенные Штаты). Следует отметить, что эти примеры представляют собой просто иллюстративные примеры, которые могут быть использованы в некоторых вариантах реализации изобретения. Принципы, лежащие в основе изобретения, не ограничены никаким конкретным набором форматов данных.
В одном варианте реализации изобретения эти различные форматы данных могут быть выбраны при отображении данных табло лидеров, данных о достижениях, данных о друзьях и/или любых других данных, обрабатываемых каркасом 2000 игр. Каркас 2000 игр может определить страну и/или географическое местонахождение пользователя различными способами. Например, в одном варианте реализации изобретения эта информация просто предоставляется в данных профиля пользователя и/или может быть определена на основе провайдера сервиса сотовой связи пользователя. Местонахождение пользователя может также быть определено с использованием, например, отслеживания в Глобальной системе позиционирования (GPS).
Каркас 2000 игр может также управлять другими типами форматирования данных, которые не связаны с географическим местонахождением и/или страной. Например, при отображении данных табло лидеров, важно знать, должен ли самый низкий количественный результат помещать пользователя в верхнюю или нижнюю часть табло лидеров. Для некоторых игр (например, гольф, бег, гонки, лыжный спорт и так далее) на более успешное выступление указывает более низкое число, тогда как в других играх (например, футболе, бейсболе и так далее) на более успешное выступление указывает более высокое число. Таким образом, в одном варианте реализации изобретения приложение 2030 через API - интерфейс 2001 указывает тип количественного результата, который будет использоваться (например, "повышающийся" или "понижающийся"). После этого каркас 2000 игр может использовать соответствующие набор ярлыков и форматирование для отображения этого количественного результата.
В одном варианте реализации каркаса 2000 игр также осуществляется фильтрация пользовательских данных на основе отношения между пользователем и "друзьями" пользователя. Например, один вариант реализации изобретения позволяет "детализированное" представление (данных), представление (данных) для "друзей" и "публичное" представление (данных). В одном варианте реализации изобретения детализированное представление доступно для пользователя, который владеет этими данными (то есть персональная информация пользователя); представление для "друзей" доступно для "друзей" пользователя; а публичное представление доступно для всех других пользователей.
В порядке примера, публичное представление может просто включать в себя: "псевдоним", связанный с каждым пользователем; игры, в которые играет лицо с этим псевдонимом и связанные с ними количественные результаты; и даты/время, в которые проводились эти игры. Эта информация может быть использована каркасом 2000 игр для заполнения публичного табло лидеров, которое может затем быть отображено через игровой центр 2031.
Представление для "друзей" может включать в себя всю информацию из общего представления, так же как и любую дополнительную информацию, подлежащую распространению среди "друзей" пользователя, включающую в себя, например: игры, имеющиеся у пользователя; игры, в которые играет пользователь; достижения и количественные результаты пользователя; сколько "друзей" имеется у пользователя; идентификаторы этих "друзей"; URL (унифицированный указатель ресурса), идентифицирующий "аватаров" пользователя, и/или онлайновое состояние пользователя - вот лишь некоторая из этой информации. В одном варианте реализации изобретения представление для "друзей" предоставляет некоторый набор по умолчанию для информации, подлежащей распространению среди друзей, но конечный пользователь может скорректировать эту конфигурацию, предоставляемую по умолчанию, и указать со скрупулезностью те типы информации, которыми следует делиться с каждым отдельным "другом" или группами "друзей" (например, с сотрудниками, членами семьи, друзьями по колледжу/средней школе и так далее).
"Детализированное" представление может включать в себя всю информацию из "публичного" представления и представления для "друзей" так же, как и любую другую информацию, которой от имени конечного пользователя управляют различные сервисы (2050). В порядке примера, оно может включать в себя: все данные профиля пользователя; Универсальный уникальный идентификатор пользователя ("UUID - идентификатор") (иногда упоминаемый здесь как "идентификатор игрока"); имя игрока; псевдонимы; количество игр и что это за игры; друзей пользователя; все достижения пользователя и так далее.
При некоторых обстоятельствах, приложение 2030 может требовать только небольшое количество информации, относящейся к каждому пользователю, такой как идентификатор игрока каждого пользователя. Например, в одном варианте реализации изобретения, когда запрашивается сочетание, каркас 2000 игр может первоначально потребовать только идентификатор каждого игрока. По мере того как сочетания формируются сервисом формирователя сочетания (смотри выше), каркас 2000 игр может определить то, являются ли какие - либо из включенных в сочетание пользователей "друзьями" (например, посредством осуществления связи с сервисом друзей и/или запрашивая местные локальные пользовательские данные о "друзьях"). Если эти пользователи "друзьями" являются, то каркас 2000 игр может извлечь дополнительные данные о пользователе и предоставить эти данные каким - либо из включенных в сочетание "друзьям". Таким образом, каркас 2000 игр фильтрует информацию, основываясь на личности пользователей и отношении между каждым из пользователей.
В одном варианте реализации изобретения каркас 2000 игр первоначально предоставляет между первым пользователем и вторым пользователем публичное представление (данных), если эти два пользователя не имеют "дружеского" отношения. Однако в одном варианте реализации изобретения каркас 2000 игр позволяет первому пользователю отправить второму пользователю запрос "друга" (например, используя псевдоним второго пользователя). Если на запрос "друга" отвечают согласием, то каркас 2000 игр предоставляет каждому из пользователей дополнительную информацию (например, представление (данных) для "друзей", предоставляемое по умолчанию).
Различные варианты реализации API - интерфейса API - интерфейс, реализованный в одном варианте осуществления изобретения, представляет собой интерфейс, реализованный программным компонентом (в дальнейшем именуемым как "программный компонент реализации API - интерфейса"), который позволяет другому программному компоненту (в дальнейшем именуемому как "программный компонент вызова API - интерфейса") осуществлять доступ к одной (одному) или более функций, способов, процедур, структур данных и/или других сервисов, предоставляемых программным компонентом реализации API - интерфейса, и использовать их. Например, API - интерфейс позволяет разработчику программного компонента вызова API - интерфейса (который может быть разработчиком, являющимся третьим лицом) усиливать указанные функциональные возможности, предоставляемые программным компонентом реализации API - интерфейса. Может иметься один программный компонент вызова API - интерфейса или может иметься больше чем один такой программный компонент. API - интерфейс может быть интерфейсом с исходным кодом, который компьютерная система или библиотека программ предоставляет для того, чтобы поддерживать запросы на сервисы от программного приложения. API - интерфейс может быть определен в терминах языка программирования, который может быть интерпретационным или транслируемым при построении приложения, а не явным низкоуровневым описанием того, как данные располагаются в памяти.
API - интерфейс определяет язык и параметры, которые программные компоненты вызова API - интерфейса используют при осуществлении доступа к указанным функциональным возможностям программного компонента реализации API - интерфейса и при использовании этих функциональных возможностей. Например, программный компонент вызова API - интерфейса осуществляет доступ к указанным функциональным возможностям программного компонента реализации API - интерфейса через один или более вызовов API - интерфейса (иногда именуемых как вызовы функции или вызовы способа), выставляемых API - интерфейсом. Программный компонент реализации API - интерфейса может в ответ на вызов API - интерфейса, поступающий от программного компонента вызова API - интерфейса, возвращать через API - интерфейс некоторое значение. В то время как API - интерфейс определяет синтаксис и результат вызова API - интерфейса (например, то, как сделать вызов API - интерфейса и что вызов API - интерфейса делает), API - интерфейс обычно не раскрывает то, каким образом вызов API - интерфейса выполняет функцию, указанную вызовом API - интерфейса. Между вызывающим программным обеспечением (программным компонентом вызова API - интерфейса) и программным компонентом реализации API - интерфейса передаются через один или более интерфейсов прикладного программирования разнообразные вызовы функций или сообщения. Передача вызовов функций или сообщений может включать в себя выдачу, инициирование, запуск, вызов, прием, возврат или выдачу ответа на вызовы функций или сообщения. Следовательно, программный компонент вызова API - интерфейса может передавать вызов, и программный компонент реализации API - интерфейса может передавать вызов.
В порядке примера, программный компонент (2010) реализации API - интерфейса и программный компонент вызова API - интерфейса могут представлять собой операционную систему, библиотеку, драйвер устройства, API - интерфейс, прикладную программу или другой модуль программного обеспечения (следует понимать, что программный компонент реализации API - интерфейса и программный компонент вызова API - интерфейса могут относиться к одному и тому же типу программного модуля или к типам модуля программного обеспечения, отличным друг от друга). Программный компонент вызова API - интерфейса может представлять собой локальный программный компонент (то есть располагаться на той же самой системе обработки данных, что и программный компонент реализации API - интерфейса) или удаленный программный компонент (то есть располагаться на другой системе обработки данных по отношению к программному компоненту реализации API - интерфейса), который поддерживает связь с программным компонентом реализации API - интерфейса через API - интерфейс по сети. Следует понимать, что программный компонент реализации API - интерфейса может также действовать в качестве программного компонента вызова API - интерфейса (то есть он может делать вызовы API - интерфейса, обращенные к API - интерфейсу, выставляемому другим программным компонентом реализации API - интерфейса), и программный компонент вызова API - интерфейса может также действовать в качестве программного компонента реализации API - интерфейса, реализуя API - интерфейс, который выставляется для другого программного компонента вызова API - интерфейса.
API - интерфейс может позволять поддерживать связь с программным компонентом реализации API - интерфейса множественным программным компонентам вызова API - интерфейса, написанным на различных языках программирования (таким образом, API - интерфейс может включать в себя функциональные возможности по преобразованию вызовов и возвращаемых результатов между программным компонентом реализации API - интерфейса и программным компонентом вызова API - интерфейса); однако API - интерфейс может быть реализован в терминах одного конкретного языка программирования.
На Фигуре 21 проиллюстрирован один вариант реализации архитектуры API - интерфейса, который включает в себя программный компонент 2110 реализации API - интерфейса (например, операционную систему, библиотеку, драйвер устройства, API - интерфейс, прикладную программу или другой модуль программного обеспечения), который реализует API - интерфейс 2120. API - интерфейс 2120 определяет одну (один) или более функций, способов, классов, объектов, протоколов, структур данных, форматов и/или других функциональных возможностей программного компонента реализации API - интерфейса, которые могут использоваться программным компонентом 2130 вызова API - интерфейса. API - интерфейс 2120 может определять, по меньшей мере, одно соглашение о вызовах, которое определяет то, каким образом функция в программном компоненте реализации API - интерфейса принимает параметры от программного компонента вызова API - интерфейса и каким образом эта функция возвращает результат программному компоненту вызова API - интерфейса. Для того чтобы осуществить доступ к функциональным возможностям программного компонента 2110 реализации API - интерфейса, которые определены API - интерфейсом 2120, и использовать эти функциональные возможности, программный компонент 2130 вызова API - интерфейса (например, операционная система, библиотека, драйвер устройства, API - интерфейс, прикладная программа, или другой модуль программного обеспечения) делает вызовы API - интерфейса через API - интерфейс 2120. Программный компонент 2110 реализации API - интерфейса может через API - интерфейс 2120 в ответ на вызов API - интерфейса возвращать программному компоненту 2130 вызова API - интерфейса некоторое значение.
Следует понимать, что программный компонент 2110 реализации API - интерфейса может включать в себя дополнительные функции, способы, классы, структуры данных и/или другие функциональные возможности, которые не определены через API - интерфейс 2120 и не доступны для программного компонента 2130 вызова API - интерфейса. Следует понимать, что программный компонент 2130 вызова API - интерфейса может располагаться на той же самой системе, что и программный компонент 2110 реализации API - интерфейса, или может быть расположен удаленно и осуществлять доступ к программному компоненту 2110 реализации API - интерфейса, используя API - интерфейс 2120 по сети. В то время как на Фигуре 21 проиллюстрирован единственный программный компонент 2130 вызова API - интерфейса, взаимодействующий с API - интерфейсом 2120, следует понимать, что этот API - интерфейс 2120 может использоваться и другими программным компонентами вызова API - интерфейса, которые могут быть написаны на различных языках (или на одном и том же языке) с программным компонентом 2130 вызова API - интерфейса.
Программный компонент 2110 реализации API - интерфейса, API - интерфейс 2120 и программный компонент 2130 вызова API - интерфейса могут храниться на машиночитаемом носителе информации, которая включает в себя любой механизм для хранения информации в форме, читаемой машиной (например, компьютером или другой системой обработки данных). Например, термин "машиночитаемый носитель информации" включает в себя магнитные диски, оптические диски, оперативное запоминающее устройство; постоянное запоминающее устройство, устройства флэш - памяти и так далее.
На Фигуре 22 ("Комплект программного обеспечения"), в приводимом в качестве примера варианте реализации изобретения, приложения могут делать вызовы, обращенные к Сервисам (1) или (2), используя несколько API - интерфейсов сервисов, и к Операционной системе (ОС), используя несколько API - интерфейсов операционной системы. Сервисы (1) и (2) могут делать вызовы, обращенные к операционной системе, используя несколько API - интерфейсов операционной системы.
Отметим, что Сервис (2) имеет два API - интерфейса, один из которых (API - интерфейс (1) Сервиса (2)) принимает вызовы от Приложения (1) и возвращает ему значения, а другой (API - интерфейс (2) Сервиса (2)), принимает вызовы от Приложения (2) и возвращает ему значения. Сервис (1) (который может представлять собой, например, библиотеку программного обеспечения) делает вызовы API - интерфейсу (1) операционной системы и принимает от него возвращаемые значения, а Сервис 2 (который может представлять собой, например, библиотеку программного обеспечения) делает вызовы как API - интерфейсу (1) операционной системы, так и API - интерфейсу (2) операционной системы и принимает от них возвращаемые значения. Приложение 2 делает вызовы API - интерфейсу (2) операционной системы и принимает от него возвращаемые значения.
Приводимые в качестве примера устройства обработки данных по Фигуре 23 представляет собой структурную схему, иллюстрирующую приводимую в качестве примера компьютерную систему, которая может быть использована в некоторых вариантах реализации изобретения. Следует понимать, что хотя Фигура 23 иллюстрируют разнообразные компоненты компьютерной системы, она не предназначена для того, что представлять какую-либо конкретную архитектуру или способ взаимного соединения компонентов, поскольку такие подробности не являются тесно связанными с настоящим изобретением. Следует понимать, что с настоящим изобретением могут также быть использованы и другие компьютерные системы, которые имеют меньшее количество компонентов или большее количество компонентов.
Как проиллюстрировано на Фигуре 23, компьютерная система 2300, которая является разновидностью системы обработки данных, включает в себя шину (шины) 2350, которая соединена с процессорной системой 2320, источником 2325 электропитания, памятью 2330 и энергонезависимой памятью 2340 (например, накопителем на жестких магнитных дисках, флэш-памятью, памятью с изменением фазы (РСМ - памятью) и так далее). Шина (шины) 2350 могут быть соединены друг с другом через различные мосты, контроллеры и/или адаптеры, как это хорошо известно в данной области техники. Процессорная система 2320 может извлекать команду (команды) из памяти 2330 и/или из энергонезависимой памяти 2340 и исполнять эти команды для выполнения операций, которые описаны выше. Шина 2350 соединяет между собой вышеупомянутые компоненты и также соединяет эти компоненты с необязательным доком 2360, контроллером дисплея и дисплеем 2370, устройствами 2380 ввода - вывода (например, NIC - картой (Сетевой интерфейсной картой), средством управления курсором (например, мышью ", сенсорным экраном, сенсорной панелью и так далее), клавиатурой и так далее), и необязательным (необязательными) приемопередатчиком (приемопередатчиками) 2390 беспроводной связи (например, Bluetooth, WiFi, Инфракрасным и так далее).
Фигура 24 представляет собой структурную схему, на которой проиллюстрирована приводимая в качестве примера система обработки данных, которая может быть использована в некоторых вариантах реализации изобретения. Например, система 2400 обработки данных может представлять собой карманный персональный компьютер, персональный цифровой секретарь (PDA), мобильный телефон, портативную игровую систему, портативный универсальный проигрыватель, планшетное или карманное вычислительное устройство, которое может включать в себя мобильный телефон, универсальный проигрыватель и/или игровую систему. В качестве другого примера, система 2400 обработки данных может представлять собой сетевой компьютер или устройство обработки данных, встроенное в другое устройство.
В соответствии с одним вариантом реализации изобретения приводимая в качестве примера архитектура системы 2400 обработки данных может использоваться для мобильных устройств, описанных выше. Система 2400 обработки данных включает в себя процессорную систему 2420, которая может включать в себя один или более микропроцессоров и/или систему на интегральной схеме. Процессорная система 2420 соединена с памятью 2410, источником 2425 электропитания (который включает в себя одну или более батарей), устройством 2440 ввода/вывода звука, контроллер дисплея и дисплей 2460, необязательные устройства 2450 ввода/вывода, устройство (устройства) 2470 ввода и приемопередатчик (приемопередатчики) 2430 беспроводной связи. Следует понимать, что частью системы 2400 обработки данных в некоторых вариантах реализации изобретения могут также быть дополнительные компоненты, которые не показывают на Фигуре 24, а в некоторых вариантах реализации изобретения может использоваться меньше компонентов, чем показано на Фигуре 24. В дополнение к этому, следует понимать, что для взаимного соединения разнообразных компонентов могут использоваться одна или более шин, не показанных на Фигуре 24, как это хорошо известно в данной области техники.
Память 2410 может хранить данные и/или программы, предназначенные для исполнения системой 2400 обработки данных. Устройство 2440 ввода/вывода звука может включать в себя микрофон и/или громкоговоритель, предназначенные, например, для проигрывания музыки и/или предоставления посредством громкоговорителя и микрофона функциональных возможностей телефонной связи. Контроллер дисплея и дисплей 2460 могут включать в себя графический пользовательский интерфейс (GUI - интерфейс). Приемопередатчики 2430 беспроводной (например, радиочастотной) связи (например, приемопередатчик WiFi, инфракрасный приемопередатчик, приемопередатчик Bluetooth, приемопередатчик беспроводной сотовой телефонной связи, и так далее) могут использоваться для поддержания связи с другими системами обработки данных. Одно или больше устройств 2470 ввода позволяют пользователю, чтобы обеспечивать ввод данных в систему. Эти устройства ввода могут представлять собой цифровую клавиатуру, клавиатуру, сенсорную панель, сенсорную панель с возможностью одновременного нажатия нескольких сенсорных кнопок и так далее. Необязательно другое устройство 2450 ввода/вывода может представлять собой соединитель для дока.
Варианты реализации изобретения могут, как это сформулировано выше, включать в себя различные этапы. Эти этапы могут быть воплощены в машиноисполняемых командах, которые заставляют универсальный или специализированный процессор выполнять определенные этапы. В качестве альтернативы, эти этапы могут быть выполнены специальными аппаратными компонентами, которые содержат аппаратную логику для выполнения этих этапов, или любой комбинацией запрограммированных компьютерных компонентов и сделанных по заказу аппаратных компонентов.
Элементы настоящего изобретения могут также быть предоставлены в виде машиночитаемого носителя информации, предназначенного для хранения машиноисполняемого кода программы. Машиночитаемый носитель информации может включать в себя: гибкие магнитные диски, оптические диски, постоянные запоминающие устройства на компакт - дисках (CD-ROM) и магнитооптические диски, постоянные запоминающие устройства, оперативные запоминающие устройства, стираемые программируемые постоянные запоминающие устройства, электрически стираемые программируемые постоянные запоминающие устройства, магнитные или оптические карты или другой тип носителей / машиночитаемого носителя информации, пригодного для хранения электронного кода программы, но не ограничивается вышеперечисленными носителями.
Повсюду в приведенном выше описании, в целях разъяснения были приведены многочисленные конкретные подробности для того, чтобы обеспечить полное понимание изобретения. Однако специалисту в данной области техники должно быть ясно, что изобретение может быть осуществлено без некоторых из этих конкретных подробностей. Например, специалистам в данной области техники легко понять, что описанные здесь функциональные модули и способы могут быть реализованы как программное обеспечение, аппаратное обеспечение или любая их комбинация. Кроме того, хотя варианты реализации изобретения описаны здесь в рамках контекста мобильной вычислительной среды (то есть с использованием мобильных устройств 120-123; 601-603), принципы, лежащие в основе изобретения, не ограничены реализацией в мобильной вычислительной среде. В некоторых вариантах реализации изобретения может быть использован фактически любой тип клиентских или одноранговых устройств обработки данных, включая, например, настольные персональные компьютеры или компьютеры - рабочие станции. Соответственно, объем и сущность изобретения должны оцениваться на основе формулы изобретения, которая следует ниже.
Группа изобретений относится к области компьютерных сетей. Техническим результатом является обеспечение возможности установления, поддержания и использования резервных каналов в одноранговой (Р2Р) сети. Каждое мобильное устройство может установить первичный канал одноранговой связи с одним или более другими мобильными устройствами. Как только первичный канал установлен, каждое мобильное устройство может использовать первичный канал для осуществления обмена данными о соединении по вторичному каналу и может вслед за этим открыть один или более вторичных каналов одноранговой связи с указанными другими мобильными устройствами. При обнаружении того, что первичный канал одноранговой связи нарушен или ухудшился ниже заданного порога (например, некоторого порогового значения ширины полосы пропускания или скорости передачи битов), один из вторичных каналов одноранговой связи может быть автоматически сделан первичным каналом одноранговой связи. 3 н. и 21 з.п. ф-лы, 30 ил., 3 табл.
1. Реализуемый компьютером способ установления и поддержания резервных каналов для одноранговой связи (P2P - связи), содержащий этапы, на которых:
открывают первичный канал одноранговой связи с одним или более мобильными вычислительными устройствами, причем первичный канал одноранговой связи выполнен с возможностью использования для открытия сеансов одноранговой связи с указанными одним или более мобильными вычислительными устройствами;
осуществляют обмен данными о соединении по вторичному каналу с указанным одним или более мобильными вычислительными устройствами по первичному каналу одноранговой связи;
используют данные о соединении по вторичному каналу для открытия одного или более вторичных каналов одноранговой связи с указанным одним или более мобильными вычислительными устройствами;
обнаруживают, что первичный канал одноранговой связи ухудшился ниже заданного порога; и
в ответ на это делают один из вторичных каналов одноранговой связи первичным каналом одноранговой связи.
2. Способ по п.1, дополнительно содержащий этап, на котором:
поддерживают вторичные каналы связи посредством периодической передачи по вторичным каналам связи пакета "сердцебиения" (пакета, подтверждающего работоспособность каналов).
3. Способ по п.1, в котором на этапе открытия первичного канала связи осуществляют обмен данными о соединении с указанным одним или более мобильными вычислительными устройствами.
4. Способ по п.3, в котором на этапе осуществления обмена данными о соединении дополнительно исполняют последовательность транзакций по установлению соединения в сети Интернет (ICE-транзакций).
5. Способ по п.1, в котором заданный порог содержит нарушение первичного канала связи.
6. Способ по п.1, дополнительно содержащий этап, на котором:
сохраняют данные о соединении, относящиеся к первичному каналу связи и указанному одному или более вторичным каналам связи, на запоминающем устройстве вместе с данными о текущем состоянии каждого из каналов связи.
7. Способ по п.1, в котором каждый канал связи составлен из набора линий связи, включающих в себя линии беспроводной сотовой связи третьего поколения (3G), и/или линии беспроводной сотовой связи четвертого поколения (4G), и/или линии связи Wi-Fi, и/или линии связи Bluetooth.
8. Способ по п.1, в котором, по меньшей мере, один первичный или вторичный канал одноранговой связи включает в себя линию частной сети между первым мобильным вычислительным устройством и вторым мобильным вычислительным устройством, причем одноранговое соединение со вторым мобильным устройством установлено через первое мобильное вычислительное устройство.
9. Мобильное вычислительное устройство, содержащее память для хранения программного кода и процессор для обработки программного кода для выполнения операций:
открытия первичного канала одноранговой связи с одним или более другими мобильными вычислительными устройствами, причем первичный канал одноранговой связи выполнен с возможностью открытия сеансов одноранговой связи с указанным одним или более мобильными вычислительными устройствами;
осуществления обмена данными о соединении по вторичному каналу с указанным одним или более другими мобильными вычислительными устройствами по первичному каналу одноранговой связи;
использования данных о соединении по вторичному каналу для открытия одного или более вторичных каналов одноранговой связи с указанным одним или более другими мобильными вычислительными устройствами;
обнаружения, что первичный канал одноранговой связи ухудшился ниже заданного порога; и
в ответ на это установления одного из вторичных каналов одноранговой связи первичным каналом одноранговой связи.
10. Мобильное вычислительное устройство по п.9, содержащее дополнительный программный код, вызывающий выполнение процессором операций:
поддержания вторичных каналов связи посредством периодической передачи по вторичным каналам связи пакета "сердцебиения".
11. Мобильное вычислительное устройство по п.9, в котором открытие первичного канала связи содержит осуществление обмена данными о соединении с указанным одним или более мобильными вычислительными устройствами.
12. Мобильное вычислительное устройство по п.11, в котором осуществление обмена данными о соединении дополнительно содержит исполнение последовательности транзакций по установлению соединения в сети Интернет (ICE-транзакций).
13. Мобильное вычислительное устройство по п.9, в котором заданный порог содержит нарушение первичного канала связи.
14. Мобильное вычислительное устройство по п.9, содержащее дополнительный программный код, вызывающий выполнение процессором операций:
сохранения данных о соединении, относящихся к первичному каналу связи и указанному одному или более вторичным каналам связи, на запоминающем устройстве вместе с данными о текущем состоянии каждого из каналов связи.
15. Мобильное вычислительное устройство по п.9, в котором каждый канал связи составлен из набора линий связи, включающих в себя: линии беспроводной сотовой связи третьего поколения (3G), и/или линии беспроводной сотовой связи четвертого поколения (4G), и/или линии связи Wi-Fi, и/или линии связи Bluetooth.
16. Мобильное вычислительное устройство по п.9, в котором, по меньшей мере, один первичный или вторичный канал одноранговой связи включает в себя линию частной сети между первым мобильным вычислительным устройством и вторым мобильным вычислительным устройством, причем одноранговое соединение со вторым мобильным устройством установлено через первое мобильное вычислительное устройство.
17. Машиночитаемый носитель информации, содержащий хранящийся на нем программный код, который при его исполнении вычислительным устройством вызывает выполнение вычислительным устройством операции:
открытия первичного канала одноранговой связи с одним или более другими мобильными вычислительными устройствами, причем первичный канал одноранговой связи выполнен с возможностью открытия сеансов одноранговой связи с указанным одним или более мобильными вычислительными устройствами;
осуществления обмена данными о соединении по вторичному каналу с указанным одним или более другими мобильными вычислительными устройствами по первичному каналу одноранговой связи;
использования данных о соединении по вторичному каналу для открытия одного или более вторичных каналов одноранговой связи с указанным одним или более другими мобильными вычислительными устройствами;
обнаружения, что первичный канал одноранговой связи ухудшился ниже заданного порога; и
в ответ на это установления одного из вторичных каналов одноранговой связи первичным каналом одноранговой связи.
18. Машиночитаемый носитель информации по п.17, содержащий дополнительный программный код, вызывающий выполнение процессором операций:
поддержания вторичных каналов связи посредством периодической передачи по вторичным каналам связи пакета "сердцебиения".
19. Машиночитаемый носитель информации по п.17, в котором открытие первичного канала связи содержит осуществление обмена данными о соединении с указанным одним или более мобильными вычислительными устройствами.
20. Машиночитаемый носитель информации по п.19, в котором обмен данными о соединении дополнительно содержит исполнение последовательности транзакций по установлению соединения в сети Интернет (ICE-транзакций).
21. Машиночитаемый носитель информации по п.17, в котором заданный порог содержит нарушение первичного канала связи.
22. Машиночитаемый носитель информации по п.17, содержащий дополнительный программный код, вызывающий выполнение процессором операций:
сохранения данных о соединении, относящихся к первичному каналу связи и указанному одному или более вторичным каналам связи, на запоминающем устройстве вместе с данными о текущем состоянии каждого из каналов связи.
23. Машиночитаемый носитель информации по п.17, в котором каждый канал связи составлен из набора линий связи, включающих в себя: линии беспроводной сотовой связи третьего поколения (3G), и/или линии беспроводной сотовой связи четвертого поколения (4G), и/или линии связи Wi-Fi, и/или линии связи Bluetooth.
24. Машиночитаемый носитель информации по п.17, в котором, по меньшей мере, один первичный или вторичный канал одноранговой связи включает в себя линию частной сети между первым мобильным вычислительным устройством и вторым мобильным вычислительным устройством, причем одноранговое соединение со вторым мобильным устройством установлено через первое мобильное вычислительное устройство.
| Пломбировальные щипцы | 1923 |
|
SU2006A1 |
| Пресс для выдавливания из деревянных дисков заготовок для ниточных катушек | 1923 |
|
SU2007A1 |
| Колосоуборка | 1923 |
|
SU2009A1 |
| Способ приготовления мыла | 1923 |
|
SU2004A1 |
| ЭФФЕКТИВНОЕ ПО МОЩНОСТИ ПЛАНИРОВАНИЕ КАНАЛОВ В БЕСПРОВОДНОЙ СЕТИ | 2003 |
|
RU2319311C2 |
