СПОСОБЫ ДВУНАПРАВЛЕННОГО ОБМЕНА ПАКЕТАМИ ПО УЗЛОВЫМ ПУТЯМ Российский патент 2022 года по МПК H04L29/08 

[0001] Настоящая заявка испрашивает приоритет предварительной патентной заявки США №62/503,808, поданной 9 мая 2017 г., содержание которой включено в настоящую заявку посредством ссылки в полном объеме.

[0002] Настоящая заявка также испрашивает приоритет предварительной патентной заявки США №62/524,705, поданной 26 июня 2017 г., содержание которой включено в настоящую заявку посредством ссылки в полном объеме.

[0003] Настоящая заявка представляет собой частичное продолжение патентной заявки США №15/656,454 Гленна Александра Фидлера (Glenn Alexander Fiedler), поданной 21 июля 2017 г, содержание которой включено в настоящую заявку посредством ссылки в полном объеме. Патентная заявка США №15/656,454 испрашивает приоритет предварительной патентной заявки США №62/462,224, поданной 22 февраля 2017 г., содержание которой включено в настоящую заявку посредством ссылки в полном объеме.

Область техники

[0004] Настоящее изобретение относится к области сетевой связи.

Уровень техники

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

[0006] Многопользовательские игры в режиме реального времени по существу работают путем отправки ненадежных неупорядоченных пакетов по сети Интернет, например, в виде пакетов UDP (протокола пользовательских датаграмм), в двунаправленном режиме потока, в котором пакеты отправляют в обоих направлениях, от клиента к серверу и от сервера к клиенту, с некоторой скоростью, такой как 10, 20, 30 или 60 пакетов в секунду.

[0007] Пакеты, которыми обмениваются клиент и сервер, чрезвычайно чувствительны к задержке, дрожанию и/или потере пакетов. В совокупности это называют качеством обслуживания или "QoS".

[0008] Обычно клиенты связываются с выделенными серверами путем отправления и получения пакетов непосредственно на IP-адрес сервера, но указанный подход приводит к уязвимости выделенных серверы к атакам DDoS (распределенным атакам на отказ в обслуживании), поскольку IP-адрес сервера открыт.

[0009] Кроме того, при отправке пакетов по общедоступной сети Интернет, маршрут, проходимый пакетами между клиентом и сервером, не находится под непосредственным контролем клиента или сервера. Пакеты могут выбирать наиболее дешевый маршрут, а не маршрут, позволяющий оптимизировать QoS.

[00010] Сходным образом, при обмене пакетами по сети Интернет, в случае, если маршрут, проходимый пакетами между клиентом и сервером, ухудшается, или становится доступным лучший маршрут, клиент или сервер не имеют возможности корректировки маршрута, проходимого пакетами между клиентом и сервером.

[00011] Таким образом, существует необходимость в улучшенных способах обеспечения связи клиентов с выделенными серверами, которые не раскрывают IP-адрес сервера и обеспечивают некоторую степень управления маршрутом, проходимым пакетами между клиентом и сервером.

Краткое описание чертежей

[00012] На фиг. 1 показаны выделенные серверы, сообщающие информацию матчмейкеру.

[00013] На фиг. 2 показаны ретрансляторы, сообщающие информацию главному серверу.

[00014] На фиг. 3 показан клиент, запрашивающий связь с выделенным сервером.

[00015] На фиг 4 показан главный сервер, возвращающий клиенту массив потоковых маршрутов.

[00016] На фиг. 5А показан потоковый маршрут.

[00017] На фиг. 5В показан потоковый маркер.

[00018] На фиг. 6 показан клиент, отправляющий пакет запроса на выделенный сервер.

[00019] На фиг. 7 показан пакет ответа, отправленный клиенту в ответ на пакет запроса, полученный от указанного клиента.

[00020] На фиг. 8А показан кэш ретранслятора.

[00021] На фиг. 8В показаны данные записи в кэше ретранслятора.

[00022] На фиг. 9А показан кэш сервера.

[00023] На фиг. 9В показаны данные маркера в кэше сервера.

[00024] На фиг. 10 показан клиент, запрашивающий обновленный потоковый маршрут.

[00025] На фиг. 11 показан главный сервер, отправляющий обновленный потоковый маршрут клиенту.

[00026] На фиг. 12 показан пакет запроса обновленного маршрута, проходящий от клиента к серверу, в то время как существующий маршрут сохраняют для пакетов полезной нагрузки.

[00027] На фиг. 13 показан пакет ответа, отправляемый клиенту в ответ на обновленный пакет запроса, получаемый от указанного клиента.

[00028] На фиг. 14 показан сеансовый маркер согласно аспектам настоящего изобретения.

[00029] На фиг. 15 показана система, которая может быть использована для реализации способа связи по ретрансляционным узлам согласно одному из аспектов настоящего изобретения.

Подробное описание

[00030] В нижеприведенном описании раскрыты примеры реализации настоящего изобретения. Несмотря на то, что каждый из примеров реализации представляет собой отдельную комбинацию элементов изобретения, настоящее изобретение призвано охватывать все возможные комбинации раскрытых элементов. Таким образом, если один из примеров реализации содержит элементы А, В и С, а второй пример реализации содержит элементы В и D, следует считать, что изобретение также охватывает остальные комбинации элементов А, В, С или D, даже при отсутствии явного указания.

[00031] Использование в описании и сопутствующей формуле изобретения настоящей заявки терминов в единственном числе призвано охватывать указанные термины в множественном числе, если из контекста не очевидно обратное. Использование в описании настоящей заявки термина "в" охватывает термины "в" и "на", если из контекста не очевидно обратное.

[00032] Кроме того, использование в настоящей заявке термина "связанный с" призвано охватывать непосредственную связь (при которой два элемента, связанные друг с другом, соприкасаются друг с другом) и опосредованную связь (при которой между двумя указанными элементами расположен по меньшей мере один дополнительный элемент), если из контекста не очевидно обратное. Таким образом, термины "привязанный к" и "связанный с" в настоящем описании синонимичны.

[00033] В некоторых примерах реализации числа, характеризующие количества ингредиентов, свойства, такие как концентрация, условия реакции и т.д., и используемые для описания и заявления некоторых примеров реализации изобретения, в некоторых случаях следует считать обусловленными термином "примерно". Соответственно, в некоторых примерах реализации числовые параметры, приведенные в письменном описании и сопутствующей формуле изобретения, представляют собой приблизительные значения, которые могут варьироваться в зависимости от требуемых свойств, на обеспечение которых направлен конкретный пример реализации. В некоторых примерах реализации численные параметры следует рассматривать в контексте количества сообщенных значащих цифр и путем применения известных приемов округления. Несмотря на то, что числовые диапазоны и параметры, определяющие широкий объем некоторых примеров реализации изобретения, представляют собой приблизительные значения, числовые значения, указанные в конкретных примерах, приведены с наиболее возможной точностью в контексте практического применения. Числовые значения, представленные в некоторых примерах реализации изобретения, могут содержать определенную погрешность, неизбежно возникающую вследствие стандартного отклонения, характерного при соответствующих опытных измерениях. Кроме того, все диапазоны, приведенные в настоящей заявке, следует считать охватывающими крайние значения диапазонов, а открытые диапазоны следует считать охватывающими лишь коммерчески практичные значения, если из контекста не очевидно обратное. Сходным образом, все списки значений следует считать охватывающими промежуточные значения, если из контекста не очевидно обратное.

[00034] Следует отметить, что любые формулировки, направленные на описание компьютера, призваны охватывать любую подходящую комбинацию вычислительных устройств, включая серверы, интерфейсы, системы, базы данных, агенты, одноранговые узлы, механизмы, контроллеры или вычислительные устройства других видов, работающие отдельно или в совокупности. Следует понимать, что вычислительные устройства содержат процессор, выполненный с возможностью выполнения программных команд, сохраненных на материальном энергонезависимом машиночитаемом носителе данных (например, на жестком диске, твердотельном накопителе, в ОЗУ, флэш-памяти, ПЗУ и т.п.). Программные команды предпочтительно обеспечивают возможность выполнения вычислительным устройством ролей, обязанностей или других функций, согласно нижеприведенному описанию в контексте раскрытой установки. В особо предпочтительных примерах реализации различные серверы, системы, базы данных или интерфейсы обмениваются данными посредством стандартизированных протоколов или алгоритмов, возможно, на основе HTTP, HTTPS, AES, обмена открытыми и закрытыми ключами, API веб-служб, известных протоколов финансовых транзакций или других электронных способов обмена информацией. Обмен данными предпочтительно осуществляют по сети с коммутацией пакетов, сети Интернет, LAN, WAN, VPN или по сети с коммутацией пакетов другого вида. Нижеприведенное описание содержит информацию, которая может быть полезна для понимания настоящего изобретения. Включение любой информации, приведенной в настоящей заявке, не является признанием того, что указанная информация является предшествующим уровнем техники или имеет отношение к настоящему заявляемому изобретению; прямые или косвенные ссылки на любую публикацию не призваны указывать на то, что указанная публикация является предшествующим уровнем техники.

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

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

[00037] Использование дополнительных ретрансляторов может быть преимуществом. В системах, содержащих более одного ретранслятора, все ретрансляторы, клиент и сервер могут быть обозначены термином "узлы". Конечная цель заключается в обеспечении обмена пакетами между клиентом и сервером посредством потокового маршрута таким образом, что клиент никогда не знает IP-адрес и порт сервера, с сопутствующей оптимизацией маршрута согласно некоторому критерию.

[00038] В частности, примеры реализации изобретения обеспечивают оптимизированные маршруты между клиентами и выделенными серверами путем построения маршрута по промежуточным "ретрансляторам" по общедоступной сети Интернет. Маршруты могут быть оптимизированы, например, с целью уменьшения задержки, уменьшения потери пакетов или улучшения любых других критериев QoS (качества обслуживания) в соответствии с существующими требованиями. При наличии нескольких маршрутов ретрансляции между клиентом и сервером и различных характеристик каждого из маршрутов ретрансляции может быть выбран наилучший маршрут. Указанный принцип аналогичен программам поиска маршрутов, таким как Google Maps, Apple Maps, Waze и т.д., тем, что требуемый конечный результат заключается в выборе и обеспечении наиболее быстрого маршрута к пункту назначения.

[00039] Примеры реализации настоящего изобретения также обеспечивают защиту от DDoS-атак путем скрытия IP-адреса выделенного сервера от клиентов, связывающихся с указанным сервером. Указанный подход исключает возможность атаки выделенного сервера в виде известной DdoS-атаки. Примеры реализации также обеспечивают возможность динамического изменения маршрутов с сохранением продолжающегося обмена пакетами между клиентом и выделенным сервером. Например, в случае возникновения доступности лучшего маршрута или наличия на текущем маршруте ретранслятора, подверженного DDoS-атаке, динамическое изменение маршрута без прекращения обмена пакетами между клиентом и сервером по существующему маршруту обеспечивает возможность беспрерывного продолжения сеанса клиента (например, игрового сеанса) на выделенном сервере, несмотря на выполненную динамическую корректировку маршрута связи.

[00040] Примеры реализации настоящего изобретения также обеспечивают улучшение безопасности. Злоумышленные третьи лица не могут перехватить ретрансляторы по настоящему изобретению с целью отправки пакетов по указанным ретрансляторам. Настоящее изобретение обеспечивает возможность свободного отклонения пакетов, не исходящих от действительного клиента или сервера, системой.

[00041] На фиг. 1 и 2 показаны несколько фоновых операций опроса. Периодически (например, с регулярными или нерегулярными интервалами) выделенные серверы {s₁, …, s_j} (например, выделенный игровой сервер, представляющий собой консольную версию игры, запущенную в центре хранения и обработки данных, таком как частное облако (например, центр хранения и обработки данных или сервер без предустановленного программного обеспечения), или общедоступное облако, такое как Google Compute, Amazon ЕС2 или Microsoft Azure), сообщают матчмейкеру свои IP-адреса, порты и открытые ключи. На фиг. 1 показаны выделенные серверы s₁, s₂…s_j, сообщающие (104) свои IP-адреса и порты, а также открытые ключи, обратно матчмейкеру 101. Указанный отчет выполняют периодически (например, с регулярными или нерегулярными интервалами). Например, каждый выделенный сервер s₁, s₂…s_j может сообщать (104) свои IP-адрес и порт матчмейкеру 101 один раз через каждые 1-5 минут. Также возможен вариант, в котором выделенные серверы s₁, s₂…s_j могут сообщать данные матчмейкеру 101 с другими интервалами, включая каждые 1-30 секунд, 30-59 секунд или даже несколько раз в секунду (например, 2-10 Гц). Периодические отчеты 104 обеспечивают возможность реализации оптимизированной архитектуры микрослужб, основанной на очереди, с целью обеспечения возможности работы с большим количеством выделенных серверов.

[00042] Матчмейкер 101 ведет указанный список и обновляет его по мере необходимости (например, если выделенный сервер s₁, s₂…s_j перестает сообщать данные, матчмейкер 101 убирает указанный выделенный сервер из ведомого им списка, или если новый выделенный сервер сообщает новый IP-адрес и порт, матчмейкер добавляет указанную информацию в свою базу данных). Данные для каждого выделенного сервера содержат как минимум IP-адрес, порт и открытый ключ для каждого выделенного сервера, но могут также содержать и другие критерии, полезные для определения выделенных серверов, наилучшим образом удовлетворяющих запросу клиента (например, номер версии игры, число игроков, в настоящее время подключенных к серверу, общее разрешенное для подключения к серверу число игроков, регион, в котором расположен сервер, режим игры, в котором в настоящий момент работает сервер, например "захват флага" или "смертельный бой", уровень навыка игроков, подключенных к серверу в настоящее время и т.д.).

[00043] Матчмейкером 101 может управлять, например, компания, поддерживающая видеоигру. Матчмейкер 101 имеет некоторую аутентификацию, позволяющую ему связываться с главным сервером 102, который в других случаях не является общедоступным. Функция матчмейкера 101 заключается в принятии запроса клиента 103 на игру и в поиске группы IP-адресов и портов выделенных серверов для подключения клиента к серверам, удовлетворяющим запросу указанного клиента. Указанные серверы могут представлять собой, например, серверы, работающие в игровом режиме, запрошенном клиентом, или серверы в регионе, в котором находится клиент 103, серверы с соответствующим номером версии игры и набором игроков, сходных по навыку с игроком клиента, или серверы, подходящие по любым другим критериям.

[00044] В настоящем описании под термином "потоковый маршрут" понимают узловой путь, связывающий клиента с сервером. Термином "поток" обозначают пакеты, обмениваемые по "потоковому маршруту" после его установления.

[00045] На фиг. 2 показаны ретрансляторы r₁, r₂…r_i, сообщающие свои IP-адреса и порты, а также открытые ключи, главному серверу. Главный сервер 102 в данном качестве выполняет функции, идентичные функциям матчмейкера 101: сервер сохраняет IP-адреса и порты, а также открытые ключи ретрансляторов r₁, r₂…r_i, и обновляет указанную информацию по мере необходимости. Сходным с матчмейкером 101 образом, отчет 201 выполняют периодически (например, с регулярными или нерегулярными интервалами). Например, каждый из ретрансляторов r₁, r₂…r_i может сообщать (201) свои IP-адрес и порт главному серверу один раз через каждые 1-5 минут. Также возможен вариант, в котором ретрансляторы могут сообщать (201) данные главному серверу 102 с другими интервалами, включая каждые 1-30 секунд, 30-59 секунд или даже несколько раз в секунду (например, 2-10 Гц). Периодические отчеты 201 обеспечивают возможность реализации оптимизированной архитектуры микрослужб, основанной на очереди, с целью обеспечения возможности работы с большим количеством ретрансляторов.

[00046] Также возможен вариант, в котором ретрансляторы r₁, r₂…r_i могут проходить процедуру аутентификации на главном сервере 102 с целью исключения возможности регистрации неавторизованных ретрансляторов на главном сервере 102.

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

[00048] Функция главного сервера 102 заключается в выработке потоковых маршрутов между двумя конечными точками (например, пути от клиента к выделенному серверу посредством ряда ретрансляторов). Узловые пути могут быть идентифицированы алгоритмическим путем с целью определения потокового маршрута, оптимизированного на основании одного или нескольких факторов (например, для минимизирования задержки, минимизирования потери пакетов, минимизирования дрожания или обеспечения любой комбинации указанных факторов). Главный сервер 102 доступен для запросов от матчмейкера 101 посредством, например, REST API (запросов на основе передачи состояния представления).

[00049] Перед описанием процесса обеспечения потока важно представить различные виды пакетов, включенные в примеры реализации настоящего изобретения. Пакеты, отправляемые по сети в примерах реализации настоящего изобретения, содержат префикс с одним байтом, идентифицирующим вид пакета. Обеспечены пакеты четырех видов: 0, 1, 2 и 3. Пакет вида 0 представляет собой пакет запроса. Пакет вида 0 имеет вид [0][потоковый маркер 0, потоковый маркер 1, …, потоковый маркер n-1] и соответствует структуре данных потокового маршрута с префиксом нулевого байта. Пакет вида 1 представляет собой пакет ответа. Пакет вида 2 представляет собой пакет полезной нагрузки, проходящий от клиента к серверу. Пакет вида 3 представляет собой пакет полезной нагрузки, проходящий от сервера к клиенту. Порядковые номера пакетов применимы только к пакетам ответа и пакетам полезной нагрузки. Пакеты вида 1 имеют вид: [1][порядковый номер пакета][идентификатор потока][версия потока][hmac (алгоритм вычисления кода аутентификации)], а пакеты видов 2 и 3 имеют вид: [1, 2 или 3][порядковый номер пакета][идентификатор потока][версия потока][hmac] (данные полезной нагрузки).

СОСТОЯНИЯ КЛИЕНТА

[00050] Изначально клиент может существовать в нескольких состояниях:

[00061] Клиенты изначально находятся в "остановленном" состоянии (состояние 0), а когда пользователю необходимо установить поток, пользователь передает потоковый маршрут клиенту. Затем клиент совершает попытку расшифровки первого потокового маркера в потоковом маршруте посредством своего закрытого ключа и открытого ключа главного сервера (который известен клиенту). В случае неудачной расшифровки, истечения срока или недопустимости потокового маркера по любой причине клиент переходит в состояние недопустимого потокового маршрута (состояние -2). В противном случае клиент переходит в состояние "запроса" (состояние 1). В указанном состоянии клиент отправляет пакеты запроса на некоторой частоте (например, 10 Гц) на первый ретранслятор. Если в состоянии "запроса" клиент получает "пакет ответа" от первого ретранслятора, клиент переходит в "установленное" состояние (состояние 2). В "установленном состоянии" клиент прекращает отправку "пакетов запроса". Если клиент, находящийся в состоянии "запроса" или в "установленном" состоянии, не получает пакет от первого ретранслятора в течение некоторого промежутка времени (например, 1-10 секунд), время ожидания истекает, и клиент переходит в "истекшее" состояние.

[00062] Если клиент находится в состоянии "запроса" или в "установленном", пользователь может отправлять пакеты полезной нагрузки от клиента на сервер и потенциально получать любые пакеты полезной нагрузки, отправленные от сервера клиенту. Указанная конфигурация позволяет клиенту оптимистично отправлять пакеты полезной нагрузки до подтверждения полной установки потока. Кроме того, при отправлении клиентом пакетов полезной нагрузки в направлении сервера клиент генерирует "заголовок пакета" для каждого пакета, содержащий порядковый номер пакета, идентификатор потока, версию потока и НМАС (например, подписанный закрытым ключом потока из потокового маркера), а затем передает указанный пакет на первый ретранслятор. Затем клиент увеличивает порядковый номер пакета, который начинается с 0 и увеличивается на 1 с каждым пакетом, отправляемым в направлении сервера. Закрытый ключ потока представляет собой обособленный симметричный ключ, используемый для защиты потока от неавторизованных пакетов. Закрытый ключ потока может быть сформирован случайным образом для каждого потока, предоставленного главным сервером 102.

[00063] При получении клиентом пакетов полезной нагрузки от сервера, клиент сравнивает порядковый номер пакета с буфером защиты от повтора. Пакеты отвергают в случае, если они уже были получены ранее или являются излишне старыми. Указанная конфигурация позволяет избежать атак на уровне протокола, называемых атаками "с повтором", при которых злоумышленник повторяет действительные пакеты, уже обмененные по всей системе, с целью нарушения протокола. Многие из указанных принципов более подробно описаны ниже.

ПОВЕДЕНИЕ РЕТРАНСЛЯТОРОВ

[00064] Ретрансляторы в нескольких примерах реализации могут иметь некоторые сходные характеристики поведения. Например, при получении пакетов по сети ретранслятором, если первый байт в пакете имеет значение 0, указывающее на "пакет запроса", ретранслятор в некоторых примерах реализации выполняет несколько действий: (1) ретранслятор расшифровывает первый потоковый маркер в пакете (например, маркер, соответствующий данному ретранслятору в потоковом маршруте) посредством закрытого ключа ретранслятора и открытого ключа главного сервера; (2) в случае неудачной расшифровки потокового маркера ретранслятор игнорирует пакет; (3) ретранслятор проверяет возможное истечение потокового маркера и игнорирует пакет, если маркер истек; (4) ретранслятор осуществляет поиск записи потока, соответствующей идентификатору потока и версии потока (например, кортежа {идентификатор потока, версия потока}) в потоковом маркере; (5) если запись уже существует, ретранслятор обновляет временную метку последнего пакета, полученного от предыдущего узла, до текущей временной метки; (6) если запись еще не существует в кэше ретранслятора, ретранслятор создает новую запись для этого потока, проиндексированную идентификатором потока и версией потока (например, кортежом {идентификатор потока, версия потока}), причем временной метке последних пакетов, полученных от предыдущего и текущего узла, присваивают значение текущей временной метки, (6а), если предыдущий адрес в потоковом маркере помечен "отсутствует", то в качестве предыдущего адреса и порта в новой записи потока записывают IP-адрес и порт, от которых был отправлен пакет запроса, что позволяет клиентам без фиксированного общедоступного IP-адреса и порта (например, клиентам с трансляцией сетевых адресов (NAT)) участвовать в потоковых маршрутах; (7) в обоих случаях 5 и 6 ретранслятор принимает пакет запроса и удаляет байт префикса (0 для пакета данного вида) и первый потоковый маркер; (8) ретранслятор затем добавляет новый байт 0 префикса перед остальной частью пакета запроса и передает указанный модифицированный пакет на следующий узел на потоковом маршруте (например, на следующий ретранслятор или на сервер в случае, если сервер представляет собой следующий узел).

[00065] Указанный закрытый ключ ретранслятора может быть сформирован случайным образом для каждого ретранслятора. Каждый закрытый ключ ретранслятора имеет соответствующий открытый ключ. Закрытый ключ ретранслятора позволяет главному серверу 102 защищенным образом передавать потоковые маркеры на указанный ретранслятор, причем главному серверу известен только открытый ключ указанного ретранслятора. В некоторых вариантах реализации узлы на концах каждого потока, например, клиенты и серверы, также могут иметь собственные сформированные случайным образом закрытые ключи. Термин "закрытый ключ узла" в настоящем описании иногда используют для общего обозначения закрытых ключей для ретрансляторов и узлов других видов, таких как клиенты и серверы.

[00066] Если первый байт пакета имеет значение 1, указывающее на "пакет ответа", в некоторых примерах реализации ретранслятор выполняет несколько действий: (1) ретранслятор осуществляет поиск записи потока, соответствующей идентификатору потока и версии потока (например, кортежу {идентификатор потока, версия потока}), в пакете; (2) если запись потока не существует, ретранслятор игнорирует пакет; (3) ретранслятор проверяет тот факт, что НМАС пакета указывает на то, что данные пакета (порядковый номер, идентификатор потока, версия потока) подписаны закрытым ключом потока (который был отправлен на ретранслятор в потоковом маркере в пакете запроса); (4) если подпись не совпадает, ретранслятор игнорирует пакет; (5) ретранслятор проверяет порядковый номер пакета относительно буфера защиты от повтора для пакетов, полученных от следующего узла, и, если пакет уже был принят или является старым (например, пакет находится за пределами буфера защиты от повтора), ретранслятор игнорирует пакет; (6) в противном случае пакет является действительным, и ретранслятор передает пакет без изменений на предыдущий узел (например, на предыдущий ретранслятор или клиент, если ретранслятор представляет собой первый ретранслятор на потоковом маршруте); (7) ретранслятор обновляет временную метку последнего пакета, полученного от следующего узла в записи, до текущей временной метки.

[00067] Если первый байт пакета имеет значение 2, указывающее на "пакет клиент-сервер", в некоторых примерах реализации ретранслятор выполняет несколько действий: (1) ретранслятор осуществляет поиск записи потока, соответствующей идентификатору потока и версии потока (например, кортежу {идентификатор потока, версия потока}), в пакете; (2) если запись потока не существует, ретранслятор игнорирует пакет; (3) ретранслятор проверяет тот факт, что НМАС пакета указывает на то, что данные пакета (порядковый номер, идентификатор потока, версия потока) подписаны закрытым ключом потока (который был отправлен на ретранслятор в потоковом маркере в пакете запроса); (4) если подпись не совпадает, ретранслятор игнорирует пакет; (5) ретранслятор проверяет порядковый номер пакета относительно буфера защиты от повтора для пакетов, полученных от предыдущего узла, и, если пакет уже был принят или является старым (например, за пределами буфера защиты от повтора), ретранслятор игнорирует пакет; (6) в противном случае пакет является действительным, и ретранслятор передает пакет без изменений на следующий узел (например, на следующий ретранслятор или сервер, если данный ретранслятор представляет собой последний ретранслятор перед сервером); и (7) ретранслятор обновляет временную метку последнего пакета, полученного от предыдущего узла, до текущей временной метки.

[00068] Если первый байт пакета имеет значение 3, указывающее на "пакет сервер-клиент", в некоторых примерах реализации ретранслятор выполняет несколько действий: (1) ретранслятор осуществляет поиск записи потока, соответствующей идентификатору потока и версии потока (например, кортежу {идентификатор потока, версия потока}), в пакете; (2) если запись потока не существует, ретранслятор игнорирует пакет; (3) ретранслятор проверяет тот факт, что НМАС пакета указывает на то, что данные пакета (порядковый номер, идентификатор потока, версия потока) подписаны закрытым ключом потока (который был отправлен на ретранслятор в потоковом маркере в пакете запроса); (4) если подпись не совпадает, ретранслятор игнорирует пакет; (5) ретранслятор проверяет порядковый номер пакета относительно буфера защиты от повтора для пакетов от следующего узла, и, если пакет уже был принят или является старым (например, за пределами буфера защиты от повтора), ретранслятор игнорирует пакет; (6) в противном случае пакет является действительным, и ретранслятор передает пакет без изменений на предыдущий узел на потоковом маршруте, представляющий собой предыдущий ретранслятор или клиент (для первого ретранслятора в потоке); и (7) ретранслятор обновляет временную метку последнего пакета, полученного от следующего узла, до текущей временной метки.

[00069] Если в любой момент времени запись в кэше ретранслятора не принимала пакеты от предыдущего узла в течение некоторого промежутка времени (например, 5 секунд) или не принимала пакеты от следующего узла в течение некоторого промежутка времени (например, 5 секунд), указанная запись потока, индексированная кортежом {идентификатор потока, версия потока}, истекает, и ее удаляют из кэша ретранслятора. При этом ретранслятор перестает перенаправлять пакеты для потока, идентифицированного кортежом {идентификатор потока, версия потока}, в обоих направлениях.

ПОВЕДЕНИЕ СЕРВЕРОВ

[00070] Сходно с ретрансляторами, серверы в нескольких примерах реализации могут иметь сходные характеристики поведения. Серверы прослушивают пакеты и создают записи для сеансов клиентов. Записи индексируют по идентификатору потока, в результате чего сервер может "обновить" сеанс клиента при возникновении более новой версии потока (например, если для клиента установлен обновленный потоковый маршрут). Указанная конфигурация обеспечивает возможность плавного перехода от одного потокового маршрута на другой.

[00071] Если первый байт пакета имеет значение 0, указанный пакет представляет собой "пакет запроса". Серверы в некоторых примерах реализации выполняют следующие действия: (1) сервер расшифровывает первый потоковый маркер в пакете посредством закрытого ключа сервера и открытого ключа главного сервера; (2) в случае неудачной расшифровки потокового маркера сервер игнорирует пакет; (3) если маркер истек, сервер игнорирует пакет; (4) в противном случае сервер осуществляет поиск записи с идентификатором потока в маркере; (5) если запись уже существует и номер версии потока совпадает, сервер обновляет временную метку получения последнего пакета в указанной записи до текущей временной метки; (6) если запись уже существует, но номер версии потока в пакете запроса превышает значение записи, сервер копирует новые данные потока (например, идентичным новому сеансу клиента образом) и обновляет временную метку получения последнего пакета в указанной записи до текущей временной метки; (7) в противном случае сервер добавляет новую запись потока, индексированную по идентификатору потока, с временной меткой получения последнего пакета в указанной записи, установленной на текущую временную метку; (8) во всех вышеупомянутых случаях (5, 6 и 7) сервер отвечает "пакетом ответа" на предыдущий ретранслятор с порядковым номером пакета для указанной записи со старшим битом, имеющим значение 1 (например, во избежание повторения одинакового nonce-значения в пакетах клиент-сервер и пакетах сервер-клиент); и (9) после отправления сервером пакета ответа на предыдущий узел порядковый номер пакета для указанной записи потока увеличивают.

[00072] Если первый байт пакета имеет значение 2, указанный пакет представляет собой "пакет клиент-сервер". Серверы в некоторых примерах реализации выполняют следующие действия: (1) сервер осуществляет поиск соответствующей записи потока для идентификатора потока в пакете; (2) если запись потока не существует, сервер игнорирует пакет; (3) сервер проверяет НМАС в пакете с целью определения того факта, что проверка подписи проходит согласно закрытому ключу потока, соответствующему указанной записи потока, и при отрицательном результате сервер игнорирует пакет; (4) сервер доставляет полезные данные пакета пользователю. Указанная конфигурация позволяет клиенту отправлять данные по потоковому маршруту на сервер, как если бы клиент был непосредственно связан с сервером.

[00073] Пользователь может отправлять пакеты полезной нагрузки с сервера клиенту путем указания идентификатора потока, по которому следует отправлять пакеты. Когда сервер отправляет пакеты полезной нагрузки клиенту, сервер осуществляет поиск записи для указанного идентификатора потока в кэше сервера. Затем сервер генерирует "заголовок потока" с порядковым номером пакета из указанной записи потока, идентификатором потока, версией потока и НМАС (например, подписанным закрытым ключом потока из потокового маркера) и передает указанный пакет на предыдущий ретранслятор на потоковом маршруте для указанной записи потока. Сходно с ответными пакетами, сервер устанавливает значение старшего бита порядкового номера пакета, равное 1, с целью обеспечения уникальности значений порядковых номеров пакетов (nonce-значений) для всех пакетов клиент-сервер и сервер-клиент конкретного потока. Затем сервер увеличивает порядковый номер пакета для указанной записи потока, который начинается с 0 и увеличивают на 1 с каждым пакетом, отправляемым клиенту в указанном потоке.

[00074] Если в любой момент времени запись потока в кэше сервера не принимала пакет в течение некоторого времени (например, 5 секунд), указанная запись, индексированная идентификатором потока, истекает, и ее удаляют из кэша. При этом сервер более не имеет возможности получать пакеты, отправленные от клиента, соответствующего указанному идентификатору потока, и более не имеет возможности отправлять пакеты клиенту, соответствующему указанному идентификатору потока.

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

[00076] На фиг. 3 показаны первые этапы установления потокового маршрута. Например, в контексте игры матчмейкер 101 представляет собой сервер, принадлежащий игровой компании, который отслеживает все выделенные серверы s₁, s₂…s_j, работающие для размещения игры. Запрос клиента к матчмейкеру содержит набор параметров (например, вид игры, количество игроков, игровая карта и т.д.) вкупе с открытым ключом клиента, что отмечено позицией 301. Запрос клиента 301 к матчмейкеру 101 может быть осуществлен, например, посредством REST API. Указанный запрос 301 включает передачу матчмейкеру открытого ключа клиента.

[00077] Поскольку матчмейкеру 101 известны требуемые клиентом параметры сервера, матчмейкер может идентифицировать серверы s₁ s₂…s_j, удовлетворяющие запросу 101 клиента. При наличии идентифицированного ряда выделенных серверов s₁ s₂…s_j матчмейкер 101 может формировать запрос маршрута и отправлять его на главный сервер 102, что отмечено позицией 302.

[00078] Запрос 302 маршрута содержит открытый ключ клиента, а также открытые ключи, IP-адреса и порты выделенных серверов s₁ s₂…s_j, удовлетворяющих изначальному запросу 301 клиента (с учетом того, что множество выделенных серверов не является необходимым в запросе маршрута). В указанном процессе отсутствует необходимость известности IP-адреса клиента. Напротив, главному серверу 102 по меньшей мере должен быть известен открытый ключ клиента, поскольку адрес клиента в потоковом маршруте имеет значение "none" и может быть определен первым ретранслятором как адрес, с которого был отправлен пакет запроса.

[00079] Главный сервер 102 получает запросы 302 маршрута от матчмейкера 101 (например, посредством REST API), и главный сервер 102 определяет наилучшие маршруты для каждого из выделенных серверов s₁ s₂…s_j, идентифицированных матчмейкером 101, по некоторым критериям (например, минимальные задержка, потеря пакета, дрожание и т.д.). Главный сервер 102 затем отвечает матчмейкеру 101 сообщением массива маршрутов от клиента к серверам 401, причем каждый из маршрутов соответствует одному серверу в списке выделенных серверов в запросе маршрута, согласно фиг. 4. В альтернативных примерах реализации настоящего изобретения главный сервер 102 может отвечать на запрос матчмейкера путем отправления идентификатора сеанса и массива маркеров сеанса матчмейкеру 101. Каждый маркер сеанса соответствует идентифицированному выделенному серверу, а идентификатор сеанса идентифицирует сеанс клиента. В некоторых примерах реализации идентификатор сеанса представляет собой число (например, 64-разрядное число, 128-разрядное число и т.д.). Необязательно, но предпочтительно, каждый идентификатор сеанса уникален.

[00080] Каждый потоковый маршрут имеет потоковые маркеры. Первый потоковый маркер соответствует клиенту 103. Указанный маркер зашифрован открытым ключом клиента и закрытым ключом главного сервера. Маркеры, поступающие после маркера клиента, но до маркера сервера (последнего маркера), соответствуют ретрансляторам, и каждый из указанных маркеров зашифрован закрытым ключом главного сервера и открытым ключом соответствующего ретранслятора. Последний потоковый маркер на каждом потоковом маршруте зашифрован открытым ключом сервера и закрытым ключом главного сервера. Зашифрованные потоковые маркеры затем передают (402) клиенту 103 посредством матчмейкера 101.

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

[00082] В альтернативных примерах реализации маркеры сеанса используют для поддержания защищенного соединения. Содержимое маркера сеанса показано на фиг. 14. Маркеры сеанса содержат два субмаркера: маркер инициации сеанса и маркер продолжения сеанса. Маркер инициации сеанса содержит частную и общедоступную информацию. Частная информация зашифрована асимметрично, в результате чего она может быть создана только главным сервером и может быть считана лишь соответствующим ретранслятором. Общедоступная информация может быть сводобно считана, но она подписана таким образом, что ее подлинность может быть проверена получателем. Частная информация в маркере инициации сеанса содержит, например, IP-адрес и порт выделенного сервера, порядковый номер сеанса, идентификатор сеанса, ограничение пропускной способности на выгрузку и ограничение пропускной способности на загрузку. Общедоступная информация в маркере продолжения сеанса содержит, например, IP-адрес ретранслятора и временную метку истечения. Маркер продолжения сеанса содержит частную информацию, включая порядковый номер сеанса и идентификатор сеанса.

[00083] На фиг. 5А показан пример реализации потокового маршрута. На каждом маршруте выполнен ряд потоковых маркеров, каждый из которых соответствует конкретному узлу. Узел 0 всегда соответствует клиенту, а последний узел (например, узел n-1) всегда соответствует выделенному серверу. Все промежуточные узлы (например, узлы с 1 по n-2) соответствуют ретрансляторам и упорядочены в последовательности, указывающей на требуемый потоковый маршрут. На фиг. 5В показан пример реализации потокового маркера, содержащего: идентификатор потока, версию потока, временную метку истечения, IP-адрес и порт предыдущего узла, IP-адрес и порт следующего узла и закрытый ключ потока. В некоторых примерах реализации IP-адрес и порт предыдущего узла в потоковом маркере может быть заменен на запись "none", указывающую на то, что ретранслятор, соответствующий указанному маркеру, должен использовать адрес, с которого был отправлен пакет запроса, в качестве предыдущего IP адреса и порта для указанной записи потока.

[00084] На фиг. 6 и 7 показан принцип установления потока между клиентом 103 и сервером s_j посредством любого количества ретрансляторов r₁, r₂…r_i. Несмотря на то, что показанный на чертежах пример реализации содержит три ретранслятора, предусмотрена возможность реализации любого количества ретрансляторов посредством примеров реализации настоящего изобретения.

[00085] На фиг. 6 и 7 показаны действия, выполняемые для одного потокового маршрута. В примерах реализации, в которых массив маршрутов к серверу s_j включает более одного маршрута, клиент осуществляет перебор по каждому из потоковых маршрутов до момента установления потока. Например, если клиент 103 и сервер s_j не могут установить поток по первому потоковому маршруту в течение некоторого времени (например, 1 секунды), клиент 103 переходит ко второму потоковому маршруту с целью осуществления попытки установления потока по второму потоковому маршруту, и повторяет указанное действие для третьего маршрута и т.д. В некоторых примерах реализации клиент 103 совершает попытку установления потока по всем потоковым маршрутам одновременно, и принимает первый установленный поток. В других примерах реализации клиент 103 может совершать попытку установления потока по подгруппам маршрутов к серверу s_j. Сходным образом, в альтернативных примерах реализации с использованием маркеров сеанса клиент 103 получает маркеры сеанса от матчмейкера 101 и может осуществлять перебор по ряду маркеров сеанса в попытке использования каждого маркера сеанса для установления связи с выделенным сервером посредством одного или нескольких ретрансляторов. Клиент прекращает перебор маркеров сеанса после успешного установления им связи с выделенным сервером посредством одного или нескольких ретрансляторов.

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

[00087] Таким образом, позицией 601 отмечено, что клиент 103 получает потоковый маршрут и расшифровывает первый маркер с заменой первого маркера на индикатор вида пакета запроса, представляющий собой префикс одного байта значения "0", таким образом формируя пакет запроса. Для контекста на фиг. 6 показано, что число ретрансляторов равно "i". Указанное обозначение приведено для указания на тот факт, что в контексте фиг. 6i представляет собой любое число от 4 до произвольно большого числа, ограниченного только количеством ретрансляторов, которые могут быть целесообразно выполнены в реальном мире (например, в виде физических или виртуальных устройств). Таким образом, предусмотрено, что может быть выполнено любое количество ретрансляторов от 1 до указанного произвольно большого числа.

[00088] Клиент 103 выполнен с возможностью расшифровки первого потокового маркера на потоковом маршруте вследствие того, что указанный маркер зашифрован посредством открытого ключа клиента и закрытого ключа главного сервера. При замене первого маркера (например, маркера, соответствующего узлу 0, согласно фиг. 5А) на индикатор вида пакета (например, 0), потоковый маршрут преобразуют в пакет запроса. Таким образом, пакет запроса содержит на один маркер меньше, а первый маркер в пакете запроса теперь соответствует узлу 1, который представляет собой первый ретранслятор r₁ на потоковом маршруте. Затем клиент отправляет ряд указанных пакетов запроса на первый ретранслятор r₁, указанный в потоковом маршруте (и адрес которого обеспечен в потоковом маркере клиента в виде IP-адреса и порта следующего узла), с конечной целью установления потока. В некоторых примерах реализации ряд пакетов запроса отправляют с некоторой частотой (например, 10 Гц) в течение некоторого промежутка времени (например, 5 секунд), а в других примерах реализации некоторое количество пакетов запроса (например, 100) отправляют вне временных рамок. Указанный принцип применяют при каждом отправлении узлом "ряда" пакетов.

[00089] В примерах реализации, в которых используют маркеры сеанса, связь устанавливают в ходе нескольких фаз. После начала процесса отправления клиентом пакетов на ретранслятор (например, на ретранслятор, указанный в маркере сеанса) клиент проходит две фазы отправления пакетов. В ходе первой фазы отправления пакетов клиент отправляет пакеты на идентифицированный ретранслятор с префиксом в виде маркера инициации сеанса. Указанные пакеты отправляют в течение определенного времени (например, 1-2 с, 2-3 с, 3-4 с, 4-5 с, 5-10 с, 10-15 с). По истечении указанного промежутка времени, в ходе второй фазы отправления пакетов, пакетам присваивают префикс, представляющий собой маркер продолжения сеанса, вместо маркера инициации сеанса.

[00090] Первый ретранслятор r₁ (соответствующий узлу 1 в потоковом маршруте) получает по меньшей мере один из пакетов запроса, отправленных от клиента 103, что обозначено позицией 602. Первый ретранслятор r₁ расшифровывает первый маркер пакета запроса с последующей заменой первого маркера и существующего индикатора вида пакета на индикатор вида пакета запроса (например, в данном случае имеющий значение 0, поскольку пакет представляет собой пакет запроса). Поскольку клиент 103 уже расшифровал исходный "первый" маркер и заменил его на индикатор вида пакета запроса, новый "первый" маркер представляет собой маркер, который может быть расшифрован первым ретранслятором r₁ (и только первым ретранслятором), поскольку указанный маркер был зашифрован посредством открытого ключа первого ретранслятора и закрытого ключа главного сервера.

[00091] При любом обращении потокового маркера к клиенту 103 в качестве предыдущего узла (например, потокового маркера, соответствующего первому ретранслятору на потоковом маршруте), клиент имеет вид адреса 0 (где вид 0 указывает на неизвестный адрес или адрес "none", вид 1 указывает на адрес IPv4, а вид 2 указывает на адрес IPv6). При каждом получении пакета запроса, соответствующий которому маркер имеет предыдущий адрес вида 0, указанный маркер заменяют на адрес и порт узла, от которого отправлен указанный пакет запроса. Таким образом, никогда не существует необходимости включения адреса клиента в маркер ретранслятора. Указанную конфигурацию в основном используют для разрешения ситуаций, в которых клиент 103 работает в условиях трансляции сетевого адреса (NAT) (например, маршрутизатор динамически вырабатывает публичный IP-адрес и порт указанного клиента), но указанный принцип может быть расширен и использован в отношении любого узла, в котором предыдущий узел имеет адрес вида 0. Указанная конфигурация может быть полезна в ситуациях, в которых некоторые узлы на маршруте находятся в частной сети и не сообщают или могут не знать свои общедоступные IP-адреса.

[00092] Затем первый ретранслятор r₁ проверяет факт наличия идентификатора потока и версии потока, выполненных в указанном маркере, в кэше ретранслятора и определяет следующий пункт назначения для отправления пакета. При обнаружении новых идентификатора потока и версии потока идентификатор потока и другое содержимое маркера сохраняют в кэше ретранслятора. Модифицированный пакет запроса затем передают в следующий узел на потоковом маршруте.

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

[00094] После расшифровки ретранслятор проверяет факт наличия идентификатора сеанса, выполненного в маркере инициации сеанса, в кэше ретранслятора. Ретранслятор также может проверять ограничения пропускной способности на выгрузку/загрузку для сеанса (указанные в маркере инициации сеанса) и завершает сеанс в случае, если объем данных превышает указанные пределы в любом направлении в течение некоторого промежутка времени (например, 1-5 секунд, 5-10 секунд, 10-15 секунд или другого заданного промежутка времени). Таким образом, даже если клиент обладает действительным маркером сеанса, указанный клиент по-прежнему не способен совершить DDoS-атаку на выделенный сервер.

[00095] Если идентификатор сеанса является новым, то идентификатор сеанса и другое содержимое маркера инициации сеанса (например, вся или часть общедоступной и частной информации в маркере инициации сеанса) сохраняют в кэше ретранслятора перед отправлением пакета на выделенный сервер или на другой ретранслятор. Перед отправлением пакета на выделенный сервер или другой ретранслятор указанный ретранслятор удаляет префикс (например, маркер инициации сеанса) из пакета и заменяет его на идентификатор сеанса и порядковый номер сеанса с последующей передачей пакета на выделенный сервер s_j или ретранслятор r_i, идентифицированный в маркере сеанса.

[00096] Если ретранслятор обнаруживает, что идентификатор сеанса, выполненный в маркере инициации сеанса, уже существует в кэше ретранслятора (что указывает на тот факт, что пакет с префиксом в виде маркера инициации сеанса уже получен и записан), пакет передают на выделенный сервер или другой ретранслятор. Идентичным образом, перед отправлением пакета на выделенный сервер или другой узел указанный ретранслятор удаляет префикс (например, маркер инициации сеанса) из пакета и заменяет его на идентификатор сеанса и порядковый номер сеанса с последующей передачей пакета на выделенный сервер s_j или ретранслятор r_i, идентифицированный в маркере сеанса.

[00097] Если ретранслятор получает пакеты с префиксом в виде маркера продолжения сеанса, ретранслятор проверяет только наличие идентификатора сеанса в кэше. Если идентификатор сеанса существует в кэше ретранслятора, ретранслятор удаляет префикс и заменяет его на идентификатор сеанса и порядковый номер сеанса с последующей передачей пакета на выделенный сервер. Если идентификатор сеанса не существует в кэше, пакет игнорируют.

[00098] На фиг. 8А показано содержимое в кэше ретранслятора, необходимое для некоторых примеров реализации настоящего изобретения. Кэш для каждого ретранслятора содержит таблицу, содержащую ключи и значения, причем ключ содержит кортеж {идентификатор потока, версия потока}, а значение, соответствующее каждому из ключей, содержит запись. На фиг. 8В показан пример записи данных, разбитой на данные маркера и данные времени выполнения. Данные маркера содержат: временную метку истечения, адрес предыдущего узла (например, IP-адрес и порт), адрес следующего узла (например, IP-адрес и порт) и закрытый ключ потока. Данные времени выполнения содержат: время последнего приема пакета от предыдущего узла, время последнего приема пакета от следующего узла, защиту от повтора предыдущего узла и защиту от повтора следующего узла. Защита от повтора более подробно раскрыта в нижеприведенном описании.

[00099] В некоторых примерах реализации настоящего изобретения второй ретранслятор r₄ (соответствующий узлу 2 потокового маршрута) получает по меньшей мере один из пакетов запроса, отправленных от узла 1 (т.е., ретранслятора r₁), что обозначено позицией 603. Второй ретранслятор и расшифровывает первый маркер пакета запроса с последующей идентичной заменой первого маркера и существующего индикатора вида пакета на индикатор вида пакета запроса (например, в данном случае имеющий значение 0, поскольку пакет представляет собой пакет запроса). Поскольку первый ретранслятор 1 уже расшифровал предыдущий "первый" маркер и заменил его на индикатор вида пакета запроса, новый "первый" маркер представляет собой маркер, который может быть расшифрован вторым ретранслятором r₄ (и только вторым ретранслятором), поскольку указанный маркер был зашифрован посредством открытого ключа второго ретранслятора и закрытого ключа главного сервера.

[000100] Затем второй ретранслятор r₄ проверяет факт наличия идентификатора потока и версии потока, выполненных в указанном маркере, в кэше ретранслятора и определяет следующий пункт назначения для отправления пакета. При обнаружении новых идентификатора потока и версии потока идентификатор потока и другое содержимое маркера сохраняют в кэше ретранслятора. Модифицированный пакет запроса затем передают в следующий узел на потоковом маршруте.

[000101] Третий ретранслятор r₃ (соответствующий следующему в последовательности узлу после узла 2 в исходном потоковом маршруте) принимает по меньшей мере один из пакетов запроса, отправленных от узла 2 (т.е., ретранслятора r₄), что обозначено позицией 604. Третий ретранслятор гз расшифровывает первый маркер пакета запроса с последующей идентичной заменой первого маркера и существующего индикатора вида пакета на индикатор вида пакета запроса (например, в данном случае имеющий значение 0, поскольку пакет представляет собой пакет запроса). Поскольку второй ретранслятор 4 уже расшифровал предыдущий "первый" маркер и заменил его на индикатор вида пакета запроса, новый "первый" маркер представляет собой маркер, который может быть расшифрован третьим ретранслятором r₃ (и только третьим ретранслятором), поскольку указанный маркер был зашифрован посредством открытого ключа третьего ретранслятора и закрытого ключа главного сервера.

[000102] Затем третий ретранслятор гз проверяет факт наличия идентификатора потока и версии потока, выполненных в указанном маркере, в кэше ретранслятора и определяет следующий пункт назначения для отправления пакета. При обнаружении новых идентификатора потока и версии потока идентификатор потока и другое содержимое маркера сохраняют в кэше ретранслятора. Модифицированный пакет запроса затем передают в следующий узел на потоковом маршруте. Несмотря на то, что на чертежах третий ретранслятор r₃ является последним ретранслятором, предусмотрено, что для нахождения оптимального потокового маршрута может быть использовано любое необходимое количество ретрансляторов.

[000103] Наконец, выделенный сервер s_j (соответствующий последнему узлу в пакете запроса) получает по меньшей мере один из пакетов запроса, отправленных от узла 3 (т.е., ретранслятора r₃), что обозначено позицией 605. Выделенный сервер s_j расшифровывает первый маркер пакета запроса (который теперь соответствует потоковому маркеру, который может расшифровать только сервер, поскольку он зашифрован посредством закрытого ключа главного сервера и открытого ключа сервера) и проверяет наличие идентификатора потока, выполненного в указанном маркере, в кэше выделенного сервера. При обнаружении нового идентификатора потока, идентификатор потока и другое содержимое маркера сохраняют в кэше выделенного сервера. Сервер отвечает на каждый действительный пакет запроса пакетом ответа, отправляемым на предыдущий узел на потоковом маршруте.

[000104] В целях безопасности пакеты видов 1, 2 и 3 "подписаны" закрытым ключом потока, который включен в каждый потоковый маркер и идентичен для каждой записи потока, соответствующей указанному потоку на каждом задействованном узле (например, на клиенте, ретрансляторах и сервере). Указанная конфигурация обеспечивает возможность свободного отклонения пакетов, отправленных неавторизованными лицами (например, лицами, которым не известен закрытый ключ потока), каждым из узлов. Важно отметить, что пакеты ответа и полезной нагрузки (например, пакеты видов 1, 2 и 3) не зашифрованы, а лишь подписаны. Таким образом, содержимое может быть прочитано любым лицом, но третье лицо не может вырабатывать или изменять идентификатор потока или номер версии потока в заголовке потока для пакетов указанных видов. Для обеспечения работы указанных примеров реализации пакеты видов 1, 2 и 3 должны иметь порядковый номер пакета (например, номер "временного значения", который используют только единожды) и код аутентификации сообщения с хеш-ключом (НМАС). Во избежание многократного использования порядкового номера пакета пакеты видов 1, 2 и 3, отправляемые в направлении от клиента на сервер, имеют старший бит 64-разрядного порядкового номера, имеющий значение 0, а пакеты вида 1, 2 и 3, отправляемые в направлении от сервера к клиенту, имеют старший бит 64-разрядного порядкового номера, имеющий значение 1.

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

[000106] Кроме того, в примерах реализации, в которых используют маркеры сеанса в соответствии с аспектами настоящего изобретения, предусмотрено, что главный сервер также имеет собственную пару открытый ключ/закрытый ключ. Главный сервер сообщает свой открытый ключ ретрансляторам. Таким образом, ретрансляторы могут расшифровывать, но не могут создавать маркеры сеанса. Также предусмотрено, что ретранслятор может подписывать или зашифровывать и подписывать пакеты, которыми он обменивается с выделенным сервером.

[000107] Сходным с ретрансляторами образом, выделенные серверы имеют кэш для хранения данных, связанных с различными потоками. Указанное свойство позволяет серверу отслеживать связь конкретного потока с конкретным клиентом, и т.д. На фиг. 9А показан пример принципа хранения сервером ключей и значений, связанных с потоками. Ключ содержит идентификатор потока, а значение, соответствующее каждому ключу, содержит запись. Запись содержит данные маркера и данные времени выполнения, согласно фиг. 9В. Данные маркера содержат: временную метку истечения, IP-адрес и порт предыдущего узла, закрытый ключ потока и версию потока. Данные времени выполнения содержат время приема последнего пакета, порядковый номер пакета и буфер защиты от повтора.

[000108] При получении действительного пакета запроса на выделенном сервере r_j, выделенный сервер r_j, отвечает пакетами ответа на предыдущий узел r₃, что обозначено позицией 701. В конечном итоге пакеты ответа перенаправляют обратно клиенту 103 по тому же потоковому маршруту, заданному пакетом запроса, но в обратном направлении. Следует понимать, что обратный потоковый маршрут может не быть ограниченным идентичным прямому потоку маршрутом, и обратный поток может принимать любое количество других

[000109] Согласно позиции 702, ретранслятор r₃ получает пакет ответа от выделенного сервера s_j, подписанный посредством закрытого ключа потока (например, закрытого ключа потока, содержащегося в данных маркера, которые выделенный сервер расшифровывает из пакета запроса, который в конечном итоге поступил на выделенный сервер s_j по ряду ретрансляторов на потоковом маршруте). Ретранслятор r₃ осуществляет поиск записи потока в кэше ретранслятора по идентификатору потока и версии потока, а затем проверяет действительность подписи. Если подпись действительна, ретранслятор пересылает пакет ответа на предыдущий ретранслятор r₄.

[000110] Согласно позиции 703, ретранслятор r₄ получает пакет ответа от ретранслятора r₃, подписанный посредством закрытого ключа потока. Ретранслятор r₄ осуществляет поиск записи потока по идентификатору потока и версии потока, а затем проверяет действительность подписи. Если подпись действительна, ретранслятор пересылает пакет ответа на предыдущий ретранслятор r₁.

[000111] Согласно позиции 704, ретранслятор r₁ получает пакет ответа от ретранслятора r₄, подписанный посредством закрытого ключа потока. Ретранслятор r₁ осуществляет поиск записи потока по идентификатору потока и версии потока, а затем проверяет действительность подписи. Если подпись действительна, ретранслятор пересылает пакеты ответа на предыдущий узел (в данном случае на клиент или узел 0).

[000112] При получении клиентом пакета ответа от первого ретранслятора клиент выполняет проверку подписи, идентичную осуществленной всеми предыдущими узлами, и, если пакет успешно проходит проверку, клиент считает поток "установленным". После установки потока клиент обладает подтверждением того факта, что может быть осуществлен обмен пакетами полезной нагрузки (например, пакетами видов 2 и 3) между клиентом и сервером по потоковому маршруту. Пакеты полезной нагрузки, сходно с пакетами ответа, имеют заголовок потока, подписанный закрытым ключом потока, и могут иметь следующую структуру: [2 или 3][порядковый номер пакета][идентификатор потока][версия потока][hmac] (данные полезной нагрузки).

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

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

[000115] В ходе продолжающегося обмена пакетами полезной нагрузки между клиентом и выделенным сервером по существующему потоковому маршруту 1003 (посредством исходного идентификатора потока и номера версии потока, соответствующих указанному потоковому маршруту) клиент 103 может запросить обновленный потоковый маршрут от матчмейкера 101, что обозначено позицией 1001. В запросе передают идентификатор потока клиента (например, идентификатор, соответствующий существующему потоку, связывающему клиент с сервером) и версию потока на матчмейкер 101, с целью распознавания сервером нового потокового маршрута как принадлежащего к тому же логическому сеансу клиента, но являющегося более новым (например, обновленной версии существующего потока). В примерах реализации, в которых используют маркеры сеанса, запрос о переносе передает предыдущий маркер сеанса клиента на матчмейкер. Важно использовать один и тот же маркер сеанса с целью сохранения связи между клиентом и выделенным сервером, с которым уже связан клиент. В конечном счете единственное изменение заключается в изменении ретранслятора.

[000116] Согласно позиции 1002, матчмейкер 101 затем отправляет запрос о переносе клиента вкупе с идентификатором потока и версией потока на главный сервер 102. Согласно позиции 1101 на фиг. 11, главный сервер 102 затем отвечает с предоставлением нового потокового маршрута, имеющего идентичный идентификатор потока, причем новый потоковый маршрут (например, с другим рядом ретрансляторов) ведет к тому же выделенному серверу s_j с увеличенной на один шаг версией потока, в результате чего может быть определено, что указанный маршрут представляет собой более новую версию существующего потокового маршрута. Сходным образом, в примерах реализации, в которых используют маркеры сеанса, матчмейкер отправляет запрос о переносе, содержащий предыдущий маркер сеанса, на главный сервер. Главный сервер отвечает с предоставлением нового маркера сеанса, имеющего свойства, идентичные свойствам предыдущего маркера сеанса, за исключением того, что новый маркер сеанса указывает на один или несколько новых ретрансляторов, которые были выбраны главным сервером, а порядковый номер сеанса увеличивают на один шаг.

[000117] Затем, согласно позиции 1102, обновленный потоковый маршрут (или, в некоторых примерах реализации, маркер сеанса) отправляют от матчмейкера 101 клиенту 103. Затем, согласно фиг. 12, клиент 103 использует обновленный потоковый маршрут для создания пакета 1201 запроса, который клиент использует для выполнения процесса, идентичного описанному в контексте фиг. 6, с целью установления нового потока. После получения клиентом 103 пакета ответа от сервера s_j по обновленному потоковому маршруту 1302, согласно фиг. 13 (и вышеприведенному подробному описанию в контексте фиг. 7), установлен обновленный поток. При этом обмен пакетами полезной нагрузки продолжают осуществлять по существующему потоковому маршруту только до принятия выделенным сервером s_j обновленного пакета запроса, соответствующего обновленному потоковому маршруту и переданного по новому ряду ретрансляторов r₂, r₃, r₄ на обновленном маршруте 1301. После получения пакета запроса выделенный сервер s_j начинает отправку пакетов полезной нагрузки клиенту 103 по обновленному потоковому маршруту 1302 и получает пакеты для указанного сеанса клиента только с обновленного потокового маршрута, игнорируя любые пакеты, отправленные от клиента 103 по предыдущему потоковому маршруту. В свою очередь, клиент 103 немедленно начинает отправление пакетов полезной нагрузки клиент-сервер по обновленному потоковому маршруту, а в переходный период клиент принимает пакеты полезной нагрузки сервер-клиент по существующему или обновленному маршрутам. После установления обновленного маршрута клиент позволяет предыдущему маршруту истечь и прекращает принимать пакеты, отправленные клиенту по указанному маршруту, в результате чего обновленный маршрут полностью установлен, и переход на обновленный потоковый маршрут завершен.

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

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

[000120] Согласно аспектам способа связи посредством маркера сеанса по настоящему изобретению, все пакеты, отправленные посредством нового ретранслятора, имеют увеличенный на один шаг порядковый номер сеанса, в результате чего выделенный сервер может сравнить предыдущий порядковый номер сеанса и новый порядковый номер сеанса с целью определения того факта, что новый ретранслятор является более новым по сравнению со старым ретранслятором. Другими словами, порядковый номер сеанса изменяют (например, увеличивают на один шаг) при каждом переносе ретрансляторов. Например, порядковый номер сеанса может возрасти от 1 до 2 после переноса ретрансляторов. Указанная конфигурация позволяет выделенному серверу сравнивать порядковые номера сеанса и принимать только пакеты, имеющие самый новый порядковый номер сеанса (т.е., в данном случае, 2).

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

[000122] Предусмотрено, что истечение сеанса может происходить в любом узле на потоковом маршруте. Например: если клиент не получает пакетов от первого ретранслятора в течение некоторого промежутка времени (например, 1-10, и предпочтительно, 5 секунд), ретранслятор истекает; если сервер не получает пакетов от предыдущего ретранслятора для конкретного потока в течение некоторого промежутка времени (например, 1-10, и предпочтительно, 5 секунд), ретранслятор истекает и клиент удаляет указанную запись потока; и если ретранслятор не получает пакетов от предыдущего узла в течение некоторого промежутка времени (например, 1-10, и предпочтительно, 5 секунд) или не получает предыдущих пакетов от следующего узла в течение некоторого промежутка времени (например, 1-10, и предпочтительно, 5 секунд), узел истекает и ретранслятор удаляет указанную запись потока.

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

[000124] Соответственно, защита от повтора работает следующим образом. Сначала пакеты получают и сохраняют в буфере повтора узла, имеющем заданный размер буфера повтора. Размер буфера повтора определяет количество пакетов, которые могут быть сохранены в буфере повтора (например, 64-128, 128-256, 256-512, 512-1028 пакетов). Размер буфера повтора зависит от практической реализации. В некоторых примерах реализации поддерживают объем пакетов в несколько секунд при типичной скорости передачи (20-60 Гц). Например, размер буфера повтора в 256 записей для каждого клиента должен быть достаточен для большинства областей применения. Каждый полученный пакет имеет присвоенный ему порядковый номер. Любой пакет, имеющий порядковый номер старше самого последнего полученного порядкового номера (например, полученного с пакетом), за вычетом размера буфера повтора, отбрасывают на принимающей стороне.

[000125] Например, если размер буфера повтора равен 100, а последний принятый пакет имеет порядковый номер, равный 600, пакет, имеющий порядковый номер, равный или меньше 599 (то есть на 1 меньше 600 минус 100), будет отброшен. При получении нового пакета, имеющего более новый порядковый номер по сравнению с предыдущим наиболее новым принятым порядковым номером, порядковый номер, присвоенный новому пакету, обновляют на принимающей стороне, и новый пакет принимают. При получении пакета, находящегося в пределах размера буфера повтора самого нового порядкового номера, пакет принимают лишь в случае, если его порядковый номер не был получен ранее. При получении пакета с порядковым номером, уже полученным ранее, указанный пакет игнорируют.

Реализация

[000126] Аспекты настоящего изобретения могут быть реализованы на соответствующим образом сконфигурированной компьютерной установке, такой как сервер (например, сервер-матчмейкер, главный сервер и т.д.), персональный компьютер, сетевой ретранслятор и т.п. На фиг. 15 показана функциональная схема системы 1500, которая может быть использована для реализации способа связи по ретрансляционным узлам согласно одному из аспектов настоящего изобретения. Установка 1500 обычно может содержать модуль 1501 процессора и память 1505.

[000127] Модуль 1501 процессора может содержать одно или несколько ядер процессора. Модуль 1501 процессора может содержать несколько ядер процессора, например, при необходимости реализации параллельной обработки. Примеры подходящих многоядерных процессоров без ограничения включают двухъядерные процессоры, четырехъядерные процессоры, процессорные архитектуры, содержащие основной процессор и один или несколько сопроцессоров, архитектуры сотовых процессоров и т.п.Возможность параллельной обработки данных экономит ценное время обработки, что приводит к обеспечению более эффективной и оптимизированной системы распознавания эмоций.

[000128] Память 1505 может быть выполнена в виде интегральной схемы, например, ОЗУ, DRAM, ПЗУ и т.п. Память 1505 также может представлять собой основную память, доступную для всех модулей процессора. В некоторых примерах реализации модуль 1501 процессора может содержать локальную память, связанную с каждым из ядер. Программа 1503 может быть сохранена в основной памяти 1505 в виде читаемых процессором команд, которые могут быть выполнены на модулях процессора. Программа 1503 может быть выполнена с возможностью реализации способа связи между узлами посредством маркеров согласно вышеприведенному описанию и изображениям на фиг. 1-13. Программа 1503 может быть написана на любом подходящем читаемом процессором языке, например, С, С++, JAVA, Assembly, MATLAB, FORTRAN и на ряде других языков. В ходе работы программы пакеты 1507 данных могут быть сохранены в памяти до их передачи на другой узел. Программа может обеспечивать хранение данных пакетов в базе 1508 данных и индексирование указанной базы данных в соответствии с идентификатором потока и/или версией потока в памяти 1505. Кроме того, в базе данных могут быть сохранены открытые ключи или закрытые ключи для расшифровки маркеров. В некоторых примерах реализации, в которых система 1500 представляет собой главный сервер, в памяти 1505 может быть сохранен закрытый ключ для шифрования данных маркера. Кроме того, в случае главного сервера, программа 1503 может обеспечивать построение потокового маршрута системой по сети 1550 для клиентского устройства, использующего сетевой интерфейс 1523, и предоставление ряда потоковых маркеров, задающих указанный потоковый маршрут. В ходе выполнения программы 1503 части программного кода и/или данных могут быть загружены в память или локальные хранилища ядер процессора для параллельной обработки несколькими ядрами процессора.

[000129] Установка 1500 также может содержать широко известные вспомогательные функции 1509, такие как элементы 1511 ввода-вывода, источники 1513 питания, тактовый генератор 1515 и кэш 1517. Установка 1500 может при необходимости содержать массовое запоминающее устройство 5119, такое как жесткий диск, CD-ROM, накопитель на ленте или т.п., для хранения программ и/или данных. Установка 1500 может при необходимости содержать блок 1521 дисплея для облегчения взаимодействия между установкой и пользователем. Блок 1521 дисплея может быть выполнен в виде электронно-лучевой трубки (ЭЛТ) или плоской панели экрана, отображающей текст, цифры, графические символы или изображения. Пользовательский интерфейс 1525 может содержать клавиатуру, мышь, джойстик, сенсорный экран, сенсорную панель или другое устройство, которое может быть использовано в комбинации с графическим пользовательским интерфейсом (GUI).

[000130] Компоненты установки 1500, включая процессор 1501, память 1505, вспомогательные функции 1509, массовое запоминающее устройство 1519, пользовательский интерфейс 1525, сетевой интерфейс 1523 и дисплей 1521, могут быть функционально связаны друг с другом посредством одной или нескольких шин 1527 передачи данных. Указанные компоненты могут быть реализованы в виде аппаратного, программного или аппаратнореализованного программного обеспечения или в виде некоторой комбинации двух или более из указанных элементов.

[000131] Таким образом, раскрыты конкретные составы и способы установления потоков для двунаправленного обмена пакетами. Однако специалистам в области техники очевидно, что возможно множество других модификаций, помимо раскрытых в настоящем описании, без выхода за рамки изобретательских принципов настоящей заявки. Следовательно, настоящее изобретение не призвано быть ограниченным каким-либо образом, за исключением объема настоящей заявки. Кроме того, при толковании изобретения все термины следует интерпретировать в наиболее широком смысле, целесообразном в соответствующем контексте. В частности, термины "содержит" и "содержащий" следует интерпретировать как относящиеся к элементам, компонентам или этапам неисключительным образом, указывая на то, что приведенные элементы, компоненты или этапы могут присутствовать, или могут быть использованы, или могут быть комбинированы с другими элементами, компонентами или этапами, на которые не сделана прямая ссылка.

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

1. Система для организации связи по узловым ретрансляторам, содержащая:

процессор;

память;

причем система выполнена с возможностью реализации способа связи по узловым ретрансляторам, содержащего:

a) получение описания записи потока в пакете от другого узла, причем описание записи потока содержит адрес в потоке, идентификатор потока записи потока, версию потока, информацию об адресах и портах одного или более других узлов в потоке и закрытый ключ, причем пакет от другого узла содержит временную метку истечения, и причем информация об адресах и портах одного или более других узлов в потоке содержит IP-адрес и порт следующего узла в потоке;

b) сохранение записи потока и закрытого ключа в базе данных, индексированной по идентификатору потока;

c) получение пакета, причем пакет содержит код аутентификации и данные пакета, содержащие информацию о последовательности пакетов и идентификатор потока пакета;

d) осуществление поиска в базе данных записи потока, соответствующей идентификатору потока пакета; и

e) игнорирование пакета или перенаправление пакета на IP-адрес следующего узла в потоке, в зависимости от результата поиска.

2. Система по п. 1, в которой этап e) включает игнорирование пакета в случае отсутствия записи потока.

3. Система по п. 1, в которой осуществление поиска в базе данных на этапе d) также включает проверку того факта, что код аутентификации пакета указывает на то, что данные пакета подписаны закрытым ключом потока, соответствующим закрытому ключу в записи потока в базе данных.

4. Система по п. 3, в которой этап е) включает игнорирование пакета в случае, если данные пакета не подписаны закрытым ключом потока, соответствующим закрытому ключу в записи потока.

5. Система по п. 3, в которой этап e) также включает проверку порядкового номера пакета относительно буфера защиты от повтора для пакетов, полученных от следующего узла в потоке, в случае, если данные пакета подписаны закрытым ключом потока, соответствующим закрытому ключу в записи потока в базе данных, и, если пакет уже был получен или является старым, также включает игнорирование пакета.

6. Система по п. 5, в которой этап e) также включает перенаправление пакета без модификации на предыдущий узел и/или указанный следующий узел в потоке в случае, если данные пакета подписаны закрытым ключом потока, соответствующим закрытому ключу в записи потока в базе данных, и если пакет еще не был получен и пакет не является старым.

7. Система по п. 6, также включающая обновление временной метки в записи потока последнего полученного пакета до текущей временной метки.

8. Система по п. 6, в которой пакет принимают от предыдущего узла, и система перенаправляет пакет без модификации на следующий узел.

9. Система по п. 6, в которой пакет принимают от следующего узла, и система перенаправляет пакет без модификации на предыдущий узел.

10. Система по п. 6, также включающая f) удаление записи потока из базы данных в случае, если пакеты с идентификатором потока записи потока не получены в течение заданного промежутка времени от предыдущего узла и/или следующего узла, и прекращение перенаправления пакетов с идентификатором потока удаленной записи потока.

11. Система по п. 1, в которой база данных также индексирована по версии потока.

12. Система по п. 1, в которой пакет содержит версию потока.

13. Система по п. 12, в которой осуществление поиска в базе данных включает поиск с использованием указанной версии потока в пакете.

14. Система по п. 1, в которой этап а) включает получение описания записи потока от главного сервера.

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

16. Система по п. 15, в которой пакет от другого узла содержит IP-адрес и порт предыдущего узла.

17. Система по п. 15, также включающая попытку расшифровки первого потокового маркера в пакете от другого узла посредством закрытого ключа узла и открытого ключа главного сервера; и

модифицирование пакета путем удаления первого потокового маркера и перенаправления полученного измененного пакета на IP-адрес и порт следующего узла в первом потоковом маркере в случае успешной попытки расшифровки первого потокового маркера.

18. Энергонезависимый машиночитаемый носитель, содержащий реализованные в нем машиночитаемые команды, причем машиночитаемые команды выполнены с возможностью реализации способа связи по узловым ретрансляторам при выполнении способа связи по узловым ретрансляторам, содержащего:

a) получение описания записи потока в пакете от другого узла, причем описание записи потока содержит адрес в потоке, идентификатор потока записи потока, версию потока, информацию об адресах и портах одного или более других узлов в потоке и закрытый ключ, причем пакет от другого узла содержит временную метку истечения, и причем информация об адресах и портах одного или более других узлов в потоке содержит IP-адрес и порт следующего узла в потоке;

b) сохранение записи потока и закрытого ключа в базе данных, индексированной по идентификатору потока;

c) получение пакета, причем пакет содержит код аутентификации и данные пакета, содержащие последовательность пакетов и идентификатор потока пакета;

d) осуществление поиска в базе данных записи потока, соответствующей идентификатору потока пакета; и

e) игнорирование пакета или перенаправление пакета на IP-адрес следующего узла в потоке в зависимости от результата поиска.

19. Энергонезависимый машиночитаемый носитель по п. 18, в котором этап e) включает игнорирование пакета в случае отсутствия записи потока.

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

21. Энергонезависимый машиночитаемый носитель по п. 20, в котором этап e) включает игнорирование пакета в случае, если данные пакета не подписаны закрытым ключом потока, соответствующим закрытому ключу в записи потока.

22. Энергонезависимый машиночитаемый носитель по п. 20, в котором этап e) также включает проверку порядкового номера пакета относительно буфера защиты от повтора для пакетов, полученных от следующего узла, в случае, если данные пакета подписаны закрытым ключом потока, соответствующим закрытому ключу в записи потока в базе данных, и, если пакет уже был получен или является старым, также включает игнорирование пакета.

23. Энергонезависимый машиночитаемый носитель по п. 22, в котором этап e) также включает перенаправление пакета без модификации на предыдущий узел и/или следующий узел в случае, если данные пакета подписаны закрытым ключом потока, соответствующим закрытому ключу в записи потока в базе данных, и если пакет еще не был получен и пакет не является старым.

24. Энергонезависимый машиночитаемый носитель по п. 23, также включающий обновление временной метки в записи потока последнего полученного пакета до текущей временной метки.

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

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

27. Энергонезависимый машиночитаемый носитель по п. 23, также включающий f) удаление записи потока из базы данных в случае, если пакеты с идентификатором потока, соответствующим записи потока, не получены в течение заданного промежутка времени от предыдущего узла и/или следующего узла, и прекращение перенаправления пакетов с идентификатором потока, соответствующим удаленной записи потока.

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

29. Энергонезависимый машиночитаемый носитель по п. 18, в котором пакет содержит версию потока.

30. Энергонезависимый машиночитаемый носитель по п. 29, в котором осуществление поиска в базе данных включает поиск с использованием версии потока в пакете.

31. Энергонезависимый машиночитаемый носитель по п. 18, в котором этап а) также включает получение описания записи потока от главного сервера.

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

33. Энергонезависимый машиночитаемый носитель по п. 32, в котором пакет от другого узла содержит временную метку истечения, IP-адрес и порт предыдущего узла, IP-адрес и порт следующего узла.

34. Энергонезависимый машиночитаемый носитель по п. 32, в котором способ связи по узловым ретрансляторам также включает попытку расшифровки первого потокового маркера в пакете от другого узла посредством закрытого ключа узла и открытого ключа главного сервера; и

модифицирование пакета путем удаления первого потокового маркера и перенаправления полученного измененного пакета на IP-адрес и порт следующего узла в первом потоковом маркере в случае успешной попытки расшифровки первого потокового маркера.

35. Система главного сервера для организации связи по узловым ретрансляторам, содержащая:

процессор;

память;

причем система главного сервера выполнена с возможностью реализации способа связи по узловым ретрансляторам, включающего:

a) получение информации об узлах от узлов в сети;

b) определение одного или более потоковых маршрутов между начальным узлом и конечным узлом из информации об узлах, причем каждый потоковый маршрут из одного или более потоковых маршрутов включает один или более узлов в сети, кроме начального узла и конечного узла;

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

36. Система сервера-матчмейкера для организации связи по узловым ретрансляторам, содержащая:

процессор;

память;

причем система сервера-матчмейкера выполнена с возможностью реализации способа связи по узловым ретрансляторам, включающего:

a) получение запроса от клиента на установку связи с одним или более серверами;

b) осуществление запроса одного или более потоковых маршрутов между клиентом и одним или более серверами от главного сервера;

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