Приветствую всех. Написал минимальный луа-скрипт, который пишет лог по событию OnOrder. По некоторым ордерам (небольшой части относительно общей массы) событие приходит с нулевым trans_id. А затем приходит с нормальным id.
Лог: https://www.sendspace.com/file/d57512 Формат лога: "время|номер ордера из квика|номер транзакции|структура flags" Ордера с нулевыми транзакциями можно найти по строке "transaction:0"
Это баг или это нормальное допустимое поведение? Сам я с этим столкнулся, потому что библиотека StockSharp неправильно обрабатывает эту ситуацию. И вот хочу знать с какого конца ее нужно устранить - со стороны квика или со стороны S#
Денис X пишет: Приветствую всех. Написал минимальный луа-скрипт, который пишет лог по событию OnOrder. По некоторым ордерам (небольшой части относительно общей массы) событие приходит с нулевым trans_id. А затем приходит с нормальным id.
Лог: https://www.sendspace.com/file/d57512 Формат лога: "время|номер ордера из квика|номер транзакции|структура flags" Ордера с нулевыми транзакциями можно найти по строке "transaction:0"
Это баг или это нормальное допустимое поведение? Сам я с этим столкнулся, потому что библиотека StockSharp неправильно обрабатывает эту ситуацию. И вот хочу знать с какого конца ее нужно устранить - со стороны квика или со стороны S#
Добрый день.
Как понимаем trans_id у Вас формируется автоматически? Посмотрите на стороне S#, так как нами подобные вещи ранее не замечались.
Олег Хуснутдинов пишет: Таблица заявок - обновляемая таблица. Поэтому, теоретически, обновлён (дописан/удалён) может быть любой параметр, кроме ключевых (ключевые это Номер заявки, Дата торгов, Код класса). На практике же дописывается UID и ID транзакции. Сделано это для того, чтобы как можно скорее отправить информацию о заявке пользователю и не ожидать определения всех атрибутов заявки (определение UID и ID транзакции происходит внутри сервера QUIK и занимает какое-то время).
Надо делать так, как надо. А как не надо - делать не надо.
Ситуация такая. По некоторым ордерам сначала приходит сообщение, о новом ордере, с нулевым transaction_id, затем приходит сообщение о новом ордере (этом же самом) с нормальным trans_id. Затем приходит сообщение о том, что ордер с нормальным trans_id исполнился, а по нулевому естественно не приходит. И в итоге в S# в списке активных ордеров есть лишние (те, по которым пришло сообщение с нулевым trans_id). Что именно можно насмотреть в S# я сам пока не особо понимаю, пока просто попробую разобраться в механизме обмена сообщениями с квиком.
user пишет: В логе из первого сообщения - для ордеров, начинающихся на "num:1394" - всегда "transaction:0"
Хм, сам я на это не обратил внимание. Затрудняюсь сказать, что это значит. Возможно этот ордер и был выставлен руками.. но остальные ордера с нулевым trans_id точно выставлялись моей программой через S#
Подниму тему. Убедился, что дело точно не в StockSharp. Набросал минимальный lua-скрипт, для выставления заявок на продажу и на покупку. Запустил свой логер и начал покупать-продавать через новый скрипт. Ситуация как и в первом посте, по небольшой части заявок приходят сообщения с нулевым transactionId.
На всякий случай выложу еще скрипты логера и торговой формы. За качество кода прошу не пинать, на луа вообще не программирую и скрипты написал на коленке за 5 минут, лишь бы работало. Форма торговая требует библиотеку VCLua в папке квика. Логер: http://pastebin.com/PhSPCuGi Форма для торговли: http://pastebin.com/q5LXxwzk
Michael Bulychev, вы отвечаете от лица разработчиков? Как тогда нужно обрабатывать такие сообщения на своей стороне? Есть ситуации когда сообщение с теми же флагами дублируется с проставленным transId: 01.09.2015 17:20:09 num:17043507444|transaction:0|flags:25 01.09.2015 17:20:09 num:17043507444|transaction:12209159|flags:25 01.09.2015 17:20:14 num:17043507444|transaction:12209159|flags:24
А есть, когда не дублируется: 01.09.2015 17:15:28 num:17043266652|transaction:0|flags:25 01.09.2015 17:15:28 num:17043266652|transaction:121528146|flags:24 01.09.2015 17:15:28 num:17043266652|transaction:121528146|flags:24
Алгоритмы обработки зависят от решаемых задач, тут сложно подсказать универсальный рецепт. Насчет разных флагов - можно сказать точнее если знать параметры транзакции и ответ торговой системы
Понятнее не стало. Какой ответ был на транзакцию? на каком рынке совершалась операция? В любом случае, заявка с нулевым trans_id допускается. Причины уже были описаны выше в этой ветке.
Michael Bulychev пишет: Алгоритмы обработки зависят от решаемых задач,
Задача - отслеживать состояние своих ордеров. Если более конкретно, есть библиотека S#, внутри нее информация об имеющихся ордерах и сообщения об их изменении сопоставляется между собой по transactionId. Соответственно, когда приходит сообщение с нулевым transactionId, оно не сопоставляется с нужным ордером.
Michael Bulychev пишет: Алгоритмы обработки зависят от решаемых задач,
Задача - отслеживать состояние своих ордеров. Если более конкретно, есть библиотека S#, внутри нее информация об имеющихся ордерах и сообщения об их изменении сопоставляется между собой по transactionId. Соответственно, когда приходит сообщение с нулевым transactionId, оно не сопоставляется с нужным ордером.
Вы можете использовать примечание для решение задачи. Оно в отличии от TRANS_ID содержится в поле BROKERREF которое транслирует биржа, а значит оно точно не потеряется. То есть чтобы робот писал в примечание какой-либо спец признак. Примечание указывается в параметре транзакции CLIENT_CODE после кода клиента, в качестве разделителя добавляется признак "/" или "//" (зависит от настроек на стороне брокера) если в правах только один код клиента, можно его не указывать, а сразу писать примечание.
Michael Bulychev пишет: Какой ответ был на транзакцию? на каком рынке совершалась операция?
В лог ответ на транзакцию не писался, если просто словами сказать, то заявка либо попадала с стакан и затем исполнялась, либо сразу исполнялась (если цена заявки получалась рыночной). Все ордера выставлялись по SPBFUT RIU5.
Michael Bulychev пишет: Понятнее не стало. Какой ответ был на транзакцию? на каком рынке совершалась операция? В любом случае, заявка с нулевым trans_id допускается. Причины уже были описаны выше в этой ветке.
Столкнулся с аналогичной проблемой. Иногда для заявок приходят подрят несколько раз колбэки с нулевой транзакцией. Затем снова нормально. Затем опять. Рынок ФОРТС. Инструменты фДолларРубль
Michael Bulychev пишет: Понятнее не стало. Какой ответ был на транзакцию? на каком рынке совершалась операция? В любом случае, заявка с нулевым trans_id допускается. Причины уже были описаны выше в этой ветке.
Столкнулся с аналогичной проблемой. Иногда для заявок приходят подрят несколько раз колбэки с нулевой транзакцией. Затем снова нормально. Затем опять. Рынок ФОРТС. Инструменты фДолларРубль
Биржа ничего не знает про TRANS_ID, его проставляет сервер QUIK, связывая номер заявки с тем что получен в ответе на транзакцию. В некоторых случаях тело заявки бывает получено раньше ответа на транзакцию. Тогда сервер просто не знает какой TRANS_ID ей указать и отправляет пользователю как есть. Позже, когда ответ на транзакцию получен, сервер проставляет на заявке TRANS_ID.
Michael Bulychev пишет: Какой ответ был на транзакцию? на каком рынке совершалась операция?
В лог ответ на транзакцию не писался, если просто словами сказать, то заявка либо попадала с стакан и затем исполнялась, либо сразу исполнялась (если цена заявки получалась рыночной). Все ордера выставлялись по SPBFUT RIU5.
Скорее всего заявка приехала на сервер уже в снятом состоянии. Это особенность выставления заявок на ФОРТС с признаком рыночная. Если нет встречного предложения, заявка приезжает уже снятой.
Sergey Gorokhov пишет: Позже, когда ответ на транзакцию получен, сервер проставляет на заявке TRANS_ID.
А ситуация, когда дублирующее сообщение с проставленным transID _не_ придет возможна? Сообщение в этой же ветке выше: "В логе из первого сообщения - для ордеров, начинающихся на "num:1394" - всегда "transaction:0""
Sergey Gorokhov пишет: Вы можете использовать примечание для решение задачи. Оно в отличии от TRANS_ID содержится в поле BROKERREF которое транслирует биржа, а значит оно точно не потеряется. То есть чтобы робот писал в примечание какой-либо спец признак. Примечание указывается в параметре транзакции CLIENT_CODE после кода клиента, в качестве разделителя добавляется признак "/" или "//" (зависит от настроек на стороне брокера) если в правах только один код клиента, можно его не указывать, а сразу писать примечание.
Как узнать, какие настройки на стороне брокера? Нужно к брокеру обращаться или можно выяснить экспериментальным путём? Есть ли какие-то ограничения на содержание этого поля, кроме длины в 20 символов? Я так понимаю, что в поле CLIENT_CODE можно указать тот же Trans_ID?
Надо делать так, как надо. А как не надо - делать не надо.
Это значит, что эти ордера были выставлены по другой бумаге, а не по SPBFUT RIU5.
Цитата
Денис X пишет: А ситуация, когда дублирующее сообщение с проставленным transID_не_ придет возможна? Сообщение в этой же ветке выше: "В логе из первого сообщения - для ордеров, начинающихся на "num:1394" - всегда "transaction:0""
Денис X пишет: Хм, сам я на это не обратил внимание. Затрудняюсь сказать, что это значит. Возможно этот ордер и был выставлен руками..но остальные ордера с нулевым trans_id точно выставлялись моей программой через S#
Не? Возможно, вам стоит восстановить хронологию событий?
Надо делать так, как надо. А как не надо - делать не надо.
Ключевое слово здесь "Возможно". Может быть да, а может быть нет. И поэтому в моем сообщении звучит вопрос "А ситуация, когда дублирующее сообщение с проставленным transID_не_ придет возможна? ", а не утверждение.
Старатель пишет: Как узнать, какие настройки на стороне брокера? Нужно к брокеру обращаться или можно выяснить экспериментальным путём?
Просто посмотреть как комментарий выглядит в таблице заявок.
Цитата
Старатель пишет: Есть ли какие-то ограничения на содержание этого поля, кроме длины в 20 символов? Я так понимаю, что в поле CLIENT_CODE можно указать тот же Trans_ID?
там можно что угодно написать. с учетом ограничения 20 символов
Sergey Gorokhov пишет: Биржа ничего не знает про TRANS_ID, его проставляет сервер QUIK, связывая номер заявки с тем что получен в ответе на транзакцию. В некоторых случаях тело заявки бывает получено раньше ответа на транзакцию. Тогда сервер просто не знает какой TRANS_ID ей указать и отправляет пользователю как есть. Позже, когда ответ на транзакцию получен, сервер проставляет на заявке TRANS_ID.
Денис X пишет: А ситуация, когда дублирующее сообщение с проставленным transID_не_ придет возможна? Сообщение в этой же ветке выше: "В логе из первого сообщения - для ордеров, начинающихся на "num:1394" - всегда "transaction:0""
Денис X, видимо, проще самостоятельно проверить: уточните, по какой именно бумаге подавались транзакции с "num:1394", повыставляйте заявки через S#/Lua по этой бумаге и посмотрите, приходят ли вообще по этой бумаге OnOrder с проставленным trans_id.
Надо делать так, как надо. А как не надо - делать не надо.
Michael Bulychev пишет: Понятнее не стало. Какой ответ был на транзакцию? на каком рынке совершалась операция? В любом случае, заявка с нулевым trans_id допускается. Причины уже были описаны выше в этой ветке.
Столкнулся с аналогичной проблемой. Иногда для заявок приходят подрят несколько раз колбэки с нулевой транзакцией. Затем снова нормально. Затем опять. Рынок ФОРТС. Инструменты фДолларРубль
Биржа ничего не знает про TRANS_ID, его проставляет сервер QUIK, связывая номер заявки с тем что получен в ответе на транзакцию. В некоторых случаях тело заявки бывает получено раньше ответа на транзакцию. Тогда сервер просто не знает какой TRANS_ID ей указать и отправляет пользователю как есть. Позже, когда ответ на транзакцию получен, сервер проставляет на заявке TRANS_ID.
А какое решение вы предлагаете? Игнорировать при нуле? В этом случае теряются заявки, введенные в терминал руками.
Антонов К. пишет: Вопрос актуальный. Как отслеживать состояние заявки.
Вы можете использовать примечание для решение задачи. Оно в отличии от TRANS_ID содержится в поле BROKERREF которое транслирует биржа, а значит оно точно не потеряется. То есть чтобы робот писал в примечание какой-либо спец признак. Примечание указывается в параметре транзакции CLIENT_CODE после кода клиента, в качестве разделителя добавляется признак "/" или "//" (зависит от настроек на стороне брокера) если в правах только один код клиента, можно его не указывать, а сразу писать примечание.
Egor Zaytsev пишет: Более подробно можете пояснить и привести пример.
Иногда trans_id в колбэкэ OnOrder возвращает заведомо неправильное значение. Тоесть даже не 0, а нечто сверх малое (в диапазоне от 0 до 200). Случается редко (на 1000 заявок всего несколько раз). Но баг сервера Квика не лицо. Где-то ошибка синхронизации данных.
Насчет номера транзакции в комментарии. Данный аргумент ограничен 20 символами, и в этот аргумент передается так же код клиента. Тоесть в некоторых случаях просто невозможно его использовать как признак идентификации транзакции. Как же все таки с т.з. Луа рекомендуется идентифицировать транзакции?
Egor Zaytsev пишет: Более подробно можете пояснить и привести пример.
Иногда trans_id в колбэкэ OnOrder возвращает заведомо неправильное значение. Тоесть даже не 0, а нечто сверх малое (в диапазоне от 0 до 200). Случается редко (на 1000 заявок всего несколько раз). Но баг сервера Квика не лицо. Где-то ошибка синхронизации данных.
Насчет номера транзакции в комментарии. Данный аргумент ограничен 20 символами, и в этот аргумент передается так же код клиента. Тоесть в некоторых случаях просто невозможно его использовать как признак идентификации транзакции. Как же все таки с т.з. Луа рекомендуется идентифицировать транзакции?
Добрый день.
Вопрос про нулевой trans_id уже обсуждался в этой ветке, посмотрите выше ответы Michael Bulychev, он отвечал по этому поводу.
Egor Zaytsev пишет: Более подробно можете пояснить и привести пример.
Иногда trans_id в колбэкэ OnOrder возвращает заведомо неправильное значение. Тоесть даже не 0, а нечто сверх малое (в диапазоне от 0 до 200). Случается редко (на 1000 заявок всего несколько раз). Но баг сервера Квика не лицо. Где-то ошибка синхронизации данных.
Насчет номера транзакции в комментарии. Данный аргумент ограничен 20 символами, и в этот аргумент передается так же код клиента. Тоесть в некоторых случаях просто невозможно его использовать как признак идентификации транзакции. Как же все таки с т.з. Луа рекомендуется идентифицировать транзакции?
Добрый день.
Вопрос про нулевой trans_id уже обсуждался в этой ветке, посмотрите выше ответы Michael Bulychev , он отвечал по этому поводу.
Егор, конечно же я читал ответ. Поэтому и привел вопрос с тем, как быть, если номер транзакции не вмещается из-за слишком длинного кода клиента. Получается это не гарантированное решение, и еще нужно тщательно взвесить, что лучше (нулевая транзакция или же потенциально маленькое поле).
Но многократно хуже ситуация, когда приходит левый номер. Это не ноль, который может отбросить. А совсем левая транзакция. Это 100% баг.
Антонов К. пишет: Поэтому и привел вопрос с тем, как быть, если номер транзакции не вмещается из-за слишком длинного кода клиента
Не видим в этом какой-либо проблемы Зачем в комментарий записывать именно номер транзакции. Пишите буквы+цифры, например в шестнадцатиричной системе. Таким образом можно сжать любой номер до нескольких символов.
Цитата
Антонов К. пишет: Но многократно хуже ситуация, когда приходит левый номер. Это не ноль, который может отбросить. А совсем левая транзакция. Это 100% баг.
Да так не должно быть. Для анализа нам нужен конкретный пример. От Вас требуется сообщить кто Ваш брокер, через какой сервер работаете и Ваш UID Воспроизвести проблему и сообщить нам все параметры транзакции которые отправлялись со стороны Lua (например можно добавить логирование) И точное время отправки транзакции. Мы в свою очередь получив эту информацию, свяжемся с Вашим брокером и посмотрим что происходило с транзакцией со стороны сервера. После чего сообщим причин и примем меры.
Если Вы считаете запрошенную информацию конфиденциальной, можно сообщить ее нам на адрес quiksupport@arqatech.com
Антонов К. пишет: Вопрос актуальный. Как отслеживать состояние заявки.
Вы можете использовать примечание для решение задачи. Оно в отличии от TRANS_ID содержится в поле BROKERREF которое транслирует биржа, а значит оно точно не потеряется. То есть чтобы робот писал в примечание какой-либо спец признак. Примечание указывается в параметре транзакции CLIENT_CODE после кода клиента, в качестве разделителя добавляется признак "/" или "//" (зависит от настроек на стороне брокера) если в правах только один код клиента, можно его не указывать, а сразу писать примечание.
Заявки, переставляемые транзакцией "MOVE_ORDERS", таскают за собой параметр brokerref от самой первой заявки. Это нормальная ситуация?
Надо делать так, как надо. А как не надо - делать не надо.
Здравствуйте, MOVE_ORDERS является биржевой транзакцией brokerref является биржевым параметром. В связи с чем, раз биржа переносит brokerref значит биржа считает это нормальной ситуацией. За комментариями к специалистам биржи.