order_num == nil и status == 3 в ответ на NEW_ORDER
Пользователь
Сообщений: Регистрация: 10.04.2015
30.03.2018 13:32:06
По документации, поле order_num может быть nil в OnTransReply(trans), а в OnOrder(order) нет.
Возможна ли ситуация, что в ответ на NEW_ORDER придёт успешный OnTransReply(trans) с trans.status == 3 в котором trans.order_num == nil? То-есть, заявка будет успешно зарегистрирована, но её номер останется неизвестным. И придёт только в поле order.order_num ~= 0 при последующем вызове OnOrder(order) имеющим такой же идентификатор транзакции order.trans_id == trans.trans_id.
QUIK clients support
Сообщений: Регистрация: 27.01.2015
02.04.2018 11:38:10
Добрый день.
За все торговые площадки мы сказать затруднимся, это нужно проверять. Но направление такое, если в OnTransReply order_num равен null, то и в OnOrder он может и не быть.
На фондовом, валютном, срочном рынке такой ситуации не должно быть.
За все торговые площадки мы сказать затруднимся, это нужно проверять. Но направление такое, если в OnTransReply order_num равен null, то и в OnOrder он может и не быть.
На фондовом, валютном, срочном рынке такой ситуации не должно быть.
Значит ответ: «Да»...
Пользователь
Сообщений: Регистрация: 10.04.2015
02.04.2018 11:53:01
Сюда же задам ещё два вопроса по поведению OnTransReply, OnOrder и OnTrade, чтобы не плодить темы.
1. Возможна ли ситуация потери одного из вызовов, например при сетевых ошибках, сбоях сервера и т.п... то-есть OnTransReply вообще не приходит, а сразу приходят OnOrder и OnTrade? 2. Возможна ли ситуация изменения порядка прихода вызовов. Например, первым придут несколько OnTrade, за ними OnOrder и в конце OnTransReply, и все разумеется в рамках одного trans_id?
QUIK clients support
Сообщений: Регистрация: 27.01.2015
02.04.2018 12:52:01
Цитата
Suntor написал: Сюда же задам ещё два вопроса по поведению OnTransReply, OnOrder и OnTrade, чтобы не плодить темы.
1. Возможна ли ситуация потери одного из вызовов, например при сетевых ошибках, сбоях сервера и т.п... то-есть OnTransReply вообще не приходит, а сразу приходят OnOrder и OnTrade? 2. Возможна ли ситуация изменения порядка прихода вызовов. Например, первым придут несколько OnTrade, за ними OnOrder и в конце OnTransReply, и все разумеется в рамках одного trans_id?
Ответ на ваши вопросы да, теоретически такое может быть.
Пользователь
Сообщений: Регистрация: 31.01.2015
03.04.2018 06:00:49
Подтверждаю, что OnTransReply может не придти. Хотя это бывает очень редко, при сетевых проблемах, но проектировать логику отслеживания статусов заявок надо с учётом этого.
Порядок прихода коллбэков может быть любым. Это тоже надо учитывать.
Пользователь
Сообщений: Регистрация: 10.04.2015
03.04.2018 16:33:34
Всем ответившим спасибо за предыдущие ответы...
Ещё вопрос по очерёдности OnOrder и OnTrade при замене заявки со сроком действия при переносе через вечерний клиринг на срочке.
По логам, OnOrder для новой заменённой заявки приходит с trans_id == 0, новыми order_num и datetime, и linkedorder равным order_num старой заявки. Насколько я понимаю, OnTrade также придёт с trans_id == 0, новым order_num, но без linkedorder, так как такого параметра в сделках нет. Единственный способ связать между собой новые сделки по новой заменённой заявке, это сравнить новый order_num в OnTrade с новым order_num полученным в OnOrder. Но для этого, OnOrder для новой заменённой заявки должен обязательно прийти первым. По логам вижу, что он пришёл в середине вечернего клиринга вчера.
Возможна ли ситуация, что до начала торговой сессии не придёт OnOrder с новым order_num, а первым придёт в начале новой торговой сессии OnTrade с этим новым order_num? Или гарантируется, что при заменах, OnOrder с новым order_num будет приходить всегда первым и до начала новой торговой сессии?
QUIK clients support
Сообщений: Регистрация: 27.01.2015
09.04.2018 05:33:50
Добрый день.
Цитата
Возможна ли ситуация, что до начала торговой сессии не придёт OnOrder с новым order_num, а первым придёт в начале новой торговой сессии OnTrade с этим новым order_num? Или гарантируется, что при заменах, OnOrder с новым order_num будет приходить всегда первым и до начала новой торговой сессии?
Возможна ли ситуация, что до начала торговой сессии не придёт OnOrder с новым order_num, а первым придёт в начале новой торговой сессии OnTrade с этим новым order_num? Или гарантируется, что при заменах, OnOrder с новым order_num будет приходить всегда первым и до начала новой торговой сессии?
Да, такая ситуация возможна.
Очень плохая ситуация... если OnOrder с новым order_num потерялся... то все последующие OnTrade невозможно ни к чему привязать, так как старого order_num в них нет. Фактически это «сделки из ниоткуда»... у них trans_id нулевой, linkedorder нет и order_num новый.
Возможна ли ситуация, что до начала торговой сессии не придёт OnOrder с новым order_num, а первым придёт в начале новой торговой сессии OnTrade с этим новым order_num? Или гарантируется, что при заменах, OnOrder с новым order_num будет приходить всегда первым и до начала новой торговой сессии?
Да, такая ситуация возможна.
Очень плохая ситуация... если OnOrder с новым order_num потерялся... то все последующие OnTrade невозможно ни к чему привязать, так как старого order_num в них нет. Фактически это «сделки из ниоткуда»... у них trans_id нулевой, linkedorder нет и order_num новый.
Добрый день.
Здесь универсального решения нет. Надо быть готовым к любому порядку прихода данных.
Suntor написал: Фактически это «сделки из ниоткуда»... у них trans_id нулевой, linkedorder нет и order_num новый.
Здесь универсального решения нет. Надо быть готовым к любому порядку прихода данных.
Порядок одно, а целостность протокола совсем другое. В данном случае, речь идёт о потери связи между начальными и конечными сообщениями в рамках транзакции. Ситуация возникает из-за обнуления trans_id для перевыставленных заявок. А также из-за отсутствия в сделках информации об исходной заявке.
Suntor написал: Фактически это «сделки из ниоткуда»... у них trans_id нулевой, linkedorder нет и order_num новый.
Здесь универсального решения нет. Надо быть готовым к любому порядку прихода данных.
Порядок одно, а целостность протокола совсем другое. В данном случае, речь идёт о потери связи между начальными и конечными сообщениями в рамках транзакции. Ситуация возникает из-за обнуления trans_id для перевыставленных заявок. А также из-за отсутствия в сделках информации об исходной заявке.
О trans_id торговая система ничего не знает, это внутренняя сущность сервера QUIK.
Пользователь
Сообщений: Регистрация: 10.04.2015
12.04.2018 08:09:56
Цитата
Egor Zaytsev написал: О trans_id торговая система ничего не знает, это внутренняя сущность сервера QUIK.
Тем лучше для Quik. Сервер Quik может сохранять trans_id для перевыставленных заявок, а не обнулять его.
