Каким образом ограничивается скорость скачки на стороне клиента?

← →
Дмитрий С © (2011-01-25 12:05) [0]

Например:

С помощью менеджера закачки начинаю загрузку некого файла с сервера. Скорость подключения, к примеру, 10МБайт/сек, сервер специально не ограничивает скорость.

Начинается скачка со скоростью около 10МБайт/сек.

В менеджере загрузок устанавливаю ограничение скорости загрузки, например, 2 МБайт/с.

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

Или просто клиент начинает реже делать recv, а сервер получает дополнительные "отлупы" при выполнении send ?

← →
Anatoly Podgoretsky © (2011-01-25 12:19) [1]

> Дмитрий С (25.01.2011 12:05:00) [0]

Запрашивая данные раз в секунду порциями по 2 мБ

← →
Slym © (2011-01-25 12:45) [2]

Anatoly Podgoretsky © (25.01.11 12:19) [1]
запрашивая данные раз в 1/n секунд порциями размера n*Speed

← →
Inovet © (2011-01-25 14:26) [3]

Мне другое интересно. Вот пользовался я много времени FlashGet, он умеет работать прозрачно, так что его не чувствуешь - качает на максимальной скорости, как только кто-то полез куда, отдаёт ему сколько надо. Потом FlashGet стал в другом нехороший, поставил я Download Master, всем он хорош, а вот такой фичи с автоматической скоростью нет - только вручную менять, вернее есть там авто, если включить, но она снижает до совсем мало и оставляят так, назад не возвращает. То же самое и uTorrent.

Что мешает сделать аналогично FlashGet?

← →
Smile (2011-01-25 14:39) [4]

> Inovet © (25.01.11 14:26) [3]

До сих пор пользуюсь FlashGet

← →
Palladin © (2011-01-25 17:16) [5]

До сих пор пользуюсь ReGet

← →
KSergey © (2011-01-25 17:27) [6]

До сих пор пользуюсь IE6

← →
Inovet © (2011-01-25 17:34) [7]

> [4] Smile (25.01.11 14:39)
> До сих пор пользуюсь FlashGet

> [5] Palladin © (25.01.11 17:16)
> До сих пор пользуюсь ReGet

ReGet не знаю, а те версии FlashGet, что на их сайте, какие-то глючные стали и лазят постоянно по непонятным адресам в Инете, и всё по новым. А инсталяцию предыдущих версий я потерял, вот и стал смотреть что советуют, вроде ДМ всё больше, поставил - нормальный 0 показал ненавязчиво рекламму на прогрессбаре и всё, вот только скорость вручную крутить как-то неудобно да и неправильно. Наверно не всё так просто.

← →
Дмитрий С © (2011-01-25 18:33) [8]

> Запрашивая данные

Это понятно. Но как это реализуется на уровне tcp, ip или чего там еще?
Разве сервер ждет каких то запросов данных?

← →
Сергей М. © (2011-01-26 10:14) [9]

> как это реализуется на уровне tcp, ip

Никак. Шейпер работает уровнем выше - на прикладном уровне.

> сервер ждет каких то запросов данных?

А ты думаешь он по собственной инициативе начинает пхать клиенту поток данных ?)

Клиент раз в секунду спрашивает : сервер, дай мне очередной 1 кбайт
Сервер раз в секунду отвечает: на тебе, клиент, твой очередной килобайт.
Результат: 1 кб/сек

Клиент раз в пол-секунды спрашивает : сервер, дай мне очередной 1 кбайт
Сервер раз в пол-секунды отвечает: на тебе, клиент, твой очередной килобайт.
Результат: 2 кб/сек

← →
han_malign (2011-01-26 10:31) [10]

> Но как это реализуется на уровне tcp, ip или чего там еще?

GET ... HTTP/1.1
If-Range: ...

HTTP/1.1 206 Partial Content
Content-Range: ...

← →
Дмитрий С © (2011-01-26 10:39) [11]

> Сергей М. © (26.01.11 10:14) [9]

Уже становится понятнее.
Немного отойдем от темы качалок: Сервер и клиент, соединение установлено. Клиент не читает ничего (например пока занят обработкой предыдущих данных), а сервер посылает килобайт клиенту. В таком случае где храниться этот килобайт?

← →
Сергей М. © (2011-01-26 11:33) [12]

> где храниться этот килобайт?

В буфере приема сокета.
Как только клиент освободится, он обращается к сокету "дай столько-то принятых от партнера данных, если таковые на сей момент есть", сокет берет из своего буфера данные и отдает клиенту.

← →
DiamondShark © (2011-01-26 12:54) [13]

Без QoS -- туфта все эти ограничения, типа: "раз в секунду дай столько-то".

← →
Сергей М. © (2011-01-26 13:46) [14]

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

← →
Andy BitOff © (2011-01-26 14:00) [15]

А без компьютера и это все туфта =)

← →
KSergey © (2011-01-26 14:06) [16]

> Andy BitOff © (26.01.11 14:00) [15

а без электричества - и компьютер не поможет.

Про QoS
Скажите, я правильно понимаю, что если хоть одно устройство по пути следования траффика этот самый QoS не поддерживает - то в итоге QoS не работает? или ошибаюсь?

← →
Сергей М. © (2011-01-26 14:09) [17]

> без компьютера и это все туфта

Угу.
Все фигня кроме пчел, да и пчелы тоже фигня)

Всё туфта без полноценной поддержки RFC-2324.

> приличный шейпер, работающий на транспортном и ниже уровнях.

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

При запросе клиентом при вызове сокетной функции recv в неё передаётся размер приёмного буфера. Если сервер передаёт больший объём данных - буфер заполняется и функция возвращает его размер в этом случае клиент должен скопировать данные и снова вызвать функцию recv. Если сервер передал меньший объём информации возврат из функции recv не производится. По истечении тайм-аута или явного разрыва соединения работа recv прекращается и функция возвращает число, меньшее указанного размера буфера. При этом клиент должен считать, что закачка завершена и закрыть сокет. Ограничить скорость закачки можно введением пауз после каждого последующего вызова recv. Всяческими инкапсулирующими сокеты прибамбахами сделать это нельзя, если это не заложено в функционал изначально.

> Dimka Maslov © (26.01.11 21:04) [19]

> Если сервер передал меньший объём информации возврат из
> функции recv не производится

Ты эту траву больще не кури).. и других ею тоже не угощай)

> Dimka Maslov © (26.01.11 21:04) [19]

Это то понятно. Непонятно что будет происходить, если сервер передает данные, а клиент не делает recv.

> Сергей М. © (26.01.11 22:52) [20]

В чем он не прав? Все правильно вроде.

> В чем он не прав?

В том что:

1. После установления соединения нет ни сервера ни клиента - есть равноправные партнеры по соединению.

2. Если партнер таки передал некий (пусть даже меньший ожидаемого) объём информации, возврат из функции recv производится
.
recv висит только в случае если партнер молчит, т.е. в случае когда на момент вызова recv буфер приема гнезда пуст и нет признака штатного либо аварийного разрыва петли соединения.

> Дмитрий С (27.01.2011 09:05:21) [21]

> если сервер передает данные, а клиент не делает recv

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

> Anatoly Podgoretsky © (27.01.11 10:37) [23]

> > если сервер передает данные, а клиент не делает recv
> Сервер отвалится по ошибке.

НетЪ.
Сервер МОЖЕТ отвалиться по ошибке, но не обязательно.

> Dimka Maslov © (26.01.11 21:04) [19]

> При этом клиент должен считать, что закачка завершена и
> закрыть сокет.

Это бред.

На одной стороне я выставляю опцию TCP_NODELAY и передаю данные кусками разной длины, но не больше чем по 666 байт за раз.
На другой стороне я читаю данные буферами по 4 КБ.
При этом, где-то между участниками обмена стоит хитровыпендренная девайсина, которая полностью переформатирует поток в равные сегменты по 512 байт.

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

Каким образом ограничивается скорость скачки на стороне клиента? Найти похожие ветки