«Одним сетевым интерфейсом сервер смотрит на специально выделенный для скоростных роботов пул наших серверов доступа, а вторым интерфейсом – в Интернет – это так называемый управляющий канал, предназначенный для обслуживания робота» — под интерфейсом подразумеваются VLAN? в общем случае сейчас ведь задействованно 2 сетевых интерфейса для LACP поверх которых идёт всё — и интернет и торговля. конечно можно брать 4 интерфейса — 2 для торговли, и для для интернет, но это будет немножко дороже по деньгам, да и в сервере не всякий раз имеется 4 порта.

Когда можно ожидать что FIX на срочке по скорости сравняется с cgate?

Через 2 года какой способ подключения планируется быть более быстрым, бинарный протокол или cgate? Кстати про бинарный протокол расскажите тоже :)
Приветствуем! :) Ответим по пунктам:
  1. Тут подразумевается, что принимающий интерфейс (коммутаторы в зоне колокации, в которые подключается сервер/сетевое оборудование участника) в сторону торговой системы и управляющий интерфейс (который смотрит в интернет и через который можно управлять сервером) это суть разные вещи. Формально комментирующий прав – на сервере в общем случае две сетевых карты, которые собраны в teaming и через которые идет весь трафик
  2. В силу архитектурного устройства системы FIX на срочном рынке вряд ли когда-нибудь будет быстрее CGate, но мы надеемся, что в ближайший год его latency будет планомерно улучшаться.
  3. Бинарный протокол, но об этом мы будем рассказывать подробнее позже, после выдачи данного протокола в публичный тест.

Спасибо. По пункту 2 ещё было бы интересно знать в граммах в микросекундах насколько биржа дольше обрабатывает FIX постановку заявку, чем cgate. Ведь клиент имеет возможность по фиксу транзакции ставить ощутимо быстрее (поскольку нет надобности запускать роутер) и возможно планомерное ускорние fix на стороне бирже приведёт к суммарной задержке «клиент + сервер» для фикса меньшей, чем для cgate.
Фикс гейт медленнее CGate на время конвертации фикс сообщения в формат Plaza-2, который является внутренним форматом торговой системы, это время составляет сейчас в районе 50-70 мкс на транзакцию. В то же время обработка сообщения в роутере на стороне клиента занимает, в общем случае, 10-30 мкс. В связи с этим улучшить время RTT заявки через фикс – можно, и мы над этим работаем, но обогнать CGate пока не представляется возможным.
50-70 — это очень много

грамотно написанный С++ фикс парсер должен меньше 10-ки давать
Зачем вообще вы тащите этот архаичный FIX? Не кривите душой и не называйте это протоколом или стандартом. Нет в мире двух бирж, которые использовали бы совместимые реализации FIX. Это просто некий способ кодирования полей и значений. Способ дурацкий, надо заметить, так как в нём все кодируется тестом, и, очевидно, является пережитком времен прямого модемного подключения к биржам.
Формально это всё-таки протокол, имеющий спецификации и версионность. Но протокол этот определяет не формат контента, а скорее транспортный уровень. Протокол сам по себе довольно широкий, потому многие биржи его заимствуют не полностью или берут только что-то прикладное. К тому же у каждой биржи своя специфика инструментов и торгов, поэтому вполне логично, что у каждой есть свои нюансы, несовместимые с другими. И опять же, наличие особенностей реализации и специфики есть и в других международных стандартах (ISO).

Наличие бинарного протокола именно в этом плане задачу не облегчит. Текст может и считаться архаикой, но например ITCH – это тоже вещь достаточно специфическая. А что рекомендуете вы?

Поддержка FIX’a, как показывает наша практика, позволяет частным клиентам максимально быстро разработать софт с нуля и выйти на рынок – за счёт его простоты, наличия библиотек и независимых ресурсов, где можно почитать туториалы или получить помощь сообщества. А у большинства крупных зарубежных банков/брокеров FIX считается стандартом де-факто и имеется солидный опыт в его использовании — если имеешь цель сделать фиксовый продукт с подключением ко многим биржам, наличие протокола делает задачу проще — вместо того, чтобы изучать совершенно разные протоколы каждой отдельной биржи, проще адаптировать свое FIX-решение к реалиям конкретной биржи.

> Наличие бинарного протокола именно в этом плане задачу не облегчит.

Вы противоречите сами себе: почему вы собираетесь заменить Plaza2 на бинарный протокол, а не довести до совершенства связку FIX/FAST? )
Переход на бинарный протокол обусловлен тем, что особенности его реализации позволяют сделать данный протокол максимально близким по структуре к внутреннему протоколу ТС Спектра ( в отличие от протокола FIX) и тем самым обеспечить максимальное быстродействие протокола внутри с отсутствием библиотек на стороне клиента. При этом работы по усовершенствованию связки FIX/FAST все равно ведутся.
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.