DOM цитирует по глубине Delta-кавычки - кто-нибудь идея?

Question

Хорошо, поехали.Это хитрый.Финансовый рынок.

У меня есть торговое приложение, изначально разработанное для Rithmic API.По разным причинам я сейчас перевожу данные в реальном времени на NxCore.

RIthmic не имеет понятия "уровни DOM".Я получаю сообщения за каждую цитату с объемом, ценой.Если цитата становится недействительной, она получает 0 том.Работает хорошо ....

NxCore работает с уровнями.Я получаю разные сообщения для каждого уровня (D1 - D10).

Проблема в том, что мне нужно перейти от этого к RIthmic представлению, не отправляя слишком много ошибок / лишних сообщений.

В основном, isue выглядит так:

Мы устанавливаем DOM - просто игнорируем элементы здесь.Интересно D1 8 @ 11417

CBOT/YM.Z10 MM D2: 17 @ 11416 vs 10 @ 11421
CBOT/YM.Z10 MM D3: 10 @ 11415 vs 14 @ 11422
CBOT/YM.Z10 MM D5: 13 @ 11413 vs 13 @ 11424
CBOT/YM.Z10 MM D4: 17 @ 11414 vs 12 @ 11423
CBOT/YM.Z10 MM D9: 12 @ 11409 vs 12 @ 11428
CBOT/YM.Z10 MM D10: 14 @ 11408 vs 14 @ 11429
CBOT/YM.Z10 MM D5: 13 @ 11413 vs 16 @ 11424
CBOT/YM.Z10 MM D6: 20 @ 11412 vs 11 @ 11425
CBOT/YM.Z10 MM D1: 8 @ 11417 vs 3 @ 11420
CBOT/YM.Z10 2010-12-14 05:00:20.275000 BestBid 8 @ 11417

Something happens to he BestBid here..... so now it goes to 11418

CBOT/YM.Z10 MM D1: 3 @ 11418 vs 3 @ 11420
CBOT/YM.Z10 MM D2: 10 @ 11417 vs 10 @ 11421
CBOT/YM.Z10 MM D3: 17 @ 11416 vs 14 @ 11422
CBOT/YM.Z10 MM D4: 10 @ 11415 vs 12 @ 11423
CBOT/YM.Z10 MM D5: 16 @ 11414 vs 16 @ 11424
CBOT/YM.Z10 MM D6: 13 @ 11413 vs 11 @ 11425
CBOT/YM.Z10 MM D7: 17 @ 11412 vs 6 @ 11426
CBOT/YM.Z10 MM D8: 12 @ 11411 vs 5 @ 11427
CBOT/YM.Z10 MM D9: 18 @ 11410 vs 12 @ 11428
CBOT/YM.Z10 MM D10: 12 @ 11409 vs 14 @ 11429
CBOT/YM.Z10 2010-12-14 05:00:30.325000 BestBid 3 @ 11418

And that gives ups 10 updates just to move the DOM on the bid side. What I would need here is 2....
0 @ 11417
18 @ 11409

Каждая строка представляет собой отдельный обратный вызов в мой код (или событие, если вы хотите использовать этот термин).Я уже знаю, что мне нужно сохранить что-то вроде буфера (D1 - D10 с обеих сторон, бид и аск, с ценой, уровнем и объемом).Моя главная проблема - все крайние случаи.Когда объем меняется, тот же уровень DOM, та же цена - просто.

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

Любойидея?Также обратите внимание, что D1 - D10 не обязательно обрабатывают следующие 10 цен - иногда (в нерабочее время) есть пробелы ...., что делает ДЕЙСТВИТЕЛЬНО неприятными.Я вроде знаю, что если я получу D1 или D10, я могу выбросить все предметы, о которых сообщают, «дальше по линии».Но моя проблема в основном из-за пробелов ...

О, и это должно быть быстро.Как 200.000 сообщений в секунду иногда.

Кто-нибудь умная идея?

Answer 1

Если я вычислю это право: 2000 уровней * 8000 символов * 4 байта (размер) * 2 (bid / ask) = 256 МБ

Нет проблем с современными компьютерами.

Возможно 2Размер в байтах также будет выполнять работу, которая сократит его до 128 МБ.

(Кстати, если я правильно понимаю, задача состоит в том, чтобы проследить весь мир американских акций через NxCore)

Answer 2

Приготовьте лестницу DOM для каждого символа, за которым вы следуете (два отдельных массива, один для ставки, один для запроса).

Этот размер должен быть достаточно большим, чтобы можно было ожидать любую волатильность. Обычно 2000 уровней наверняка хватит на один день. Нет проблем с современными компьютерными воспоминаниями, даже если вы следуете нескольким символам одновременно.

Когда событие DOM приходит просто - обновить объем на соответствующем уровне цен - обновить индекс текущей внутренней заявки или спросить (если эта информация поступает также с событием)

Другими словами, игнорируйте информацию о «уровне DOM», просто запишите том в соответствующее место.

Можно с уверенностью предположить, что в DOM нет «дыр», уровни всегда расположены на расстоянии одного тика (это видно на вашем примере).

Надеюсь, я изложил эту идею достаточно ясно. Если нет, не стесняйтесь спрашивать.