Как я могу контролировать перегрузку для протокола UDP?

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

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

РЕДАКТИРОВАТЬ: пожалуйста, никаких комментариев относительно использования UDP, подходит ли это или нет. Этот протокол использует UDP, но повторно собирает пакеты в целые файлы, когда они приходят.

Чтобы перефразировать вопрос: как работают алгоритмы управления перегрузками и как обнаруживается перегрузка?

Ответ 1

Предполагается, что вы должны использовать UDP (предпочтительным будет TCP).

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

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

RTP работает через UDP и RTCP (протокол управления транспортным средством в реальном времени), работающий с RTP, обеспечивает меры для QoS (Quality of Service), такие как потеря пакетов, задержки, дрожание и т.д., чтобы сообщать отправителю, чтобы он знал, когда замедлять вниз или изменить кодеки.

Нельзя сказать, что вы можете использовать RTP, но может быть полезно посмотреть, как это работает.

Ответ 2

Задержка - это хороший способ обнаружить заторы. Если ваша латентность начинает расти, то вам, вероятно, следует замедлить работу. Потерянный пакет эквивалентен задержке = бесконечность. Но вы никогда не можете быть уверены, что пакет был потерян или просто очень медленный, поэтому у вас должен быть тайм-аут для "обнаружения" потерянных пакетов.

Ответ 3

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

В следующей статье рассматриваются эти статистические данные и их значение в глубине: DEI Tech Note 0021: Потеря, Задержка и Скорость

Нахождение хорошего решения стало предметом многих исследований и коммерческих усилий. Различные алгоритмы (TCP, UDT, Многоцелевой протокол транзакций и т.д.) используют разные методы и делают разные предположения, все пытаются выяснить, что происходит в сети на основе очень редких данных.

Ответ 4

Кажется, алгоритм AIMD - это то, что они используют в TCP и UDT, чтобы избежать перегрузок.

Со страницы Википедии:

Алгоритм аддитивного увеличения/мультипликативного уменьшения (AIMD) представляет собой алгоритм управления с обратной связью, наиболее известный его использованием в TCP Congestion Avoidance. AIMD сочетает линейный рост окна скопления с экспоненциальным уменьшением при перегрузке. Несколько потоков, использующих управление перегрузкой AIMD, в конечном итоге сходятся, чтобы использовать равные количества конкурирующей ссылки.

Ответ 5

У меня была следующая идея:

Отправитель отправляет данные.
Приемник ждет пару секунд, а затем вычисляет пропускную способность /s
Приемник отправляет скорость, с которой его принимающие пакеты (байты/с) отправителю
Отправитель рассчитывает скорость отправки пакетов
Если скорость отправителя значительно выше, уменьшите ее, чтобы она соответствовала скорости приема.

Альтернативно, более продвинутый подход:

Отправитель начинает отправку с предопределенной минимальной скоростью (например, 1 кбит/с)
Приемник отправляет вычисленную скорость приема обратно отправителю.
Если скорость приема равна скорости передачи (принимая во внимание задержку), увеличьте скорость с помощью набора pct (например, rate * 2)
Продолжайте делать это, пока скорость отправки не станет выше скорости приема.
Следите за тем, чтобы тарифы учитывались при изменении скорости увеличения/уменьшения полосы пропускания, если это необходимо.

Отказ от ответственности: im не эксперт сети, это может не сработать для вас.