Является ли этот метод управления перегрузкой для UDP допустимым/звуковым?

Question

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

В качестве альтернативы, более продвинутый подход:

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

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

Answer 1

Конечно, это возможно. Теперь, это даст вам ожидаемый результат, или это звучит ...

Я думаю, вы пытаетесь решить проблему, которая была изучена и стандартизована очень умными людьми IETF. Я бы посоветовал вам взглянуть на RTP/RTCP, которые сидят поверх UDP, было бы только понять, почему это сложная проблема и захватывать некоторые идеи.

https://en.wikipedia.org/wiki/RTP_Control_Protocol

«Основная функция RTCP должна обеспечить обратную связь по качеству обслуживания (QoS) в распределении средств массовой информации периодически рассылает информацию статистики для участников потокового мультимедиа сессии.»

https://en.wikipedia.org/wiki/Real-time_Transport_Protocol

Тот факт, что это основной случай использования аудио/видеопотоков, я думаю, не так уж важно: точка RTCP является обеспечение обратной связи между particpants о UDP потока данных [*].

Имейте в виду, что:

• Это сложные протоколы, потому что проблема под рукой действительно сложно.

• IIRC, RTCP не определяет , что сторона отправителя должна делать с этими отчетами QoS. Он просто формализует обмен этими отчетами из стороны в сторону.

[*]: Ну, не enterily верно, так как в A/V, синхронизация является важным аспектом («отправить/получить своевременно»), в то время как то, что вы пытаетесь сделать, это «идти как можно быстрее, но не слишком быстро ».