Способ и система для управления трафиком

Изобретение относится к технологиям сетевой связи. Технический результат заключается в повышении скорости передачи данных. Способ содержит: прием шлюзом запроса на вызов интерфейса внутреннего приложения платформы разработки приложений от клиентского приложения; получение шлюзом правил по управлению трафиком клиентского приложения или интерфейса внутреннего приложения; и обнаружение шлюзом, удовлетворяются ли правила по управлению трафиком клиентским приложением или интерфейсом внутреннего приложения; если да, то признание запроса на вызов от клиентского приложения; в противном случае отклонение запроса на вызов от клиентского приложения. 2 н. и 12 з.п. ф-лы, 3 ил.

 

ОБЛАСТЬ ТЕХНИКИ

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

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

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

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

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

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

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

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

Способ для управления трафиком содержит:

прием шлюзом запроса на вызов интерфейса внутреннего приложения платформы разработки приложений от клиентского приложения;

получение шлюзом правил по управлению трафиком клиентского приложения или интерфейса внутреннего приложения;

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

Система для управления трафиком, включающая в себя шлюз и модули, расположенные в шлюзе, содержит:

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

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

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

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

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

ФИГ. 1 - блок-схема последовательности этапов в способе управления трафиком согласно настоящему изобретению;

ФИГ. 2 - блок-схема модулей системы для управления трафиком согласно настоящему изобретению; и

ФИГ. 3 - блок-схема одного варианта осуществления системы для управления трафиком согласно настоящему изобретению.

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

Подробное описание приводится ниже в связи с прилагаемыми чертежами и конкретными вариантами осуществления.

Как показано на фиг. 1, блок-схема последовательности этапов в способе управления трафиком согласно настоящему изобретению содержит:

этап S101 - прием шлюзом запроса на вызов интерфейса внутреннего приложения платформы разработки приложений от клиентского приложения;

этап S102 - получение шлюзом правил по управлению трафиком клиентского приложения или интерфейса внутреннего приложения;

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

Шлюз является интерфейсом, используемым для сообщения с клиентом, и запросы от клиентов принимаются через шлюз. Когда клиентскому приложению нужно обратиться к интерфейсу приложения, шлюз выполняет этап S 102 для получения соответствующих правил по управлению трафиком, причем решение по выбору правил для управления трафиком клиентского приложения или правил по управлению трафиком интерфейса внутреннего приложения, или же правил по управлению трафиком как клиентского приложения, так и интерфейса внутреннего приложения принимается шлюзом согласно профилю. На этапе S102 шлюз получает правила по управлению трафиком клиентского приложения или интерфейса внутреннего приложения, и этот этап содержит три следующих случая:

случай I: получение правил по управлению трафиком клиентского приложения;

случай II: получение правил по управлению трафиком интерфейса внутреннего приложения;

случай III: получение правил по управлению трафиком клиентского приложения и интерфейса внутреннего приложения.

В одном из вариантов осуществления правила по управлению трафиком являются следующими:

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

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

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

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

Например, для клиентского приложения A, вызывающего интерфейс B приложения, могут быть выбраны следующие правила по управлению трафиком:

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

При этом ограничиваются только вызовы от клиентского приложения, но интерфейс приложения не ограничивается.

Альтернативно правила по управлению трафиком могут быть выбраны следующими:

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

При этом ограничиваются только вызовы интерфейса приложения, но клиентское приложение не ограничивается.

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

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

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

Что касается периода времени для подсчета вызовов заданного приложения, то период времени для подсчета вызовов заданного интерфейса приложения и период времени для подсчета вызовов интерфейса внутреннего приложения от заданного клиентского приложения могут быть одним и тем же или разными, и период времени может выбираться в соответствии с практическим требованием, таким как один день, один час или одна минута.

Один из вариантов осуществления дополнительно содержит:

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

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

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

Один из вариантов осуществления дополнительно содержит:

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

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

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

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

Один из вариантов осуществления дополнительно содержит:

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

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

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

В одном из вариантов осуществления,

когда запрос на вызов клиентского приложения признается шлюзом, число совершения вызовов клиентским приложением возрастает и число вызовов интерфейса внутреннего приложения возрастает, число раз, когда клиентское приложение вызывает интерфейс внутреннего приложения, возрастает, и эти увеличенные числа раз посылаются в счетчик кластеров, который связан со шлюзом;

когда шлюз обнаруживает, удовлетворяет ли клиентское приложение или интерфейс внутреннего приложения правилам по управлению трафиком, получение от счетчика кластеров:

числа раз, когда клиентское приложение совершает вызов в течение периода времени, для подсчета вызовов заданного приложения;

числа раз, когда вызывается интерфейс внутреннего приложения в течение периода времени, для подсчета вызовов заданного интерфейса приложения; или

числа раз, когда клиентское приложение вызывает интерфейс внутреннего приложения в течение периода времени, для подсчета вызовов интерфейса внутреннего приложения от заданного клиентского приложения.

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

Один из вариантов осуществления дополнительно содержит:

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

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

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

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

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

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

модуль 2110 для приема запроса на вызов, выполненный с возможностью приема запроса на вызов интерфейса внутреннего приложения платформы разработки приложений от клиентского приложения;

модуль 2102 для получения правил по управлению трафиком, выполненный с возможностью получения правил по управлению трафиком клиентского приложения или интерфейса внутреннего приложения;

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

В одном из вариантов осуществления правила по управлению трафиком являются следующими:

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

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

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

Один из вариантов осуществления дополнительно содержит систему 22 контролируемого анализа, которая связана со шлюзом, и

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

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

Один из вариантов осуществления дополнительно содержит систему 22 контролируемого анализа, которая связана со шлюзом, и

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

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

модуль 2105 для приема подтверждения запроса на увеличение верхнего порогового значения для вызова приложения, расположенный в шлюзе 21 и выполненный с возможностью передачи принятого подтверждения запроса на увеличение верхнего порогового значения для вызова приложения в систему контролируемого анализа.

Один из вариантов осуществления дополнительно содержит систему 22 контролируемого анализа, которая связана со шлюзом, и

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

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

модуль 2107 для приема подтверждения запроса на увеличение верхнего порогового значения для совместного вызова, расположенный в шлюзе 21 и выполненный с возможностью передачи принятого подтверждения запроса на увеличение верхнего порогового значения для совместного вызова в систему контролируемого анализа.

Один из вариантов осуществления дополнительно содержит:

модуль 2108 для посылки числа совершения вызовов, расположенный в шлюзе 21 и выполненный с возможностью того, что когда запрос на вызов клиентского приложения признан, число совершения вызовов клиентским приложением возрастает и число вызовов интерфейса внутреннего приложения возрастает, число раз, когда клиентское приложение вызывает интерфейс внутреннего приложения, возрастает, и эти увеличенные числа раз посылаются в счетчик 23 кластеров, который связан со шлюзом;

модуль 2103 обнаружения трафика, расположенный в шлюзе 21 и выполненный с возможностью, когда он обнаруживает, удовлетворяет ли клиентское приложение или интерфейс внутреннего приложения правилам управления трафиком, получать от счетчика кластеров:

число раз, когда клиентское приложение совершает вызов в течение периода времени, для подсчета вызовов заданного приложения, или

число раз, когда интерфейс внутреннего приложения вызывается в течение периода времени, для подсчета вызовов заданного интерфейса приложения, или

число раз, когда клиентское приложение вызывает интерфейс внутреннего приложения в течение периода времени, для подсчета вызовов интерфейса внутреннего приложения от заданного клиентского приложения.

Один из вариантов осуществления дополнительно содержит:

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

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

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

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

На фиг. 3 представлена блок-схема одного примера системы управления трафиком согласно настоящему изобретению. Система содержит шлюз 31, распределенный центральный счетчик 32, систему 33 анализа регистрационных данных, систему 34 управления транзакциями.

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

При этом система 33 анализа регистрационных данных и система 34 управления транзакциями совместно образуют вышеупомянутую систему контролируемого анализа. Система 33 анализа регистрационных данных получает регистрационные данные от шлюза 31 для анализа и вычисляет, превышает ли число раз, когда клиентское приложение совершало вызов, порог предупреждения для вызова приложения, соответствующего клиентскому приложению, в течение периода времени, для подсчета вызовов заданного приложения, или превышает ли число раз, когда клиентское приложение вызывало интерфейс внутреннего приложения, порог предупреждения для совместного вызова, соответствующего как клиентскому приложению, так и интерфейсу внутреннего приложения, в течение периода времени, для подсчета вызовов интерфейса внутреннего приложения от заданного клиентского приложения. Если да, то это извещает систему 34 управления транзакциями о посылке предупреждающего электронного сообщения. При этом период времени для подсчета вызовов заданного приложения и период времени для подсчета вызовов интерфейса внутреннего приложения от заданного клиентского приложения устанавливаются равными одному дню.

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

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

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

1. Способ для управления трафиком, отличающийся тем, что он содержит:

прием шлюзом запроса на вызов интерфейса внутреннего приложения платформы разработки приложений от клиентского приложения;

получение шлюзом правил по управлению трафиком клиентского приложения или интерфейса внутреннего приложения; и

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

причем правила по управлению трафиком являются следующими:

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

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

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

2. Способ для управления трафиком по п. 1, отличающийся тем, что этот способ дополнительно содержит:

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

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

3. Способ для управления трафиком по п. 1, отличающийся тем, что этот способ дополнительно содержит:

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

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

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

4. Способ для управления трафиком по п. 1, отличающийся тем, что этот способ дополнительно содержит:

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

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

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

5. Способ для управления трафиком по п. 1, отличающийся тем, что этот способ дополнительно содержит:

когда запрос на вызов клиентского приложения признан шлюзом, число раз совершения вызовов клиентским приложением возрастает и число вызовов интерфейса внутреннего приложения возрастает, число раз, когда клиентское приложение вызывает интерфейс внутреннего приложения, возрастает, и эти увеличенные числа раз посылаются в счетчик кластеров, который связан со шлюзом;

когда шлюз обнаруживает, удовлетворяет ли клиентское приложение или интерфейс внутреннего приложения правилам по управлению трафиком, получение от счетчика кластеров:

числа раз, когда клиентское приложение совершает вызов в течение периода времени, для подсчета вызовов заданного приложения, или

числа раз, когда вызывается интерфейс внутреннего приложения в течение периода времени, для подсчета вызовов заданного интерфейса приложения, или

числа раз, когда клиентское приложение вызывает интерфейс внутреннего приложения в течение периода времени, для подсчета вызовов интерфейса внутреннего приложения от заданного клиентского приложения.

6. Способ для управления трафиком по п. 1, отличающийся тем, что этот способ дополнительно содержит:

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

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

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

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

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

8. Система для управления трафиком, отличающаяся тем, что эта система содержит шлюз и модули, расположенные в шлюзе, которые содержат:

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

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

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

причем правила по управлению трафиком являются следующими:

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

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

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

9. Система для управления трафиком по п. 8, отличающаяся тем, что эта система дополнительно содержит систему контролируемого анализа, которая связана со шлюзом, и

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

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

10. Система для управления трафиком по п. 8, отличающаяся тем, что эта система дополнительно содержит систему контролируемого анализа, которая связана со шлюзом, и

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

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

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

11. Система для управления трафиком по п. 8, отличающаяся тем, что эта система дополнительно содержит систему контролируемого анализа, которая связана со шлюзом, и

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

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

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

12. Система для управления трафиком по п. 8, отличающаяся тем, что дополнительно содержит:

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

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

числа раз, когда клиентское приложение совершает вызов в течение периода времени, для подсчета вызовов заданного приложения, или

числа раз, когда вызывается интерфейс внутреннего приложения в течение периода времени, для подсчета вызовов заданного интерфейса приложения, или

числа раз, когда клиентское приложение вызывает интерфейс внутреннего приложения в течение периода времени, для подсчета вызовов интерфейса внутреннего приложения от заданного клиентского приложения.

13. Система для управления трафиком по п. 8, отличающаяся тем, что дополнительно содержит:

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

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

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

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

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



 

Похожие патенты:

Изобретение относится к технике связи и может использоваться в системах беспроводной связи. Технический результат состоит в повышении пропускной способности каналов передачи.

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

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

Изобретение относится к области виртуализации мобильной сети. Технический результат изобретения заключается в повышении производительности обработки пользовательских данных за счет распределения пакетов пользовательских данных по множеству CPU-ядер.

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

Изобретение относится к объекту управления (MO) Открытого альянса мобильной связи (OMA) для управления затором в мобильных сетях. Технический результат – обеспечение гранулярности для управления использованием сетевого доступа в определенных типах приложений, работающих в мобильных устройствах при запрете класса доступа.

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

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

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

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

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

Группа изобретений относится к испытанию и контролю систем управления устройств. Способ удаленного взаимодействия с изделием включает в себя использование программы, загруженной на смартфон пользователя. Устанавливают первый канал беспроводной связи между смартфоном и процессором изделия. Устанавливают второй канал беспроводной связи посредством глобальной сети между смартфоном и центром обслуживания, ответственным за выполнение ремонта и технического обслуживания изделия. Используют второй канала связи для обеспечения возможности передачи команд и информации от центра обслуживания на процессор изделия посредством каналов связи. Выполняют диагностику неисправности изделия и обеспечивают обновление встроенного программного обеспечения для изделия. Каналы связи обеспечивают возможность идентификации центром обслуживания неисправного компонента изделия на основании диагностики изделия. Создают центром обслуживания заявки на заменяющую деталь на основании неисправного компонента. Также заявлены система технического обслуживания оборудования и смартфон, используемый в качестве коммуникационного звена между оборудованием и центром обслуживания. Технический результат изобретения заключается в повышении эффективности устранения неисправности бытовых приборов. 3 н. и 11 з.п. ф-лы, 3 ил.

Изобретение относится к технологиям сетевой связи. Технический результат заключается в повышении скорости передачи данных. Способ содержит этапы, на которых: создают посредством многоадресного передающего устройства многоадресную группу; управляют посредством многоадресного передающего устройства элементом многоадресной группы; и завершают посредством модуля службы управления деревом многоадресной маршрутизации, расположенного на многоадресном передающем устройстве или на контроллере программно-конфигурируемой сети SDN, планирование дерева многоадресной маршрутизации и преобразовывают планирование дерева многоадресной маршрутизации в инструкцию по модификации записи потока, которая может исполняться контроллером SDN, так что контроллер SDN исполняет инструкцию по модификации записи потока и инструктирует коммутатор SDN, используя южный интерфейс прикладного программирования API, исполнять, в соответствии с записью модифицированного потока, многоадресную задачу. 4 н. и 10 з.п. ф-лы, 9 ил.

Изобретение относится к системам связи и управления и может быть использовано для создания транспортных сетей полевой системы связи, осуществляющих образование каналов и трактов, коммутацию и передачу по магистральным линиям связи различного вида информации. Технический результат заключается в расширении функциональных возможностей аппаратной по организации контроля и управления средствами транспортной сети полевой системы связи на технологическом уровне. Для этого в подвижную аппаратную связи, контроля и управления для транспортной сети полевой системы связи дополнительно введены защищенный монитор автоматизированного рабочего места (АРМ) оператора аппаратной, АРМ оператора контроля и управления (ОКУ), защищенный монитор АРМ ОКУ, устройство документирования, телефонный аппарат системы АТС, автоматизированный коммутатор каналов и трактов (ККТ), агрегатор, аппаратура волнового уплотнения, оптический кросс линейный, оптический кросс канальный, устройство контроля оптических кабелей (УКОК), коммутатор Ethernet, блок коммутации, мониторинга и управления трафиком (КМУТ), групповой мультиплексор, волоконно-оптические линии связи (ВОЛС) для приема/выдачи каналов на взаимодействующие аппаратные, соединительные линии (СЛ) для выдачи каналов связи потребителям, СЛ для выдачи цифровых трактов Е1 потребителям, ВОЛС для приема трактов от взаимодействующих аппаратных, станция широкодиапазонная широкополосного радиодоступа с антенной, первый и второй пульты связи оператора. 1 ил.

Изобретение относится к области радиотехники. Техническим результатом является повышение достоверности оценки результатов моделирования сетевой атаки типа "человек посередине" (MITM), за счет учета особенностей распространения передаваемых пакетов в единой сети электросвязи ЕСЭ и оценки необходимого ресурса для проведения эффективной сетевой атаки типа MITM. Способ моделирования сетевой атаки типа "человек посередине" заключается в том, что задают и записывают в ячейки оперативной памяти персонального компьютера (ПК) параметры, характеризующие топологию компьютерной сети связи (КСС), периодичность и интенсивность воздействия, создают физическую модель направления КСС, моделируют процессы функционирования КСС, моделируют воздействия на системы связи, измеряют, запоминают показатели, характеризующие основные параметры воздействия, производят корректировку (изменения) физических моделей объектов, измеряют, подсчитывают, записывают в ячейки оперативной памяти ПК основные значения характеристик моделируемых воздействий, отличающийся тем, что задают параметры, характеризующие процесс передачи пакетов в единой сети электросвязи (ЕСЭ), создают физическую модель направления КСС, фрагмент ЕСЭ, включающую два ПК, имитирующих узлы КСС сети, маршрутизатор, управляемый ПК, имитирующий фрагмент ЕСЭ, маршрутизатор, управляемый ПК, имитирующий сетевую атаку на КСС "человек посередине", устанавливают требуемое программное обеспечение для работы ПК в ЕСЭ, указывают IP-адреса, устанавливают требуемое программное обеспечение и настраивают маршрутизатор, управляемый ПК, имитирующий фрагмент ЕСЭ, и управляющий ПК, ПК, управляющий маршрутизатором, осуществляет подмену передаваемых пакетов и обеспечивает имитируемую возможную вероятность ошибки, задержку и джиттер при нормальном функционировании ЕСЭ, устанавливают требуемое программное обеспечение и настраивают маршрутизатор, управляемый ПК, имитирующий деструктивное воздействие типа "человек посередине", и управляющий ПК, ПК, управляющий маршрутизатором, осуществляет подмену передаваемых пакетов или осуществляет задержку передаваемых пакетов с целью срыва сеанса связи, при моделировании функционирования КСС, использующей сетевой ресурс ЕСЭ без сетевой атаки "человек посередине", передают заданную информационную последовательность и в маршрутизаторе, имитирующем фрагмент ЕСЭ, случайным образом изменяют передаваемую последовательность и задерживают передачу, имитируя передачу в ЕСЭ, осуществляют моделирование для различных скоростей передачи, различного программного обеспечения и различных фрагментов ЕСЭ. 2 ил.

Изобретение относится к технологиям сетевой связи. Технический результат заключается в повышении скорости передачи данных. Способ маршрутизации услуг «точка - много точек» в многодоменной сети с архитектурой с иерархическими элементами вычисления канала, H-PCE, содержит, в дочернем элементе вычисления канала, C-PCE, одного из доменов, этапы, на которых: определяют информацию об обобщенной топологии домена, причем информация об обобщенной топологии домена содержит по меньшей мере одно из: указания относительно того, способен ли домен поддерживать услуги «точка - много точек»; указания относительно того, способен ли узел обобщенной топологии домена поддерживать точку ветвления для услуг «точка - много точек»; и отправляют информацию об обобщенной топологии домена родительскому элементу вычисления канала, P-PCE. 8 н. и 13 з.п. ф-лы, 10 ил.

Изобретение относится к средствам управления трафиком. Техническим результатом является экономия ресурсов хранения, требуемых для буферизации информации связанного списка, и улучшение рабочих характеристик системы управления трафиком. В способе принимают запрос операции, когда запрос операции включает запрос на удаление очереди либо запрос на установку очереди, выполняют операцию диспетчеризации на списке очередей согласно запросу операции, при этом список очередей содержит первый участок и второй участок, при этом второй участок связывают с хвостом первого участка, при этом первый участок используют для хранения одной либо большего количества активных очередей, а второй участок используют для хранения одной либо большего количества неактивных очередей. Устройство реализует заявленный способ. 2 н.п. и 9 з.п. ф-лы, 5 ил.

Изобретение относится к технологиям сетевой связи. Технический результат заключается в повышении скорости передачи данных. Способ содержит этапы, на которых задают с помощью организатора виртуализации сетевой функции или системы поддержки эксплуатации конфигурационную информацию виртуализированного управления сетью, где конфигурационная информация включает в себя по меньшей мере одно или комбинацию из следующей конфигурационной информации: конфигурационную информацию функции управления сетью, конфигурационную информацию топологической зависимости между функцией управления сетью и другим виртуализированным сетевым объектом, конфигурационную информацию интерфейса, связанного с управлением сетью, конфигурационную информацию жизненного цикла, конфигурационную информацию требования к рабочим характеристикам управления сетью или конфигурационную информацию политики развертывания; и инструктируют с помощью организатора виртуализации сетевой функции или системы поддержки эксплуатации менеджера виртуализации управления сетью выполнить в соответствии с конфигурационной информацией виртуализацию функции управления сетью. 7 н. и 14 з.п. ф-лы, 8 ил.

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

Изобретение относится к коммуникационным технологиям. Технический результат заключается в расширении арсенала средств для установки рабочего состояния устройств. Способ включает обнаружение рабочего режима первого устройства и управление вторым устройством, связанным с первым устройством. Управление вторым устройством, связанным с первым устройством, для переключения рабочего режима в целевой режим при обнаружении, что первое устройство находится в режиме без звука, управление вторым устройством для переключения его в целевой режим, соответствующий режиму без звука. 7 н. и 15 з.п. ф-лы, 16 ил.

Изобретение относится к технологиям сетевой связи. Технический результат заключается в повышении скорости передачи данных. Способ содержит: прием шлюзом запроса на вызов интерфейса внутреннего приложения платформы разработки приложений от клиентского приложения; получение шлюзом правил по управлению трафиком клиентского приложения или интерфейса внутреннего приложения; и обнаружение шлюзом, удовлетворяются ли правила по управлению трафиком клиентским приложением или интерфейсом внутреннего приложения; если да, то признание запроса на вызов от клиентского приложения; в противном случае отклонение запроса на вызов от клиентского приложения. 2 н. и 12 з.п. ф-лы, 3 ил.

Наверх