Перейти к содержимому
Калькуляторы

Размазать входящие пакеты (pps rate limit)

Други, подскажите как сделать. Есть входящие пакеты определенного типа, конкретно SIP INVITE. Их я могу выцепить iptables'ом.

Нюанс в том, что они прилетают кучей, к примеру сразу штук 20, а потом тишина. Получается 20 pps. А мне надо получить 5 pps, не прибегаю к дропу пакетов, а лишь придержав их через lanetcy, т.е. обработать за 4 секунды.

Как такое реализовать в Linux?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это шейпинг, в линуксах используется tc.

Но такое обычно решают через QoS, если речь за качество связи.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, morfair сказал:

Други, подскажите как сделать. Есть входящие пакеты определенного типа, конкретно SIP INVITE. Их я могу выцепить iptables'ом.

Нюанс в том, что они прилетают кучей, к примеру сразу штук 20, а потом тишина. Получается 20 pps. А мне надо получить 5 pps, не прибегаю к дропу пакетов, а лишь придержав их через lanetcy, т.е. обработать за 4 секунды.

Как такое реализовать в Linux?

Сип лучше дропать чем буферизовать, алло.

Даже инвайты.

Нахера так делать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
12 hours ago, GrandPr1de said:

Сип лучше дропать чем буферизовать, алло.

Даже инвайты.

Нахера так делать?

Уже пробовал сделать DROP'ами, т.к. рассуждал, что UDP, всё равно еще пакет пришлет... В итоге стали жаловаться клиенты, что долго тишина в трубке, потом сброс.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
22 часа назад, morfair сказал:

Как такое реализовать в Linux?

А зачем, если не секрет?

Тут на L7 надо выходить - ставить "прокси", на запрос отвечать Trying (первое плечо), чтобы не было ретрансмитов, на сервер отправлять INVITE (второе плечо) с выравненным рейтом.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
On 10/10/2018 at 5:50 PM, TheUser said:

А зачем, если не секрет?

Тут на L7 надо выходить - ставить "прокси", на запрос отвечать Trying (первое плечо), чтобы не было ретрансмитов, на сервер отправлять INVITE (второе плечо) с выравненным рейтом.

 

А есть пример такого прокси?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 минуты назад, morfair сказал:

А есть пример такого прокси?

Может быть на базе OpenSER/Kamailio можно накостылить.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 час назад, morfair сказал:

А есть пример такого прокси?

freeswitch +  application limit_execute + LUA script

 

в скрипте выставите задержку для INVITE  session:execute("set", "originate_retry_sleep_ms=500");    https://freeswitch.com/confluence/pages/viewpage.action?pageId=16353306

 

для freeswitch еще один вариант думаю может сработать, - зациклить вызов через тот же самый extension контекста диалплана, но в скрипте просто чутка заснуть - чтобы не подвесить freeswitch

т.е. вызов крутится в цикле пока pps не уменьшится до Ваших 5

Изменено пользователем QWE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И всё-таки я подтянул Kamailio к своей этой задаче.

 

Прямо перед отправкой в под-роутер DISPATCH (dispatcher на FreeSWITCH) сделал вот такой приём:

if ( is_method("INVITE") ) {
	# https://kamailio.org/docs/modules/3.3.x/modules_k/cfgutils.html#idp1794224
	$var(delay) = ($RANDOM / 1048576 * 1000); # 2 ** 20 = 2048
	#xlog("L_DBG","INVITE SLEEP: $var(delay)\n");
	sl_send_reply("100", "Trying, sleep $var(delay)");
	t_set_auto_inv_100(0); # turn off automatic 100 replies
	usleep("$var(delay)"); # waits "time" micro-seconds.
}

 

И ситуация стала намного лучше!! Т.е. я придерживаю INVITE перед проксированием на рандомное время в 0 до 2000 мс и CPS у меня как-то размазываются.

 

Но у меня серьезный вопрос!! Функция usleep() в Kamailio блокирующая или нет? Т.е. у меня весь children тупо висит в бесконечном цикле указанное кол-во micro-seconds, или способен выполнять работу по другим соединениям??

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
В 06.02.2019 в 14:01, morfair сказал:

И всё-таки я подтянул Kamailio к своей этой задаче.

 

Прямо перед отправкой в под-роутер DISPATCH (dispatcher на FreeSWITCH) сделал вот такой приём:


if ( is_method("INVITE") ) {
	# https://kamailio.org/docs/modules/3.3.x/modules_k/cfgutils.html#idp1794224
	$var(delay) = ($RANDOM / 1048576 * 1000); # 2 ** 20 = 2048
	#xlog("L_DBG","INVITE SLEEP: $var(delay)\n");
	sl_send_reply("100", "Trying, sleep $var(delay)");
	t_set_auto_inv_100(0); # turn off automatic 100 replies
	usleep("$var(delay)"); # waits "time" micro-seconds.
}

 

И ситуация стала намного лучше!! Т.е. я придерживаю INVITE перед проксированием на рандомное время в 0 до 2000 мс и CPS у меня как-то размазываются.

 

Но у меня серьезный вопрос!! Функция usleep() в Kamailio блокирующая или нет? Т.е. у меня весь children тупо висит в бесконечном цикле указанное кол-во micro-seconds, или способен выполнять работу по другим соединениям??

и freeswitch у Вас и kamailio, зачем столько софта?

у fs (у библитеки sofia) многопоточность для каждого вызова, lua скрипт выставялет задержку по типу переменной окружения linux bash для момента отправки INVITE. никакой блокировки не будет, за исключением к.м.к на время выполнения lua скрипта, ну и она эта "блокировка"  как бы нужна чтобы корректно детектить текущий pps SIP INVITE. предполагается что lua скрипт не вызывает sleep. Только делает расчеты и передает вычисленное значение задержки в sofia

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас