order_num == nil и status == 3 в ответ на NEW_ORDER

Страницы: 1
RSS
order_num == nil и status == 3 в ответ на NEW_ORDER
 
По документации, поле 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.
 
Добрый день.

За все торговые площадки мы сказать затруднимся, это нужно проверять.
Но направление такое, если в OnTransReply order_num равен null, то и в OnOrder
он может и не быть.

На фондовом, валютном, срочном рынке такой ситуации не должно быть.
 
Цитата
Egor Zaytsev написал:
Добрый день.

За все торговые площадки мы сказать затруднимся, это нужно проверять.
Но направление такое, если в OnTransReply order_num равен null, то и в OnOrder
он может и не быть.

На фондовом, валютном, срочном рынке такой ситуации не должно быть.
Значит ответ: «Да»...
 
Сюда же задам ещё два вопроса по поведению OnTransReply, OnOrder и OnTrade, чтобы не плодить темы.

1. Возможна ли ситуация потери одного из вызовов, например при сетевых ошибках, сбоях сервера и т.п... то-есть OnTransReply вообще не приходит, а сразу приходят OnOrder и OnTrade?
2. Возможна ли ситуация изменения порядка прихода вызовов. Например, первым придут несколько OnTrade, за ними OnOrder и в конце OnTransReply, и все разумеется в рамках одного trans_id?
 
Цитата
Suntor написал:
Сюда же задам ещё два вопроса по поведению OnTransReply, OnOrder и OnTrade, чтобы не плодить темы.

1. Возможна ли ситуация потери одного из вызовов, например при сетевых ошибках, сбоях сервера и т.п... то-есть OnTransReply вообще не приходит, а сразу приходят OnOrder и OnTrade?
2. Возможна ли ситуация изменения порядка прихода вызовов. Например, первым придут несколько OnTrade, за ними OnOrder и в конце OnTransReply, и все разумеется в рамках одного trans_id?
Ответ на ваши вопросы да, теоретически такое может быть.
 
Подтверждаю, что OnTransReply может не придти. Хотя это бывает очень редко, при сетевых проблемах, но проектировать логику отслеживания статусов заявок надо с учётом этого.

Порядок прихода коллбэков может быть любым. Это тоже надо учитывать.
 
Всем ответившим спасибо за предыдущие ответы...

Ещё вопрос по очерёдности 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 будет приходить всегда первым и до начала новой торговой сессии?
 
Добрый день.

Цитата
Возможна ли ситуация, что до начала торговой сессии не придёт OnOrder с новым order_num, а первым придёт в начале новой торговой сессии OnTrade с этим новым order_num? Или гарантируется, что при заменах, OnOrder с новым order_num будет приходить всегда первым и до начала новой торговой сессии?
Да, такая ситуация возможна.
 
Цитата
Egor Zaytsev написал:
Добрый день.
Цитата
Возможна ли ситуация, что до начала торговой сессии не придёт OnOrder с новым order_num, а первым придёт в начале новой торговой сессии OnTrade с этим новым order_num? Или гарантируется, что при заменах, OnOrder с новым order_num будет приходить всегда первым и до начала новой торговой сессии?
Да, такая ситуация возможна.
Очень плохая ситуация... если OnOrder с новым order_num потерялся... то все последующие OnTrade невозможно ни к чему привязать, так как старого order_num в них нет.
Фактически это «сделки из ниоткуда»... у них trans_id нулевой, linkedorder нет и order_num новый.
 
Цитата
Suntor написал:
Цитата
Egor Zaytsev   написал:
Добрый день.
Цитата
Возможна ли ситуация, что до начала торговой сессии не придёт OnOrder с новым order_num, а первым придёт в начале новой торговой сессии OnTrade с этим новым order_num? Или гарантируется, что при заменах, OnOrder с новым order_num будет приходить всегда первым и до начала новой торговой сессии?
Да, такая ситуация возможна.
Очень плохая ситуация... если OnOrder с новым order_num потерялся... то все последующие OnTrade невозможно ни к чему привязать, так как старого order_num в них нет.
Фактически это «сделки из ниоткуда»... у них trans_id нулевой, linkedorder нет и order_num новый.
Добрый день.

Здесь универсального решения нет.
Надо быть готовым к любому порядку прихода       данных.
 
Цитата
Egor Zaytsev написал:
Цитата
Suntor   написал:
Фактически это «сделки из ниоткуда»... у них trans_id нулевой, linkedorder нет и order_num новый.
Здесь универсального решения нет.
Надо быть готовым к любому порядку прихода       данных.
Порядок одно, а целостность протокола совсем другое. В данном случае, речь идёт о потери связи между начальными и конечными сообщениями в рамках транзакции.
Ситуация возникает из-за обнуления trans_id для перевыставленных заявок. А также из-за отсутствия в сделках информации об исходной заявке.
 
Цитата
Suntor написал:
Цитата
Egor Zaytsev   написал:
Цитата
Suntor   написал:
Фактически это «сделки из ниоткуда»... у них trans_id нулевой, linkedorder нет и order_num новый.
Здесь универсального решения нет.
Надо быть готовым к любому порядку прихода       данных.
Порядок одно, а целостность протокола совсем другое. В данном случае, речь идёт о потери связи между начальными и конечными сообщениями в рамках транзакции.
Ситуация возникает из-за обнуления trans_id для перевыставленных заявок. А также из-за отсутствия в сделках информации об исходной заявке.
О  trans_id торговая система ничего не знает, это внутренняя сущность сервера QUIK.
 
Цитата
Egor Zaytsev написал:
О  trans_id торговая система ничего не знает, это внутренняя сущность сервера QUIK.
Тем лучше для Quik. Сервер Quik может сохранять trans_id для перевыставленных заявок, а не обнулять его.
Страницы: 1
Читают тему
Наверх