Одноранговая сеть доставки контента, способ и управляющее устройство

Одноранговая сеть доставки контента, способ и управляющее устройство

Иллюстрации

Показать все

Реферат

УРОВЕНЬ ТЕХНИКИ

ОБЛАСТЬ ИЗОБРЕТЕНИЯ

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Настоящее изобретение предлагает одноранговую сеть доставки контента (далее, сеть CDN), которая может быть добавлена к любой существующей стандартной сети доставки контента или конфигурации сервера без каких-либо изменений серверных систем. Одноранговая сеть CDN в соответствии с настоящим изобретением создается, когда конечный пользователь инсталлирует локальный шлюзовой сервер для одноранговых узлов на клиентский компьютер. Шлюзовой сервер принимает запрос (запросы) от потребляющего медиаклиента с помощью зашифрованных или незашифрованных соединений (например, НТТР, HTTPS, Secure Socket, и/или Socket).

Локальный шлюзовой сервер действует как одноранговый узел в одноранговой сети и имеет зашифрованную кэш-память для хранения данных для доставки на другие одноранговые узлы или для локальной доставки для потребляющего данные клиента. Локальный шлюзовой сервер может также извлекать ресурсы из связанного с ним удаленного источника данных (например, сервер или другая сеть CDN). Потребляющему данные клиенту нужно только передать один запрос на шлюзовой сервер, и шлюзовой сервер управляет ресурсами и сетевым соединением независимо от клиента. Этот тип инсталляции позволяет доставку медиа не только для автономных приложений рабочего стола, но также для браузеров и медиаплееров, и мобильных приложений, которые имеют стандартные возможности веб-браузеров (например, HTTP, HTTPS, и/или Socket).

Настоящее изобретение предлагает шлюзовой сервер одноранговых узлов (peer-to-peer,P2P), который принимает сообщение от клиента на локальный компьютер. Сообщение или запрос могут форматироваться как стандартный HTTP запрос, направленный на локальный шлюзовой сервер, который будет зарегистрирован под именем локального домена. Предполагается, что упомянутый запрос (запросы) могут форматироваться различно, если новый протокол передачи создается, который ссылается на зарезервированный порт, где размещается шлюзовой сервер. В этом случае, запрос будет форматироваться немного иным путем (т.е. без HTTP префикса).

Изобретение предлагает сервер имен ресурсов (далее, сервер RNS), при этом сервер RNS кэширует URL ресурса (универсальный адрес ресурса) и местоположения ресурсов (т.е. IP адреса) и разрешает запросы ресурсов с адресов компьютеров (машинных адресов). Общий процесс или методология для несогласованного типа медиа будут следующими.

1. Клиент направляет запрос ресурсов на шлюзовой сервер;

2. Шлюзовой сервер затем направляет запрос на сервер RNS для разрешения запроса ресурсов с адресом ресурсов;

3. Как только запрос ресурса согласован с оптимальными (наименее дорогостоящими) местоположениями ресурсов, данные местоположения ресурсов возвращаются на шлюзовой сервер;

4. Шлюз затем направляет запрос данных ресурсов соответствующим компьютерам или серверным кластерам;

5. Затем эти компьютеры и серверные кластеры отвечают, посредством передачи запрошенных данных, шлюзовому серверу, размещаемому на этом локальном компьютере.

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

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

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

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

Шлюзовой сервер принимает запрос и затем разрешает запрос для ресурса с помощью сервера имен ресурсов (сервер RNS) (т.е. сервера индексирования ресурсов). Сервер RNS готовит ответ с местоположениями ресурсов (IP адрес), которые могут быть источниками ресурсов или одноранговыми узлами ресурсов. Учитывая то, что упомянутая сеть является инвариантной для источника данных, данные одноранговых узлов не управляются центральным сервером данных, а индексируются на сервере RNS и как запросы передаются и кэшируются на шлюзовом сервере.

Соответственно, в такой сети источник данных находится отдельно от сервера индексирования ресурсов, таким образом, позволяя автономному клиенту заполнить любой запрос от источника данных или одноранговой сети Р2Р, поскольку данные в пределах сети Р2Р кэшируются, когда запрос передается от автономного клиента.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

На Фиг. 1 представлен схематический рисунок фрагментированного расположения для файла данных, включая строки пакетов суб-потока и столбцы пакетов проверки достоверности.

На Фиг. 2 представлен первый схематический рисунок общего представления системы в соответствии с настоящим изобретением, изображающий шлюзовой сервер, расположенный между облаком серверных кластеров и сервером имен ресурсов.

На Фиг. 3 представлен второй схематический рисунок общего представления системы в соответствии с настоящим изобретением, изображающий шлюзовой сервер, расположенный между облаком серверных кластеров и сервером имен ресурсов.

На Фиг. 4 представлен схематический рисунок общего представления системы сервера имен доменов.

На Фиг. 5 представлен схематический рисунок общего представления системы сервера имен ресурсов.

На Фиг. 6 представлен схематический рисунок общего представления не встраиваемого средства безопасности.

На Фиг. 7 представлен схематический рисунок традиционных взаимосвязей клиент-сервер, когда клиент запрашивает данные и сервер доставляет данные.

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

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

На Фиг. 10 представлен схематический рисунок общего представления централизованной гибридной одноранговой сети, в которой одноранговая сеть используется наряду с централизованным источником данных / сервером индексирования, чтобы обеспечить низкие затраты доставки для однорангового узла, но и корректность и скорость централизованного источника данных.

На Фиг. 11 представлен схематический рисунок общего представления шлюзового сервера одноранговой сети.

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

На Фиг. 13 представлен схематический рисунок того, как через подключение проверяется подлинность шлюзового сервера.

На Фиг. 14 представлен схематический рисунок индексации ресурсов с первоначальным запросом и без сопоставления файлов.

На Фиг. 15 представлен схематический рисунок варианта индексации ресурсов с последующим запросом и без сопоставления файлов.

На Фиг. 16 представлен схематический рисунок варианта развивающейся облачной индексации с первоначальным запросом.

На Фиг. 17 представлен схематический рисунок варианта локальной индексации ресурсов.

На Фиг. 18 представлен схематический рисунок первого варианта процесса обработки запроса индексированных ресурсов.

На Фиг. 19 представлен схематический рисунок второго варианта процесса обработки запроса индексированных ресурсов.

На Фиг. 20 представлен схематический рисунок третьего варианта процесса обработки запроса индексированных ресурсов.

На Фиг. 21 представлен схематический рисунок четвертого варианта процесса обработки запроса индексированных ресурсов.

На Фиг. 22 представлен схематический рисунок варианта облачной доставки, сублицензирования.

На Фиг. 23 представлен схематический рисунок варианта сублицензирования доставки для одноранговых узлов.

На Фиг. 24 представлен первый схематический рисунок поставщика потоковой передачи при запросе воспроизведения песни на мобильном устройстве в соответствии с настоящим изобретением.

На Фиг. 25 представлен второй схематический рисунок поставщика потоковой передачи при запросе воспроизведения песни на мобильном устройстве в соответствии с настоящим изобретением.

На Фиг. 26 представлен схематический рисунок общего вида расширенной шлюзовой серверной системы в соответствии с настоящим изобретением.

На Фиг. 27 представлен схематический рисунок структуры очереди предварительно записаного медиа в соответствии с настоящим изобретением.

На Фиг. 28 представлен схематический рисунок механизма деления потока в соответствии с настоящим изобретением.

На Фиг. 29 представлен схематический рисунок МР3 файловой структуры в соответствии с настоящим изобретением, изображающий заголовки кадров и аудиокадры аудиопотока.

На Фиг. 30 представлен схематический рисунок способов современного уровня техники для потокового радио через сеть Интернет.

На Фиг. 31 представлен схематический рисунок общего вида системы для интеграции рекламы без микширования звука в соответствии с настоящим изобретением.

На Фиг. 32 представлен схематический рисунок с представлением варианта рекламного маркера в соответствии с настоящим изобретением.

На Фиг. 33 представлен схематический рисунок методологии, связанной с маршрутизацией HTTP запросов от браузеров и/или других потребляющих медиаклиентов.

ПОДРОБНОЕ ОПИСАНИЕ ПРЕДПОЧТИТЕЛЬНОГО ВАРИАНТА

ОСУЩЕСТВЛЕНИЯ СПОСОБА / МЕТОДОЛОГИИ

Как показано на чертежах и в более подробном описании, настоящее изобретение предлагает сеть доставки контента и соответствующую технологию для облачной независимой потоковой передачи данных между одноранговыми узлами. Как рассматривалось выше, изобретение содержит шлюзовой сервер для связи между одноранговыми узлами (Р2Р), который обозначен как 3. Упомянутый Р2Р шлюзовой сервер 3 принимает передачи данных (показано как 200) от клиента 2 на локальном компьютере 101.

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

Потребляющему данные клиенту 2 дается полностью форматированное доменное имя для удаленных одноранговых серверов 4 или серверов 4 имен ресурса. Ради простоты, читатель рассмотрит доменное имя www.rns_server.com. Для того чтобы запросить медиа 401 (см. фиг. 33) через сеть доставки контента (сеть CDN) одноранговых узлов, обозначенную как 144, клиент 2 содержит в себе унифицированный указатель ресурса (URL) с RNS открытым доменным именем, и переменную GET с местоположением запрошенного медиа, что-то вида.

www.rns_server.com?media=www.somemediasource.com/media.mp4&protocol=http.

Когда сервер RNS 4 принимает запрос, он делает запросы 404 двух различных баз данных. Первый запрос использует открытый адрес протокола сети Интернет (IP) запрашивающих устройств, чтобы идентифицировать, существуют ли какие-нибудь сетевые одноранговые узлы 3 в пределах локальной сети 101 запрашивающих устройств. Второй запрос выполняет поиск базы данных ресурсов, чтобы идентифицировать одноранговые узлы 3 с запрашиваемым медиа, доступным для потоковой передачи (показано как 200, 207, 208, 209, и 210) в пределах одноранговой сети CDN 144 (peer-to-peer, Р2Р).

На основе запросов 404 может произойти следующее. Во-первых, если отсутствует зарегистрированный одноранговый узел на локальной сети, то запрос перенаправляется, показано как 403 (фиг. 30), на удаленный источник 104 медиа, и Р2Р сеть 144 не будет использоваться. Если имеется зарегистрированный одноранговый узел 3 в пределах локальной сети 101, то запрос перенаправляется, показано как 402 (фиг. 30), на одноранговый узел 3 локальной сети наряду с данными о местоположении ресурса и данными о доступности, которые были извлечены во втором запросе 404. Одноранговый узел 3 локальной сети затем обрабатывает медиапоток (показано как 200, 207, 208, 209, и 210).

Таким образом, читатель поймет, что сервер имен ресурсов (сервер RNS), который указан как 4, занимает центральное место для осуществления на практике настоящего изобретения. Сервер RNS 4 кэширует указатели URL ресурсов и местоположения ресурсов (IP адреса), и разрешает запросы ресурсов с адресами компьютеров (IP адреса). Обычный процесс для несогласованного типа медиа будет выглядеть следующим образом. Клиент 2 передает запрос ресурсов (показано как 200) на шлюзовой сервер 3.

Шлюзовой сервер 3 затем передает запрос (показано как 201) на обособленный сервер RNS 4 для принятия решения (показано как 202) запроса (показано как 203) идентификатора ID входящего ресурса / URL с адресом ресурса (показано как 204), упомянутый ресурс или IP адрес затем передается обратно (показано как 205) на шлюзовой сервер 3, как более подробно изображено на Фиг. 5. Другими словами, как только запрос 203 ресурса согласован, показано как 202, с оптимальными (например, (а) с наиболее эффективной стоимостью или (b) наиболее высоким качеством звука источника) местоположениями ресурсов 204, данные местоположения ресурсов или IP адрес (адреса) 204 возвращаются 205 на шлюзовой сервер 3.

Шлюзовой сервер 3 затем передает (показано как 206, 207, и 208) запрос (запросы) данных ресурсов для соответствующих компьютеров (102 и/или 103) или серверных кластеров показано как 104. Упомянутые компьютеры 102 / 103 или серверные кластеры 104 затем отвечают посредством передачи (показано как 209) данных, которые запрашиваются, на шлюзовой сервер 3, размещаемый на компьютере 101. Шлюзовой сервер 3 на компьютере 101 обрабатывает (т.е. подготавливает и проверяет подлинность) данные, которые были переданы на 209, и затем доставляет 210 ресурсы для клиента 2.

Конкретные отношения клиент-сервер-одноранговый узел в основном схематически изображены на фигурах 7, 8, 9, и 10. Традиционные отношения клиент-сервер изображены на Фиг. 7; неуправляемые одноранговые сети изображены на Фиг. 8; управляемые одноранговые сети изображены на Фиг. 9; и централизованные / гибридные одноранговые сети изображены на Фиг. 10.

В традиционных отношениях клиент-сервер клиент 105 запрашивает 211 данные от сервера 106 и сервер 106 доставляет 212 данные циклическим способом, как изображено на Фиг. 7. В традиционной неуправляемой одноранговой сети каждый одноранговый узел (или сочетание клиент/сервер) 107 может действовать как сервер 106 для доставки данных и как клиент 105 для приема данных. В неуправляемой среде, как в целом изображено на Фиг. 8, запрос 211 данных передается от однорангового узла 107 к одноранговому узлу 107 пока не будет найден файл.

Управляемая одноранговая сеть, как в целом изображено на Фиг. 9, имеет централизованный сервер 108 индексирования ресурсов, который функционирует для индексирования ресурсов. Индексированные ресурсы доставляются 213 одноранговым узлам 107 с использованием последующих запросов 214. Доступность индексированных ресурсов затем сообщается и регистрируется посредством одноранговых узлов 107. Этот тип устройства делает быстрее и легче нахождение ресурса.

В гибридной системе, в целом изображенной на Фиг. 10, одноранговая сеть используется наряду с централизованным источником данных / сервером индексирования 109. Как индексированные ресурсы, так и данные доставляются 215 на узлы 107 от сервера 109 после запрашивания 216 ресурсов и данных узлом (узлами) 107. Этот тип устройства обеспечивает низкие затраты доставки одноранговыми узлами, но и корректность и скорость централизованного источника данных, и ускорение доставки ресурсов, как в управляемой одноранговой сети. В этой ситуации происходит смешивание данных от сервера 109 и одноранговых узлов 107, доставляющих данные.

В одноранговой сети 144 доставки контента (сеть CDN), в целом изображенной на Фиг. 2 и Фиг. 3, клиент 2 является автономным клиентом. Другими словами, запрос данных подготавливается и потребляется автономным клиентом 2 (т.е. браузер, рабочий стол или мобильное приложение). В отличие от других сетей, запрос данных происходит не с помощью узла 107, но с помощью автономного клиента 2, как в традиционных отношениях клиент-сервер, как в целом изображено на Фиг. 7.

Шлюзовой сервер 3 принимает запрос от клиента 2 и затем принимает решение запроса ресурса вместе с сервером имен ресурсов или RNS, или сервером 4 индексирования ресурсов. Сервер RNS 4 дает ответ с местоположениями ресурсов (например, IP адрес), упомянутые местоположения ресурсов могут быть первичными источниками ресурсов или одноранговыми узлами. Предполагается, что сеть является не зависящей от источника данных, данные одноранговых узлов не управляются посредством центрального сервера данных, а индексируются на сервере RNS 4 как запросы, которые передаются и кэшируются на шлюзовом сервере 3.

В такой сети источник данных находится отдельно от сервера индексирования ресурсов RNS 4. Это позволяет заполнить любой запрос данных автономным клиентом 2 от источника данных или от одноранговой сети, поскольку данные в пределах одноранговой сети кэшируются, когда запрос передается от автономного клиента 2.

Настоящее изобретение не ограничивается использованием HTTP или WebSockets, но может также использовать стандартные протоколы передачи файлов (FTP, WebDAV, SMB, AFP и т.д.). В этом случае клиент будет автономным FTP (или любым клиентом стандартного протокола передачи данных). Если директория FTP (или WebDAV, SMB, AFP и т.д.) монтируется как сетевой накопитель в пределах операционной системы, то упомянутая операционная система будет действовать как клиент. В этой ситуации шлюзовой сервер будет работать как файловый сервер.

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

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

Скрипты на стороне клиента наряду с встроенными модулями программного обеспечения могут также использоваться для аутентификации как клиента, так и сервера, путем внедрения той или иной формы проверки идентификации в пределах дополнительного модуля программного обеспечения, что затем передается для скриптов стороны клиента, которые проверяют достоверность проверки идентификации с использованием AJAX. Использование скриптов на стороне клиента в тандеме с дополнительным программным модулем браузера является предпочтительным, поскольку это обеспечивает проверку как клиента, так и сервера в одном процессе. Этот способ рассматривается ниже.

Со ссылкой на фигуры 12 и 13, читатель будет рассматривать проверку клиента через встроенный программный модуль браузера и скрипты на стороне клиента. Процесс создания безопасного соединения начинается с инсталляции локального сервера. После инсталляции, сервер создает подписанный им самим сертификат и добавляет этот подписанный им самим сертификат к корню дерева сертификата. Это позволяет серверу создать безопасное соединение от браузера.

Для добавления другого уровня безопасности локальный сервер 110 загружает множество вхождений 24 дополнительного программного модуля браузера обработки медиа (например, flash, sliver light и т.д.). Локальный сервер 110 может легко загружать более чем 1000 множественных вхождений 24 дополнительного программного модуля браузера обработки медиа. В каждое вхождение встраивается индивидуальный ключ шифрования, показано как 27. Вместо загрузки множественных вхождений, ключ 27 шифрования может вводиться в компонентный файл встроенного программного модуля, если библиотеки дополнительного программного модуля позволяют вводить пользовательский код.

Когда браузер создает безопасное соединение, показано как 26, сервер 110 создает индивидуальный сеанс для инициированного соединения и затем объединяет сеанс с медиавхождением 24 дополнительного программного модуля и его встроенным ключом 27 шифрования или создает ключ 27 шифрования и вводит его в компонентный файл встроенного программного модуля. Упомянутый компонентный файл 25 дополнительного программного модуля затем загружается в браузер 111. Упомянутый файл 25 дополнительного программного модуля шифрует все запросы, которые поступают от браузера 111 через сценарий на стороне клиента, и передает их на сервер 110 через зашифрованное соединение 26. Индивидуальный ключ 27 шифрования может также быть индивидуальным маркером, используемым для подписи запросов для проверки их достоверности.

Для того чтобы извлечь ключ шифрования или маркер 27, нужно декомпилировать файл 25 дополнительного программного модуля, вручаемый локальным сервером 110, и затем повторно установить соединение с сервером 110, используя новый "взломанный" экземпляр дополнительного программного модуля. Однако, поскольку сервер 110 выбирает иной ключ 27 шифрования в каждом сеансе в момент, когда новое безопасное сокет соединение 26 устанавливается, действие предыдущего ключа 27 шифрования заканчивается. Это делает ключ шифрования 27, извлекаемый посредством декомпилирования, непригодным.

Одной из основных проблем использования локального сервера для доставки контента является возможность "атаки через посредника", в этом сценарии вредоносное программное обеспечение может выступать в качестве действительного шлюза и, возможно, перехватывать пользовательские данные. Для того чтобы предотвратить эту форму атаки, настоящая система использует способы, которые требуют от локального сервера 110 проверить подлинность действительного шлюза посредством представления идентификации 31 аутентификации действительного сервера через компоненту 25 дополнительного программного модуля браузера. Этот процесс описан более подробно далее.

Каждый локальный шлюзовой сервер 110 регистрирует (показано как 19) себя с использованием удаленного хоста 112 посредством создания идентификации 31 проверки (идентификации проверки правильности регистрации), которая подключена к протоколу сети Интернет общего пользования локального компьютера. Эта идентификация 31 проверки и ее связанный протокол сети Интернет общего пользования хранятся в базе данных 29 на удаленном хосте 112. Когда загружается веб-страница 30, которую будет использовать локальный шлюзовой сервер 110, браузер 111 передает запрос (показано как 217) на локальный сервер 110. Сервер 110 отвечает посредством представления своей идентификации 31 проверки.

Браузер 111 затем передает запрос (показано как 218), используя идентификацию 31 проверки, на удаленный хост 112. Если идентификация 31 проверки соответствует упомянутому адресу протокола сети Интернет и идентификации проверки, хранящейся в удаленной базе данных 29, удаленный сервер 112 передает ответ по пути 218, подтверждая локальный шлюзовой сервер 110. После проверки, браузер 111 затем переходит к загрузке (показано как 26) медиа дополнительного программного модуля 24 из локального сервера 110. Медиа дополнительный программный модуль 24 затем создает безопасное соединение 219 для локального шлюзового сервера 110, через которое он будет доставлять данные (например, данные на основе музыки).

Со ссылкой на Фиг. 6, читатель рассмотрит меры безопасности без дополнительного программного модуля. Способ, который не требует использования медиа дополнительного программного модуля в соответствии с настоящим изобретением, подразумевает наличие клиента 2, передающего запрос (показано как 220) идентификации 113 для регистрируемого сеанса от шлюзового сервера 3 для проверки достоверности его подлинности. Идентификация 114 сеанса предварительно регистрируется (показано как 221) шлюзовым сервером и является недействительной после единственной аутентификации.

Это требует от шлюзового сервера 3 регистрации нескольких сеансов 114 заблаговременно, и каждая идентификация 113 сеанса является действительной только для одного подтверждения. Шлюзовой сервер 3 представляет (показано как 222) идентификацию 113 сеанса клиенту 2. Клиент 2 затем проверяет подлинность (показано как 223) принятой идентификации 115 сеанса с помощью сервера 116 проверки. Упомянутый сервер 116 проверки сопоставляет (показано как 224 и 225) идентификацию 115 сеанса, передаваемую клиентом 2, с идентификациями 114 регистрированных сеансов. Если соответствие найдено, тогда сервер 116 проверки подтверждает (показано как 224) для клиента 2 достоверность шлюзового сервера 3.

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

rstp://domain.com/resource_directory/resource_name?var=123

(a нehttp://vertigo/domain.com/resource_directory/resource_name?var=123)

Другим способом защиты системы является - ограничить контент, доставляемый через эту систему, для медиа (музыка, изображения, видео и т.д.), и ограничить распределение файлов для контента, который не связан со структурой и кодом веб-сайта или приложения. Этот способ является более трудным для импортирования вредоносного кода, поскольку только медиафайлы разрешены. Это делается с учетом требований безопасности. Другими словами, HTML, Javascript, CSS, PHP файлы и т.д. не могут быть доставлены через шлюзовой сервер. Другим ограничением является то, что клиент (браузер) должен иметь ограничение на использование такого шлюза или протокола, если веб-сайт (структура, код и медиа) загружается через http и является чувствительным.

Со ссылкой на Фиг. 1, читатель будет рассматривать аспекты достоверности конкретных данных и аспекты безопасности в соответствии с настоящим изобретением. Одна из проблем в сети CDN 144, не зависящей от источника данных, заключается в достоверности данных. Если, например, один из одноранговых узлов имеет вредоносные данные, или если кто-нибудь создал вредоносный одноранговый узел, который регистрирует файлы, которые не связаны с исходными данными, как кэшированную одноранговым узлом версию исходного файла, надежность и полезность системы могут быть под угрозой.

Именно поэтому способы проверки и фрагментации данных должны включаться для того, чтобы система была надежной и полезной. Таким образом, для того чтобы сохранить отдельный одноранговый узел от возможного повреждения или целенаправленного замещения данных ненадлежащим образом является предпочтительным фрагментировать доставку данных через несколько одноранговых узлов посредством конкретных средств фрагментации доставки данных. Средства фрагментации доставки данных в соответствии с настоящим изобретением могут быть иллюстрированы посредством нескольких механизмов. Фрагментация доставки данных, например, может достигаться посредством разбиения данных 199 на пакеты или суб-потоки показано как строки 117, 118, 119, и 120. Фрагментация может быть оптимизирована для соответствия требованиям системы.

Фрагментация может быть сделана посредством простого ограничения доставки каждым одноранговым узлом максимально примерно до трети или четверти конкретного медиафайла. Это управляется с использованием сервера имен ресурсов или сервера RNS 4, как рассматривается более подробно ниже. Наряду с фрагментацией доставки данных, каждый файл данных имеет пакет для проверки для конкретного сектора данных, показано как столбцы 121, 122, 123 и 124. Это делается, поскольку каждый одноранговый узел, который подает данные, должен сначала кэшировать медиа перед их подачей снова. Соответственно, в качестве примера, если одноранговый узел доставляет суб-поток 117 данных, то он будет также доставлять наряду с этими данными пакет для проверки для сектора 121 файла. Этот пакет для проверки является контрольной суммой, созданной посредством заранее определенного алгоритма.

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

Со ссылкой на фигуры 4 и 5, читатель сравнительно рассмотрит конкретные отличия между сервером доменных имен (сервер DNS) и сервером имен ресурсов (сервер RNS). Главным отличием между сервером DNS 130 и сервером RNS 4 является то, как обрабатывается запрос ресурса. В сервере DNS 130 запрос ресурса (показано как 226) разрешается (показано как 227) для доменного имени 129 или начала полномочий (SOA) 126, которые имеют определенный ресурс 127 в директории 128 SOA 126. Клиент 2 принимает (показано как 228) IP адрес SOA от DNS и затем осуществляет запрос (показано как 229) ресурса 127 из SOA 126.

В сервере имен ресурсов или RNS 4, RNS 4 разрешает (показано как 202) запрос (показано как 201) ресурса для нескольких компьютеров, которые имеют отдельный ресурс, хранящийся или кэшированный. Соответственно, IP адрес SOA с упомянутым ресурсом может быть возвращен (показано как 205) как достоверное местоположение ресурса, но также как IP адрес для кэшируемых узлом ресурсов. Другими словами, в системе DNS указатель URL больше напоминает адрес конкретного ресурса, в сервере RNS 4, указатель URL 240 рассматривается как индивидуальный идентификатор, соответствующий отдельному ресурсу, для нескольких местоположений.

Конкретные средства для индексации ресурсов без сопоставления файлов изображены на фигурах 14 и 15; и конкретные средства для индексации ресурсов с сопоставлением файлов изображены на фигурах 16 и 17. Одним из основных вопросов, который возникает, когда имеем дело с совместимостью, является вопрос, как проверить, что в настоящее время воспроизводится. Метаданные часто повреждены или изменены пользователем. Следовательно, чтобы более эффективно передавать поток локального медиа, необходимо предложить способ проверки с очень высокой степенью уверенности, что медиафайл или музыкальная композиция на локальном накопителе соответствуют тем, которые хранятся в облаке.

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

Как показано на Фиг. 16, процесс прогрессивной индексации 247 начинается с запроса, который поступает из клиентского приложения 3-й стороны. Это может быть автономное приложение рабочего стола, показано как 131, или веб-сайт, воспроизводящийся через браузер, показано как 132. Упомянутое приложение 131 или браузер 132 передает параллельно соответственно отформатированный и проверенный URL (показано как 241 и 242) на локальный шлюзовой сервер (133). Локальный шлюзовой сервер 133 использует унифицированный указатель ресурса (URL) (показано как 241 и 242) для извлечения запрошенного ресурса для потоковой передачи (показано как 243 и 244) из соответствующих облаков 245 и 246 (или соответствующей одноранговой сети, или ресурса на основе любой возможной сети). Как только ресурс был загружен для потоковой передачи, показано как 243 и 244, локальный сервер 133 начинает упомянутый процесс индексации, показано как 247 (с подпрограммами 248-252). Локальная ресурсная индексация 253 в целом изображена на Фиг. 17 (с подпрограммами 254-258).

Обработка 259 запроса индексированного ресурса в целом изображена на Фиг. 18. После того как ресурс был индексирован, следующий процесс происходит тогда, когда последующие запрашивания осуществляются от клиентов 3-й стороны. Предполагая, что поставщик услуги потоковой передачи медиа (показано как 132) подает запрос 242 на локальный сервер 133 с использованием его стандартных указателей URL, запрос 242 поступает и локальный сервер 133 запрашивает базу 135 данных локальной файловой системы и сервер индексирования 134 для определения того, был ли ресурс ранее индексирован. (Указатель URL используется для определения того, существует ли он на сервере индексирования 134 или в локальной файловой системе 137.) В этом случае, локальный сервер 133 определяет, что ресурс был индексирован и доступен на одноранговой сети 138. Медиа затем извлекается из одноранговой сети 138 и подается для поставщика услуги пот