|
|
12
|
|
Hello Openbsd,
Может быть кто-то может сделать backport altq с netbsd.
Дело в том что в нэтке altq сделан таким образом что одновременно
работает и с pf и altqd. Кто-то может сделать патч чтобы этот кусок
кода можно было запихнуть в OPenBSD и в опёнке в довесок к pf(altq)
можно было ещё скомпилить altqd и его использовать ?
--
Best regards,
irix mailto: [hidden email]
|
|
|
On Tue, 12 May 2009 11:17:56 +0300
irix < [hidden email]> wrote:
> Hello Openbsd,
>
> Может быть кто-то может сделать backport altq с netbsd.
>
> Дело в том что в нэтке altq сделан таким образом что одновременно
> работает и с pf и altqd. Кто-то может сделать патч чтобы этот кусок
> кода можно было запихнуть в OPenBSD и в опёнке в довесок к pf(altq)
> можно было ещё скомпилить altqd и его использовать ?
>
А зачем?
--
Динар Талыпов
|
|
|
Hello Dinar,
Tuesday, May 12, 2009, 1:37:23 PM, you wrote:
DT> On Tue, 12 May 2009 11:17:56 +0300
DT> irix < [hidden email]> wrote:
>> Hello Openbsd,
>>
>> Может быть кто-то может сделать backport altq с netbsd.
>>
>> Дело в том что в нэтке altq сделан таким образом что одновременно
>> работает и с pf и altqd. Кто-то может сделать патч чтобы этот кусок
>> кода можно было запихнуть в OPenBSD и в опёнке в довесок к pf(altq)
>> можно было ещё скомпилить altqd и его использовать ?
>>
DT> А зачем?
Чтобы можнло было шейпить входящий поток и создавать динамические
очереди
--
Best regards,
irix mailto: [hidden email]
|
|
|
On Tue, 12 May 2009 15:16:38 +0300
irix < [hidden email]> wrote:
> Hello Dinar,
>
> Tuesday, May 12, 2009, 1:37:23 PM, you wrote:
>
> DT> On Tue, 12 May 2009 11:17:56 +0300
> DT> irix < [hidden email]> wrote:
>
> >> Hello Openbsd,
> >>
> >> Может быть кто-то может сделать backport altq с netbsd.
> >>
> >> Дело в том что в нэтке altq сделан таким образом что одновременно
> >> работает и с pf и altqd. Кто-то может сделать патч чтобы этот кусок
> >> кода можно было запихнуть в OPenBSD и в опёнке в довесок к pf(altq)
> >> можно было ещё скомпилить altqd и его использовать ?
> >>
> DT> А зачем?
>
>
> Чтобы можнло было шейпить входящий поток и создавать динамические
> очереди
>
шейпить входящий поток по определению нельзя, ибо даже в драйвере нет функции инпута(инпут идет сразу в ether_input, если это эзернет)и соответсвенно очереди тоже нет, очередь можно организовать только на выходе.
Эта тема тут уже неоднократно подымалась.
--
Динар Талыпов
|
|
|
Hello Dinar,
Tuesday, May 12, 2009, 3:40:14 PM, you wrote:
DT> On Tue, 12 May 2009 15:16:38 +0300
DT> irix < [hidden email]> wrote:
>> Hello Dinar,
>>
>> Tuesday, May 12, 2009, 1:37:23 PM, you wrote:
>>
>> DT> On Tue, 12 May 2009 11:17:56 +0300
>> DT> irix < [hidden email]> wrote:
>>
>> >> Hello Openbsd,
>> >>
>> >> Может быть кто-то может сделать backport altq с netbsd.
>> >>
>> >> Дело в том что в нэтке altq сделан таким образом что одновременно
>> >> работает и с pf и altqd. Кто-то может сделать патч чтобы этот кусок
>> >> кода можно было запихнуть в OPenBSD и в опёнке в довесок к pf(altq)
>> >> можно было ещё скомпилить altqd и его использовать ?
>> >>
>> DT> А зачем?
>>
>>
>> Чтобы можнло было шейпить входящий поток и создавать динамические
>> очереди
>>
DT> шейпить входящий поток по определению нельзя, ибо даже в драйвере
DT> нет функции инпута(инпут идет сразу в ether_input, если это
DT> эзернет)и соответсвенно очереди тоже нет, очередь можно организовать только на выходе.
DT> Эта тема тут уже неоднократно подымалась.
Хорошо скажу по другому. Измерить скорость входящего потока от
определённого ипа и если больше чем нужно то дропать пакеты пока не
станет меньше.
--
Best regards,
irix mailto: [hidden email]
|
|
|
On Tue, 12 May 2009 15:43:26 +0300
irix < [hidden email]> wrote:
> Hello Dinar,
>
> Tuesday, May 12, 2009, 3:40:14 PM, you wrote:
>
> DT> On Tue, 12 May 2009 15:16:38 +0300
> DT> irix < [hidden email]> wrote:
>
> >> Hello Dinar,
> >>
> >> Tuesday, May 12, 2009, 1:37:23 PM, you wrote:
> >>
> >> DT> On Tue, 12 May 2009 11:17:56 +0300
> >> DT> irix < [hidden email]> wrote:
> >>
> >> >> Hello Openbsd,
> >> >>
> >> >> Может быть кто-то может сделать backport altq с netbsd.
> >> >>
> >> >> Дело в том что в нэтке altq сделан таким образом что одновременно
> >> >> работает и с pf и altqd. Кто-то может сделать патч чтобы этот кусок
> >> >> кода можно было запихнуть в OPenBSD и в опёнке в довесок к pf(altq)
> >> >> можно было ещё скомпилить altqd и его использовать ?
> >> >>
> >> DT> А зачем?
> >>
> >>
> >> Чтобы можнло было шейпить входящий поток и создавать динамические
> >> очереди
> >>
> DT> шейпить входящий поток по определению нельзя, ибо даже в драйвере
> DT> нет функции инпута(инпут идет сразу в ether_input, если это
> DT> эзернет)и соответсвенно очереди тоже нет, очередь можно организовать только на выходе.
> DT> Эта тема тут уже неоднократно подымалась.
>
>
> Хорошо скажу по другому. Измерить скорость входящего потока от
> определённого ипа и если больше чем нужно то дропать пакеты пока не
> станет меньше.
можно через rate-limit в самом pf, там идет скорость пакетов
--
Динар Талыпов
|
|
|
Hello Dinar,
Tuesday, May 12, 2009, 3:46:43 PM, you wrote:
DT> On Tue, 12 May 2009 15:43:26 +0300
DT> irix < [hidden email]> wrote:
>> Hello Dinar,
>>
>> Tuesday, May 12, 2009, 3:40:14 PM, you wrote:
>>
>> DT> On Tue, 12 May 2009 15:16:38 +0300
>> DT> irix < [hidden email]> wrote:
>>
>> >> Hello Dinar,
>> >>
>> >> Tuesday, May 12, 2009, 1:37:23 PM, you wrote:
>> >>
>> >> DT> On Tue, 12 May 2009 11:17:56 +0300
>> >> DT> irix < [hidden email]> wrote:
>> >>
>> >> >> Hello Openbsd,
>> >> >>
>> >> >> Может быть кто-то может сделать backport altq с netbsd.
>> >> >>
>> >> >> Дело в том что в нэтке altq сделан таким образом что одновременно
>> >> >> работает и с pf и altqd. Кто-то может сделать патч чтобы этот кусок
>> >> >> кода можно было запихнуть в OPenBSD и в опёнке в довесок к pf(altq)
>> >> >> можно было ещё скомпилить altqd и его использовать ?
>> >> >>
>> >> DT> А зачем?
>> >>
>> >>
>> >> Чтобы можнло было шейпить входящий поток и создавать динамические
>> >> очереди
>> >>
>> DT> шейпить входящий поток по определению нельзя, ибо даже в драйвере
>> DT> нет функции инпута(инпут идет сразу в ether_input, если это
>> DT> эзернет)и соответсвенно очереди тоже нет, очередь можно организовать только на выходе.
>> DT> Эта тема тут уже неоднократно подымалась.
>>
>>
>> Хорошо скажу по другому. Измерить скорость входящего потока от
>> определённого ипа и если больше чем нужно то дропать пакеты пока не
>> станет меньше.
DT> можно через rate-limit в самом pf, там идет скорость пакетов
По какой формуле расчитывать скорость, в зависимости от кол-ва пакетов
?
--
Best regards,
irix mailto: [hidden email]
|
|
|
Hello Dinar,
Tuesday, May 12, 2009, 3:46:43 PM, you wrote:
DT> On Tue, 12 May 2009 15:43:26 +0300
DT> irix < [hidden email]> wrote:
>> Hello Dinar,
>>
>> Tuesday, May 12, 2009, 3:40:14 PM, you wrote:
>>
>> DT> On Tue, 12 May 2009 15:16:38 +0300
>> DT> irix < [hidden email]> wrote:
>>
>> >> Hello Dinar,
>> >>
>> >> Tuesday, May 12, 2009, 1:37:23 PM, you wrote:
>> >>
>> >> DT> On Tue, 12 May 2009 11:17:56 +0300
>> >> DT> irix < [hidden email]> wrote:
>> >>
>> >> >> Hello Openbsd,
>> >> >>
>> >> >> Может быть кто-то может сделать backport altq с netbsd.
>> >> >>
>> >> >> Дело в том что в нэтке altq сделан таким образом что одновременно
>> >> >> работает и с pf и altqd. Кто-то может сделать патч чтобы этот кусок
>> >> >> кода можно было запихнуть в OPenBSD и в опёнке в довесок к pf(altq)
>> >> >> можно было ещё скомпилить altqd и его использовать ?
>> >> >>
>> >> DT> А зачем?
>> >>
>> >>
>> >> Чтобы можнло было шейпить входящий поток и создавать динамические
>> >> очереди
>> >>
>> DT> шейпить входящий поток по определению нельзя, ибо даже в драйвере
>> DT> нет функции инпута(инпут идет сразу в ether_input, если это
>> DT> эзернет)и соответсвенно очереди тоже нет, очередь можно организовать только на выходе.
>> DT> Эта тема тут уже неоднократно подымалась.
>>
>>
>> Хорошо скажу по другому. Измерить скорость входящего потока от
>> определённого ипа и если больше чем нужно то дропать пакеты пока не
>> станет меньше.
DT> можно через rate-limit в самом pf, там идет скорость пакетов
Полистал только что ман по pf.conf.5 про количество пакетов в ед.
времени ничего не увидел. Про количество стейтов и стейтов в ед.
времени увидел, количество создаваемых стейтов с одного источника
увидел. А вот проверки количества пакетов в ед.времени в одном уже
созданном стейте
не увидел. Направь в нужное русло.
--
Best regards,
irix mailto: [hidden email]
|
|
|
Hello irix,
Tuesday, May 12, 2009, 3:16:38 PM, you wrote:
i> Чтобы можнло было шейпить входящий поток и создавать динамические
i> очереди
Уж сколько раз твердили миру: шейпить уже принятое - глупо.
Если уж очень хочется - поставьте FreeBSD + Dummynet, будет Вам
входящий шейп и динамические очереди с любыми масками.
--
WBR, Alexander Sheiko
|
|
|
On Tue, 12 May 2009 23:03:47 +0300
irix < [hidden email]> wrote:
> Hello Dinar,
>
> Tuesday, May 12, 2009, 3:46:43 PM, you wrote:
>
> DT> On Tue, 12 May 2009 15:43:26 +0300
> DT> irix < [hidden email]> wrote:
>
> >> Hello Dinar,
> >>
> >> Tuesday, May 12, 2009, 3:40:14 PM, you wrote:
> >>
> >> DT> On Tue, 12 May 2009 15:16:38 +0300
> >> DT> irix < [hidden email]> wrote:
> >>
> >> >> Hello Dinar,
> >> >>
> >> >> Tuesday, May 12, 2009, 1:37:23 PM, you wrote:
> >> >>
> >> >> DT> On Tue, 12 May 2009 11:17:56 +0300
> >> >> DT> irix < [hidden email]> wrote:
> >> >>
> >> >> >> Hello Openbsd,
> >> >> >>
> >> >> >> Может быть кто-то может сделать backport altq с netbsd.
> >> >> >>
> >> >> >> Дело в том что в нэтке altq сделан таким образом что одновременно
> >> >> >> работает и с pf и altqd. Кто-то может сделать патч чтобы этот кусок
> >> >> >> кода можно было запихнуть в OPenBSD и в опёнке в довесок к pf(altq)
> >> >> >> можно было ещё скомпилить altqd и его использовать ?
> >> >> >>
> >> >> DT> А зачем?
> >> >>
> >> >>
> >> >> Чтобы можнло было шейпить входящий поток и создавать динамические
> >> >> очереди
> >> >>
> >> DT> шейпить входящий поток по определению нельзя, ибо даже в драйвере
> >> DT> нет функции инпута(инпут идет сразу в ether_input, если это
> >> DT> эзернет)и соответсвенно очереди тоже нет, очередь можно организовать только на выходе.
> >> DT> Эта тема тут уже неоднократно подымалась.
> >>
> >>
> >> Хорошо скажу по другому. Измерить скорость входящего потока от
> >> определённого ипа и если больше чем нужно то дропать пакеты пока не
> >> станет меньше.
>
> DT> можно через rate-limit в самом pf, там идет скорость пакетов
>
>
> Полистал только что ман по pf.conf.5 про количество пакетов в ед.
> времени ничего не увидел. Про количество стейтов и стейтов в ед.
> времени увидел, количество создаваемых стейтов с одного источника
> увидел. А вот проверки количества пакетов в ед.времени в одном уже
> созданном стейте
> не увидел. Направь в нужное русло.
Ошибся, я имел ввиду как раз max-src-conn-rate :)
>
--
Динар Талыпов
|
|
|
> i> Чтобы можнло было шейпить входящий поток и создавать динамические
> i> очереди
> Уж сколько раз твердили миру: шейпить уже принятое - глупо.
Твердили-то твердили... Но вот например сервак. 3-4-5 сетевух. 1-ая -
в локалку клиентов. 2-ая в индырнет. 3-я на game-серверы. 4-ая-5-ая
ещё куда (например второй индырнет и так далее).
Надо чтобы некие клиенты в/из локалки получали каждый суммарно не
больше чем 256/256 кбит (ну обычный какой-нить "безлимит 256"). Как и
где будем шейпить "восходящий"? А если без головняков?
> Если уж очень хочется - поставьте FreeBSD + Dummynet, будет Вам
> входящий шейп и динамические очереди с любыми масками.
Вот то-то и оно, что фрюшники ведь тоже не идиоты, ведь сделали,
пользуются. Потому что просто. Так что я бы не стал так категорично.
Грязный хак - засунуть чо-то своё в упомянутый ether_input например,
или уже в ipv4_input. Тока блин управление этим хаком нетривиальное.
Хотя Олег выкладывал примеры всяких там всячин.
--
engineer
|
|
|
On Wed, 13 May 2009 10:44:40 +0600
engineer < [hidden email]> wrote:
> > i> Чтобы можнло было шейпить входящий поток и создавать динамические
> > i> очереди
> > Уж сколько раз твердили миру: шейпить уже принятое - глупо.
>
> Твердили-то твердили... Но вот например сервак. 3-4-5 сетевух. 1-ая -
> в локалку клиентов. 2-ая в индырнет. 3-я на game-серверы. 4-ая-5-ая
> ещё куда (например второй индырнет и так далее).
>
> Надо чтобы некие клиенты в/из локалки получали каждый суммарно не
> больше чем 256/256 кбит (ну обычный какой-нить "безлимит 256"). Как и
> где будем шейпить "восходящий"? А если без головняков?
>
> > Если уж очень хочется - поставьте FreeBSD + Dummynet, будет Вам
> > входящий шейп и динамические очереди с любыми масками.
> Вот то-то и оно, что фрюшники ведь тоже не идиоты, ведь сделали,
> пользуются. Потому что просто. Так что я бы не стал так категорично.
>
> Грязный хак - засунуть чо-то своё в упомянутый ether_input например,
> или уже в ipv4_input. Тока блин управление этим хаком нетривиальное.
> Хотя Олег выкладывал примеры всяких там всячин.
навскидку можно просто в pf засунуть шейп по скорости пакетов по правилу, если конечно
скорость в pf'е уже мерится где нить :)
--
Динар Талыпов
|
|
|
> навскидку можно просто в pf засунуть шейп по скорости пакетов по правилу, если конечно
> скорость в pf'е уже мерится где нить :)
Так пакеты разных размеров бывают. Какой-нить ослоторент будет мелкими
пакетишками пуляться, мы их по количеству дропанём (исходя из
предположения 1500байтного пакета посчитали что "не больше стоко-то
пакетов" будет 256к), а клиент прибежит с криками что не 256, а всего
60 кбит у него прокачивается.
А в плане направления идеи ты скорее прав: надо pf хачить, там для
этого всё подготовлено - и конфиг с парсером, и так далее.
--
engineer
|
|
|
On Wed, 13 May 2009 11:54:12 +0600
engineer < [hidden email]> wrote:
> > навскидку можно просто в pf засунуть шейп по скорости пакетов по правилу, если конечно
> > скорость в pf'е уже мерится где нить :)
>
> Так пакеты разных размеров бывают. Какой-нить ослоторент будет мелкими
> пакетишками пуляться, мы их по количеству дропанём (исходя из
> предположения 1500байтного пакета посчитали что "не больше стоко-то
> пакетов" будет 256к), а клиент прибежит с криками что не 256, а всего
> 60 кбит у него прокачивается.
по идее TCP умный при дропе пакетов будет понижать скорость отправки :)
>
> А в плане направления идеи ты скорее прав: надо pf хачить, там для
> этого всё подготовлено - и конфиг с парсером, и так далее.
> --
> engineer
>
> !DSPAM:10,4a0a6097272713001712912!
>
>
> __________ NOD32 4065 (20090511) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com>
>
--
Динар Талыпов
т.+7(8555) 455810
ООО "Камател-Янтел"
|
|
|
Dinar Talypov wrote:
>>> навскидку можно просто в pf засунуть шейп по скорости пакетов по правилу, если конечно
>>> скорость в pf'е уже мерится где нить :)
>> Так пакеты разных размеров бывают. Какой-нить ослоторент будет мелкими
>> пакетишками пуляться, мы их по количеству дропанём (исходя из
>> предположения 1500байтного пакета посчитали что "не больше стоко-то
>> пакетов" будет 256к), а клиент прибежит с криками что не 256, а всего
>> 60 кбит у него прокачивается.
> по идее TCP умный при дропе пакетов будет понижать скорость отправки :)
Если в договоре с клиентом прописаны КБ/с, ограничение по количеству
пакетов, очевидно, неприемлемо :-)
|
|
|
On Wed, 13 May 2009 10:21:21 +0400
"Andrey N. Oktyabrski" < [hidden email]> wrote:
> Dinar Talypov wrote:
> >>> навскидку можно просто в pf засунуть шейп по скорости пакетов по правилу, если конечно
> >>> скорость в pf'е уже мерится где нить :)
> >> Так пакеты разных размеров бывают. Какой-нить ослоторент будет мелкими
> >> пакетишками пуляться, мы их по количеству дропанём (исходя из
> >> предположения 1500байтного пакета посчитали что "не больше стоко-то
> >> пакетов" будет 256к), а клиент прибежит с криками что не 256, а всего
> >> 60 кбит у него прокачивается.
> > по идее TCP умный при дропе пакетов будет понижать скорость отправки :)
> Если в договоре с клиентом прописаны КБ/с, ограничение по количеству
> пакетов, очевидно, неприемлемо :-)
в любом случае все существующие алгоритмы так или иначе оперируют с размерами очереди.
А в очереде что? пакеты. Соответсвенно задача по ограничению трафика сводится к ограничению скорости пакетов в первую очередь, что приводит в конечном счете к ограничению скорсти в кбитах и мбитах
--
Динар Талыпов
|
|
|
> в любом случае все существующие алгоритмы так или иначе оперируют с размерами очереди.
> А в очереде что? пакеты. Соответсвенно задача по ограничению трафика сводится к ограничению скорости пакетов в первую очередь, что приводит в конечном счете к ограничению скорсти в кбитах и мбитах
Я ленивый и редко смотрю код... но ведь в дополнение к пакетам
хранится их размер? в мбуфах он есть собсно, и по крайней мере на
входе в pf_test уже всё что надо - известно.
pf_test(int dir, struct ifnet *ifp, struct mbuf **m0, struct ether_header *eh)
{
...
struct mbuf *m = *m0;
...
...m->m_pkthdr.len... вот размер пакета (езернет как я полагаю)
...
h = mtod(m, struct ip *);
...
можно заюзать h->ip_len - вот и размер ip-пакета.
Так что мне _на первый взгляд_ кажется что суммировать не кол-во
пакетов а их размеры никакой сложности не представляет... Не подгоняя
под "существующие алгоритмы", а чисто так, обычным(и)
счётчиком-накопителем.
--
engineer
|
|
|
On Wed, 13 May 2009 14:25:25 +0600
engineer < [hidden email]> wrote:
> > в любом случае все существующие алгоритмы так или иначе оперируют с размерами очереди.
> > А в очереде что? пакеты. Соответсвенно задача по ограничению трафика сводится к ограничению скорости пакетов в первую очередь, что приводит в конечном счете к ограничению скорсти в кбитах и мбитах
>
> Я ленивый и редко смотрю код... но ведь в дополнение к пакетам
> хранится их размер? в мбуфах он есть собсно, и по крайней мере на
> входе в pf_test уже всё что надо - известно.
>
> pf_test(int dir, struct ifnet *ifp, struct mbuf **m0, struct ether_header *eh)
> {
> ...
> struct mbuf *m = *m0;
> ...
> ...m->m_pkthdr.len... вот размер пакета (езернет как я полагаю)
> ...
> h = mtod(m, struct ip *);
> ...
> можно заюзать h->ip_len - вот и размер ip-пакета.
>
> Так что мне _на первый взгляд_ кажется что суммировать не кол-во
> пакетов а их размеры никакой сложности не представляет... Не подгоняя
> под "существующие алгоритмы", а чисто так, обычным(и)
> счётчиком-накопителем.
> --
А причем тут размер пакета, собственно?
Ведь чтобы ограничить скорость надо пакет либо задержать в очереди,
либо его дропнуть не смотря на его размер.
--
Динар Талыпов
|
|
|
Hello engineer,
Wednesday, May 13, 2009, 7:44:40 AM, you wrote:
>> i> Чтобы можнло было шейпить входящий поток и создавать динамические
>> i> очереди
>> Уж сколько раз твердили миру: шейпить уже принятое - глупо.
e> Твердили-то твердили... Но вот например сервак. 3-4-5 сетевух. 1-ая -
e> в локалку клиентов. 2-ая в индырнет. 3-я на game-серверы. 4-ая-5-ая
e> ещё куда (например второй индырнет и так далее).
e> Надо чтобы некие клиенты в/из локалки получали каждый суммарно не
e> больше чем 256/256 кбит (ну обычный какой-нить "безлимит 256"). Как и
e> где будем шейпить "восходящий"? А если без головняков?
>> Если уж очень хочется - поставьте FreeBSD + Dummynet, будет Вам
>> входящий шейп и динамические очереди с любыми масками.
e> Вот то-то и оно, что фрюшники ведь тоже не идиоты, ведь сделали,
e> пользуются. Потому что просто. Так что я бы не стал так категорично.
e> Грязный хак - засунуть чо-то своё в упомянутый ether_input например,
e> или уже в ipv4_input. Тока блин управление этим хаком нетривиальное.
e> Хотя Олег выкладывал примеры всяких там всячин.
В оргинальном altqd это делал кондиционер с дропером. И динамические
очереди ещё можно было содавать и не писать дофига правил. Тут дофига
отличных програмистов которые могут исправить эти два упущения. Тем
более что кондиционер уже есть в ядре опёнка нужно только pf науить
его понимать
--
Best regards,
irix mailto: [hidden email]
|
|
|
>> Так что мне _на первый взгляд_ кажется что суммировать не кол-во
>> пакетов а их размеры никакой сложности не представляет... Не подгоняя
>> под "существующие алгоритмы", а чисто так, обычным(и)
>> счётчиком-накопителем.
> А причем тут размер пакета, собственно?
> Ведь чтобы ограничить скорость надо пакет либо задержать в очереди,
> либо его дропнуть не смотря на его размер.
Не, ну как так. Ну мне надо ограничить "пропускную способность", то
есть дать пресловутые 256/256к в секунду. Независимо от количества
поступающих пакетов.
Пускай под этими мы будем понимать уже IP уровень, то есть 256/256к
байт (IP пакетов).
И выберем пока простое - пакеты дропаются по превышении того-то.
Мне не важно, рвутся ли сессии при этом или ещё что, неважно как там
TCP может регулировать скорость и так далее. Мне важно не дать клиенту
прокачать через меня больше чем те "256/256 к в секунду" за которые он
мне заплатил. А клиент уже пусть полагается на то, что TCP учтёт
потери и снизит скорость.
Грубый план.
Чтобы реализовать это дело я беру размер каждого поступающего
(входящего) пакета и добавляю его к счётчику. Ну, скажем, счётчик этот
сбрасывается раз в секунду. Или в несколько секунд, ну неважно для
понимания (важно для реализации).
Далее, в течение этой длящейся секунды, до тех пор пока не накопится
тех 256килобайт ничо не делается, пакеты (входящие) идут как шли. Как
накопилось - все новые пакеты (входящие) дропаются, и так до конца
этой длящейся секунды. Через секунду счётчик обнуляется - снова пошли
пропускать пакеты (входящие) и добавлять их размер в счётчик.
Это если для исходящих отдельно применять стандартные средства altq.
Но уж если мутить указанный план, и вообще в целях унификации, по уму
надо бы сделать 2 счётчика - для входящих и для исходящих пакетов. И
считать их размер и дропать их независимо.
P.S. не вижу как это выразить через количество пакетов в секунду (их
размеры могут меняться).
--
engineer
|
12
|
Locked
