|
|
Дмитрий ГлотиковСтаж: 11 лет 7 месяцевОткуда: Московская биржаСообщений: 590 | | | | Уважаемые коллеги,
По вашим просьбам, в подсистеме контроля флуда сделаны следующие изменения:
1. Разделено понятие торговых и неторговых операций.
К торговым операциям относятся все операции с заявками, к неторговым - все остальные.
Ограничения 30 или 150 операций в секунду теперь относятся только к торговым операциям.
Неторговых операций можно сделать 500 в секунду.
2. Сделано отдельное сообщение-ответ с информацией о параметрах задержанных флуд-контролем сообщений польхователя:
P2_Type = 99,
queue_size i4 Количество сообщений в очереди для данного пользователя
penalty_remain i4 Время в миллисекундах, по прошествии которого будет успешно принято следущее сообщение от этого пользователя
message c128 Текст сообщения об ошибке
Соответствующий раздел добавлен в документацию:
ftp://FTP.RTS.RU/pub/FORTS/test/Plaza2/forts_p2gate_public.doc
Выложены новые схемы сообщений:
ftp://FTP.RTS.RU/pub/FORTS/test/Plaza2/Scheme/p2fortsgate_messages.ini
Изменения доступны в тестовой системе.
Изменения доступны в production-системе с 6го сентября 2010г.
| | |
|
NorvadСтаж: 8 лет 6 месяцевСообщений: 10 | | | | Относится ли к неторговой операции заявка на которую отвечено SQL Proxy Flood control?
Что вообще такое неторговая операция?
| | |
|
reaperСтаж: 8 летСообщений: 206 | | | | Неторговая операция, например, FutChangeClientMoney, как я понимаю.
Значит механизм (P2_Type = 100) + (code = 10001) совсем упразднен?
| | |
|
reaperСтаж: 8 летСообщений: 206 | | | | При асинхронных командах это вряд ли поможет. Все равно нужен контроль на своей стороне.
| | |
|
Alexander56Стаж: 8 лет 1 месяцОткуда: ОренбургСообщений: 218 | | | | | denis5 писал(а): |
А почему в в ответе на присланное сообщение (любое) не выдавать число сообщений, на которые еще есть лимит? Так было бы проще оценить вероятность попадания на флуд и притормозить посылку сообщений на своей стороне |
+1
Писал то же самое. penalty_remain конечно полезно, а вот queue_size при срабатывании флуд-контроля и так понятно, что будет равно длине очереди.
ps. или queue_size в ответном сообщении будет больше, чем 30 (150)?
| | | | | | | Последний раз редактировалось автором 03.08.2010 13:26, всего редактировалось 2 раза |
|
reaperСтаж: 8 летСообщений: 206 | | | | Мне кажется это те же яйца, только может иногда и сбивать с толку. И скорее всего собственный алгоритм флуда заметно усложнится. Ну а если так нужно, то к бирже вопрос, да, может и сделают на радость людям. То, что дают время необходимого ожидания при промахе, это да, весчь. Не надо огород городить и придумывать свои задержки.
| | |
|
reaperСтаж: 8 летСообщений: 206 | | | | | Alexander56 писал(а): |
ps. или queue_size будет больше, чем 30 (150)? |
По идее как раз может быть меньше... от 30(150) до нуля....
| | |
|
Alexander56Стаж: 8 лет 1 месяцОткуда: ОренбургСообщений: 218 | | | | | reaper писал(а): |
По идее как раз может быть меньше... от 30(150) до нуля.... |
конечно, меньше оно быть может, но мы этого не узнаем, пока не получим P2_Type = 99!
| | |
|
reaperСтаж: 8 летСообщений: 206 | | | | Ну да. А на что оно нам раньше? Я и так знаю сколько я отправил в данный момент и сколько пришло ответов. Так что размер очереди я примерно знаю и что мне даст число, которое прийдет в ответном сообщении, да еще и неизвестно когда пришло? Ну вообщем не знаю... мне оно как-то не нужно, только путает и усложняет...
| | |
|
reaperСтаж: 8 летСообщений: 206 | | | | А мне и не надо знать сколько попало, мне надо знать сколько я отправил в последнее текущее скользящее секундное окно. И я это знаю. Но я не знаю распределение моих заявок в течении этого окна и не хочу его рассчитывать. Также предполагается более или менее стабильный канал связи, можно вводить настройками некоторые допущения, но реальное состояние канала мне тоже не известно. Так вот и распределение и состояние канала фактически будет учтено во времени пенальти. Это надежно и достаточно чем самому изобретать хитроумные анализаторы. Пока я не вижу, что их результат даст лучшие результаты. Может у вас есть алгоритм как эту всю информацию увязать при всех возможных ситуациях?
| | |
|
reaperСтаж: 8 летСообщений: 206 | | | | Да я и не против, в принципе, если так надо, то используйте конечно. Мне эти данные точно мешать не будут))
Вопрос только остается в том, предоставит ли биржа эти данные?
| | |
|
reaperСтаж: 8 летСообщений: 206 | | | | | denis5 писал(а): | | скажем отправили 25 сообщений и получили отклил что лимит позволяет отправить еще только 2 (а не 5 как вы думаете), поскольку 3 сообщения пришли с опозданием и были засчитаны биржей как отправленные в эту секунду, значит надо притормозить |
Не очень понял пример, если честно.
| | |
|
Alexander56Стаж: 8 лет 1 месяцОткуда: ОренбургСообщений: 218 | | | | | reaper писал(а): | | Это надежно и достаточно чем самому изобретать хитроумные анализаторы. |
Ниче изобретать не нужно, просто моделировать флуд-контроль на основае не только своих данных, но и данных, поступающих от биржи. Такой флуд-контроль будет максимально возможно учитывать задержки сети, будет более похож та тот, который фактически работает на стороне биржи.
| | |
|
reaperСтаж: 8 летСообщений: 206 | | | | Если вы считаете, что искажения, которые сильно меняют картину моделируемую нашим флуд-контролем не будут оказывать такого же влияния на информацию в ответных сообщениях, используемую для дальнейшего принятия решений по отправке, то это ваше право и ваш алгоритм поведения. Меня больше устраивает работать по факту отказа в обслуживании при расхождении модели и реальности, при том что мне дается достоверная информация о времени возобновления обслуживания.
| | |
|
reaperСтаж: 8 летСообщений: 206 | | | | | Alexander56 писал(а): | | Ниче изобретать не нужно, просто моделировать флуд-контроль на основае не только своих данных, но и данных, поступающих от биржи. Такой флуд-контроль будет максимально возможно учитывать задержки сети, будет более похож та тот, который фактически работает на стороне биржи. |
С этим готов согласиться, только мне не кажется, что эти данные от биржи будут отражать достоверную картину происходящего.
| | |
|
|
Поиск
Правила
Пользователи
Профиль
Регистрация
Вход
