Ограничение скорости

← →
SPeller (2003-08-27 08:25) [0]

Извиняюсь, если мой вопрос уже был, но ни в поиске, ни в faq я ответа не нашёл.
Можно ли и как ограничить скорость Socket-соединения, работающего на HTTP протоколе?
Мне для отладки надо гонять загрузку файлов по HTTP протоколу, а при использовании Apache скорость соединения с localhost просто зверская :) и ничего визуально отследить не удаётся. А гонять гигабайты возможности нет.

← →
Digitman (2003-08-27 08:34) [1]

> Socket-соединения, работающего на HTTP протоколе

строго наоборот - HTTP-протокол базируется на Socket-соединении)... точнее - на TCP/IP-протоколе

непонятно, что здесь подразумевается под словом "скорость" ... а HTTP здесь совершенно ни при чем..

← →
SPeller (2003-08-27 08:53) [2]

Скорость тут при том, что мне надо бы поставить потолок скорости передачи, например в 5 килобайт/сек. Как например, в качалках разных есть штучка типа "ограничить скорость". Мне нужно именно это.

← →
Reindeer Moss Eater (2003-08-27 09:17) [3]

Если клиент - твой ограничивай в клиенте.
Если не твой, напиши шлюз и ограничивай в нем.

← →
Е-Моё имя (2003-08-27 09:17) [4]

> SPeller © (27.08.03 08:53) [2]

апач надо настроить, должна быть возможность
мп3 качал когда-нить с ограничением скорости?

← →
SPeller (2003-08-27 09:25) [5]

> Reindeer Moss Eater © (27.08.03 09:17) [3]
> Если клиент - твой ограничивай в клиенте.

КАК? :)

← →
Digitman (2003-08-27 09:27) [6]

> SPeller

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

← →
SPeller (2003-08-27 09:29) [7]

Что-то я не совсем понял. Как это играться задержками? Мне вот, допустим 3КБ/сек надо поставить, и как это раелизовать? Алгоритм хотябы?

← →
Digitman (2003-08-27 09:33) [8]

ты асинхронные OnRead()/OnWrite() события пользуешь ?
или у тебя синхр.режим кл.гнезда ?

← →
Reindeer Moss Eater (2003-08-27 09:34) [9]

Берем блок длины X.
Расчитываем время, необходимое на передачу при заданной скорости Y.
Передаем блок.
Меряем затраченное время. Если поторопились, спим столько, чтобы компенсировать разницу.
Повторяем все с начала.

← →
SPeller (2003-08-27 09:41) [10]

> Digitman © (27.08.03 09:33) [8]
> ты асинхронные OnRead()/OnWrite() события пользуешь ?
> или у тебя синхр.режим кл.гнезда ?

У меня компонент с асинхронным соединением.

> Reindeer Moss Eater © (27.08.03 09:34) [9]
> Берем блок длины X.
> Расчитываем время, необходимое на передачу при заданной
> скорости Y.
> Передаем блок.
> Меряем затраченное время. Если поторопились, спим столько,
> чтобы компенсировать разницу.
> Повторяем все с начала.

1. Блок длины Х - блок данных, как я понял. Так?
2. Куда его передаём-то в 3-м пункте? Может, получаем?

← →
Reindeer Moss Eater (2003-08-27 09:42) [11]

Передаем/получаем - разницы нет.

← →
SPeller (2003-08-27 09:45) [12]

То есть, я получаю не блок, например в 6 килобайт, смотрю за какое время он пришёл бы при заданной скорости и сплю это время. Немного не то. Как мне ещё вычислить, за какое время этот блок дошёл до меня?

← →
Reindeer Moss Eater (2003-08-27 09:49) [13]

То есть, я получаю не блок, например в 6 килобайт, смотрю за какое время он пришёл бы при заданной скорости и сплю это время. Немного не то.
Почему не то? В реальных условиях скорость передачи будет всегда непостоянной. Поэтому можно располагать реальными данными исключительно после приема передачи блока.
Чем меньше блок, тем точнее можно выдержать заданную скорость.

Как мне ещё вычислить, за какое время этот блок дошёл до меня?
GetTickCount до и GetTickCount после.

← →
SPeller (2003-08-27 09:54) [14]

> То есть, я получаю не блок

Сорри, опечатка :) Что-то другое хотел написать. а потом передумал :)

Значит, вид функции асинхронного чтения будет примерно такой:

procedure AsyncRead;
begin
GetTickCount
<Вычисляем время, за которое дошёл блок>
<Вычисляем время простоя>
<Замораживаем связь на нужное время>
GetTickCount
end;

Правильно?

← →
Reindeer Moss Eater (2003-08-27 09:58) [15]

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

← →
SPeller (2003-08-27 10:00) [16]

Да, это асинхронный обработчик. А почему не всё так просто? Трудно приостановить связь в асинхронном режиме?

← →
Reindeer Moss Eater (2003-08-27 10:03) [17]

Трудно приостановить связь в асинхронном режиме?
Труднее определить момент полного приема/отправки блока.
Он не наступает в следующей строчке после Send.

← →
Verg (2003-08-27 10:07) [18]

Мнгновенная скорость определяется только канальным уровнем (Если 10 мБит/с - то ее никак не уменьшить). Средняя же скорость опередяется кроме этого еще и производительностью клиента-сервера. Т.е. если на обработку пакета в 1024 байта клиент будет тратить 1 секунду, то средняя скорость будет <1024 б/c. Таким образом, если необходимо добиться определенной средней скорости, то в обработчике пакета надо сделать искусственную задержку длительностью равной (<количество принятых байт>/<требуемая ср. скорость>) секунд.

> А почему не всё так просто?

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

В частном можно - например, ping это делает, но это специальный протокол. И определяет он время = <время передачи пакета в одну сторону>+<время реакции пингуемого>+<время передачи пакета в обратную сторону>

А так как в общем случае
<время передачи пакета в одну сторону>
<>
<время передачи пакета в обратную сторону>
то точно определить <время передачи пакета в одну сторону> не представляется возможным.

← →
SPeller (2003-08-27 10:08) [19]

Ну погрешности возможны, мне не космический аппарат проектировать :). Я исходил из того, что время между вызовами обработчика почти равно времени приёма блока. Длина полученного блока известна. Таким образом, замеряя время между вызовами и вычисляя требуемое время, мы получаем и время простоя. Вопрос, как остановить связь?

← →
Reindeer Moss Eater (2003-08-27 10:10) [20]

Вопрос, как остановить связь?
Это значит не вызывать методы чтения/записи.

← →
Verg (2003-08-27 10:13) [21]

> Вопрос, как остановить связь?

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

← →
SPeller (2003-08-27 10:15) [22]

> Reindeer Moss Eater © (27.08.03 10:10) [20]
> Это значит не вызывать методы чтения/записи.

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

> Verg © (27.08.03 10:13) [21]
> Наверное никак.

Так... В тупик пришли? Как же мне ограничить скорость-то?

← →
Verg (2003-08-27 10:16) [23]

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

← →
Verg (2003-08-27 10:17) [24]

> Так... В тупик пришли? Как же мне ограничить скорость-то?

> > Verg © (27.08.03 10:13) [21]
> > Наверное никак.

← →
SPeller (2003-08-27 10:19) [25]

Ладно, пусть TCP/IP, как мне заставить это дело ждать?

← →
Digitman (2003-08-27 10:28) [26]

> SPeller

в OnRead() считываешь данные, переданные Апачем, целиком или фрагментами (как это предусмотрено твоим алгоритмом), если надо - делаешь их препарсинг, анализ и т.п..... результат приема/обработки поступающего потока (!!) данных записываешь в хвост некой очереди

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

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

← →
Reindeer Moss Eater (2003-08-27 10:34) [27]

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

Ну так извлекать-то их из буфера для уровня приложения никто насильно без задержки не заставляет.

← →
SPeller (2003-08-27 10:41) [28]

> Digitman © (27.08.03 10:28) [26]

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

> Reindeer Moss Eater © (27.08.03 10:34) [27]

Ага, знаю я про этот буфер :) Получается, что пока буфер этот не освободим, получать больше не будем? Т.е. пока не вызовем recv, загрузка не продолжится?

← →
Reindeer Moss Eater (2003-08-27 10:45) [29]

Т.е. пока не вызовем recv, загрузка не продолжится?
Тебе что важно? Что бы физический канал был нагружен заданным bandwidth, или уровень приложения "думал", что данные передаются с заданной скоростью?
По моему - второе.

← →
SPeller (2003-08-27 10:48) [30]

Сейчас второе, а потом и первое понадобится. Лучше сразу всё выяснить.

← →
Digitman (2003-08-27 10:52) [31]

> SPeller

первое ты никак не ограничишь...

ну разве что внедрившись каким-то невообразимым способом в "дебри" драйвера физического транспортного устройства... скажем, ОЕМ-драйвера сет.карты...

← →
SPeller (2003-08-27 10:56) [32]

← →
Digitman (2003-08-27 10:57) [33]

> В вашем случае скорость передачи будет та же

не нравится ? на здоровье ! я уже сказал - организуй транспорт в доп.код.потоке и регулируй ограничения траффика уровнем приоритета код.потока ... именно так и организован механизм управления траффик-приоритетом, скажем, в ReGet

но подход этот, думаю, гораздо более проктологический, чем контролируемый программно по таймеру

← →
SPeller (2003-08-27 11:13) [34]

← →
Digitman (2003-08-27 11:17) [35]

> А как это, "приоритета код.потока", если у меня асинхронно?

А какое отношение понятие "асинхронность" имеет к механизму квантования времени в мультизадачной/мультипоточной среде ?

← →
Reindeer Moss Eater (2003-08-27 11:21) [36]

А как с помошью семи значений параметра THREAD_PRIORITY_...
поиметь ограничение трафика с точностью, скажем, до байта в секунду (Reget)?

← →
Digitman (2003-08-27 11:21) [37]

методы, асинхронно вызываемые как реакция на то или иное сообщение/событие, выполняются в контексте определенного код.потока

задав приоритет этого кодового потока, ты можешь регулировать параметры квантования времени, выделяемого ОС на выполнение маш.инструкций этого код.потока ... а что там за инструкции - системе глубоко индифферентно, будь то инструкции, исполняемые в контексте вызовов send()/recv() или еще чего-то)

← →
Reindeer Moss Eater (2003-08-27 11:26) [38]

Хотя, если подумать, то семи даже много. Хватит двух.

← →
SPeller (2003-08-27 11:30) [39]

Так значит задержку нужно делать до вызова recv?

← →
Digitman (2003-08-27 11:51) [40]

> Reindeer Moss Eater

а в ReGet , кстати, и нет опции установки абс.значения скорости

есть всего три опции приоритета по траффику : высокий, корпоративный, спящий

Ограничение скорости Найти похожие ветки