Алгоритм эффективного управления ресурсами соединения

Question

сложно просмотреть это, если оно было задано ранее, так как я не знаю его имени. Так вот:

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

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

Так эффективно это вопрос спроса и предложения с ограничениями:

У меня есть шлюз, который может обрабатывать только N одновременные соединения (имя пользователя/PW комбо) У меня есть X сообщений штабелироваться, принадлежащими к Y другому из эти соединения

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

Кто-нибудь знает, какие существуют алгоритмы для этого? Поэтому я могу сделать это для Google. Или, может быть, кто-то уже может дать мне несколько указателей.

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

благодарит

Answer 1

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

1. Для каждого подключения (имя пользователя/пароль) создайте простую очередь LIFO. Модуль, который получает сообщения, должен вставлять их в очередь для соответствующего пользователя.
2. Модуль диспетчера должен поддерживать очереди очереди с приоритетом.Это означает, что у вас есть функция priority(queue), которая вычисляет приоритет для данной очереди на основе количества сообщений, приоритета учетной записи, времени с момента последней отправки и т. Д. Реализация priority(queue) остается в качестве упражнения для читателя.
3. Внутренний контур диспетчера берет N очередей с наивысшим приоритетом очереди очередей, делает соединение с шлюзом для каждого имени пользователя/пароля и отправляет все сообщения в этих очередях. Новые опустошенные очереди возвращаются в очередь очередей. Пересчитайте приоритет для всех очередей, промойте и повторите.

В идеале, часть отправки сообщения на этапе № 3 может быть многопотоковой.

Альтернативная реализация этапа № 3 должна заключаться в том, чтобы отправлять сообщения из каждой очереди, пока приоритет очереди не опустится ниже приоритета следующей очереди ожидания. Однако это означает, что вы пересчитываете priority(queue) после каждой отправки, что может быть дороже, чем того стоит.

Answer 2

Концептуально вы хотите реализовать Priority Queue.

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

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

Если ваш гат eway даже немного медленнее алгоритма маршрутизации, у вас будет чистое увеличение скорости, сделав алгоритм маршрутизации максимально умным.

Answer 3

Посмотрите на планирование задач ОС и алгоритмы сетевого планирования. Они пытаются решить множество аналогичных проблем по назначению временных рядов ограниченного ресурса для большего числа потребителей. Там огромное количество исследований. В частности, weighted fair queueing звучит так, как будто это может быть полезно для вас.

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

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