Очередность срабатывания 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 - третьей, вообще говоря, "ступенью" во всем этом обмене, а отнюдь не первой и даже не второй.  
 
Вы много всего написали. На самом деле все просто.

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

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

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
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,
Такой ситуации не может быть.
 
Цитата
Цитата
По логике последовательность вызовов должна быть жесткой:  OnTransReply --> OnOrder --> OnTrade (***).
Да, верно. Однако могут приходить  в любом порядке. Заранее нельзя быть уверенным в порядке срабатывания.
Сообщение старое - актуально ли данное по сегодняшний день в плане хаотичности очередности функций OnTransReply (), OnOrder (), OnTrade ()? Или были какие-то исправления в плане жесткой фиксации последовательности, т.к. в моем понимании она должна быть такой как пишет автор? Были ли изменения?
Торговый привод на Lua: https://github.com/iv-litovchenko/Quik-Enter-Trade
 
"Случайный" порядок будет всегда.
В этом нет ни намеренной ошибки, ни злого умысла.
Соответственно и "исправлено" это никогда не будет. Исправлять нечего.

Причина проста: биржа отправляет информацию о сделках, заявках и ответах на транзакции (OnTransReply) через разные подключения в шлюзам биржи. Это физически разные подключения, через разные порты (возможно даже разные хосты), посмотрите сами документацию по шлюзу МосБиржи, например. Таким образом эти потоки не синхронны уже на стороне шлюза биржи.

Так что порядок "случайный" будет всегда и везде.
 
Цитата
s_mike@rambler.ru написал:
Сервер посылает информацию вам с вполне определённой последовательностью в соответствии со своим внутренним алгоритмом.

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

Добрый день.

Допустим, произошли две сделки: #1 и #2.
Возможно ли, что в результате таких "путешествий" пакет со сделкой #2 приехал к клиенту раньше, чем пакет #1 или это не более, чем домыслы?
 
?
 
Незнайка, добрый день!

Если говорить конкретно про сделки то они идут в одном синхронном потоке, в связи с чем там порядок поступления записей гарантируется.
Другими словами, в терминал QUIK записи поступят ровно в том порядке, в котором их отправила биржа.

Гарантирует ли биржа строгий порядок отправки, следует уточнять у самой биржи.

Разные же сущности (транзакции/заявки/сделки) могут транслироваться разными потоками, это значит, что может произойти так, что заявка придет раньше ответа на транзакцию и тому подобное.
Страницы: 1
Читают тему
Наверх