Программное определение максимальной скорости передачи

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

На данный момент единственное решение, которое я могу придумать, — это передать несколько мегабайт между клиентом и сервером, а затем измерить, сколько времени заняла передача. Однако это решение очень нежелательно, потому что при наличии 100 000 клиентов оно потенциально может привести к слишком большому увеличению использования пропускной способности нашего сервера (которое уже слишком велико).

У кого-нибудь есть решения этой проблемы?

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

РЕДАКТИРОВАНИЕ: после дальнейшего изучения я не думаю, что это возможно; здесь задействовано слишком много переменных, чтобы точно измерить максимальную скорость передачи при выходе из сети провайдера. Тем не менее, оставив вопрос открытым, на случай, если кто-то предложит точное решение.


c networking tcp bandwidth microsoft-bits
person Collin Dauphinee    schedule 07.05.2010    source источник
comment
Для какой ОС вы пишете код? Вероятно, вы можете получить хотя бы теоретический максимум для конкретного интерфейса, но способ сделать это зависит от ОС.   -  person Jerry Coffin    schedule 07.05.2010
comment
Окна. Меня не интересует максимум интерфейса, меня интересует максимум того, что можно передать мимо через провайдера клиента; если это разрешено, наша программа будет использовать все, что ей дано, что снижает производительность других приложений. Заставлять пользователя выбирать свои собственные ограничения неприемлемо с точки зрения удобства использования.   -  person Collin Dauphinee    schedule 07.05.2010
comment
Не думайте, что у вас есть большой выбор, кроме выборки фактической скорости передачи во время передачи. Если вы не хотите ломать свой сервер, вы можете использовать один из существующих сервисов для его измерения, например, speakeasy.net. У кого-то должен быть API для вас.   -  person AlG    schedule 07.05.2010
comment
У вас нет времени, чтобы напечатать полный ответ, но взгляните на удобный для TCP контроль скорости? faqs.org/rfcs/rfc5348.html   -  person KillianDS    schedule 07.05.2010
comment
Что важнее: количество данных, которые вы должны получить, или задержка/дрожание связи? Пробовали ли вы использовать сквозное QoS?   -  person rsarro    schedule 02.06.2010

Ответы (5)


arrow_upward
2
arrow_downward

Если вы можете ограничить код Windows Vista или новее (маловероятно, но кто знает?), вы можете использовать SetPerTcpConnectionEStats и GetPerTcpConnectionEStats вместе с TCP_ESTATS_BANDWIDTH_RW_v0, чтобы Windows оценила пропускную способность соединения и позже получила эту оценку. Затем, основываясь на этой оценке, вы можете ограничить используемую полосу пропускания.

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

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

person Jerry Coffin    schedule 07.05.2010
comment
К сожалению, нам приходится поддерживать Windows XP. :( - person Collin Dauphinee; 10.05.2010

arrow_upward
1
arrow_downward

Если у вас есть устройства Windows на обоих концах соединения, вы можете использовать фоновую интеллектуальную службу передачи (BITS) для перемещения информации и решения всего вопроса пропускной способности. (Почти) всегда установленный компонент описан по адресу http://msdn.microsoft.com/en-us/library/aa362708(VS.85).aspx.

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

person Pekka    schedule 06.06.2010

arrow_upward
0
arrow_downward

Единственные ответы, которые я вижу, это:

  1. Используйте небольшой образец, чтобы рассчитать скорость передачи.
  2. Рассчитывайте фактические данные порциями (скажем, по 1 КБ) и сообщайте среднее значение.

Некоторые вопросы, усложняющие дело:

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

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

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

person Thomas Matthews    schedule 07.05.2010

arrow_upward
0
arrow_downward

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

Если проблема в том, что соединение имеет большую задержку и/или дрожание, попробуйте отправить информацию меньшими пакетами (фактические пакеты IP/TCP). Обычно система пытается использовать максимальный размер пакета, но фрагментация пакетов в Интернете может привести к задержке трафика. Если это по-прежнему не улучшит задержку, вы можете вернуться к использованию UDP вместо TCP. Но это не обеспечит доставку данных.

person rsarro    schedule 01.06.2010

arrow_upward
0
arrow_downward

Одним из вариантов может быть реализация чего-то вроде транспортного протокола UDP uTorrent между клиентом и сервером для снизить задержку. Простое измерение сырой пропускной способности не поможет, когда какой-то другой процесс также начнет использовать полосу пропускания, сокращая объем свободной полосы пропускания.

person bdonlan    schedule 21.06.2010