Замедление количества FIX-сообщений, отправляемых в секунду, чтобы удовлетворить требования поставщика по регулированию

Я отправляю заказы поставщику через протокол FIX. Поставщик будет принимать только 100 FIX-сообщений в секунду и попросил меня ограничить отправляемые им заказы, чтобы они не превышали эту скорость. Я уверен, что могу написать что-нибудь, чтобы замедлить отправляемые им сообщения, подобно тому, что я нашел здесь: Дросселирование вызовов метода для M запросов за N секунд

Но у меня есть два вопроса:

Я хотел бы знать, является ли замедление скорости сообщений, отправляемых поставщику исполнения или клиринговой фирме, обычным требованием в отрасли, или это тревожный сигнал, что я имею дело с поставщиком хлама?

Есть ли какой-то параметр, чтобы QuickFix/J автоматически замедлял пропускную способность сообщений для меня?


quickfix fix-protocol quickfixj
person birkner    schedule 07.03.2014    source источник
comment
Я никогда не слышал о таком требовании регулирования, и моя компания проделала немало работы по FIX.   -  person Grant Birchmeier    schedule 08.03.2014
comment
Кажется довольно странным, что они просят клиентов регулировать скорость сообщений. Что произойдет, если вы превысите норму? Есть ли ограничение на размер сообщения?   -  person Jason    schedule 08.03.2014
comment
Это первый раз, когда я слышу это. Люди пытаются сделать это быстрее, а не медленнее. Насколько я помню, QuickFix/J не позволяет регулировать его, возможно, вам придется сделать это самостоятельно.   -  person DumbCoder    schedule 08.03.2014
comment
CQG имеет максимальную скорость по умолчанию 10 ордеров в секунду... и если она превышена, она отклоняет ордер с превышенной скоростью действия ордера.   -  person Brian Rice    schedule 28.12.2016

Ответы (2)


arrow_upward
2
arrow_downward

Есть много систем, которые испытывают трудности с обработкой больших объемов заполнения. Скорее всего, это не связано с пропускной способностью сети, а с базовой обработкой сообщений на прикладном уровне.

Например, некоторые старые системы полагаются на реляционную базу данных с блокировкой таблиц, и если выполнение выполняется в больших объемах, у всей системы управления заказами могут возникнуть проблемы с производительностью.

Решение грубой силы состоит в том, чтобы заставить провайдера выполнения либо свернуть выполнение, либо задушить его.

person TheFIXGuy    schedule 24.03.2014

arrow_upward
2
arrow_downward

Это связано с тем, что поставщик имеет ограниченную пропускную способность и, вероятно, подключаются десятки или сотни клиентов. Если вы запрашиваете цены, скажем, для 100 инструментов, и на спокойном рынке все они обновляются один раз в секунду, то на одно соединение FIX поставщику приходится иметь дело со 100 сообщениями в секунду. ОК, хорошо, сообщение FIX о том, сколько байтов: скажем, 500 символов по 1 байту на символ = 500 байт (кто-то поправит меня здесь). Итак, 500 * 100 = 50 000 байт в секунду на соединение.

Затем подключите 100 клиентов = 5 000 000 байт в секунду. Хм, еще много места.

Но на оживленном рынке, когда котировки обновляются 10 или 20 раз в секунду. Цифры умножаются на коэффициент 10 или 20. Вы получаете сетевые штормы, длинные очереди сообщений, высокую загрузку процессора, потерянные сообщения или все это просто выходит из строя. Тогда поставщик потеряет весь свой бизнес, потому что не сможет оставаться на связи в самые критические моменты.

Хорошо, вероятно, есть много решений этой проблемы, но это описание проблемы, которую необходимо решить...

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

person rupweb    schedule 10.03.2014
comment
Конечно, с биржами, как у маркет-мейкера, у вас может быть контракт, по которому вы платите бирже за право котировки, а взамен они дают вам «мощность» в котировках в секунду. - person user1717259; 10.03.2014