Очередность срабатывания OnTransReply, OnOrder, OnTrade

Страницы: 1
RSS
Очередность срабатывания OnTransReply, OnOrder, OnTrade
 
Вопрос в первую очередь к разработчикам, так как тесно связан с особенностями функционирования сервера QUIK.

Ранее группа поддержки уже упоминала о том, что возможна ситуация, когда сообщение об исполнении заявки - т.е. вызов OnTrade - поступит раньше, чем ответ на заявку - т.е. вызов OnTransReply. По данной теме одно существенное замечание: заявки выставляются клиентом ТОЛЬКО через программный уровень - т.е. через Lua-скрипт.

По логике последовательность вызовов должна быть жесткой:
OnTransReply --> OnOrder --> OnTrade (***).
Однако, замечание группы поддержки говорит, что возможны исключения из общих правил. Поэтому задаю главный вопрос:

в каких случаях может измениться порядок прихода с сервера и отработки терминалом callback-вызовов в сравнении с указанной очередностью (***)?
Если порядок прихода на терминал вызовов изменяется, то какова будет действительная очередность?
Прошу указать все возможные варианты при штатной работе терминала и сервера, т.е. при отсутствии обрывов связи терминала с сервером, сервера с биржей либо падения сервера/терминала.
 
И еще один вопрос также к разработчикам.

Если я правильно понимаю, то в ситуации с несколькими вызовами OnOrder и OnTrade на данный момент картина такая:
1) Приходит запись с биржи, в которой пользователя идентифицирует только client_code. Информация о пользовательском номере транзакции trans_id и идентификаторе пользователя uid (код рабочего места в нумерации конкретного брокера) хранится на сервере QUIK у брокера и на биржу при выставлении заявки не отправляется. Соответственно, этих параметров в записи, пришедшей на сервер QUIK с биржи, нет.
2) Сервер QUIK сразу же отправляет запись, пришедшую с биржи, пользователю в соответствии с имеющимся в биржевой записи параметром client_code - по ВСЕМ кодам uid рабочих мест клиента, зарегистрированных у данного брокера. Для обычных - не корпоративных - пользователей такой uid обычно один, в связи с тем, что немногие пользователи - физические лица работают сразу с двумя и более рабочими местами. Но для корпоративных клиентов брокера наличие нескольких рабочих мест и, соответственно, нескольких uid - дело обычное.
3) После отправки биржевой записи, детализированной только в части кода клиента client_code, сервер QUIK проводит поиск по своей базе данных, где определяет какому uid соответствует пришедшая биржевая запись, и уже по реестру заявок с этого uid, находит нужную, соответствующую пришедшей биржевой записи, берет из нее дополнительно trans_id, flags и какие-то еще специфические для сервера и терминала данные, вставляет их в ту самую пришедшую с биржи запись и отправляет ее пользователю с client_code на уже один конкретный, а не на все пользовательские как при первой отправке, uid, при этом в отправляемой клиенту записи стоит trans_id, в случае, если таковой параметр был задан пользователем изначально - т.е. при отправке транзакции через программный уровень, либо поле trans_idстоит равным 0, если заявка изначально была отправлена, к примеру, вручную с терминала.
4) В результате к пользователю приходит следующий комплект:
- ОДНА запись, приводящая к ОДНОМУ вызову OnTransReply(), если транзакция передавалась программным способом;
- ДВЕ записи, приводящие к ДВУМ вызовам OnOrder() при каждом изменении состояния заявки на бирже;
- ДВЕ записи, приводящие к ДВУМ вызовам OnTrade() при получении с биржи каждой новой сделки пользователя (пусть и в результате частичного исполнения исходной заявки);
- ОДНА или более записей, приводящих к ОДНОМУ или более вызовам OnTrade(), если состояние конкретной сделки изменилось в результате записи, пришедшей с биржи, либо в результате изменения на сервере QUIK у брокера - как в результате действий самого брокера, так и в результате внутренних процессов сервера QUIK.

Посему и вопросы к разработчикам:
1) Может ли OnTransReply() быть вызван ДВА раза? Если да, то в каких случаях?
2) Может ли OnOrder() быть вызван ТРИ раза или более? Если да, то в каких случаях?
3) Какое максимальное количество вызовов OnTrade() может быть совершенно в условно отдельный момент обработки информации о новой сделке (биржевая запись + информационные преобразования на сервереQUIKу брокера)?
4) Планируется ли, возможно ли увеличение в обозримом будущем количества вызовов указанных QLUA-функций^ OnTransReply(), OnOrder(), OnTrade()?

Все изложенное мною и все заданные вопросы относятся ТОЛЬКО к штатной работе терминала и сервера QUIK.
Ситуации падения терминала, падения сервера QUIK, проблем со связью, с работой брокера либо с работой биржи - просьба НЕ РАССМАТРИВАТЬ.
 
Добрый день.

Цитата
Может ли OnTransReply() быть вызван ДВА раза? Если да, то в каких случаях?
Нет, одна транзакция - один ответ.

Цитата
Может ли OnOrder() быть вызван ТРИ раза или более? Если да, то в каких случаях?
OnOrder вызывается не только когда заявка приезжает, но и при любых
других изменениях относящихся к заявке. Речь не только про изменения
видимых параметров, есть еще и служебные параметры. Например, в
ситуации когда ответ на транзакцию приезжает позже тела транзакции.
Или случае, когда заявка исполняется несколькими сделками.

Цитата
3) Какое максимальное количество вызовов OnTrade() может быть совершенно в условно отдельный момент обработки информации о новой сделке (биржевая запись + информационные преобразования на сервереQUIKу брокера)?
В теории сколько угодно.

Цитата
4) Планируется ли, возможно ли увеличение в обозримом будущем количества вызовов указанных QLUA-функций^ OnTransReply(), OnOrder(), OnTrade()?
Пока информации нет.

Цитата
По логике последовательность вызовов должна быть жесткой:  OnTransReply --> OnOrder --> OnTrade (***).
Да, верно. Однако могут приходить  в любом порядке. Заранее нельзя быть уверенным в порядке срабатывания.
 
Andrei2016, можно ещё почитать обсуждение по этой ссылке:
https://forum.quik.ru/messages/forum10/message11805/topic940/#message11805
 
_sk_,
спасибо за ссылку, ознакомился.
 
Egor Zaytsev,

прошу дать ответы еще на ряд вопросов:

5) Правильно ли изложена мною схема взаимодействия сервера QUIK у брокера и рабочего места пользователя в пунктах 1, 2 и 3 в моем сообщении #2? Если есть какие-то неточности или ошибки, равно как и дополнения, прошу изложить.
6) Относительно вашего ответа на вопрос по функции OnOrder().
  Если мы рассматриваем  в качестве условного отдельного момента времени изменение состояния заявки, то я вижу возможность наступления такого изменения в следующих случаях:
6.1) произошло изменение состояния заявки на бирже и пришла очередная запись с биржи (заявка только что зарегистрирована, заявка частично исполнена, заявка снята и другие варианты биржевых результатов);
6.2) произошло изменение состояния заявки на сервере QUIK в результате действий брокера (изменились флаги состояния, проведена переоценка возможности дальнейшего исполнения заявки и изменились "правила" брокера и т.п.);
6.3) произошло изменение состояния заявки на сервере QUIK в результате внутренних процессов и преобразований самого сервера QUIK как программного комплекса.
  Можно ли уверенно сказать, что при любом подобном - "удельном" - изменении состояния заявки функция OnOrder() будет вызвана НЕ БОЛЕЕ ДВУХ раз? Если это не так, то прошу указать, какое максимальное количество вызовов OnOrder(), относящихся к одному конкретному изменению состояния заявки может произойти.
7) Может ли вызов OnTrade() придти раньше вызова OnOrder() по одной и той же заявке? Прошу прокомментировать случаи:
7.1) заявка только что зарегистрирована торговой системой биржи;
7.2) произошло очередное частичное исполнение заявки;
7.3) произошло изменение состояния сделки на бирже.
 
Дополнительно еще один вопрос к разработчикам:

возможна ли в штатном режиме работы ситуация, когда ответный вызов OnTransReply() на отправленную программным образом заявку не поступит вовсе? Если да, то прошу пояснить в каких конкретно случаях такое возможно.
 
Цитата
Andrei2016 написал:
2) Сервер QUIK сразу же отправляет запись, пришедшую с биржи, пользователю в соответствии с имеющимся в биржевой записи параметром client_code - по ВСЕМ кодам uid рабочих мест клиента, зарегистрированных у данного брокера. Для обычных - не корпоративных - пользователей такой uid обычно один, в связи с тем, что немногие пользователи - физические лица работают сразу с двумя и более рабочими местами. Но для корпоративных клиентов брокера наличие нескольких рабочих мест и, соответственно, нескольких uid - дело обычное.
Здравствуйте, по первому пункту верно.
По второму есть уточнения. Если у пользователя два разных UID, то он получит ответ только на одном UID.
По 3 пункту такие уточнения:
QUIK не требует уникальности поля trans_id, его уникальность должен поддерживать пользователь. Данное поле предоставляет возможность однозначного сопоставления поданной пользователем транзакции и полученного с
сервера QUIK ответа на транзакцию. Если пользователь не поддерживает уникальность поля TRANS_ID, он теряет возможность корректного определения, по какой транзакции пришел ответ с сервера. Стоит отметить, что событие OnTransReply() срабатывает для всех транзакций с полем TRANS_ID.

На остальные вопросы ответим позже.  
 
Цитата
Andrei2016 написал:
Дополнительно еще один вопрос к разработчикам:

возможна ли в штатном режиме работы ситуация, когда ответный вызов OnTransReply() на отправленную программным образом заявку не поступит вовсе? Если да, то прошу пояснить в каких конкретно случаях такое возможно.
Я хоть и не разработчик, но могу сказать, что в при штатной работе программы  OnTransReply приходит всегда. На практике при проблемах с интернетом ответы  OnTransReply могут пропадать (очень редко).
 
Цитата
Egor Zaytsev написал:
Цитата
Andrei2016   написал:
2) Сервер QUIK сразу же отправляет запись, пришедшую с биржи, пользователю в соответствии с имеющимся в биржевой записи параметром client_code - по ВСЕМ кодам uid рабочих мест клиента, зарегистрированных у данного брокера. Для обычных - не корпоративных - пользователей такой uid обычно один, в связи с тем, что немногие пользователи - физические лица работают сразу с двумя и более рабочими местами. Но для корпоративных клиентов брокера наличие нескольких рабочих мест и, соответственно, нескольких uid - дело обычное.
Здравствуйте, по первому пункту верно.
По второму есть уточнения. Если у пользователя два разных UID, то он получит ответ только на одном UID.

OnOrder и OnTrade будут отправлены всем пользователям, у которых есть права на просмотр заявок / сделок для данного кода клиента.

Скрытый текст
 
Egor Zaytsev,

добрый день!
Спасибо за комментарий.
Когда можно ожидать ответы на остальные вопросы?

Возник еще один вопрос.
8) Вы пишете:
Цитата
По второму есть уточнения. Если у пользователя два разных UID, то он получит ответ только на одном UID.
Допустим, у клиента имеется два рабочих места с uid = 102 и 107, к примеру. Пришла запись с биржи, которая не содержит uid, сервер QUIK отправляет ее сразу же "в сыром виде" пользователю, допустим, на рабочее место с uid = 102. Исходя из ваших слов, на второе рабочее место - с uid = 107 - отправки не произойдет. Но, если после того, как сервер QUIK отыщет в своей базе uid, с которого и была отправлена заявка, на которую пришел вызов OnOrder(), выяснилось, что этот uid = 107, а отнюдь не 102, на который произошла отправка "сырой" записи, то какой смысл в той самой - первой - "сырой" отправке? Рабочее место с uid = 107 все равно получит "свой" вызов OnOrder() только после проставления в биржевую запись <uid = 107>, а рабочему месту с uid = 102, первая полученная - "сырая" - запись с биржи не нужна вовсе, равно как и с проставленным uid, поскольку этот конкретный вызов OnOrder() - "чужой" для данного рабочего места  c uid = 102.
Тогда какой вообще смысл в той - первой - "сырой" отправке без uid, trans_id, флагов и т.п.? Ведь адресат может быть неправильный, и рабочее место должно будет отбраковать и отбракует не "свою" пришедшую запись.
 
Цитата
Andrei2016 написал:
  Можно ли уверенно сказать, что при любом подобном - "удельном" - изменении состояния заявки функция OnOrder() будет вызвана НЕ БОЛЕЕ ДВУХ раз? Если это не так, то прошу указать, какое максимальное количество вызовов OnOrder(), относящихся к одному конкретному изменению состояния заявки может произойти.
Вот возможный сценарий заявки, на каждый пункт будет OnOrder:
1. поставили заявку на 100 лотов;
2. исполнилась сделка на 1 лот;
3. исполнилась сделка на 1 лот;
...
100. исполнилась сделка на 1 лот;
101. сняли оставшийся лот;
Если сервер решит что необходимо что-то дописать или поменять в заявке, то в любом пункте возможен дополнительный вызов OnOrder.

Цитата

7) Может ли вызов OnTrade() придти раньше вызова OnOrder() по одной и той же заявке? Прошу прокомментировать случаи:
Теоретически может. Самое простое что может прийти в голову - торговая система предоставляет "опросный" интерфейс для получения данных. В этом случае может наступить момент, когда клиент отправил транзакцию, она зарегистрирована в ТС и заявка тут же сыграла, но шлюз в этот момент запрашивал новые сделки. Тогда сначала приедет сделка по заявке, а потом сама заявка.
Общая рекомендация для сделок и заявок - не "затачивать" алгоритм на определенный порядок вызова OnOrder/OnTrade и их количество

Цитата

возможна ли в штатном режиме работы ситуация, когда ответный вызов OnTransReply() на отправленную программным образом заявку не поступит вовсе? Если да, то прошу пояснить в каких конкретно случаях такое возможно.
Такая ситуация говорит о том, что что-то пошло не так. Перерублен кабель сразу после отправки транзакции, упал сервер QUIK, апала торговая система и т.п.
 
Michael Bulychev,

спасибо за ответы. Но возник еще вопрос:

9) Допустим, программно выставлены 2 заявки: одна с trans_id = 102 в 14-15мск, другая с trans_id = 107 в 14-25мск. Обе заявки зарегистрированы биржей, обе активны. Далее происходит отправка двух транзакций вида "KILL_ORDER": сначала отправлена заявка на снятие активного ордера с trans_id = 102 и сразу же - следующей командой sendTransaction() - на снятие ордера с trans_id = 107.
Вопрос: возможна ли ситуация, что вначале будет снят ордер с trans_id = 107 и лишь затем снимется ордер с trans_id = 102? Или же порядок вызова OnOrder() будет жестко совпадать с порядком транзакций на снятие ордеров: т.е. сначала в любом случае придет вызов OnOrder() с trans_id = 102 и лишь после него OnOrder() с trans_id = 107?
Вопрос весьма существенный, поэтому прошу прокомментировать максимально точно.

И еще: хотелось бы услышать ответ также и по моему вопросу 8, изложенному в сообщении # 11.
 
что-то тема анекдот напомнила.
------------------------------
сидит группа зеков в тюрьме ,
все анекдоты давно рассказали и поэтому называют лишь номера анекдотов.
Один зек кричит - номер  102.
Вся камера - ну это уже не смешно,
сколько можно этот анекдот рассказывать.
Через пять минут, в дальнем углу раздается смех .
Ты что, это? -удивленно спрашивает смотрящий.
Так я этот анекдот первый раз слышу - отвечает смеющийся.
-------------------------------------------
 
Николай Камынин,

поскольку сей анекдот явно недетерминированный, я хочу послушать еще раз.
Интересуют некоторые подробности.
 
Andrei2016,
Суть в том , что Вы в своих вопросах хотите получить 100% гарантии синхронного прихода сообщений при асинхронной передаче потоков от биржи  и асинхронной передачи пакетов по интернет.
Т е ответ на Ваши вопросы один - гарантий никаких нет.
Потоки не синхронизированы.
Интернет  допускает опережение  пакетов, их потерю, повторный запрос. Это же допускают и потоки с биржи. т е можно терять сообщения и повторно их запрашивать т е нарушать последовательность.
 
Цитата

Вопрос: возможна ли ситуация, что вначале будет снят ордер с trans_id = 107 и лишь затем снимется ордер с trans_id = 102?
ответ очевиден - да, порядок вызовов OnOrder будет произвольный.
 
Николай Камынин,

я не пытаюсь получить синхронизированную последовательность в вызовах разных функций. Но я хочу получить ответ от тех, кто непосредственно программировал взаимодействие сервера QUIK с биржевым шлюзом и собственно с биржевым сервером, а также взаимодействие рабочего места QUIK и сервера QUIK.
Я бы не задавал вопросов, если бы у меня было прямое подключение к бирже и я получал биржевые данные "as is". Однако, я имею дело даже не с интерфейсом сервера QUIK у брокера, а с удаленным рабочим местом QUIK. Биржа не присылает вызовов OnOrder() и других функций, а сервер QUIK присылает, хотя транслируются они терминалом не так, как поступают, а после некоторых преобразований. Вы можете в этом убедиться очень просто.
Группа поддержки говорит о том, что вначале вызов OnOrder() при любом изменении состояния заявки будет с "сырой" биржевой записью, а потом уже приходит та, в которой проставлены uid и trans_id. Это не так. Самая первая запись, касающаяся только что зарегистрированной заявки, действительно приходит без uid и trans_id. Но во всех последующих вызовах OnOrder() - неважно, сколько их будет суммарно, - ВО ВСЕХ проставлен и uid, и trans_id. Вы можете мне точно сказать, КТО проставляет эти значения, отсутствующие в биржевой записи: сервер QUIK или же уже сам терминал? Думаю, вы не сможете мне дать точный ответ. Мне же до ответа разработчиков ясно одно: то, что приходит к брокеру с биржи и то, что де-факто приводит к вызову на моем рабочем месте функции OnOrder(), - это, как говорят в Одессе, две большие разницы.
Поэтому я и задаю свои вопросы. Возможно, в вашем рабочем алгоритме подобные нюансы не играют роли. Но это зависит исключительно от тех задач, которые вы решаете.
А вариант ответа "Никто ничего не может гарантировать" - это не ответ. Хотя бы потому, что с биржи данные приходят срезами. И если исходить из предположения, что там может быть все  что угодно в каком угодно порядке, то, пардон, это не биржевые данные, а какой-то трэш из соцсетей. Если же мы говорим о биржевых данных, то они структурированы даже на уровне внутренней передачи между главным сервером биржевых транзакций и пулом распределенных серверов, выполняющих разные задачи. Заявка, попадая на биржевой конвейер, проходит предтранзакционный контроль и, если все в порядке, идет на регистрацию. И если я вначале отправляю приказ "снять № 102", то обрабатываться будет вначале снятие именно номера 102, а не 107, если, конечно, по sendTransaction() запрос на биржу о снятии уйдет именно в том порядке, как я и вызываю эти функции.
И когда мне говорится, что возможно и так, и эдак, я понимаю, что речь идет не о биржевой последовательности, а о том, как мне биржевая последовательность будет преподнесена рабочим местом QUIK - третьей, вообще говоря, "ступенью" во всем этом обмене, а отнюдь не первой и даже не второй.  
 
Вы много всего написали. На самом деле все просто.

Сервер посылает информацию вам с вполне определённой последовательностью в соответствии со своим внутренним алгоритмом.

Но информация делится на пакеты. Пакеты эти уезжают от сервера в сеть и дальше он ими не управляет. Поэтому первый пакет может уехать к вам через Камчатку, а второй через Химки. И вы запросто можете получить второй пакет раньше первого.
 
s_mike@rambler.ru,

во-первых, не совсем понятно о каком сервере вы говорите: о транзакционном сервере Мосбиржи, о распределенных серверах МБ, о сервере QUIK у брокера или еще о каком-то?
А во-вторых, нет никакой Камчатки или Химок в цепочке у моего брокера. Это не вариант общественного WiFi или частной сети. У моего брокера стоит выделенный канал подключения напрямую к Мосбирже. Информация с МБ приходит большими пакетами, или "срезами". И никакой путаницы в стиле "хз куда что пошло" там нет. Речь не идет о сравнительном порядке прихода вызовов разного типа: я не сравниваю пакет об изменении состояния заявки с пакетом о совершении/изменении сделки. Меня интересует один и тот же тип биржевой записи, который приводит к генерации последовательности действий сервера QUIK, отправляющей на мое рабочее место вызов OnOrder().
Вы можете мне детально сказать, как фактически реагирует сервер QUIK в том или ином случае, и что он отправит мне на конечный пользовательский терминал? Думаю, что не можете, поскольку вы не являетесь разработчиком QUIK.
Повторюсь, вопрос конкретный и весьма существенный именно для меня. Я не говорю о ваших нуждах или об общих принципах организации торговли через QUIK. Возможно, вам в ваших алгоритмах вообще без разницы, что, куда и в какой момент приходит, но такая ситуация - ваша, связанная с вашими задачами, а не с моими.  
 
Добрый день.
Попробую ответить на Ваш вопрос. Ниже на картинке представлена простейшая цепочка получения рыночных данных. Сервер Quik рассылает полученные сообщения на терминалы Quik (связь "3") в том порядке, в котором они приходят со шлюза Quik (связь "2"), за одни исключением, если на сервер Quik в одно и то же время шлюз пришлет цепочку вида "Order->Trade->Order", то сервер МОЖЕТ развернуть ее в цепочку "Order->Order->Trade". В связи с тем, что различные биржи предоставляют интерфейс подключения к своим системам по разным протоколам и разным схемам (связь "1"), в некоторых заявки и сделки доставляются разными не синхронизированными потоками, а так же не нужно забывать об уже отмеченном выше факте потере пакетов. Таким образом возможны ситуации, когда шлюзы по мере получения сообщений с биржи отправляет на сервер Quik следующие цепочки "Order->TransReply", "Trade1->Trade2->Order" и т.п. Никто не будет эти сообщения выстраивать в "правильные" цепочки, такой асинхронный поток данных должен уметь обрабатывать алгоритм Вашего робота на QLua. Мы так же сталкиваемся с данной задачей при разработке модулей, которые получают поток данных с сервера Quik и так же реализовываем алгоритмы обработки асинхронного потока сообщений.
Перед тем как задать вопрос, убедитесь, что решение Вашей задачи не описано в официальном мануале - 'Использование Lua в Рабочем месте QUIK.pdf' https://arqatech.com/upload/Public/quik_lua.zip
 
Nikolay Pavlov,

спасибо за комментарий.
Можете ли вы высказать свое мнение по моему вопросу 9 в сообщении #13?
Поясню: речь у меня сейчас идет только о цепочке вызовов OnOrder(), не касаясь вызовов OnTransReply и OnTrade совсем.

---

Уважаемые разработчики QUIK!

Прошу дать ответы на мои вопросы 8 и 9 в сообщениях 11 и 13 данной темы.
 
Добрый день.
По вопросу из #11 поста. Если на у пользователя с uid=102 и у пользователя с uid=107, допустим по классу TQBR, брокер настроил в правах одинаковую Фирму и Код клиента, то независимо от того пользователь с uid=102 или с uid=107 будет подавать заявку, они оба получат ее в "чистом виде", т.е. сначала с полем UID на заявке равным 0, а после с UID пользователя, которым была выставлена заявка. Сервер Quik при рассылке заявок/сделок смотрит не на UID пользователя, а на фирму и код клиента, которые прислал шлюз на заявке/сделке и рассылает ее всем у кого есть права на данную фирму и код клиента. При этом в терминале на заявке Вы увидите UID именно того пользователя, который выставил заявку, т.е. если выставить заявку от пользователя с uid=102, то пользователь с uid=107 получит заявку с полем UID=102.

По вопросу из #13 поста. Как уже говорилось ранее, сервер Quik пришлет сообщения о снятии заявок в том порядке, в котором ему пришлет эти сообщения шлюз Quik, т.е. опять же если система Биржи пожелает первым прислать сообщение о снятии заявки с trans_id = 107, а не trans_id = 102 (хотя 102 заявка снималась по времени раньше) шлюз ее и отправит первой на сервер Quik и соответственно Вы увидите, что заявка с trans_id = 107 снялась раньше чем заявка с trans_id = 102.
Перед тем как задать вопрос, убедитесь, что решение Вашей задачи не описано в официальном мануале - 'Использование Lua в Рабочем месте QUIK.pdf' https://arqatech.com/upload/Public/quik_lua.zip
 
Цитата
Nikolay Pavlov написал:
Добрый день.
По вопросу из #11 поста. Если на у пользователя с uid=102 и у пользователя с uid=107, допустим по классу TQBR, брокер настроил в правах одинаковую Фирму и Код клиента, то независимо от того пользователь с uid=102 или с uid=107 будет подавать заявку, они оба получат ее в "чистом виде", т.е. сначала с полем UID на заявке равным 0, а после с UID пользователя, которым была выставлена заявка. Сервер Quik при рассылке заявок/сделок смотрит не на UID пользователя, а на фирму и код клиента, которые прислал шлюз на заявке/сделке и рассылает ее всем у кого есть права на данную фирму и код клиента.
Nikolay, вы не совсем правильно поняли мой вопрос к разработчикам в сообщении # 11.
Я вначале рассуждал именно так, как вы и описали, однако, затем Егор Зайцев из группы поддержки ARQA в своем ответе на мои вопросы указывает:
Цитата
По второму есть уточнения. Если у пользователя два разных UID, то он получит ответ только на одном UID.
Потому я и спрашивал разработчиков, какой смысл в рассылке "безадресной" (с точки зрения, наличия uid и trans_id) самой первой записи - "фотоснимка" биржевой записи, где есть лишь код клиента для идентификации владельца заявки, - если при наличии у пользователя двух uid эта первая - "сырая" - запись, когда еще сервер QUIK не определил uid и trans_id, попадает только на один из двух терминалов. При этом нет никакой гарантии, что именно на тот терминал, который и отправли заявку изначально.
Случай с теми или иными брокерскими настройками - это частный случай работы конкретного брокера. Поэтому такие случаи я не рассматриваю, поскольку механизм обработки и рассылки пользователям биржевых записей, заложенный разработчиками  QUIK в серверное ПО, - универсальный для всех брокеров и для любых брокерских настроек.

На данный момент у меня уже есть ответ на вопрос 8 из сообщения # 11.  Поэтому на повестке остается лишь вопрос 9 в сообщении # 13.  
 
Добрый день.
Цитата
Andrei2016 написал:
Nikolay, вы не совсем правильно поняли мой вопрос к разработчикам в сообщении # 11.
Я вначале рассуждал именно так, как вы и описали, однако, затем Егор Зайцев из группы поддержки ARQA в своем ответе на мои вопросы указывает:
Цитата: По второму есть уточнения. Если у пользователя два разных UID, то он получит ответ только на одном UID.
Скорее всего Егор Зайцев имел ввиду, что если у пользователя два UID с одинаковыми правами по классам, то при отправке транзакции на выставление заявки ответ (т.е. TransReply) получит только пользователь с тем UID кто подавал данную транзакцию, а пользователь со вторым UID получит только заявку. Таким образом, как я уже и писал выше, заявку в "чистом виде", т.е. c uid=0 и trans_id=0 получат ОБА пользователя, это я проверил сам лично.
Цитата
Andrei2016 написал:
Поэтому на повестке остается лишь вопрос 9 в сообщении # 13.
Я уже выше описан, что шлюзы учитывают порядок полученных транзакций на снятие заявок только в момент отправки на Биржу запроса на снятие заявки, но если сама Биржа решит ответить сначала на 2 запрос, а после на 1, шлюз НЕ БУДЕТ ждать пока биржа пришлет ответ на запрос снятия заявки №1, он сразу отправит сообщение о снятии заявки №2 на сервер Quik и соответственно в терминале Вы увидите, что заявка №2 снялась раньше.
Перед тем как задать вопрос, убедитесь, что решение Вашей задачи не описано в официальном мануале - 'Использование Lua в Рабочем месте QUIK.pdf' https://arqatech.com/upload/Public/quik_lua.zip
 
Цитата
Nikolay Pavlov написал:
Я уже выше описан, что шлюзы учитывают порядок полученных транзакций на снятие заявок только в момент отправки на Биржу запроса на снятие заявки, но если сама Биржа решит ответить сначала на 2 запрос, а после на 1, шлюз НЕ БУДЕТ ждать пока биржа пришлет ответ на запрос снятия заявки №1, он сразу отправит сообщение о снятии заявки №2 на сервер Quik и соответственно в терминале Вы увидите, что заявка №2 снялась раньше.
Вообще-то,шлюз ничего не может решать. Он работает по правилу FIFO.
-----------------------------
Решать могут, например,  маршрутизаторы.
-----------------------------
Вы уж старайтесь не фантазировать,
а придерживаться реальной схемы каналов.
 
Цитата
Andrei2016 написал:
9) Допустим, программно выставлены 2 заявки: одна с trans_id = 102 в 14-15мск, другая с trans_id = 107 в 14-25мск. Обе заявки зарегистрированы биржей, обе активны. Далее происходит отправка двух транзакций вида "KILL_ORDER": сначала отправлена заявка на снятие активного ордера с trans_id = 102 и сразу же - следующей командой sendTransaction() - на снятие ордера с trans_id = 107.
Вопрос: возможна ли ситуация, что вначале будет снят ордер с trans_id = 107 и лишь затем снимется ордер с trans_id = 102? Или же порядок вызова OnOrder() будет жестко совпадать с порядком транзакций на снятие ордеров: т.е. сначала в любом случае придет вызов OnOrder() с trans_id = 102 и лишь после него OnOrder() с trans_id = 107?
Вопрос весьма существенный, поэтому прошу прокомментировать максимально точно.
Добрый день.
Очень часто шлюзы используют несколько транзакционных коннектов к торговой системе. Сервер отправляет транзакцию в первый найденный свободный коннект. Поэтому теоретически может возникнуть ситуация, когда, в Вашем примере, транзакция с trans_id=107 выполнится раньше чем 102 со всеми вытекающими отсюда результатами.
 
Цитата
Николай Камынин написал:
Вообще-то,шлюз ничего не может решать. Он работает по правилу FIFO.
-----------------------------
Решать могут, например,  маршрутизаторы.
-----------------------------
Вы уж старайтесь не фантазировать,
а придерживаться реальной схемы каналов.
Николай, шлюз ничего не ждет, да, в прямом направлении, т.е. входящие в шлюз транзакций от сервера Quik обрабатываются по правилу FIFO, т.е. если ему сервер Quik пришлет транзакции снятия заявок в порядке 1, 2, 3, 4, 5 в таком порядке и будут обработаны и отправлены запросы на Биржу о снятии, но как уточнил Михаил Булычев, транзакционных подключений к Бирже может быть больше чем одно, работают они отдельными потоками и если последовательность снятия заявок 1, 2, 3, 4, 5 была разослана в разные транзакционные подключений, то и обратно отчеты о снятии могут прийти уже в другом порядке.
Перед тем как задать вопрос, убедитесь, что решение Вашей задачи не описано в официальном мануале - 'Использование Lua в Рабочем месте QUIK.pdf' https://arqatech.com/upload/Public/quik_lua.zip
 
Цитата
Николай Камынин написал:
Вообще-то,шлюз ничего не может решать. Он работает по правилу FIFO.
-----------------------------
Решать могут, например,  маршрутизаторы.
Еще уточню, использую терминологию "шлюз" мы не говорим об обычном сетевом шлюзе, "шлюз Quik" это по сути маршрутизатор, который может роутить транзакции в разные подключения в зависимости от настроенных в нем правил, например в зависимости от кода клиента или торгового счета.
Перед тем как задать вопрос, убедитесь, что решение Вашей задачи не описано в официальном мануале - 'Использование Lua в Рабочем месте QUIK.pdf' https://arqatech.com/upload/Public/quik_lua.zip
 
Michael Bulychev,

Возник еще один технический вопрос.
Допустим, с биржи пришла некоторая последовательность записей о состоянии заявок клиентов. Может ли в штатном режиме работы сервера QUIK (обрывов связи либо падения сервера нет) возникнуть ситуация, при которой клиент брокера на своем рабочем месте QUIK получит вызовы OnOrder() не в той последовательности, в которой они получены с биржи, а в иной - в результате каких-либо действий/преобразований на самом сервере QUIK у брокера. Если такая ситуация возможна, то прошу прокомментировать в каких случаях.
 
Andrei2016,
Такой ситуации не может быть.
Страницы: 1
Читают тему (гостей: 1)
Наверх