ограничение трафика

← →
SEvgeniy (2003-09-05 18:27) [0]

а вот собственно и сабж мастера. подскажите плиз кто знает,как (например Reget) ограничить входящий трафик.

← →
panov © (2003-09-05 18:31) [1]

Использовать прокси, например, WinGate.

← →
Esu © (2003-09-05 18:36) [2]

В ReGet помнится есть такая настройка.

← →
panov © (2003-09-05 18:52) [3]

Esu © (05.09.03 18:36) [2]
В ReGet помнится есть такая настройка.

А что, в Reget есть возможность ограничить объем скачиваемой информации?

← →
Reindeer Moss Eater © (2003-09-05 19:56) [4]

Входящий трафик ограничивается так:
Читаем кусочек, измеряем bps.
Если больше чем надо, делаем паузу, кушаем твикс.
Переходим ко второй строчке.

← →
Anatoly Podgoretsky © (2003-09-05 19:57) [5]

panov © (05.09.03 18:52) [3]
Скорость, но не объем, на чисто лигическом уровне, просто не передаем больше чем заказано, а квант передаваемой информации ограничивает указанным размером.

← →
panov © (2003-09-05 20:05) [6]

я из вопроса понял, что нужн оогранчит объем, а не скорость.

← →
Anatoly Podgoretsky © (2003-09-05 20:10) [7]

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

← →
SEvgeniy (2003-09-08 12:12) [8]

ну вроде как объем зависит от скорости,ну да ладно,допустим у меня канал 115к,а надо из него (например) попользовать 9600,чтобы и другим осталось.

to Reindeer Moss Eater ©
ну сделаю я паузу,а буфер TCP один хрен набивается,и его надо вовремя выбрать,не выбереш - переполнение...

← →
panov © (2003-09-08 12:18) [9]

Переполнения не будет. Будет появляться ошибка(WSAEWOULDBLOCK для неблокирующего режима), которую тебе нужно обрабатывать.

← →
esu © (2003-09-08 12:36) [10]

Вообще конечно вечная тема. Все равно предложенным panov © образом красивого ограничения не получится. Будут периодические пиковые нагрузки на канал.

Интерестно почему не сделали это на уровне протокола (http, ftp ??). Скажем посылаешь команду "шлите мне не быстрее чем N байт в секунду" и сервер послушненько шлет не быстрее чем N... Вроде бы ничего сложного в реализации нет. Неужели просто "не подумали" ?

← →
Reindeer Moss Eater © (2003-09-08 12:43) [11]

Неужели просто "не подумали" ?
То, что так очевидно для комнатной сети, выглядит бессмыслицей для реальных условий.

← →
Reindeer Moss Eater © (2003-09-08 12:44) [12]

Будут периодические пиковые нагрузки на канал.

"шлите мне не быстрее чем N байт в секунду"

И периодических пиковых нагрузок не будет?????

← →
Anatoly Podgoretsky © (2003-09-08 12:51) [13]

Именно, никаких перегрузок не будет, не надо сразу передавать 9600 бит, надо передавать за раз 9600/115200 бит и будет плавно

← →
Reindeer Moss Eater © (2003-09-08 12:53) [14]

Ну а первый-то байт (и все остальные тоже) все равно полетит со свистом и неограниченной скоростью :)

← →
Anatoly Podgoretsky © (2003-09-08 12:53) [15]

9600/115200*9600 это 800 и интервал между посылками

← →
Reindeer Moss Eater © (2003-09-08 12:56) [16]

Это "средняя по палате температура"

← →
Anatoly Podgoretsky © (2003-09-08 12:59) [17]

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

← →
Anatoly Podgoretsky © (2003-09-08 13:01) [18]

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

← →
Reindeer Moss Eater © (2003-09-08 13:01) [19]

Анатолий, я в общем-то не спорю, я возражал против [10]

← →
Anatoly Podgoretsky © (2003-09-08 13:03) [20]

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

← →
esu © (2003-09-08 13:11) [21]

Reindeer Moss Eater © (08.09.03 12:53) [14] Ну а первый-то байт (и все остальные тоже) все равно полетит со свистом и неограниченной скоростью :)

Ну и пусть себе летит, главное что б пакетики других сервисов рядышком могли лететь :) У меня ping www.delphimaster.ru никаких пиковых нагрузок не вызывает. Передает себе по 32 байта раз в секунду и никому не мешает.

А среднюю по больнице температуру можно было бы и понастраивать.

← →
esu © (2003-09-08 13:14) [22]

насчет команды "шлите мне не быстрее чем N байт в секунду" погорячиля конечно. Подразумевал конечно n байт с периодичностью m.

← →
SEvgeniy (2003-09-08 18:22) [23]

посмотрел я в msdn справочку на recv и пишут там:

If no incoming data is available at the socket, the recv call blocks and waits for data to arrive. When the socket is nonblocking, a value of SOCKET_ERROR is returned with the error value set to WSAEWOULDBLOCK

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

← →
panov © (2003-09-08 20:06) [24]

Предлагал и предлагаю такой метод реализовать, хотя сам не пробовал.

1. Вычисляем, сколько байт(N) с каким интервалом(T) мы должны получать, чтобы получить искомую скорость.
2. Читаем из сокета N байт.
3. Устанавливаем паузу(T) секунд.
4. Переходим к п.1.

WSAEWOULDBLOCK использовать при приеме не надо. Эту ситуацию будет посылающая сторона обрабатывать...

← →
SEvgeniy (2003-09-09 17:43) [25]

толи лыжи не едут,толи я не понимаю :( значит имеем что то вроде:

T:=1000;
N:=1024;
repeat
tcp.readbuffer(buf,N);
.....................
sleep(T);
until false;

ну буду я медленно читать,а сервер то наливает с максимально возможной для себя скоростью(или я не прав),ну переполнится у меня буфер и что?

← →
Reindeer Moss Eater © (2003-09-09 17:47) [26]

ну буду я медленно читать,а сервер то наливает с максимально возможной для себя скоростью(или я не прав),ну переполнится у меня буфер и что?

А ты не пробовал представить ситуацию когда сервер расположен на толстенном backbone и сливает инфу на клиента со страшной скоростью а по пути к клиенту встречается канальная аппаратура провайдера клиента имеющая меньшую полосу. Происходит что-то неприятное для провайдера клиента или нет?

← →
SEvgeniy (2003-09-09 19:19) [27]

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

← →
panov © (2003-09-09 19:37) [28]

>SEvgeniy (09.09.03 17:43) [25]

ну буду я медленно читать,а сервер то наливает с максимально возможной для себя скоростью(или я не прав),ну переполнится у меня буфер и что?

Ну не может буфер переполниться - это система обеспечивает.

← →
SEvgeniy (2003-09-10 10:57) [29]

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

TCP так устроен. Он ждет квитанции на отправляемые пакеты.

← →
SEvgeniy (2003-09-10 11:21) [31]

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

[4].

Какой то нехороший сервер, не может секунду подождать.

← →
SEvgeniy (2003-09-10 14:13) [34]

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

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

Значит, получишь ошибку.
Ты смотри реально на вещи.

← →
SEvgeniy (2003-09-10 17:32) [36]

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

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

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

← →
SEvgeniy (2003-09-10 19:29) [38]

вот именно!!!!,но это же не так

>SEvgeniy (10.09.03 19:29) [38]
вот именно!!!!,но это же не так

Есть стандарты...

SEvgeniy (10.09.03 19:29) [38]
Зря сомневаешься, я встречал сайты, которые не соглашались работать на низкой скорости, при это это было явно указано в Welcome сообщении.
Тоже по времени, конечно никто не будет ставить такие маленькие таймауты, но допустимо.

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