Подсказки о маршруте

Подсказки о маршруте

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

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

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

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

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

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

Другими словами, ранее переданная информация используется для продолжения существующего сеанса. Таким образом, продолжение существующего сеанса, в основном, относится к тем ситуациям, в которых одни и те же первые и вторые субъекты, которые ранее установили сеанс, пытаются продолжить его. Следовательно, проблемы могут возникать, когда первый субъект пытается продолжить существующий сеанс, если второй субъект неизвестен, и/или его трудно идентифицировать, или с ним трудно установить контакт.

Следовательно, существует потребность в схемах и/или методах, которые улучшают, упрощают и/или способствуют продолжению сеанса между двумя субъектами.

Раскрытие изобретения

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

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

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

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

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

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

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

В данном документе описываются другие реализации способа, системы, подхода, аппарата, интерфейса прикладного программирования (ИПП), устройства, носителя, процедуры, средства и т.д.

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

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

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

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

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

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

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

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

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

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

Осуществление изобретения

Фиг.1 представляет собой примерную среду 100 передачи данных, которая иллюстрирует первое соединение 114(1), которое устанавливает сеанс, и второе соединение 114(2), которое продолжает сеанс. Как изображено, примерная среда 100 передачи данных включает в себя многочисленные клиенты 102(1), 102(2) … 102(m) и многочисленные хосты 108(1), 108(2) … 108(n), а также сеть 104 и сетевой шлюз (NG) 106. Сетевой шлюз 106 служит в качестве шлюза между сетью 104 и интрасетью 110. Хосты 108 связаны с интрасетью 110.

В описываемой реализации клиенты 102(1), 102(2) … 102(m) соответствуют адресам «С1», «С2», … «Сm», соответственно. Каждым клиентом 102 может быть любое устройство, которое может выполнять передачу данных по сети, такое как компьютер, мобильная станция, развлекательный прибор, другая сеть и т.п. Клиенты 102 также могут соответствовать человеку или другому субъекту, который работает за клиентским устройством. Другими словами, клиенты 102 могут содержать логические клиенты, которыми являются пользователи и/или машины.

Сеть 104 может быть образована из одной или нескольких сетей, таких как Интернет, другая интрасеть, проводная или беспроводная телефонная сеть, беспроводная широкополосная сеть и т.п. Дополнительные примеры устройств для клиентов 102 и типов/топологий сети для сети 104 описываются ниже с ссылкой на фиг.8. Индивидуальные клиенты 102 могут передавать данные одному или нескольким хостам 108, и наоборот, по сети 104 через сетевой шлюз 106.

Хосты 108(1), 108(2) … 108(n) соответствуют адресам «Н1», «Н2» … Нn», соответственно. Адреса Н1, Н2 … Нn хостов присутствуют в интрасети 110. Хосты 108 обычно хостируют одно или несколько приложений (не показаны). Эти приложения (i) предоставляют службы для взаимодействия и/или передачи данных клиентам 102, (ii) предназначены для использования клиентами 102 и т.п. Только в качестве примера, такие приложения могут включать в себя программы доставки файлов, программы серверов/управления веб-сайтами, программы удаленного доступа, программы электронной почты, программы доступа к базе данных и т.п.

Каждый хост 108 может соответствовать серверу и/или устройству, многочисленным серверам и/или многочисленным устройствам, части сервера и/или части устройства, некоторой их комбинации и т.п. Конкретные примерные реализации для хостов 108 описаны подробно ниже с ссылкой на фиг.2, 4 и 5. Кроме того, дополнительные примерные реализации устройств для хостов 108 описаны ниже с ссылкой на фиг.8.

Сетевой шлюз 106 может быть вызван или локализован через сеть 104 по одному или нескольким адресам «NGN», и сетевой шлюз 106 также присутствует в интрасети 110 по меньшей мере с одним адресом «NGI». Передачи данных от клиентов 102 (или других узлов), которые направляются по адресу NGN сетевого шлюза 106, принимаются сетевым шлюзом 106 и после этого маршрутизируются на хост 108 из хостов 108(1), 108(2) … 108(n). Сетевой шлюз 106 состоит из одного или нескольких элементов сетевого шлюза (не показаны отдельно на фиг.1). Каждый элемент 106 сетевого шлюза может содержать все или часть из маршрутизатора, модуля-посредника, выравнивателя нагрузки, устройства брандмауэра, некоторой их комбинации и т.п. Примерные реализации устройства общего назначения для элементов 106 сетевого шлюза также описываются ниже с ссылкой на фиг.8.

В общих чертах, соединения 114 выполняются между клиентами 102 и хостами 108 по сети 104 через сетевой шлюз 106. Клиенты 102 обычно инициируют соединения 114, но хосты 108 могут, альтернативно, быть инициаторами. Конкретно в данном примере, клиент 102(1) инициирует соединение 114(1) с хостом 108(2). Однако клиент 102(1) не осведомлен об адресе Н2 хоста 108(2). Вместо этого клиент 102(1) направляет соединение (например пакет, запрашивающий соединение) на адрес NGN сетевого шлюза 106.

Сетевой шлюз 106 затем выполняет операцию 116(1) маршрутизации по соединению 114(1) в соответствии с некоторой политикой по умолчанию (например, правилом). В результате сетевой шлюз 106 маршрутизирует соединение 114(1) по интрасети 110 на хост 108(2) для данного примера. В основном, сетевой шлюз 106 не может просто послать пакеты соединения 114 от клиента 102(1) «как есть» хосту 108(2) по сетевому адресу Н2, так как пакеты по назначению адресованы на адрес NGN сетевого шлюза 106. Вместо этого сетевой шлюз 106 обычно применяет один или несколько из следующих примерных вариантов для маршрутизации пакетов по интрасети 110: преобразование сетевых адресов (ПСА), половинное ПСА, туннелирование, некоторые их комбинации и т.п.

В среде протокола управления передачей/протокола Интернета (ПУП/ПИ), ПСА выполняется посредством (i) перезаписи адреса С1 ПИ получателя (т.е. клиента 102(1)) и номера порта адресом NGI ПИ и сгенерированным ПСА номером порта сетевого шлюза 106 и (ii) перезаписи адреса NGN ПИ получателя адресом Н2 ПИ хоста 108(2). Половинное ПСА выполняется посредством перезаписи адреса NGN ПИ получателя адресом Н2 ПИ хоста 108(2), так что сохраняются адрес С1 ПИ отправителя и номер порта. Туннелирование выполняется посредством инкапсуляции каждого пакета в новый пакет ПИ, который адресуется на адрес Н2 хоста 108(2), и передачи инкапсулированных пакетов от сетевого шлюза 106 хосту 108(2), где они могут деинкапсулироваться.

Во время соединения 114(1) сеанс устанавливается между клиентом 102(1) и хостом 108(2). Для установленного сеанса соединения 114(1) контекст 112 сеанса создается на хосте 108(2). Аналогичный, подобный и/или эквивалентный контекст сеанса (не показан) также обычно создается на клиенте 102(1). Контекст 112 сеанса способствует передаче данных между клиентом 102(1) и хостом 108(2).

Таким образом, соединение 114(1) может быть или может установить на нем любой один или несколько из многих различных типов сеансов. Примерные типы сеансов включают в себя: (i) сеанс уровня защищенных сокетов (УЗС); (ii) сеанс безопасности транспортного уровня (БТУ); (iii) сеанс защищенного протокола Интернета (ЗПИ); (iv) основанный на куки-файлах сеанс протокола передачи гипертекста (ППГТ); (v) сеанс протокола туннелирования между узлами (ПТМУ); (vi) сеанс ЗПИ/протокола туннелирования на втором уровне; (vii) частный сеанс; (viii) сеанс терминального сервера, (ix) определяемый администратором сеанс; (x) и т.п. Эти примеры различных типов сеансов также освещают, как могут устанавливаться и использоваться уровни сеансов.

Содержимое контекста 112 сеанса может изменяться, по меньшей мере частично, в зависимости от типа сеанса, для которого он был создан. Например, конкретный контекст 112 сеанса может включать в себя одно или несколько из следующего: кортеж из 4 элементов ПУП (например, для сеансов, установленных соединением ПУП); идентификатор сеанса; расположение одной или нескольких записей базы данных, которые сопровождают тупиковое состояние для соответствующего сеанса; открытый ключ клиента 102(1), который предоставляется хосту 108(2); согласованный секретный криптографический ключ(и); другой относящийся к безопасности параметр(ы); и т.п. Кортеж из 4 элементов ПУП включает в себя адрес ПИ отправителя, порт ПУП отправителя, адрес ПИ получателя и порт ПУП получателя. В качестве примера для сеанса УЗС по современным стандартам, длина идентификатора сеанса может быть до 32 байтов.

Как описано выше, после выполнения соединения 114(1) устанавливается сеанс между клиентом 102(1) и хостом 108(2) в текущем примере. Клиент 102(1), более конкретно, устанавливает сеанс с по меньшей мере одним приложением, которое является резидентным и/или выполняющимся на хосте 108(2). Однако, для ясности, такие приложения, в основном, могут включаться при ссылке на хост 108(2).

Фаза установления сеанса создает или приводит к контексту 112 сеанса. Контекст 112 сеанса предоставляет контекст для обмена данными при передаче между клиентом 102(1) и хостом 108(2). Контекст 112 сеанса может включать в себя информацию, которая, фактически, является критической, просто полезной или иным образом относящейся так или иначе к этому обмену(ам) данными при передаче.

В связи с тем, что клиент 102(1) может быть логическим клиентом, контекст 112 сеанса может относиться к обменам данными при передаче между (i) определенным устройством и/или определенным пользователем устройства и (ii) хостом 108(2). Следовательно, контекст 112 сеанса, который ассоциируется с клиентом 102(1) пользователя, может продолжаться быть ассоциированным с ним даже тогда, когда клиент 102(1) пользователя обращается к хостам 108 с различных устройств. Устройства могут отличаться на локальном уровне для клиента 102(1), на уровне сети 104 и т.п. Примеры таких различных сценариев устройств включают в себя сценарий модуля-посредника (например, сценарии некоторых провайдеров услуг Интернета (ПУИ)), сценарий сеанса терминального сервера и т.п.

Контекст 112 сеанса хранится на хосте 108(2) и/или может быть доступен с него. Когда соединение 114(1) завершается или иным образом прерывается, контекст 112 сеанса не может снова использоваться. В противоположность этому контекст 112 сеанса может быть снова полезным, если клиент 102(1) предпринимает попытку инициировать другое соединение с хостами 108 для или этого же, или подобного, или связанного с ним и т.п. сеанса. Если это другое соединение не маршрутизируется на этот же хост 108(2), который хранит контекст 112 сеанса, тогда клиенту 102(1) необходимо установить новый сеанс, что может требовать много времени, быть интенсивным в отношении данных/обработки и/или разочаровывающим для пользователей (особенно для пользователя, соответствующего клиенту 102(1)). Без некоторого механизма сохранения сходства сеансов на сетевом шлюзе 106 обычно нет вероятности большей, чем случайность, что второе соединение также маршрутизируется на хост 108(2).

Механизм или функциональная возможность сохранения сходства сеансов предназначена для маршрутизации соединений (включая запросы пакетного уровня и логического уровня) обратно на хост 108, который ассоциируется с контекстом 112 сеанса для существующего сеанса, который должен быть продолжен с соединением. Например, функциональная возможность сохранения сходства сеансов предпринимает попытку сделать возможным, чтобы соединение 114(2) для клиента 102(1) маршрутизировалось обратно на хост 108(2), с которым ассоциируется контекст 112 сеанса. Такие механизмы сохранения сходства сеансов могут быть реализованы в соответствии с одной или несколькими примерными стратегиями. Хотя эти примерные стратегии, в основном, применимы к сетевым шлюзам 106, они описываются с точки зрения реализации выравнивания нагрузки.

Первая стратегия относится к выравниванию нагрузки с режимом «с приклеиванием», в котором большинство, если не все, запросы, которые поступают с данного адреса, например, ПИ, маршрутизируются на единственный хост 108. Однако эта стратегия основывается на предположении, что данный адрес ПИ представляет единственного клиента 102, что, очевидно, является неверным для модулей-посредников. Модуль-посредник выглядит как единственный адрес ПИ для выравнивателя нагрузки, но он, фактически, представляет запросы для многих, потенциально тысяч клиентов 102. В результате маршрутизация всех этих запросов на единственный хост 108 может привести к очень неравномерному выравниванию нагрузки между/среди устройств. Обычно устройствам, которые принимают входящие запросы от модуля-посредника, последовательно назначаются значительно большее количество клиентов 102. Кроме того, запросы от клиента 102, который имеет изменяющиеся адреса ПИ, также маршрутизируются неправильно, используя эту первую стратегию. Адреса ПИ могут изменяться в мобильной среде, когда адреса временно распределяются из пула адресов ПИ, и т.п.

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

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

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

Третья стратегия для функциональной возможности сохранения сходства сеансов может достигать сохранения сходства сеансов на сетевом шлюзе 106 посредством селективного создания/определения идентификаторов сеанса для сеансов, которые вновь устанавливаются и без таблицы, которая требует записи для каждого индивидуального сеанса. При определении идентификаторов сеанса хосты 108 внедряют в них идентификатор хоста.

Сетевой шлюз 106 извлекает идентификатор хоста из идентификатора сеанса и маршрутизирует трафик для сеанса, для которого идентификатор сеанса назначается зависимым от идентификатора хоста. Третья стратегия, поэтому, может применять подход относительно без сохранения информации, который маршрутизирует запросы продолжения сеанса, используя таблицу с ограниченным количеством записей (например, количество записей, которое равно количеству хостов 108), и/или который маршрутизирует запросы продолжения сеанса без использования таблицы, которая имеет такие записи на каждый сеанс. Аспекты этой третьей стратегии описываются подробно в этом описании.

В примере среды 100 передачи данных, после того как будет завершена фаза установления сеанса в качестве части соединения 114(1), создается контекст 112 сеанса на хосте 108(2). После этого прерывается соединение 114(1). Когда поступает запрос на соединение 114(2) на сетевой шлюз 106, на нем выполняется операция 116(2) маршрутизации. Это соединение 114(2), как указывается, является предназначенным для продолжения раннее установленного сеанса, который соответствует контексту 112 сеанса посредством идентификатора сеанса, назначенного для него. Идентификатор сеанса включает в себя идентификатор хоста 108(2) в соответствии с третьей стратегией. Использование идентификатора хоста для хоста 108(2), который извлекается из идентификатора сеанса запроса продолжения сеанса, соединение 114(2) маршрутизируется операцией 116(2) маршрутизации на хост 108(2), который ассоциируется с контекстом 112 сеанса.

Элементы 114(1) и 114(2) также могут представлять относящиеся к сеансу сообщения (например, запросы), которые происходят во время единственного соединения, а также те, которые происходят во время двух или более соединений. Кроме того, определенные передачи данных между клиентами 102 и хостами 108 описываются в данном описании как сообщения. Сообщения обычно распространяются от клиентов 102 на хосты 108, и, наоборот, в виде одного или нескольких пакетов. Сообщения клиентов посылаются от клиентов 102, и сообщения хоста посылаются от хостов 108. Сообщения сеансов представляют собой те сообщения, которые относятся к сеансам (например, те, которые относятся к установлению, продолжению/возобновлению, разрыву и т.д. сеансов). Примерное сообщение сеанса описывается подробно ниже с ссылкой на фиг.3.

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

Хотя описание в данном документе не настолько ограничено, реализации, описанные ниже, время от времени придают большое значение или концентрируются на реализациях выравнивания нагрузки для сетевого шлюза 106. Также, хотя применимы другие протоколы и комбинации протоколов, и они могут использоваться альтернативно, описание ниже использует, главным образом, соединения ПУП/ПИ и сеансы УЗС/БТУ для ясности.

В качестве примера, но не ограничения, сообщением инициирования сеанса клиента или сообщением продолжения сеанса клиента может быть сообщение «Client Hello» согласно Спецификации протокола БТУ версии 1.0 (январь 1999 г.). Если сообщение Client Hello включает в себя идентификатор сеанса, тогда оно может быть сообщением продолжения сеанса клиента, иначе оно может быть сообщением инициирования сеанса клиента. Аналогично, сообщением инициирования сеанса хоста или сообщением продолжения сеанса хоста может быть сообщение «Server Hello» согласно Спецификации протокола БТУ версии 1.0. Если сообщение Server Hello включает в себя идентификатор сеанса, представленный клиентом в сообщении Client Hello, на который отвечает сообщение Server Hello, тогда оно может быть сообщением продолжения сеанса хоста. Если сообщение Server Hello отвечает на сообщение Client Hello, которое не включает в себя идентификатор сеанса, тогда оно может быть сообщением инициирования сеанса хоста. Создание идентификатора сеанса для и формулирование такого сообщения инициирования сеанса хоста описывается подробно ниже.

Фиг.2 иллюстрирует примерный подход для предоставления и использования подсказок о маршруте с сообщениями сеансов. Сообщения 202, 204 и 206 сеансов посылаются от клиента 102 хосту 108, или, наоборот, по сети 104 через элемент 106 сетевого шлюза. Элемент 106 сетевого шлюза представляет элемент сетевого шлюза 106 (по фиг.1). Хотя каждое из сообщений 202, 204 и 206 сеансов показано как маршрутизируемое элементом 106 сетевого шлюза, каждое индивидуальное сообщение сеанса может, альтернативно, маршрутизироваться различными индивидуальными элементами сетевого шлюза 106.

Как изображено, хост 108 включает в себя обработчик 208 сообщений, который обрабатывает сообщения, которые посылаются клиентам 102 и принимаются от них. Обработчик 208 сообщений включает в себя часть 208IC обработчика входящих сообщений и часть 208OG обработчика исходящих сообщений. Хост 108 ассоциируется с идентификатором 214 хоста, который хранится на хосте 108 или иным образом доступен с него. Примеры идентификатора 214 хоста описываются подробно ниже с ссылкой на фиг.3. Хост 108 также включает в себя создатель 212 идентификаторов сеанса, который создает идентификаторы сеанса (например, идентификатор 210 сеанса), используя идентификатор 214 хоста.

В описываемой реализации клиент 102 имеет адрес «С», и элемент 106 сетевого шлюза имеет адреса NGN и NGI, причем адреса С и NGN расположены в сети 104. Хост 108 имеет адрес «Н», который располагается в интрасети 110 вместе с адресом NGI. Сообщения сеанса от клиента 102 принимаются по сети 104 элементом 106 сетевого шлюза. Элемент 106 сетевого шлюза затем маршрутизирует эти сообщения сеанса вперед на хост 108 по интрасети 110 при помощи операций 216 маршрутизации. На обратном пути сообщения сеанса от хоста 108 посылаются/передаются по интрасети 110 на элемент 106 сетевого шлюза, который маршрутизирует их обратно клиенту 102 при помощи операций 216 маршрутизации.

Конкретно, клиент 102 посылает сообщение 202 инициирования сеанса (СИС) клиента по сети 104 элементу 106 сетевого шлюза. Сообщение 202 инициирования сеанса клиента не включает в себя идентификатор сеанса, так как оно содержит запрос нового сеанса. Так как сообщение 202 инициирования сеанса клиента не предназначено для существующего сеанса, элемент 106 сетевого шлюза маршрутизирует сообщение 202 инициирования сеанса клиента на хост 108, используя общую политику в операции 216(А) маршрутизации. Например, элемент 106 сетевого шлюза может маршрутизировать сообщение 202 инициирования сеанса клиента в соответствии с текущей и/или имеющей отношение политикой выравнивания нагрузки (например, циклическое распределение входящих запросов нового сеанса).

Хост 108 принимает сообщение 202 инициирования сеанса клиента по интрасети 110 частью 208IC обработчика входящих сообщений. Без идентификатора сеанса часть 208 IC обработчика входящих сообщений распознает сообщение 202 инициирования сеанса клиента как предназначенное для нового сеанса. Создатель 212 идентификатора сеанса активизируется для создания идентификатора нового сеанса для запрашиваемого нового сеанса. Создатель 212 идентификатора сеанса выясняет/извлекает идентификатор 214 хоста.

Создатель 212 идентификатора сеанса использует идентификатор 214 хоста для создания идентификатора 210 сеанса. Например, создатель 212 идентификатора сеанса вставляет идентификатор 214 хоста в идентификатор 210 сеанса. Идентификатор 210 сеанса также может включать в себя другие значения, кроме значения идентификатора 214 хоста. Могут создаваться дополнительные значения идентификатора 210 сеанса, используя любой один или несколько методов. Такие методы включают в себя, но не ограничиваются ими, случайно выбранное значение, значение из счетчика с накоплением значений, связанное с безопасностью значение, хешированное значение, некоторую их комбинацию и т.п.

В описываемой реализации первая часть (т.е. идентификатор 214 хоста) идентификатора 210 сеанса отводится для идентификации хоста 108, который в данный момент владеет соответствующим сеансом. Эта первая часть является уникальной среди хостов 108 данного кластера (т.е. никакой хост 108 не использует совместно свой идентификатор 214 хоста ни с каким любым другим хостом 108 в одном и том же кластере). Первой частью может быть адрес ПИ, принадлежащий хосту 108, целое число, которое назначается администратором, и т.п. Вторая часть идентификатора 210 сеанса может повышать уникальность (и невозможность прогнозирования) идентификатора 210 сеанса. Множество методов могут использоваться для этой второй части, такой как комбинация использования глобального счетчика, который получает приращение один раз для каждого нового сеанса (с опрокидыванием в 0), и использования псевдослучайного метода и/или метода хеширования.

Создатель 212 идентификатора сеанса предоставляет идентификатор 210 сеанса обработчику 208 сообщений. Часть 208OG обработчика исходящих сообщений готовит/формулирует сообщение 204 инициирования сеанса хоста, которое включает в себя идентификатор 210 сеанса. Сообщение 204 инициирования сеанса хоста посылается по интрасети 110 на элемент 106 сетевого шлюза. Элемент 106 сетевого шлюза затем использует операцию 216(В) маршрутизации по обратному маршруту для посылки сообщения 204 инициирования сеанса хоста по сети 104 клиенту 102. Хотя это не изображено, сообщение 204 инициирования сеанса хоста может, альтернативно, маршрутизироваться обратно по пути, который не включает в себя элемент 106 сетевого шлюза, особенно ввиду того, что элемент 106 сетевого шлюза может маршрутизировать последующие сообщения клиента без собирания информации о состоянии для каждого сеанса.

Клиент 102 извлекает идентификатор 210 сеанса из сообщения 204 инициирования сеанса хоста и сохраняет идентификатор 210 сеанса для возможного будущего использования для продолжения установленного сеанса (и для любого текущего использования с установленным сеансом). В некоторый момент прерывается фактическое использование установленного сеанса (например, соединение завершается). Чтобы продолжить установленный и существующий сеанс с хостом 108, клиент 102 формулирует сообщение 206 продолжения сеанса (СПС) клиента. Клиент 102 включает сохраненный идентификатор 210 сеанса в сообщение 206 продолжения сеанса клиента. Сообщение 206 продолжения сеанса клиента затем посылается по сети 104 от клиента 102 элементу 106 сетевого шлюза.

Когда элемент 106 сетевого шлюза принимает сообщение 206 продолжения сеанса клиента, он обнаруживает, что клиент 102 пытается продолжить существующий сеанс, что указывается посредством включенного идентификатора 210 сеанса. В операции 216(С) маршрутизации элемент 106 сетевого шлюза маршрутизирует сообщение 206 продолжения сеанса клиента, используя идентификатор 210 сеанса. Более конкретно, элемент 106 сетевого шлюза маршрутизирует сообщение 206 продолжения сеанса клиента, используя идентификатор 214 хоста, который составляет часть идентификатора 210 сеанса и извлекается из него.

Идентификатор 214 хоста идентифицирует хост 108, с которым он ассоциируется. Следовательно, элемент 106 сетевого шлюза маршрутизирует сообщение 206 продолжения сеанса клиента в операции 216(С) маршрутизации, используя идентификацию хоста 108, указываемую посредством идентификатора 214 хоста. Сообщение 206 продолжения сеанса клиента, поэтому, посылается по интрасети 110 от элемента 106 сетевого шлюза хосту 108. На хосте 108 часть 208IC обработчика входящих сообщений принимает сообщение 206 продолжения сеанса клиента и может начинать продолжение ранее установленного сеанса, используя хранимый контекст сеанса (например, контекст 112 сеанса, как показано на фиг.1).

Идентификатор 214 хоста может идентифицировать хост 108, с которым он ассоциируется, многочисленным образом. Например, идентификатор 214 хоста может содержать сетевой адрес Н (интрасети) хоста 108. В этом случае элемент 106 сетевого шлюза может маршрутизировать сообщение 206 продолжения сеанса клиента на хост 108 без использования связанной с сеансом таблицы или таблицы идентификаторов хоста. Другими словами, сообщение 206 продолжения сеанса клиента может продвигаться к хосту 108, используя идентификатор 214 хоста, или по меньшей мере часть его, в качестве адреса получателя одного или нескольких пакетов, которые посылаются в интрасеть 110 для сообщения 206 продолжения сеанса клиента.

Альтернативно, идентификатор 214 хоста может отображаться на адрес Н для хоста 108. Хотя такой метод отображения включает в себя таблицу (или вычисление), количество записей «n» в таблице может быть равно количеству хостов 108 в кластере серверов, в интрасети 110, в веб-ферме и т. п. Таким образом, эта таблица имеет ограниченное количество записей и не включает в себя информацию о состоянии для каждого сеанса. С ссылкой например, используемый выше, если каждый хост 108 кэширует 10 000 сеансов, и имеется 500 хостов 108, таблица может использовать 500 записей (вместо 5 миллионов) для эффективной маршрутизации запросов для этих сеансов.

Таблица ниже представляет собой примерную структуру данных связывания, которая связывает идентификаторы 214 хоста с хостами 108 посредством адресов хостов 108.

Структура данных для отображения идентификаторов 214 хоста на адреса Н хоста
Номер записи	Идентификатор [214] хоста	Адрес [H] хоста
1	идентификатор 214(1) хоста	адрес Н1 хоста
2	идентификатор 214(2) хоста	адрес Н2 хоста
:	:	:
n	идентификатор 214(n) хоста	адрес Hn хоста

В работе элемент 106 сетевого шлюза извлекает идентификатор 214(#) хоста из идентификатора 210 сеанса сообщения 206 продолжения сеанса клиента, принимаемого от клиента 102. Эл