ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ
[0001] Web-конференцсвязь становится все более полезным инструментальным средством для проведения онлайновых собраний, презентаций, обучающих семинаров и т.д. по Интернету или Всемирной паутине (Web). В типичной web-конференции несколько участников конференции подключаются друг к другу по Интернету со своих персональных компьютеров. Примерной программной платформой для предоставления возможностей web-конференцсвязи является MICROSOFT COMMUNICATIONS SERVER, разработанная компанией MICROSOFT Corporation, Редмонд, Вашингтон. Если клиент хочет присоединяться к онлайновому собранию, но не имеет Office Communicator, например, установленного на клиентском компьютере, клиент Communicator Web Access (CWA) на основе технологии AJAX (асинхронного JavaScript и XML) типично используется для того, чтобы предоставлять возможность клиенту присоединяться к собранию. Хотя CWA-клиент на основе технологии AJAX может присоединяться к собранию, взаимодействие с клиентом ограничивается посредством функциональности, доступной через JavaScript.
[0002] Чтобы улучшать взаимодействие при проведении собраний основывающегося на обозревателе клиента (браузера) без необходимости явной установки клиентского приложения, может быть использован тип клиента, отличный от CWA-клиента на основе технологии AJAX. Например, может быть использован клиент на основе технологии SILVERLIGHT, полученный из платформы MICROSOFT SILVERLIGHT, созданной компанией MICROSOFT Corporation, Редмонд, Вашингтон. SILVERLIGHT обеспечивает возможность разработки многофункциональных приложений, которые почти соответствуют собственным приложениям с точки зрения как функциональности, так и базового протокола, используемого для того, чтобы обмениваться данными с сервером. Тем не менее, платформа SILVERLIGHT-типа по-прежнему может иметь некоторые ограничения на возможности разрабатывать такое приложение. Например, основывающийся на обозревателе клиент типично не поддерживает сокетное соединение по протоколу управления передачей (TCP) с удаленным сервером(ами), обеспечивающее поддержку конференций по принципу web-собраний. Такие сокетные соединения запрещены вследствие усиленных функций безопасности, внутренне присущих в корпоративных сетях клиента, в которых извлечение файлов политик не допускается вследствие ограниченных портов и полной неспособности обходить брандмауэры. Действительно, ограниченные сетевые подключения существуют в таких случаях в качестве сетей, защищенных брандмауэром, сетей за прокси-серверами и т.д. Без файла политик основывающийся на обозревателе клиент отклоняет открытие сокетного соединения с удаленным сервером. Дополнительно, доступ к определенным пакетам обеспечения безопасности, таким как протокол аутентификации с помощью NT LAN Manager (NTLM), аутентификации Kerberos либо аутентификация на основе сертификатов, может быть недоступен для приложения. Без таких возможностей аутентификации основывающийся на обозревателе клиент не может быть допущен на сервер по протоколу инициирования сеанса (SIP) с использованием протокола, идентичного протоколу собственного клиента.
[0003] Хотя конкретные проблемы рассмотрены в этом разделе "Предшествующий уровень техники", это раскрытие сущности не имеет намерение каким-либо образом быть ограниченным решением этих конкретных проблем.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
[0004] Варианты осуществления, в общем, относятся к предоставлению полнофункционального взаимодействия при проведении собраний и улучшенной функциональности для web-клиента посредством использования серверного объекта, чтобы выступать в качестве "посредника" для соединения web-клиента с удаленной оконечной точкой, например с удаленным сервером(ами), в платформе собрания без необходимости изменений удаленного сервера(ов). Такой сервер-"посредник" упоминается, например, как "ретрансляционный сервер". Варианты осуществления тем самым предусматривают обеспечение возможности клиенту в ограниченном окружении расширять свою функциональность посредством соединения и тем самым использования функциональности ретрансляционного сервера. Ретрансляционный сервер, в свою очередь, имеет функциональность, ассоциированную со своим окружением, таким как, например, платформа Windows. Web-клиент типично использует протокол передачи гипертекста (HTTP) или протокол защищенной передачи гипертекста (HTTPS) для связи и обмена данными в web-окружении. Описание вариантов осуществления ниже ссылается на "HTTP". Тем не менее, как должны принимать во внимание специалисты в данной области техники, такие варианты осуществления включают в себя "HTTPS", когда выполняются ссылки на "HTTP". Если удаленный сервер в платформе собрания, к примеру, сервер MICROSOFT OFFICE COMMUNICATIONS ("сервер OCS"), имеет существующий протокол связи, который не основан на HTTP, например, использование ретрансляционного сервера разрешает обмен данными между web-клиентом и удаленным сервером(ами) посредством туннелирования произвольных двоичных данных или произвольных протокольных данных по HTTP между клиентом или оконечной HTTP-точкой и удаленным сервером или другим произвольным пунктом назначения. Варианты осуществления тем самым предоставляют возможность туннелирования любых произвольных данных по HTTP. Например, варианты осуществления предусматривают следующие примерные использования ретрансляционного сервера для надежного туннелирования протокола по HTTP: туннелирование любых данных по HTTP в транспортном протоколе реального времени (RTP)/защищенном транспортном протоколе реального времени (SRTP); туннелирование протокола удаленного рабочего стола (RDP) по HTTP в любом транспортном механизме (например, TCP или протокол пользовательских датаграмм (UDP)); туннелирование RDP по HTTP в RTP/SRTP; решение туннелирования SIP по HTTP и т.д.
[0005] Поскольку HTTP является простым протоколом запроса/ответа, он поддерживает несколько соединений из клиента с сервером и, следовательно, не гарантирует упорядоченную доставку сообщений запроса и ответа. Надежная доставка сообщений также не гарантируется при условии, что сообщения запроса и ответа могут быть отброшены в передаче сообщений. Например, промежуточный HTTP-прокси-сервер может отбрасывать HTTP-ответ. Надежная и упорядоченная организация и доставка сообщений являются ценными для окружения web-конференции. Также, варианты осуществления настоящего раскрытия предоставляют возможность использования идентификаторов сеансов для того, чтобы группировать запросы, которые принадлежат идентичному ретрансляционному сеансу. Дополнительно, надежная и упорядоченная доставка сообщений достигается посредством ограничения запросов одним незавершенным восходящим запросом и одним незавершенным нисходящим запросом одновременно. Варианты осуществления также предоставляют возможность использования порядковых номеров/чисел подтверждения приема для того, чтобы обеспечивать обнаружение потерянных сообщений и повторную отправку потерянных данных. Отрицательные HTTP-ответы также обрабатываются в вариантах осуществления, чтобы повторять запросы, чтобы способствовать надежной, например без потерь, передаче данных по HTTP и способности системы к восстановлению после сбоев. Помимо этого, варианты осуществления предусматривают платформенные службы в качестве части ретрансляционного сервера, при этом такие платформенные службы включают в себя, например, выполнение общих криптографических операций, операций службы доменных имен (DNS) и использование брокера аутентификации, чтобы помогать web-клиенту в вычислении обмена аутентификационными данными с пунктом назначения в окружении собрания. Далее, дополнительно, варианты осуществления предоставляют возможность системным компонентам быть подключаемыми по своему характеру и тем самым расширять функциональность web-клиента. Например, туннелирование произвольного протокола осуществляется, согласно вариантам осуществления, посредством задания подключаемого транспортного компонента на ретрансляционном сервере. Этот подключаемый транспортный компонент обеспечивает использование транспортировки по протоколу защиты транспортного уровня (TLS)/протоколу защищенных сокетов (SSL) при SIP-туннелировании, тогда как, с другой стороны, например, SRTP-транспортировка используется при RDP-туннелировании. Дополнительно, подключаемый характер компонента платформенных служб дает возможность клиенту выполнять SIP-аутентификацию с использованием брокера аутентификации в соответствии с вариантом осуществления настоящего раскрытия.
[0006] Это краткое изложение сущности изобретения предоставлено для того, чтобы представлять в упрощенной форме подбор из концепций, которые дополнительно описаны ниже в подробном описании. Это краткое изложение сущности изобретения не предназначено для того, чтобы идентифицировать ключевые или важнейшие признаки заявленного изобретения, а также не предназначено для использования таким образом, который ограничивает объем заявленного изобретения.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
[0007] Варианты осуществления настоящего раскрытия могут быть легко описаны в отношении прилагаемых чертежей, на которых аналогичные номера означают аналогичные элементы.
[0008] Фиг.1 иллюстрирует примерное логическое представление окружения или системы для инициирования собрания между участниками с использованием web-клиента в соответствии с вариантами осуществления, раскрытыми в данном документе.
[0009] Фиг.2 иллюстрирует примерное логическое представление окружения или системы для туннелирования произвольных двоичных данных через HTTP с использованием ретрансляционного сервера для собрания, проиллюстрированного на фиг.1, в соответствии с вариантами осуществления настоящего раскрытия.
[0010] Фиг.3 иллюстрирует логическое представление примерных функциональных компонентных модулей для туннелирования протокола по HTTP с использованием ретрансляционного сервера, проиллюстрированного на фиг.2, в соответствии с вариантами осуществления настоящего раскрытия.
[0011] Фиг.4 иллюстрирует блок-схему последовательности операций способа, показывающую функциональные характеристики процесса, демонстрирующего взаимодействия функциональных компонентных модулей, проиллюстрированных на фиг.3, в соответствии с вариантом осуществления настоящего раскрытия.
[0012] Фиг.5 иллюстрирует блок-схему последовательности операций способа, показывающую функциональные характеристики процесса, демонстрирующего подключаемый характер системы с использованием ретрансляционного сервера в соответствии с вариантами осуществления настоящего раскрытия.
[0013] Фиг.6 иллюстрирует блок-схему последовательности операций способа, показывающую функциональные характеристики процесса для группировки запросов (с помощью идентификатора сеанса), которые принадлежат ретрансляционному сеансу, в соответствии с вариантом осуществления настоящего раскрытия.
[0014] Фиг.7 иллюстрирует блок-схему последовательности операций способа, показывающую функциональные характеристики процесса для назначения порядковых номеров и чисел подтверждения приема запросам и ответам, чтобы обеспечивать надежную и упорядоченную доставку сообщений в соответствии с вариантом осуществления настоящего раскрытия.
[0015] Фиг.8A иллюстрирует логическое представление примерных функциональных компонентных модулей ретрансляционного сервера для туннелирования SIP-данных в соответствии с вариантами осуществления настоящего раскрытия.
[0016] Фиг.8B иллюстрирует блок-схему последовательности операций способа, показывающую функциональные характеристики процесса, демонстрирующего взаимодействия функциональных компонентных модулей, проиллюстрированных на фиг.8A, в соответствии с вариантом осуществления настоящего раскрытия.
[0017] Фиг.9 иллюстрирует блок-схему последовательности операций способа, показывающую функциональные характеристики процесса для аутентификации оконечной HTTP-точки с произвольным пунктом назначения с помощью брокера аутентификации на ретрансляционном сервере в соответствии с вариантом осуществления настоящего раскрытия.
[0018] Фиг.10 иллюстрирует логическое представление примерных функциональных компонентных модулей ретрансляционного сервера для туннелирования RDP-данных в соответствии с вариантами осуществления настоящего раскрытия.
[0019] Фиг.11 иллюстрирует блок-схему последовательности операций способа, показывающую функциональные характеристики процесса, показывающего взаимодействия функциональных компонентных модулей, проиллюстрированных на фиг.10, в соответствии с вариантом осуществления настоящего раскрытия.
[0020] Фиг.12 иллюстрирует примерную вычислительную систему, в которой могут быть реализованы варианты осуществления настоящего раскрытия.
ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ
[0021] Данное раскрытие далее подробнее описывает примерные варианты осуществления со ссылкой на прилагаемые чертежи, на которых показаны конкретные варианты осуществления. Тем не менее, другие аспекты могут быть осуществлены во многих различных формах, и включение конкретных вариантов осуществления в это раскрытие не должно быть истолковано в качестве ограничения таких аспектов вариантами осуществления, изложенными в данном документе. Наоборот, варианты осуществления, проиллюстрированные на чертежах, включаются, чтобы предоставлять раскрытие, которое является полным и завершенным и которое полностью передает намеченный объем для специалистов в данной области техники. Пунктирные линии могут быть использованы для того, чтобы показывать необязательные компоненты или операции.
[0022] Варианты осуществления, в общем, относятся к использованию ретрансляционного сервера, чтобы расширять функциональность основывающегося на обозревателе или web-технологиях клиента в окружении для проведения web-собраний. В альтернативных вариантах осуществления клиент не является основывающимся на обозревателе или web-технологиях клиентом, а наоборот, является любым типом клиента, понимаемого специалистами в данной области техники. Ретрансляционный сервер обеспечивает туннелирование произвольных двоичных данных, например, между web-клиентом или оконечной HTTP-точкой и произвольным пунктом назначения или удаленным сервером. Такое туннелирование является полезным, поскольку web-клиент типично обменивается данными с использованием HTTP-протокола и не может обмениваться данными с использованием транспортных протоколов, понимаемых посредством удаленного сервера. Такие транспортные протоколы, например, включают в себя TCP, UDP, SRTP, TLS и т.д. Эти протоколы предлагаются только в качестве примера. Любое число транспортных протоколов, как должны понимать специалисты в данной области техники, может быть использовано посредством удаленного сервера. Туннелирование любого произвольного протокола, к примеру, SIP и RDP, через HTTP тем самым предоставляется с помощью ретрансляционного сервера. Ретрансляционный сервер выступает в качестве некоторого типа "посредника", чтобы принимать байтовый буфер через HTTP-запрос и ретранслировать запрос в пункт назначения. Аналогично, ретрансляционный сервер принимает данные из пункта назначения и ретранслирует данные обратно в клиент через HTTP-ответ.
[0023] В варианте осуществления ретрансляционный сервер разрабатывается как web-приложение, размещенное, например, в информационном Интернет-сервере (IIS). Ретрансляционный сервер в таких вариантах осуществления содержит компонент управления сеансами, компонент ретрансляционной подсистемы и необязательный компонент платформенных служб. Любое число типов компонентов может быть использовано в вариантах осуществления, в комбинации или по отдельности, и некоторые компоненты, как указано, также могут быть необязательными в вариантах осуществления. Ретрансляционный сервер выполнен с возможностью быть наращиваемым, чтобы предоставлять возможность использования любого транспортного механизма для того, чтобы принимать туннелированные данные из оконечной HTTP-точки. Ретрансляционный сервер дает возможность туннелирования любых двоичных данных. Например, SIP- и RDP-трафик туннелируются в вариантах осуществления. Тем не менее, другие варианты осуществления предоставляют возможность туннелирования любых данных, включающих в себя данные передачи файлов. При установлении ретрансляционного сеанса варианты осуществления предусматривают возможность ретрансляционному серверу обмениваться данными с целевой оконечной точкой, чтобы устанавливать соединение, так что можно обмениваться конкретными протокольными данными, понимаемыми посредством целевой оконечной точки. Таким образом, ретрансляционный сервер выполнен с возможностью обмениваться данными в произвольном протоколе, чтобы устанавливать соединение.
[0024] Согласно варианту осуществления для установления ретрансляционного сеанса, клиент выполняет запрос, чтобы создавать сеанс в компоненте управления сеансами ретрансляционного сервера. Это взаимодействие между клиентом и ретрансляционным сервером может упоминаться как первая "ветвь" ретрансляционного сеанса. В вариантах осуществления ретрансляционный сервер конфигурируется с помощью необязательной платформенной службы, чтобы помогать в установлении сеанса, будь то, например, аутентификация или DNS-поиск. Ретрансляционный сервер также конфигурируется с помощью одного или более транспортных модулей, при этом транспортный модуль(и) обменивается данными с удаленным сервером в конкретном протоколе. Компонент управления сеансами управляет транспортным модулем, чтобы подключаться к удаленному серверу, с потенциальной помощью от клиента, например, через вызовы на основе web-служб. "Вызовы на основе web-служб" предлагаются только в качестве примера способов передачи этой информации. Другие типы связи, понимаемой специалистами в данной области техники, также могут быть использованы. В варианте осуществления, для первой ветви ретрансляционного сеанса, компонент управления сеансами взаимодействует с компонентом ретрансляционной подсистемы, формирует идентификатор сеанса, чтобы группировать трафик на стороне HTTP, и возвращает идентификатор сеанса в клиент. С помощью идентификатора сеанса виртуальное соединение между клиентом и ретрансляционным сервером устанавливается по HTTP. Этот идентификатор сеанса должен присутствовать в каждом HTTP-запросе, который клиент отправляет, согласно вариантам осуществления. Идентификатор сеанса, вместе с порядковыми номерами/числами подтверждения приема, принудительное требование того, что существует самое большее один незавершенный запрос согласно направлению (восходящее и нисходящее) согласно варианту осуществления, и повторение отправки HTTP-запроса предварительно заданное число раз, когда, например, возникает сбой, предоставляют способ для надежной и упорядоченной доставки двунаправленных данных между клиентом и ретрансляционным сервером по HTTP. Как отмечено выше, в вариантах осуществления это соединение является одной ветвью ретрансляционного сеанса, а вторая ветвь ретрансляционного сеанса идет из ретрансляционного сервера на удаленный сервер, в котором используется произвольный транспортный протокол. Согласно вариантам осуществления, транспортный стек загружается на ретрансляционном сервере, чтобы разрешать туннелирование протоколов.
[0025] Посредством туннелирования протокольных данных по HTTP варианты осуществления настоящего раскрытия значительно расширяют функциональность web-клиента, поскольку ретрансляционный сервер предоставляет возможность адаптации к различным и отличающимся средствам для подключения к каждой возможной целевой оконечной точке. Например, если целевая оконечная точка является сервером, различные средства используются для подключения к конкретному типу сервера, к примеру, TLS к SIP-серверу, RTP/SRTP к серверу управления совместным использованием экрана и т.д.
[0026] Дополнительно, варианты осуществления настоящего раскрытия также компенсируют ограничения, вызываемые посредством ограничивающих портов и корпоративных брандмауэров, используемых для улучшения признаков безопасности. Вследствие ограничивающих портов, присутствующих в корпоративных сетях, может быть затруднительно, если не невозможно, извлекать файл политик из web-клиента. Например, порт 943 хранит реализацию файла политик в платформе SILVERLIGHT. Клиентский компьютер на основе SILVERLIGHT отправляет запросы в web-узлы, чтобы осуществлять доступ к файлу политик на порте 943. Тем не менее, порт 943 обычно не открывается в корпоративных сетях. Следовательно, извлечение файлов политик затрудняется, если вообще не становится невозможным. Без файла политик основывающийся на обозревателе клиент отклоняет открытие сокетного соединения с удаленным сервером. Связь между web-клиентом и удаленным сервером, следовательно, нетипично невозможна. Варианты осуществления настоящего раскрытия, тем не менее, используют ретрансляционный сервер для того, чтобы соединять web-клиент и удаленный сервер. Способность ретрансляционного сервера обмениваться данными в HTTP с клиентом предоставляет возможность выполнения обхода корпоративных брандмауэров. Например, использование HTTP в качестве транспортного механизма уменьшает проблемы при обходе корпоративных брандмауэров, поскольку порты 80/443 (HTTP 80/TCP, HTTP для всемирной паутины; HTTPS 443/TCP, HTTP-протокол по TLS/SSL) типично открыты в корпоративной сети.
[0027] В вариантах осуществления web-клиент, следовательно, может открывать HTTP-соединение с ретрансляционным сервером, который выступает в качестве ретранслятора для связи между клиентом и удаленным сервером. Web-клиент затем обменивается данными с ретрансляционным сервером с использованием HTTP-запросов. После приема HTTP-запросов ретрансляционный сервер "разворачивает" фактические данные для обмена и перенаправляет их в удаленный хост с использованием транспортного протокола, понимаемого посредством удаленного сервера. Аналогично, при приеме данных в транспортном протоколе, используемом посредством удаленного сервера, ретрансляционный сервер "сворачивает" данные в HTTP-протокол и отправляет или передает их в качестве части HTTP-ответа в web-клиент.
[0028] Поскольку HTTP является простым протоколом запроса/ответа и поддерживает несколько соединений из клиента с сервером, упорядоченная доставка сообщений не гарантируется. Дополнительно, простой характер запроса/ответа HTTP-протоколов не предоставляет встроенного механизма для обеспечения надежной доставки сообщений, и, таким образом, ответы могут быть отброшены до достижения клиента. Дополнительно, эти протоколы не предоставляют способа группировать запросы, чтобы формировать сеанс. Неспособность гарантировать надежную и упорядоченную доставку сообщений мешает успешному проведению web-конференции. Также, варианты осуществления настоящего раскрытия предоставляют возможность использования идентификатора сеанса, такого как идентификатор сеанса в стиле GUID или другой криптографически строгий идентификатор, чтобы группировать запросы, которые принадлежат идентичному ретрансляционному сеансу, как пояснено выше. Идентификатор сеанса формируется произвольно на ретрансляционном сервере с использованием криптографического генератора случайных чисел. Посредством использования криптографического генератора случайных чисел исключаются угадывание числа и атака на службы, предоставляемые посредством системы, посредством третьей стороны. Для дополнительной безопасности идентификатор сеанса также может быть подписан с использованием секрета, известного только для ретрансляционного сервера, чтобы не допускать атаки на основе угадывания. Поддержка идентификаторов сеанса тем самым повышает безопасность и организует несколько соединений, внутренне присущих в HTTP-окружении, в конкретные ретрансляционные сеансы.
[0029] Чтобы дополнительно достигать упорядоченной доставки сообщений, варианты осуществления настоящего раскрытия отслеживают восходящие и нисходящие запросы с тем, чтобы давать возможность только одного незавершенного восходящего запроса и одного незавершенного нисходящего запроса одновременно. Порядковые номера и числа подтверждения приема назначаются сообщениям запроса и ответа, чтобы отслеживать обмен данными и обнаруживать потерянные сообщения. После обнаружения потерянного сообщения или приема индикатора относительно отрицательного/ошибочного HTTP-ответа (к примеру, ответа с кодом состояния, отличным от 200 OK) HTTP-запрос, соответствующий отрицательному/ошибочному HTTP-ответу, повторно отправляется и/или пробуется предварительно определенное число раз до завершения сеанса. Такое отслеживание сообщений выполнено с возможностью достигать передачи данных без потерь и способности системы к восстановлению после сбоев.
[0030] В дополнительном варианте осуществления, чтобы расширять функциональность web-клиента в ограниченном окружении для обмена данными с пунктом назначения, необязательный компонент платформенных служб помогает предоставлять функциональности, недоступные в ограниченном окружении. Когда различные протокольные данные ретранслируются, вероятно необходимы различные платформенные службы. Такие службы являются подключаемыми в систему. В качестве примера, при туннелировании SIP-данных платформенные службы включают в себя брокер аутентификации, чтобы помогать клиенту успешно отвечать на оклики системы безопасности, инициированные из SIP-сервера. Неспособность web-клиента успешно отвечать на такой оклик возникает из отсутствия достаточных программных пакетов для безопасности в ограниченной клиентской среде. Web-клиент расширяет свою ограниченную функциональность в вариантах осуществления настоящего раскрытия посредством делегирования возможностей аутентификации брокеру аутентификации, который является частью платформенных служб для туннелирования SIP-данных, хотя его использование не ограничивается туннелированием SIP-данных. Ретрансляционный сервер, в вариантах осуществления, имеет большее число функциональностей, чем ограниченная клиентская среда, поскольку он является полнофункциональным сервером. Например, ретрансляционный сервер в вариантах осуществления имеет больше установленных программных пакетов. В вариантах осуществления, когда ретрансляционный сервер отдельно не может предоставлять требуемую функциональность, платформенные службы ретрансляционного сервера могут обращаться к другим серверным компонентам, чтобы координировать удовлетворительный результат для клиента. В варианте осуществления, например, модуль брокера аутентификации на ретрансляционном сервере используется для того, чтобы помогать клиенту в вычислении обмена аутентификационными данными с пунктом назначения. Web-клиент, следовательно, делегирует криптографические вызовы ретрансляционному серверу и использует ретрансляционный сервер в качестве инструментального средства, чтобы обрабатывать криптографические вызовы и адреса, необходимые для протокольной связи на удаленном сервере. Другие варианты осуществления расширяют функциональность web-клиента посредством делегирования компоненту платформенных служб ретрансляционного сервера, например, обработки хэш-вычислений (посредством реализации необходимого алгоритма на ретрансляционном сервере) или API-вызовов для разрешения доменных имен (для разрешения имен хостов к IP-адресам). Операции, предоставляемые в данном документе, предлагаются только в качестве примера.
[0031] Примерное логическое окружение или система 100 для поддержания web-конференции между несколькими участниками показаны на фиг.1. Участники 102 и 104 хотят провести web-конференцию друг с другом. Также, клиенты 106 и 118 контактируют с сервером 110, к примеру, SIP-сервером, например, через сети 108 и 120, соответственно, чтобы запрашивать возможность присоединяться к собранию 114 и 124, соответственно. Если запросы на инициирование сеанса понимаются и активируются, SIP-сервер 110 отправляет сообщения 116 и 122 о приеме, соответственно, в клиенты 106 и 118. Тем не менее, если соединение не осуществляется между клиентом 106 и SIP-сервером 110, например, запрос на установление сеанса 114 может быть не окончательным или вообще отклонен (не показано). Такой сценарий может существовать, например, если ограниченное окружение клиента, к примеру, web-клиента 106, не допускает открытие сокетного соединения (не показано) на сервере 110. Далее, дополнительно, клиент 106 может иметь возможность обмениваться данными только в HTTP и, следовательно, не иметь возможность обмениваться данными в протоколах, понимаемых посредством сервера 110, к примеру, через TLS или TCP. Следовательно, желательно туннелировать SIP, например, по HTTP, если клиент 106 является web-клиентом, обменивающимся данными только в HTTP или имеющим некоторую другую форму ограниченных сетевых подключений, таких как корпоративные сети, защищенные брандмауэром, сети за прокси-серверами, NAT и т.д.
[0032] Хотя фиг.1 иллюстрирует общее окружение собрания, фиг.2 иллюстрирует примерное логическое окружение или систему 200 для расширения функциональности web-клиента 202 в ограниченном окружении с помощью ретрансляционного сервера 206, чтобы предоставлять полнофункциональное взаимодействие при проведении собраний с пунктом назначения 208. Web-клиент 202 также упоминается на фиг.2 как клиент туннелирования 202. Дополнительно, web-клиент может упоминаться в вариантах осуществления как любой тип произвольной оконечной точки, к примеру, "основывающийся на обозревателе клиент" и т.д. Термин "web-клиент" предлагается только в качестве примера. Если связь web-клиента 202 выполняется на основе HTTP, клиент 202 не может подключаться к целевой оконечной точке 208, если целевая оконечная точка 208 имеет существующие протоколы связи, которые не основаны на HTTP. В варианте осуществления пункт назначения 208 является удаленным сервером, к примеру, SIP-сервером. В другом варианте осуществления пунктом назначения 208 является сервер управления совместным использованием экрана. В еще других вариантах осуществления пунктом назначения 208 является сам клиент. Далее, дополнительно, может быть использовано любое число целевых оконечных точек 208, как показано посредством эллипсов 210 и пунктов назначения 212.
[0033] Клиент 202, основывающийся на web-технологиях или туннелировании, отправляет HTTP-запрос 214 по сети 204 на ретрансляционный сервер 206. Ретрансляционный сервер 206 разворачивает данные в запросе 214 и перенаправляет развернутые данные 216 с использованием протокола, понимаемого пунктом назначения 208 по сети 218, в пункт назначения 208. В вариантах осуществления ретрансляционный сервер 206 тем самым туннелирует данные, например протокольные SIP- и RDP-данные, через HTTP. Как пояснено выше, любые произвольные двоичные данные могут быть туннелированы посредством ретрансляционного сервера 206. В таком окружение при необходимости ретрансляционный сервер 206 уже имеет загруженным на него надлежащий транспортный стек, к примеру, RTP/SRTP или TLS (не показан), чтобы предоставлять такое туннелирование.
[0034] После обработки принимаемых протокольных данных 216 пункт назначения 208 отправляет протокольные данные 220 на ретрансляционный сервер 206. Ретрансляционный сервер 206 затем сворачивает данные, принятые из пункта назначения 208 в HTTP-протоколе, и отправляет их в качестве части HTTP-ответа 222 в клиент 202. Любой тип произвольных данных может быть туннелирован в соответствии с вариантами осуществления, раскрытыми в данном документе. Например, окружение или система 200 могут давать возможность: туннелирования любых данных по HTTP в RTP/SRTP; туннелирования RDP по HTTP в RTP/SRTP; туннелирования RDP по HTTP в любом транспортном механизме (к примеру, TCP или UDP); и туннелирования SIP по HTTP, согласно вариантам осуществления.
[0035] Логическое окружение 200 не ограничивается конкретными реализациями, а вместо этого осуществляет любое вычислительное окружение, в котором может осуществляться на практике функциональность окружения, описанного в данном документе. Например, любой тип клиентского компьютера 202, понимаемый специалистами в данной области техники, может быть использован в соответствии с вариантами осуществления. Дополнительно, сети 204 и 218, хотя показаны как отдельные одни сети, могут быть любыми типами сетей, традиционно понимаемых специалистами в данной области техники. В соответствии с вариантом осуществления, сеть может быть глобальной сетью (например, Интернет или всемирная паутина, т.е. "web", если коротко). Это также может быть локальная вычислительная сеть, например сеть intranet, или глобальная вычислительная сеть. В соответствии с вариантами осуществления, связь по сетям 204 и 218 осуществляется согласно одному или более стандартным форматам с коммутацией пакетов, например, H.323, IP, Ethernet и/или ATM.
[0036] Дополнительно, любое возможное окружение или система, как должны понимать специалисты в данной области техники, может быть использована в соответствии с вариантами осуществления настоящего раскрытия. Фиг.2 предлагается в качестве примера только для целей понимания идей вариантов осуществления, раскрытых в данном документе. Например, фиг.2 показывает ретрансляционный сервер 206 и пункты назначения 208, 210 и 212. Тем не менее, варианты осуществления также охватывают любой тип сервера, отдельные серверы, фермы серверов или другой сервер обмена сообщениями. Далее, дополнительно, фиг.2 показывает клиентский компьютер 202. Тем не менее, любой тип небольшого компьютерного устройства может быть использован, как должны понимать специалисты в данной области техники, без отступления от сущности и объема вариантов осуществления, раскрытых в данном документе. Хотя показан только один клиентский компьютер 202, например, другой вариант осуществления предоставляет возможность нескольким небольшим компьютерным устройствам обмениваться данными с ретрансляционным сервером 206. В варианте осуществления каждое небольшое компьютерное устройство обменивается данными с сетью 204, или, в других вариантах осуществления, несколько и отдельные сети обмениваются данными с небольшими компьютерными устройствами. В еще одном другом варианте осуществления каждое небольшое компьютерное устройство обменивается данными с отдельной сетью. Действительно, окружение или система 200 представляет допустимый способ осуществления на практике вариантов осуществления, раскрытых в данном документе, но никоим образом не имеет намерение ограничивать объем настоящего раскрытия. Дополнительно, примерное сетевое окружение 200 может рассматриваться с точки зрения конкретных описанных компонентов, например, ретрансляционного сервера, клиентского компьютера и т.д., или, альтернативно, может рассматриваться с точки зрения аналогичных модулей, соответствующих таким блокам.
[0037] Хотя фиг.2 показывает примерное окружение или систему 200 для туннелирования протокола по HTTP, фиг.3 иллюстрирует программные функциональные модули 300 для расширения функциональности основывающегося на обозревателе клиента 302 через ретрансляционный сервер 304 согласно вариантам осуществления настоящего раскрытия. Программные функциональные модули 300 выполняются в вычислительной системе, показанной на фиг.3, в соответствии с вариантами осуществления, раскрытыми в данном документе. В варианте осуществления, показанном на фиг.3, основывающийся на обозревателе клиент 302 контактирует, к примеру, через вызов 322 на основе web-служб, с ретрансляционным сервером 304, чтобы создавать ретрансляционный сеанс. Компонент 310 управления сеансами, содержащий web-службу 312, ретрансляционного сервера 304 взаимодействует, через вызовы 315 методов, например, с ретрансляционной подсистемой 314, содержащей простой web-дескриптор 316 по HTTP-протоколу, чтобы конфигурировать запрашиваемый ретрансляционный сеанс. В вариантах осуществления компонент 310 управления сеансами предоставляет функциональность для инициирования и установления соединений между клиентом 302 и пунктом назначения, к примеру, удаленным сервером 308, посредством формирования идентификаторов сеансов и т.д., для установления соединений между объектами, участвующими в собрании, например, и для группировки запросов, которые принадлежат идентичному ретрансляционному сеансу. Согласно варианту осуществления, идентификаторы сеансов возвращаются в клиент, например, через возвращаемое значение при вызове на основе web-служб. После того как сеанс установлен, компонент 314 ретрансляционной подсистемы предоставляет возможность обмена данными между клиентом 302 и удаленным сервером 308. Ретрансляционная подсистема 314 также предоставляет в вариантах осуществления возможность назначения порядковых номеров и чисел подтверждения приема, чтобы обеспечивать надежную и упорядоченную доставку сообщений запроса и ответа.
[0038] В варианте осуществления компонент 310 управления сеансами сначала контактирует 324 с компонентом 320 платформенных служб или компонентом 320 аутентификации, чтобы осуществлять доступ к разрешению для конфигурирования ретрансляционного сеанса. (В некоторых вариантах осуществления компонент 320 платформенных служб является необязательным, как показано посредством пунктирных линий 320.) Согласно вариантам осуществления, компонент 320 платформенных служб предоставляет возможность, например, выполнения аутентификации клиента 302, а также обработки операций криптографических вызовов и операций DNS-разрешения. Эти службы предлагаются только в качестве примера. Другие и дополнительные типы служб выполняются посредством компонента 320 платформенных служб. В некоторых вариантах осуществления компонент 320 платформенных служб может активироваться непосредственно посредством основывающегося на обозревателе клиента 302. Согласно варианту осуществления, основывающийся на обозревателе клиент 302, возможно, должен быть аутентифицирован, чтобы присоединяться к собранию с удаленным сервером или пунктом назначения 308. В дополнительном варианте осуществления компонент 320 аутентификации имеет информацию или данные, к примеру, данные по оклику, которые должны передаваться в основывающийся на обозревателе клиент 302 для аутентификации перед созданием ретрансляционного сеанса с ретрансляционным сервером 304, выступающим в качестве "посредника" между основывающимся на обозревателе клиентом 302 и удаленным сервером 308. В еще одном дополнительном варианте осуществления компонент 320 аутентификации контактирует 326 с удаленным сервером 308, чтобы проверять достоверность клиента 302 для присоединения к конференции посредством представления клиентского запроса, чтобы создавать ретрансляционный сеанс с удаленным сервером 308, и/или посредством получения аутентификационной информации или данных, например, данных по оклику и уникального идентификатора в вариантах осуществления, для отправки 322 в клиент 302 для составления сообщения 322 ответа на оклик. Необязательный характер контакта между компонентом 320 аутентификации и удаленным сервером 308 показывается посредством пунктирных линий 326. Если с удаленным сервером 308 контактируют, он может верифицировать секрет, предоставляемый посредством ретрансляционного сервера 304, согласно вариантам осуществления, и если такая верификация завершается удачно, предоставлять данные по оклику (включающие в себя уникальный идентификатор согласно вариантам осуществления) в компонент 320 аутентификации (как показано посредством двунаправленного характера контакта 326). В еще одних других вариантах осуществления секрет не предоставляется на удаленный сервер 308, и удаленный сервер 308 предоставляет данные по оклику/идентификатору без верификации запроса из ретрансляционного сервера 304.
[0039] В вариантах осуществления, в которых аутентификация требуется и завершается удачно (или если аутентификация сначала не требуется, как пояснено выше), компонент 310 управления сеансами взаимодействует 315 через вызовы методов, например, с компонентом 314 ретрансляционной подсистемы, чтобы конфигурировать ретрансляционный сеанс. После успешного создания ретрансляционного сеанса компонент 310 управления сеансами назначает идентификатор сеанса клиенту 302. В варианте осуществления идентификатор сеанса, назначаемый клиенту 302, используется для того, чтобы группировать запросы, которые принадлежат идентичному сеансу. В варианте осуществления идентификатор сеанса является идентификатором сеанса в стиле GUID (или другим криптографическим строгим идентификатором). Идентификатор в стиле GUID предлагается только в качестве примера. Другие типы идентификаторов сеансов, к примеру, типы идентификаторов сеансов для того, чтобы еще дополнительно повышать безопасность, могут быть использованы согласно вариантам осуществления настоящего раскрытия. В варианте осуществления, например, один идентификатор сеанса назначается SIP-запросам, тогда как другой идентификатор сеанса назначается RDP-запросам из основывающегося на обозревателе клиента 302. Такой идентификатор сеанса отправляется 322 в основывающийся на обозревателе клиент 302 из ретрансляционного сервера 304, и клиент 302 затем использует идентификатор сеанса в качестве HTTP-заголовка, чтобы обмениваться данными 328 с ретрансляционной подсистемой 314. При приеме данных из основывающегося на обозревателе клиента 302 ретрансляционная подсистема 314 взаимодействует 330 с транспортным компонентом 318, чтобы ретранслировать данные 332 в и из удаленного сервера 308. Ретрансляционная подсистема 314 тем самым разворачивает принимаемые или передаваемые данные в HTTP-запросах и перенаправляет данные на удаленный сервер 308 в надлежащем протоколе(ах) для такой транспортировки. Ретрансляционный сервер 304 тем самым выступает в качестве "туннеля" для обмена данными по требуемому сетевому протоколу(ам). Программные функциональные модули 300 предлагаются в качестве примера возможных программных функциональных модулей для описанных вариантов осуществления. Другие варианты осуществления могут включать в себя проиллюстрированные модули, меньшее число модулей, чем проиллюстрированные модули и/или субмодули, дополнительные модули и/или субмодули, комбинации модулей и/или субмодулей, расширения проиллюстрированных модулей и/или субмодулей и т.д.
[0040] Согласно вариантам осуществления, модули, соответствующие модулям на ретрансляционном сервере 304, также существуют на основывающемся на обозревателе клиенте 302 и удаленном сервере 308, чтобы обеспечивать такую связь и транспортировку. На стороне клиента вариант осуществления содержит, например, соответствующий модуль для ретрансляционного сервера, чтобы инициировать HTTP-запрос, помещать идентификатор сеанса в качестве HTTP-заголовка в запросы, назначать порядковые номера и использовать числа подтверждения приема для восходящего потока данных, использовать порядковые номера и формировать числа подтверждения приема для нисходящего потока данных и т.д. На удаленном сервере, согласно вариантам осуществления, соответствующая часть для ретрансляционного сервера является протоколом-участником. В варианте осуществления протокол-участник является TCP-участником, например, чтобы помогать в перемещении данных между ретрансляционным сервером и удаленным сервером.
[0041] Взаимодействия различных программных функциональных модулей, показанных на фиг.3, дополнительно иллюстрируются в функциональных этапах 400, показанных на фиг.4, для туннелирования протокольных данных через HTTP в соответствии с вариантом осуществления, раскрытым в данном документе. Операция 402 начала инициируется, и процесс 400 переходит к приему контакта, к примеру, через вызов на основе web-служб, например, из основывающегося на обозревателе клиента, чтобы создавать ретрансляционный сеанс 404. До конфигурирования запрашиваемого ретрансляционного сеанса 410 процесс 400 необязательно может (как показано посредством пунктирных линий) сначала переходить к запросу 406, чтобы определять из компонента платформенных служб то, разрешено или нет клиенту (например, он аутентифицирован и/или авторизован или нет) создавать сеанс с назначением. При выполнении этого определения 406 ретрансляционный сервер, к примеру, через компонент 320 платформенных служб, необязательно может контактировать с назначением 408, к примеру, удаленным сервером 308 на фиг.3, чтобы получать данные по оклику и/или другие данные аутентификации для выполнения процедуры установления связи между клиентом и пунктом назначения, чтобы конфигурировать запрашиваемый сеанс. Хотя этапы 406 и 408 показаны как необязательные этапы, согласно описанному варианту осуществления, другие варианты осуществления требуют такого определения аутентификации на этапе 406, но не требуют контакта с удаленным сервером 408. В еще дополнительных вариантах осуществления этапы 406 и 408 являются обязательными этапами аутентификации и авторизации. Аутентификация, участвующая на этапах 406 и 408, показывает подключаемый характер платформенных служб, например, брокера аутентификации, используемого в вариантах осуществления настоящего раскрытия. Если запрос 406 определяет то, что клиент аутентифицирован и/или авторизован для установления ретрансляционного сеанса, процесс 400 переходит к ветви "Да", чтобы конфигурировать ретрансляционный сеанс 410. Если клиент не аутентифицирован и такая аутентификация требуется для продолжения согласно вариантам осуществления, раскрытым в данном документе, процесс 400 переходит к ветви "Нет", т.е. к операции 422 завершения, на которой завершается процесс 400. Если клиенту разрешено конфигурировать ретрансляционный сеанс и такой сеанс сконфигурирован 410, процесс 400 переходит к формированию и назначению идентификатора 412 и 414 сеанса, соответственно, при котором идентификатор сеанса формируется и назначается клиенту. В варианте осуществления идентификатор сеанса формируется и назначается с тем, чтобы группировать запросы, которые принадлежат идентичному ретрансляционному сеансу. В варианте осуществления такой идентификатор сеанса формируется произвольно на ретрансляционном сервере, к примеру, в компоненте управления сеансами, например, с помощью криптографического генератора случайных чисел. Как пояснено, хотя описывается идентификатор сеанса в стиле GUID, этот тип идентификатора предлагается только в качестве примера. Может быть использовано любое число типов идентификаторов, как должны понимать специалисты в данной области техники, без отступления от сущности и объема настоящего раскрытия.
[0042] Затем процесс 400 переходит к отправке идентификатора сеанса в клиент 416, при которой идентификатор сеанса, назначаемый запросам, принадлежащим конкретному ретрансляционному сеансу, отправляется в клиент. Клиент затем использует идентификатор сеанса в качестве HTTP-заголовка, чтобы осуществлять связь с ретрансляционным сервером для дополнительного обмена данными, при котором ретрансляционный сервер принимает HTTP-запрос с идентификатором 418 сеанса. Затем происходит обмен данными с удаленным сервером 420 через ретрансляционный сервер, и процесс 400 завершается на операции 422 завершения. Фиг.4 является примером возможных функциональных характеристик для туннелирования протокола по HTTP с помощью ретрансляционного сервера в соответствии с вариантами осуществления, раскрытыми в данном документе. Проиллюстрированные функциональные этапы могут быть комбинированы в другие этапы и/или перекомпонованы. Дополнительно, может быть использовано, например, меньшее число этапов или дополнительные этапы.
[0043] Фиг.5 далее иллюстрирует подключаемый характер системы согласно вариантам осуществления настоящего раскрытия. Например, как пояснено выше, компоненты платформенных служб являются подключаемыми, чтобы предоставлять службы для клиента в ограниченном окружении. Брокер аутентификации, например, в качестве части компонента платформенных служб согласно вариантам осуществления, помогает клиенту при SIP-аутентификации. Дополнительно, транспортировка является подключаемой. Подключаемый характер транспортировки обеспечивает туннелирование произвольных данных, поскольку может быть использован любой надлежащий протокол(ы) для данных, туннелирование которых требуется. Например, SIP-туннелирование использует TLS в качестве транспортировки в вариантах осуществления, тогда как RDP-туннелирование использует SRTP в качестве транспортировки в вариантах осуществления. Фиг.5 иллюстрирует процесс, согласно варианту осуществления, для конфигурирования, к примеру, разработчиком, ретрансляционного сервера так, что он является подключаемым по своему характеру. Процесс 500 инициируется на операции 502 начала и переходит к запросу 504, чтобы определять то, требуется или нет конфигурировать ретрансляционный сервер так, что он туннелирует данные. Если "Нет", процесс 500 переходит к операции 528 завершения, и процесс 500 завершается. Если "Да", процесс 500 переходит к ветви "Да", т.е. к операции 506 определения, на которой определяется то, следует или нет туннелировать SIP-данные. Если "Да", процесс 500 переходит к добавлению 508 подключаемого транспортного TLS/SSL-модуля, при котором TLS/SSL используется в качестве транспортировки при SIP-туннелировании в варианте осуществления. В другом варианте осуществления другой тип протокола используется для транспортировки для SIP-туннелирования. Затем, процесс 500 переходит к запросу 510 для определения того, должны или нет добавляться какие-либо другие подключаемые модули. Если дополнительные подключаемые модули не требуются, процесс 500 переходит к ветви "Нет", т.е. к операции 534 завершения, и процесс 500 завершается. Если другие подключаемые модули требуются, процесс 500 переходит, например, к ветви "Да", чтобы добавлять подключаемый модуль 512 брокера аутентификации. Брокер аутентификации, в вариантах осуществления, является набором платформенных служб, которые помогают клиенту в выполнении SIP-аутентификации. После добавления подключаемого модуля 512 брокера аутентификации процесс 500 переходит к запросу 514 для определения того, требуются или нет какие-либо другие подключаемые модули. Если "Да", подключаемый модуль добавляется 516, и этапы 514-516 повторяются до тех пор, пока другие подключаемые модули больше не требуются. Если другие подключаемые модули не требуются, процесс 500 переходит к ветви "Нет", т.е. к операции 534 завершения, и завершается.
[0044] Возвращаясь к запросу 506, если SIP-туннелирование не требуется, процесс 500 переходит к ветви "Нет", т.е. к запросу 518 для определения того, требуется или нет туннелировать RDP-данные. Если требуется туннелирование RDP-данных, процесс 500 переходит к ветви "Да", чтобы добавлять подключаемый модуль для транспортного RTP/SRTP-модуля 520, при этом RDP-туннелирование использует RTP/SRTP в качестве транспортировки. Затем, определяется то, должны или нет быть добавлены какие-либо другие подключаемые модули 522. Если другие подключаемые модули не требуются, процесс 500 переходит к ветви "Нет", т.е. к операции 534 завершения, и процесс 500 завершается. Если другие подключаемые модули требуются, процесс 500 переходит к ветви "Да", чтобы добавлять подключаемый модуль 524, который переходит к запросу 522, чтобы снова определять то, требуются или нет какие-либо другие подключаемые модули, и эти этапы повторяются. Если другие подключаемые модули не требуются, процесс 500 переходит к ветви "Нет", чтобы завершать процесс 500 на операции 534 завершения.
[0045] Возвращаясь к этапу 518, если туннелирование RDP не требуется, процесс 500 переходит к ветви "Нет", т.е. к запросу 526 для определения того, требуется или нет туннелирование каких-либо произвольных данных. Если "Нет", процесс 500 завершается на операции 528 завершения. Если туннелирование произвольных данных требуется, процесс 500 переходит к ветви "Да", чтобы подключать надлежащий протокольный транспортный модуль 530, чтобы поддерживать туннелирование произвольных протокольных данных. Затем определяется то, требуются или нет какие-либо другие подключаемые модули, на операции 532. Если другие подключаемые модули требуются, процесс 500 переходит к ветви "Да", чтобы добавлять подключаемый модуль 524, и эти этапы повторяются до тех пор, пока другие подключаемые модули больше не требуются. Когда другие подключаемые модули не требуются, процесс 500 переходит к ветви "Нет", т.е. к операции 534 завершения, чтобы завершать процесс 500. Фиг.5 является примером возможных функциональных характеристик для конфигурирования, к примеру, разработчиком, ретрансляционного сервера так, что он является подключаемым по своему характеру в соответствии с вариантами осуществления, раскрытыми в данном документе. Проиллюстрированные функциональные этапы могут быть комбинированы в другие этапы и/или перекомпонованы. Дополнительно, может быть использовано, например, меньшее число этапов или дополнительные этапы.
[0046] Фиг.6 далее иллюстрирует примерные функциональные этапы 600 для назначения идентификаторов сеансов, чтобы группировать запросы, принадлежащие идентичному ретрансляционному сеансу, в соответствии с вариантом осуществления, раскрытым в данном документе. Процесс 600 инициируется на операции 602 начала и переходит к приему запроса, чтобы создавать ретрансляционный сеанс 604, при этом запрос, к примеру, SIP-запрос из основывающегося на обозревателе клиента, принимается на ретрансляционном сервере. Ретрансляционный сеанс создается на операции 606, и идентификатор сеанса формируется произвольно 608 с помощью криптографического генератора случайных чисел для назначения запроса, например SIP-запроса, группе, принадлежащей идентичному ретрансляционному сеансу. В варианте осуществления идентификатор сеанса является идентификатором сеанса в стиле GUID. Затем, процесс 600 переходит к операции 610 назначения случайного числа группе 1. Номер группы отправляется, например, в клиент 612 для "группы 1". Затем, процесс 600 переходит к приему запроса RDP-данных, например, из web-приложения 614 на основе обозревателя. Другой идентификатор сеанса затем формируется 616, например, для того, чтобы группировать запросы RDP-данных, например, в "группу 2". Идентификатор сеанса для назначения номера группы клиенту для "группы 2" отправляется в клиент 618, и процесс 600 завершается на операции 620 завершения. Фиг.6 является примером возможных функциональных характеристик для назначения идентификатора сеанса, чтобы группировать запросы, принадлежащие идентичному ретрансляционному сеансу, в соответствии с вариантами осуществления, раскрытыми в данном документе. Проиллюстрированные функциональные этапы могут быть комбинированы в другие этапы и/или перекомпонованы. Дополнительно, может быть использовано, например, меньшее число этапов или дополнительные этапы.
[0047] Дополнительно, фиг.7 иллюстрирует примерные функциональные этапы 700 для осуществления способа для назначения порядковых номеров и чисел подтверждения приема, чтобы обеспечивать надежную и упорядоченную доставку данных между клиентом, к примеру, основывающимся на web-обозревателе клиентом и ретрансляционным сервером, в соответствии с вариантами осуществления, раскрытыми в данном документе. Процесс 700 инициируется на операции 702 начала и переходит к формированию HTTP-запроса в основывающемся на обозревателе клиенте 704, при этом процесс 700 иллюстрирует перемещение восходящего потока данных из основывающегося на обозревателе клиента на удаленный сервер через ретрансляционный сервер. На операции 704 порядковый номер также назначается запросу посредством клиента. Затем HTTP-запрос с порядковым номером принимается 706 на ретрансляционном сервере. Ретрансляционный сервер использует порядковый номер 708, при этом порядковый номер передается на ретрансляционный сервер в качестве HTTP-заголовка. Ретрансляционный сервер затем формирует число подтверждения приема 710. Ретрансляционный сервер передает число подтверждения приема с HTTP-ответом обратно в клиент 712 в качестве HTTP-заголовка в HTTP-ответе и/или в качестве тела ответа согласно вариантам осуществления. На стороне клиента HTTP-ответ (если принят) согласуется с незавершенным запросом (не показан). Согласование HTTP-ответа с его запросом выполняется в клиенте посредством базовой платформы, такой как web-обозреватель согласно варианту осуществления. В этом варианте осуществления HTTP-ответ принимается в клиенте через идентичное соединение, к примеру, TCP, по которому отправлен запрос. Это согласование и отслеживание последовательности запросов/ответов и чисел подтверждения приема дает возможность, в вариантах осуществления, помощи в упорядоченной и надежной передаче данных по HTTP.
[0048] Поскольку ответные сообщения и числа подтверждения приема могут быть отброшены в ходе передачи из ретрансляционного сервера в клиент, процесс 700 предоставляет возможность определения в запросе 714 того, принимает или нет клиент подтверждение приема, соответствующее данным, отправленным в HTTP-запросе. Для восходящего потока данных, например, каждый HTTP-запрос, инициированный из клиента, переносит порядковый номер для первого байта данных, которые переносит конкретный запрос, согласно варианту осуществления, раскрытому в данном документе. Помимо этого, каждый запрос имеет показатель длины, указывающий число байтов данных, которые переносит запрос. На стороне ретрансляционного сервера число подтверждения приема, сформированное для ответного сообщения, является последним байтом, который принимает ретрансляционный сервер. Все данные с порядковыми номерами до этого числа подтверждения приема, следовательно, также подтверждаются с самым последним числом подтверждения приема. После того как клиент подтверждает, что байты приняты, он удаляет байты из своего кэша. В противном случае, если подтверждение не принимается, данные повторно доставляются согласно вариантам осуществления. Например, если порядковый номер начинается с 1 и длина запроса содержит 100 байтов, число подтверждения приема, которое ищет клиент, равняется 100. Когда второй запрос отправляется, порядковый номер начинается с 101, и если длина составляет 200, клиент ищет соответствующее число подтверждения приема 300.
[0049] Возвращаясь к фиг.7, если подтверждение приема принимается на 714 (указывая надежную доставку сообщений запроса/ответа), процесс 700 переходит к ветви "Да", т.е. к запросу 716 для определения того, требуется или нет клиенту отправлять какие-либо другие запросы на удаленный сервер через ретрансляционный сервер. Если другие запросы требуются, процесс 700 переходит к ветви "Да", чтобы формировать HTTP-запрос и назначать порядковый номер 704 следующему запросу. Если другие запросы не требуются, процесс 700 переходит к ветви "Нет", т.е. к операции 718 завершения, и процесс 700 завершается.
[0050] Когда запрос 714 определяет то, что подтверждение приема не принято или, в других вариантах осуществления, что ответ, указывающий отрицательную обработку и/или ошибочную обработку, принят, процесс 700 переходит к ветви "Нет", т.е. к запросу 720, чтобы определять то, превышено или нет предварительно определенное время ожидания. Если время ожидания, к примеру, указываемое посредством таймера в вариантах осуществления, для подтверждения приема еще не превышено, процесс 700 возвращается к запросу 714, чтобы определять то, принято уже или нет подтверждение приема, и этапы 714 и 720 повторяются. Если предварительно определенное время ожидания превышено, процесс 700 переходит к ветви "Да", т.е. к операции 722, чтобы повторять отправку запроса, и процесс 700 затем переходит снова к операции 706. После повторения этапов 706-716 процесс 700, в конечном счете, переходит к операции 718 завершения, и процесс 700 завершается. Фиг.7 является примером возможных функциональных характеристик для назначения порядковых номеров и отслеживания подтверждений приема запросов, чтобы обеспечивать упорядоченную и надежную доставку сообщений в соответствии с вариантами осуществления, раскрытыми в данном документе. Проиллюстрированные функциональные этапы могут быть комбинированы в другие этапы и/или перекомпонованы. Дополнительно, может быть использовано, например, меньшее число этапов или дополнительные этапы.
[0051] Посредством использования запросов подтверждения приема и/или чисел подтверждения приема и ожидания, чтобы отправлять второй запрос, до тех пор, пока не подтверждается прием первого запроса, процесс 700 предоставляет возможность надежной и упорядоченной доставки сообщений посредством отслеживания сообщений, чтобы не допускать потерянных данных и достигать передачи данных без потерь, со способностью системы к восстановлению после сбоев. Дополнительно, отслеживание сообщений запроса/ответа предоставляет возможность системе поддерживать упорядоченную доставку посредством только одного незавершенного восходящего запроса и одного нисходящего запроса одновременно, при этом второй запрос не может отправляться до тех пор, пока не подтверждается прием первого запроса/ответа, согласно вариантам осуществления, раскрытым в данном документе. Дополнительно, использование чисел подтверждения приема дает возможность системе отслеживать запросы, которые повторяются для отправки с новыми данными в дополнение к данным, переносящим запрос. Помимо этого, как пояснено, упорядоченная доставка сообщений является полезной в окружении конференцсвязи на основе HTTP-запросов/ответов при условии, например, что HTTP предоставляет возможность нескольких соединений одновременно. Хотя фиг.7 иллюстрирует этапы для достижения надежной и упорядоченной доставки данных между клиентом и ретрансляционным сервером и наоборот, надежная и упорядоченная доставка данных между ретрансляционным сервером и удаленным сервером обусловливаются посредством протокола, используемого между ними, согласно вариантам осуществления, раскрытым в данном документе.
[0052] Хотя фиг.7 показывает порядковые номера/числа подтверждения приема для восходящего потока данных, т.е. из клиента на удаленный сервер через ретрансляционный сервер, соответствующие этапы участвуют для нисходящего потока данных, т.е. из удаленного сервера в клиент через ретрансляционный сервер, согласно вариантам осуществления, раскрытым в данном документе. В варианте осуществления порядковый номер формируется на стороне ретрансляционного сервера и используется посредством клиента. Клиент затем формирует число подтверждения приема, которое используется на ретрансляционном сервере, согласно вариантам осуществления.
[0053] Хотя вышеприведенная фиг.3 иллюстрирует примерные программные функциональные модули 300 для расширения функциональности основывающегося на обозревателе клиента 302 через ретрансляционный сервер 304, фиг.8A иллюстрирует примерные программные функциональные модули 800 для туннелирования SIP-данных и для использования необязательных платформенных служб, подключаемых в систему, чтобы помогать в туннелировании SIP-данных, к примеру, посредством выполнения аутентификации, в соответствии с вариантами осуществления, раскрытыми в данном документе. Основывающийся на обозревателе клиент 802 контактирует, например через вызов 822 на основе web-служб, с ретрансляционным сервером 804, чтобы конфигурировать ретрансляционный сеанс. Компонент 810 управления сеансами ретрансляционного сервера 804, содержащий web-службу 812, взаимодействует через вызовы 806 методов, например, с ретрансляционной подсистемой 814, содержащей простой web-дескриптор 816 по HTTP-протоколу, чтобы конфигурировать запрашиваемый ретрансляционный сеанс. В вариантах осуществления компонент 810 управления сеансами предоставляет функциональность для инициирования и установления STP-сеанса с соединениями между клиентом 802 и пунктом назначения, к примеру, удаленным сервером 808, посредством формирования идентификаторов сеансов и т.д., для установления соединений между объектами, участвующими в собрании, например, и для группировки запросов, которые принадлежат идентичному ретрансляционному сеансу. Согласно варианту осуществления, идентификаторы сеансов возвращаются в клиент, например, через возвращаемое значение при вызове 822 на основе web-служб. После того как сеанс установлен, компонент 814 ретрансляционной подсистемы предоставляет возможность обмена данными между клиентом 802 и удаленным сервером 808. Ретрансляционная подсистема 814 также предоставляет в вариантах осуществления возможность назначения порядковых номеров и чисел подтверждения приема, чтобы обеспечивать надежную и упорядоченную доставку сообщений запроса и ответа.
[0054] В варианте осуществления с необязательным (как показано посредством пунктирных линий 820) компонентом 820 платформенных служб сначала контактируют 824, чтобы осуществлять доступ к разрешению для конфигурирования требуемого ретрансляционного сеанса. Согласно вариантам осуществления, компонент 820 платформенных служб предоставляет возможность, например, выполнения аутентификации клиента 802, а также обработки операций криптографических вызовов и операций DNS-разрешения. В дополнительном варианте осуществления брокер 821 аутентификации используется в качестве набора подключаемых платформенных служб, которые помогают клиенту в выполнении SIP-аутентификации. Брокер аутентификации, в этом варианте осуществления, имеет информацию или данные, к примеру, данные по оклику, которые должны передаваться в основывающийся на обозревателе клиент 802 для аутентификации перед созданием ретрансляционного сеанса с ретрансляционным сервером 804, выступающим в качестве "посредника" между основывающимся на обозревателе клиентом 802 и удаленным сервером 808. В еще одном дополнительном варианте осуществления компонент 826 аутентификации контактирует с удаленным сервером 808, чтобы проверять достоверность клиента 802 для присоединения к конференции, например, посредством представления клиентского запроса, чтобы создавать ретрансляционный сеанс с удаленным сервером 808, и/или посредством получения аутентификационной информации или данных, например данных по оклику и уникального идентификатора в вариантах осуществления, для отправки 822 в клиент 802 для составления сообщения 822 ответа на оклик. Необязательный характер контакта 826 между компонентом 820 аутентификации и удаленным сервером 808 показывается посредством пунктирных линий 826. Если с удаленным сервером 808 контактируют, он может верифицировать секрет, предоставляемый посредством ретрансляционного сервера 804 согласно вариантам осуществления, и если такая верификация завершается удачно, предоставлять данные по оклику (включающие в себя уникальный идентификатор согласно вариантам осуществления) в компонент 820 аутентификации (как показано посредством двунаправленного характера контакта 826). В еще одних других вариантах осуществления секрет не предоставляется на удаленный сервер 808, и удаленный сервер 808 предоставляет данные по оклику/идентификатору без верификации запроса из ретрансляционного сервера 804.
[0055] В вариантах осуществления, в которых аутентификация выполняется и завершается удачно (или если аутентификация сначала не выполняется, как пояснено выше), компонент 810 управления сеансами взаимодействует через вызовы 806 методов, например, с компонентом 814 ретрансляционной подсистемы, чтобы конфигурировать ретрансляционный сеанс. После успешного создания ретрансляционного сеанса компонент 810 управления сеансами назначает идентификатор сеанса клиенту 802. В варианте осуществления идентификатор сеанса, назначаемый клиенту 802, используется для того, чтобы группировать SIP-запросы, принадлежащие идентичному сеансу. Такой идентификатор сеанса отправляется 822 в основывающийся на обозревателе клиент 802 из ретрансляционного сервера 804, и клиент 802 затем использует идентификатор сеанса в качестве HTTP-заголовка, чтобы обмениваться данными 828 с ретрансляционной подсистемой 814. При приеме данных из основывающегося на обозревателе клиента 802 ретрансляционная подсистема 814 взаимодействует 830 с модулем 818 транспортировки SSL-потоков, чтобы ретранслировать данные 832 в и из удаленного сервера 808 с использованием, например, TLS/SSL 832. Ретрансляционная подсистема 814 тем самым разворачивает принимаемые или передаваемые данные в HTTP-запросах и перенаправляет данные на удаленный сервер 808 в TLS/SSL-протоколах для транспортировки. Ретрансляционный сервер 804 тем самым выступает в качестве "туннеля" для обмена данными по SIP. Примерные программные функциональные модули 800 предлагаются в качестве примера возможных программных функциональных модулей для описанных вариантов осуществления. Другие варианты осуществления могут включать в себя проиллюстрированные модули, меньшее число модулей, чем проиллюстрированные модули и/или субмодули, дополнительные модули и/или субмодули, комбинации модулей и/или субмодулей, расширения проиллюстрированных модулей и/или субмодулей и т.д.
[0056] Переходя к фиг.8B, примерные функциональные этапы 834 показаны для туннелирования SIP-данных с использованием модуля транспортировки SSL-потоков и подключаемого модуля аутентификации, как проиллюстрировано на фиг.8A, и в соответствии с вариантами осуществления, раскрытыми в данном документе. Процесс 834 инициируется на операции 836 начала и переходит к приему контакта, к примеру, через вызов на основе web-служб, например, в компоненте управления сеансами ретрансляционного сервера, чтобы создавать ретрансляционный сеанс 838. Компонент управления сеансами затем взаимодействует с ретрансляционной подсистемой, чтобы конфигурировать запрашиваемый ретрансляционный сеанс 844. Тем не менее, процесс 834 может сначала необязательно переходить к запросу 840, чтобы определять из компонента платформенных служб то, разрешено или нет клиенту (например, он аутентифицирован и/или авторизован или нет) создавать сеанс. При выполнении этого определения 840 ретрансляционный сервер, к примеру, через компонент 820 платформенных служб и/или брокер 821 аутентификации необязательно может контактировать 842 с удаленными серверами 808, чтобы получать данные по оклику и/или данные аутентификации для выполнения процедуры установления связи между клиентом 802 и удаленным сервером 808 (как показано посредством необязательного двунаправленного характера стрелки между этапами 840 и 842). В других вариантах осуществления брокер 821 аутентификации предоставляет данные по оклику и/или данные аутентификации для выполнения процедуры установления связи. Если клиент 802 не аутентифицирован и/или авторизован, чтобы создавать ретрансляционный сеанс, процесс 834 переходит к ветви "Нет", т.е. к операции 856 завершения, и процесс 834 завершается. Если аутентификация и/или авторизация требуется и выполнена успешно, процесс 834 переходит к ветви "Да", чтобы конфигурировать операцию 844 ретрансляционного сеанса, на которой ретрансляционный сеанс конфигурируется 844. Идентификатор сеанса формируется 846 и назначается 848 клиенту в компоненте управления сеансами, и отправляется в клиент 850. Ретрансляционная подсистема затем взаимодействует с транспортным модулем для SIP-туннелирования, например модулем SSL-потоков, чтобы ретранслировать данные в и из удаленного сервера 852. Модуль транспортировки SSL-потоков затем осуществляет связь с удаленным сервером, чтобы обмениваться данными 854, и процесс 834 завершается на операции 856 завершения. Фиг.8B является примером возможных функциональных характеристик для туннелирования SIP по HTTP с использованием ретрансляционного сервера между клиентом и удаленным сервером в соответствии с вариантами осуществления, раскрытыми в данном документе. Проиллюстрированные функциональные этапы могут быть комбинированы в другие этапы и/или перекомпонованы. Дополнительно, может быть использовано, например, меньшее число этапов или дополнительные этапы.
[0057] Затем фиг.9 иллюстрирует примерные функциональные этапы 900, показывающие то, как необязательные платформенные службы подключаются в общую систему, чтобы помогать в туннелировании конкретного протокола, например, SIP-данных. Например, фиг.9 показывает использование подключаемого модуля аутентификации для помощи клиенту, например оконечной HTTP-точке, в выполнении обмена аутентификационными данными с пунктом назначения, например удаленным сервером, в соответствии с вариантами осуществления, раскрытыми в данном документе. Процесс 900 тем самым показывает делегирование аутентификации ретрансляционному серверу посредством основывающегося на обозревателе клиента. Процесс 900 инициируется на операции 902 начала и переходит к приему данных по оклику из web-приложения 904 на основе обозревателя. Ретрансляционный сервер затем выполняет аутентификацию 906 с использованием данных по оклику, принимаемых из основывающегося на обозревателе клиента, чтобы формировать ответ на оклик для отправки ответа на оклик в клиент 908. В варианте осуществления ретрансляционный сервер контактирует с удаленным сервером в выполнении аутентификации 906, и в другом варианте осуществления ретрансляционный сервер выполняет саму аутентификацию для формирования ответа на оклик для основывающегося на обозревателе клиента. После приема ответа на оклик приложение на основе обозревателя компонует возвращаемый ответ на оклик в новое сообщение с запросом, к примеру, новое сообщение SIP для инициирования сеанса с ретрансляционным сервером и удаленным сервером. Ретрансляционный сервер затем принимает новый запрос со скомпонованным ответом 910 на оклик и отправляет новый запрос на удаленный сервер 912, например, для инициирования сеанса. После определения того, что клиент является допустимым участником (не показан), удаленный сервер отправляет на ретрансляционный сервер подтверждение, которое принимается посредством ретрансляционного сервера 914. Ретрансляционный сервер затем уведомляет web-приложение на основе обозревателя относительно подтверждения и инициирования сеанса 916. Данные для обмена затем принимаются из web-приложения на основе обозревателя на ретрансляционном сервере 918, и процесс 900 завершается на операции 920 завершения. Фиг.9 является примером возможных функциональных характеристик для аутентификации процедуры установления связи между web-приложением на основе обозревателя и пунктом назначения посредством делегирования аутентификации ретрансляционному серверу в соответствии с вариантами осуществления, раскрытыми в данном документе. Проиллюстрированные функциональные этапы могут быть комбинированы в другие этапы и/или перекомпонованы. Дополнительно, может быть использовано, например, меньшее число этапов или дополнительные этапы.
[0058] Затем фиг.10 иллюстрирует примерные программные функциональные модули 1000 для подключения транспортного стека, такого как мультимедийный стек, в общую систему, чтобы помогать в туннелировании RDP-данных по RTP/SRTP в соответствии с вариантом осуществления настоящего раскрытия. Основывающийся на обозревателе клиент 1002 контактирует, например через вызов 1018 на основе web-служб, с компонентом 1008 конфигурирования ретрансляционного сервера 1004, чтобы конфигурировать SRTP-канал. В вариантах осуществления компонент 1008 конфигурирования содержит web-службу 1010 и взаимодействует через вызовы 1026 методов, например, с ретрансляционной подсистемой 1012 для конфигурирования канала. Затем, компонент 1008 конфигурирования конфигурирует 1020 мультимедийный стек 1016, загружаемый на ретрансляционный сервер 1004.
[0059] Мультимедийный стек 1016, из других модулей, предоставляет возможность ретрансляционному серверу 1004 расширять функциональность основывающегося на обозревателе клиента 1002. Согласно вариантам осуществления, мультимедийный стек загружается на ретрансляционный сервер, чтобы разрешать туннелирование определенных протоколов. Например, в сценарии RDP-ретрансляции, чтобы переносить RDP-данные через RTP/SRTP, сведения по RTP/SRTP и интерактивному установлению подключений (ICE) также используются в вариантах осуществления. ICE, например, используется для того, чтобы предоставлять возможность RTP/SRTP-трафику обходить брандмауэры. Ретрансляционный сервер тем самым загружает мультимедийный стек, поддерживающий RTP/SRTP/ICE, поскольку RDP-данные типично переносятся на сервер управления совместным использованием экрана через RTP/SRTP. В варианте осуществления, заключающем в себе RDP-ретрансляцию и установление соединения с сервером управления совместным использованием экрана, web-клиент обменивается данными в SIP с сервером управления совместным использованием экрана, чтобы устанавливать RTP/SRTP/ICE-соединение между ретрансляционным сервером и сервером управления совместным использованием экрана. Загрузка мультимедийного стека для RTP/SRTP/ICE на ретрансляционном сервере упрощает этот процесс. Клиент затем может обмениваться данными в SIP с сервером управления совместным использованием экрана, поскольку часть тела SIP-сообщений, а именно, часть протокола описания сеанса (SDP), извлекается из ретрансляционного сервера через вызовы на основе web-служб. Аналогично, SDP SIP-запросов из сервера управления совместным использованием экрана передается на ретрансляционный сервер через вызовы на основе web-служб. Загрузка мультимедийного стека на ретрансляционный сервер, следовательно, обеспечивает транспортировку RDP-данных в окружениях, в иных случаях не имеющих такой транспортировки. Например, мультимедийный стек RTP/SRTP и ICE типично не доступен на платформе Mac. На платформе Mac, например, разработчики либо переносят мультимедийный стек в собственный Mac, либо разрабатывают его в web-клиенте. Тем не менее, такие решения являются сложными, и ограничивающая функциональность по-прежнему существует для такого перенесения и/или разработки.
[0060] Возвращаясь к фиг.10, как пояснено выше, чтобы переносить RDP-данные через RTP/SRTP, сведения по RTP/SRTP и ICE используются в вариантах осуществления. В варианте осуществления такая конфигурация заключает в себе связь с удаленной оконечной SIP/RTP-точкой 1006 для проверки возможностей подключения, чтобы определять то, может или нет осуществляться соединение. В другом варианте осуществления проверка возможностей подключения не проводится. После конфигурирования SRTP-канала и мультимедийного стека клиент 1002 отправляет/принимает RDP-данные через HTTP 1022 в ретрансляционную подсистему 1012, содержащую простой web-дескриптор 1014 по HTTP-протоколу для конфигурирования ретрансляционного сеанса. Ретрансляционная подсистема 1012 затем обменивается данными 1024 с мультимедийным стеком 1016, чтобы получать RDP-данные посредством обмена связанными с RTP сообщениями 1028 между мультимедийным стеком 1016 и удаленной оконечной RTP-точкой 1006. Программные функциональные модули 1000 предлагаются в качестве примера возможных программных функциональных модулей для описанных вариантов осуществления. Другие варианты осуществления могут включать в себя проиллюстрированные модули, меньшее число модулей, чем проиллюстрированные модули и/или субмодули, дополнительные модули и/или субмодули, комбинации модулей и/или субмодулей, расширения проиллюстрированных модулей и/или субмодулей и т.д.
[0061] Хотя фиг.10 иллюстрирует примерные программные функциональные модули для подключения транспортного стека, к примеру, мультимедийного стека в общую систему, чтобы помогать в туннелировании RDP-данных по RTP/SRTP, фиг.11 иллюстрирует примерные функциональные этапы 1100 для туннелирования RDP-данных по RTP/SRTP с использованием подключаемого транспортного стека в соответствии с вариантом осуществления настоящего раскрытия. Процесс 1100 инициируется на операции 1102 начала и переходит к операции 1104, на которой с ретрансляционным сервером между клиентом и удаленной оконечной RTP-точкой контактируют, к примеру, через вызов на основе web-служб, например, чтобы конфигурировать SRTP-канал для туннелирования RDP-данных. Затем компонент конфигурирования конфигурирует подключаемый мультимедийный стек 1106 и, таким образом, необязательно (как показано посредством пунктирных линий) осуществляет связь с удаленной оконечной RTP-точкой для проверки возможностей подключения 1107. Оконечная RTP-точка отвечает информацией, как показано посредством двунаправленного характера стрелки между 1106 и 1107. Клиент затем отправляет/принимает RDP-данные через HTTP в и из ретрансляционной подсистемы 1108. Ретрансляционная подсистема, в свою очередь, обменивается данными с мультимедийным стеком, чтобы получать RDP-данные 1110. Чтобы получать RDP-данные, мультимедийный стек обменивается RTP-сообщениями с удаленной оконечной RTP-точкой 1112. Процесс 1100 завершается на операции 1114 завершения. Фиг.11 является примером возможных функциональных характеристик для туннелирования RDP-данных по RTP/SRTP с использованием подключаемого транспортного стека в соответствии с вариантами осуществления, раскрытыми в данном документе. Проиллюстрированные функциональные этапы могут быть комбинированы в другие этапы и/или перекомпонованы. Дополнительно, может быть использовано, например, меньшее число этапов или дополнительные этапы.
[0062] В завершение фиг.12 иллюстрирует примерную вычислительную систему 1200, в которой могут быть реализованы варианты осуществления, раскрытые в данном документе. Компьютерная система 1200, к примеру, клиентский компьютер 202, ретрансляционный сервер 206 или удаленный сервер 208, которая имеет, по меньшей мере, один процессор 1202 для обмена данными сообщения, как показано на фиг.2, проиллюстрирована в соответствии с вариантами осуществления, раскрытыми в данном документе. Система 1200 имеет запоминающее устройство 1204, содержащее, например, системное запоминающее устройство, энергозависимое запоминающее устройство и энергонезависимое запоминающее устройство. В своей самой базовой конфигурации вычислительная система 1200 проиллюстрирована на фиг.12 посредством пунктирной линии 1206. Дополнительно, система 1200 также может включать в себя дополнительные устройства хранения данных (съемные и/или стационарные), включающие в себя, но не только, магнитные или оптические диски или ленту. Такое дополнительное устройство хранение данных проиллюстрировано на фиг.12 посредством съемного устройства 1208 хранения данных и стационарного устройства 1210 хранения данных.
[0063] Термин "машиночитаемые носители" при использовании в данном документе может включать в себя компьютерные носители данных. Компьютерные носители данных могут включать в себя энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные любым способом или технологией для хранения информации, такой как машиночитаемые инструкции, структуры данных, программные модули или другие данные. Системное запоминающее устройство 1204, съемное устройство 1208 хранения данных и стационарное устройство 1210 хранения данных являются примерами компьютерных носителей данных (т.е. запоминающего устройства). Компьютерные носители данных могут включать в себя, но не только, RAM, ROM, электрически стираемое постоянное запоминающее устройство (EEPROM), флэш-память или другую технологию запоминающих устройств, CD-ROM, универсальные цифровые диски (DVD) или другое оптическое устройство хранения, магнитные кассеты, магнитную ленту, устройство хранения на магнитных дисках или другие магнитные устройства хранения, либо любой другой носитель, который может быть использован для того, чтобы сохранять информацию, и к которому может осуществляться доступ посредством вычислительного устройства 1200. Любые такие компьютерные носители данных могут быть частью устройства 1200. Иллюстрация на фиг.12 никоим образом не имеет намерение ограничивать объем настоящего раскрытия.
[0064] Термин "машиночитаемые носители" при использовании в данном документе также может включать в себя среды связи. Среды связи могут быть осуществлены посредством машиночитаемых инструкций, структур данных, программных модулей или других данных в модулированном сигнале данных, таком как несущая или другой транспортный механизм, и включают в себя любые среды для доставки информации. Термин "модулированный сигнал данных" может описывать сигнал, который имеет одну или более характеристик, заданных или измененных таким образом, чтобы кодировать информацию в сигнале. В качестве примера, а не ограничения, среды связи могут включать в себя проводные среды, такие как проводная сеть или проводное соединение, и беспроводные среды, такие как акустические, радиочастотные (RF), инфракрасные и другие беспроводные среды.
[0065] Система 1200 также может содержать соединение(я) 1216 связи, которое дает возможность устройству обмениваться данными с другими устройствами. Дополнительно, чтобы вводить содержимое в поля пользовательского интерфейса (UI) на клиентском компьютере 202, например, в соответствии с соответствующим UI-модулем (не показан) на клиентском компьютере 202, например, в соответствии с вариантом осуществления настоящего раскрытия, система 1200 может иметь устройство(а) 1214 ввода, такое как клавиатура, мышь, перо, устройство речевого ввода, устройство сенсорного ввода и т.д. Также может быть включено устройство(а) 1212 вывода, такое как дисплей, динамики, принтер и т.д. Все эти устройства хорошо известны в данной области техники и не обязательно должны подробно описываться в данном документе. Вышеуказанные устройства являются примерами, и могут использоваться другие устройства.
[0066] После вышеприведенного описания описанных вариантов осуществления настоящего раскрытия в отношении чертежей следует принимать во внимание, что в варианты осуществления может вноситься множество модификаций, которые очевидны для специалистов в данной области техники и которые попадают в пределы объема и сущности настоящего раскрытия, как определено в прилагаемой формуле изобретения. Фактически, хотя варианты осуществления описаны для целей этого раскрытия, могут выполняться различные изменения и модификации, которые естественным образом вписываются в объем настоящего раскрытия.
[0067] Аналогично, хотя это раскрытие использует язык, характерный для структурных признаков, технологических этапов и машиночитаемых носителей, содержащих такие этапы, следует понимать, что объем изобретения, определяемый прилагаемой формулой изобретения, не обязательно ограничивается конкретной структурой, этапами, признаками или носителями, описанным в данном документе. Наоборот, конкретные структуры, признаки, этапы и/или носители, описанные выше, раскрываются в качестве примерных форм реализации формулы изобретения. Аспекты вариантов осуществления предоставляют возможность нескольких клиентских компьютеров, нескольких удаленных серверов, нескольких ретрансляционных серверов и нескольких сетей и т.д. Альтернативно, в других вариантах осуществления используется один клиентский компьютер с одним удаленным сервером, одним ретрансляционным сервером и одной сетью. Специалисты в данной области техники должны признавать другие варианты осуществления или улучшения, которые находятся в пределах объема и сущности настоящего раскрытия. Следовательно, конкретная структура, этапы или носители раскрываются в качестве примерных вариантов осуществления для реализации настоящего раскрытия. Раскрытие сущности задается посредством прилагаемой формулы изобретения.
Изобретение относится к системам связи. Технический результат заключается в повышении скорости передачи данных внутри сетей связи. Способ содержит этапы, на которых: принимают передачу на ретрансляционном сервере от клиента, чтобы создать ретрансляционный сеанс с удаленной оконечной точкой; аутентифицируют клиент, при этом при аутентификации клиента отправляют данные ответа на проверочное обращение в клиент; конфигурируют ретрансляционный сеанс; формируют идентификатор сеанса для ретрансляционного сеанса; отправляют идентификатор сеанса в клиент; и передают HTTP-запросы и ответы в клиент, чтобы обмениваться данными с удаленной оконечной точкой, причем HTTP-запросы содержат идентификатор сеанса, при этом HTTP-ответы содержат отрицательные HTTP-ответы, причем отрицательные HTTP-ответы обрабатываются для повторения HTTP-запросов и обеспечения передачи данных без потерь по HTTP. 3 н. и 17 з.п. ф-лы, 13 ил.
1. Машинореализуемый способ расширения функциональности клиента посредством туннелирования протокольных данных по протоколу передачи гипертекста (HTTP) через ретрансляционный сервер, при этом способ содержит этапы, на которых:
принимают передачу на ретрансляционном сервере от клиента, чтобы создать ретрансляционный сеанс с удаленной оконечной точкой;
аутентифицируют клиент, при этом при аутентификации клиента отправляют данные ответа на проверочное обращение в клиент;
конфигурируют ретрансляционный сеанс;
формируют идентификатор сеанса для ретрансляционного сеанса;
отправляют идентификатор сеанса в клиент; и
передают HTTP-запросы и ответы в клиент, чтобы обмениваться данными с удаленной оконечной точкой, причем HTTP-запросы содержат идентификатор сеанса, при этом HTTP-ответы содержат отрицательные HTTP-ответы, причем отрицательные HTTP-ответы обрабатываются для повторения HTTP-запросов и обеспечения передачи данных без потерь по HTTP.
2. Способ по п. 1, в котором идентификатор сеанса используется, чтобы группировать запросы, принадлежащие одному и тому же ретрансляционному сеансу.
3. Способ по п. 2, в котором идентификатор сеанса формируется посредством криптографического генератора случайных чисел.
4. Способ по п. 1, в котором порядковые номера и числа подтверждения приема назначаются HTTP-запросам и ответам, принадлежащим одному и тому же сеансу.
5. Способ по п. 1, в котором начальные запросы и ответы инициируют ретрансляционный сеанс, при этом последующие HTTP-запросы передают данные по протоколу инициирования сеанса (SIP) через HTTP в удаленную оконечную точку через ретрансляционный сервер.
6. Способ по п. 5, в котором SIP-данные передаются через HTTP по механизму транспорта, при этом механизм транспорта содержит одно из группы, состоящей из следующего: протокол управления передачей (TCP), протокол пользовательских дейтаграмм (UDP) и протокол защиты транспортного уровня (TLS).
7. Способ по п. 1, в котором начальные запросы и ответы инициируют ретрансляционный сеанс, при этом последующие HTTP-запросы передают данные по протоколу удаленного рабочего стола (RDP) через HTTP в удаленную оконечную точку через ретрансляционный сервер.
8. Способ по п. 7, в котором RDP-данные передаются через HTTP по механизму транспорта, при этом механизм транспорта содержит одно из группы, состоящей из следующего: транспортный протокол реального времени (RTP) / защищенный транспортный протокол реального времени (SRTP), TLS, UDP и TCP.
9. Компьютерный носитель данных, на котором сохранены машиноисполняемые инструкции, которыми при их исполнении процессором осуществляется способ расширения функциональности клиента посредством туннелирования протокольных данных по протоколу передачи гипертекста (HTTP) через ретрансляционный сервер, при этом способ содержит этапы, на которых:
принимают передачу на ретрансляционном сервере от клиента,чтобы создать ретрансляционный сеанс с удаленной оконечной точкой;
аутентифицируют клиент, при этом при аутентификации клиента отправляют данные ответа на проверочное обращение в клиент;
конфигурируют ретрансляционный сеанс;
формируют идентификатор сеанса для ретрансляционного сеанса;
назначают идентификатор сеанса клиенту;
передают HTTP-запросы, чтобы обмениваться данными с удаленной оконечной точкой, при этом HTTP-запросы содержат идентификатор сеанса и порядковый номер, причем порядковый номер принимается ретрансляционным сервером в качестве HTTP-заголовка;
передают HTTP-запросы и ответы в клиент, причем HTTP-запросы в клиент содержат идентификатор сеанса, при этом HTTP-ответы содержат отрицательные HTTP-ответы, причем отрицательные HTTP-ответы обрабатываются для повторения HTTP-запросов и обеспечения передачи данных без потерь по HTTP;
используют, посредством ретрансляционного сервера, порядковый номер;
формируют число подтверждения приема; и
передают число подтверждения приема с HTTP-ответом в клиент.
10. Компьютерный носитель данных по п. 9, в котором способ дополнительно содержит этап, на котором используют идентификатор сеанса для группирования запросов, принадлежащих одному и тому же ретрансляционному сеансу, при этом группа запросов содержит RDP-запросы.
11. Компьютерный носитель данных по п. 9, при этом идентификатором сеанса является GUID.
12. Компьютерный носитель данных по п. 9, при этом аутентификация выполняется с помощью брокера аутентификации на ретрансляционном сервере.
13. Компьютерный носитель данных по п. 9, при этом протокольные данные, туннелируемые по HTTP, содержат произвольные протокольные данные.
14. Компьютерный носитель данных по п. 9, при этом протокольные данные содержат одно или более из группы, состоящей из данных по протоколу удаленного рабочего стола (RDP) и данных по протоколу инициирования сеанса (SIP).
15. Компьютерный носитель данных по п. 14, в котором способ дополнительно содержит этапы, на которых:
туннелируют данные RDP с использованием первого механизма транспорта; и
туннелируют данные SIP с использованием второго механизма транспорта, причем первый механизм транспорта представляет собой защищенный транспортный протокол реального времени (SRTP), а второй механизм транспорта представляет собой протокол защиты транспортного уровня (TLS).
16. Компьютерная система, выполненная с возможностью туннелировать протокольные данные по протоколу передачи гипертекста (HTTP) через ретрансляционный сервер между клиентом и удаленной оконечной точкой, при этом система содержит:
процессор; и
запоминающее устройство, соединенное с процессором, причем запоминающее устройство содержит компьютерные программные инструкции, исполняемые процессором для реализации:
компонента управления сеансами на ретрансляционном сервере, при этом компонент управления сеансами формирует идентификатор сеанса, чтобы группировать HTTP-запросы, и возвращает идентификатор сеанса в клиент;
компонента ретрансляционной подсистемы на ретрансляционном сервере, причем компонент ретрансляционной подсистемы назначает один или более порядковых номеров и одно или более чисел подтверждения приема HTTP-запросам и ответам, при этом HTTP-ответы содержат отрицательные HTTP-ответы, причем отрицательные HTTP-ответы обрабатываются для повторения HTTP-запросов и обеспечения передачи данных без потерь по HTTP;
компонента платформенных служб на ретрансляционном сервере, при этом компонент платформенных служб предоставляет возможность аутентификации клиента, чтобы расширять функциональность клиента; и
подключаемого транспортного модуля на ретрансляционном сервере, при этом подключаемый транспортный модуль поддерживает туннелирование протокольных данных.
17. Компьютерная система по п. 16, в которой данные, туннелируемые по HTTP через ретрансляционный сервер, содержат одно или более из группы, состоящей из данных RDP и данных SIP.
18. Компьютерная система по п. 17, в которой упомянутые данные представляют собой данные SIP, при этом подключаемый транспортный модуль содержит одно или более из группы, состоящей из TLS/SSL, TCP и UDP.
19. Компьютерная система по п. 17, в которой произвольные двоичные данные туннелируются по HTTP с использованием механизма транспорта, причем механизм транспорта представляет собой одно из группы, состоящей из транспортного протокола реального времени (RTP)/защищенного транспортного протокола реального времени (SRTP), TCP, UDP и TLS.
20. Компьютерная система по п. 16, в которой упомянутые протокольные данные представляют собой данные RDP, при этом подключаемый транспортный модуль содержит одно или более из группы, состоящей из RTP/SRTP, TCP, UDP и TLS.
| Станок для изготовления деревянных ниточных катушек из цилиндрических, снабженных осевым отверстием, заготовок | 1923 |
|
SU2008A1 |
| Приспособление для точного наложения листов бумаги при снятии оттисков | 1922 |
|
SU6A1 |
| Пресс для выдавливания из деревянных дисков заготовок для ниточных катушек | 1923 |
|
SU2007A1 |
| Способ и приспособление для нагревания хлебопекарных камер | 1923 |
|
SU2003A1 |
