Нулевой transaction_id

Страницы: 1 2 След.
RSS
Нулевой transaction_id, Проскакивает нулевой transaction_id
 
Приветствую всех.
Написал минимальный луа-скрипт, который пишет лог по событию 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#, так как нами подобные вещи ранее не замечались.
 
Видимо да.. я почему-то думал, что id транзакции генерирует либо квик либо биржа. Спасибо за ответ, пойду копаться в S#.
 
Цитата
Egor Zaytsev пишет:
Как понимаем trans_id у Вас формируется автоматически?
Посмотрите на стороне S#, так как нами подобные вещи ранее не замечались.
Egor Zaytsev, транзакция, подданная через API с нулевым trans_id будет отвергнута сервером, разве нет?

Цитата
Денис X пишет:
По некоторым ордерам (небольшой части относительно общей массы) событие приходит с нулевым trans_id. А затем приходит с нормальным id.
Денис X, по всем ли ордерам приходит trans_id? Возможно, часть из этих ордеров поданы вручную?
Надо делать так, как надо. А как не надо - делать не надо.
 
По всем приходит. Точно не вручную, все ордера поданы одним способом.
 
Тогда не понятно, что можно "посмотреть на стороне S#"
Надо делать так, как надо. А как не надо - делать не надо.
 
https://forum.quik.ru/messages/forum10/message6266/topic617/#message6266
Цитата
Олег Хуснутдинов пишет:
Таблица заявок - обновляемая таблица. Поэтому, теоретически, обновлён (дописан/удалён) может быть любой параметр, кроме ключевых (ключевые это Номер заявки, Дата торгов, Код класса). На практике же дописывается UID и ID транзакции. Сделано это для того, чтобы как можно скорее отправить информацию о заявке пользователю и не ожидать определения всех атрибутов заявки (определение UID и ID транзакции происходит внутри сервера QUIK и занимает какое-то время).
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Денис X пишет:
По всем приходит. Точно не вручную, все ордера поданы одним способом.
В логе из первого сообщения - для ордеров, начинающихся на "num:1394" - всегда "transaction:0"
 
Ситуация такая. По некоторым ордерам сначала приходит сообщение, о новом ордере, с нулевым transaction_id, затем приходит сообщение о новом ордере (этом же самом) с нормальным trans_id. Затем приходит сообщение о том, что ордер с нормальным trans_id исполнился, а по нулевому естественно  не приходит. И в итоге в S# в списке активных ордеров есть лишние (те, по которым пришло сообщение с нулевым trans_id).
Что именно можно насмотреть в S# я сам пока не особо понимаю, пока просто попробую разобраться в механизме обмена сообщениями с квиком.
 
Цитата
user пишет:
В логе из первого сообщения - для ордеров, начинающихся на "num:1394" - всегда "transaction:0"
Хм, сам я на это не обратил внимание. Затрудняюсь сказать, что это значит. Возможно этот ордер и был выставлен руками..  но остальные ордера с нулевым trans_id точно выставлялись моей программой через S#
 
Подниму тему. Убедился, что дело точно не в StockSharp. Набросал минимальный lua-скрипт, для выставления заявок на продажу и на покупку.
Запустил свой логер и начал покупать-продавать через новый скрипт. Ситуация как и в первом посте, по небольшой части заявок приходят сообщения с нулевым transactionId.

Новый лог: https://www.sendspace.com/file/41dxty

На всякий случай выложу еще скрипты логера и торговой формы. За качество кода прошу не пинать, на луа вообще не программирую и скрипты написал на коленке за 5 минут, лишь бы работало.
Форма торговая требует библиотеку VCLua в папке квика.
Логер: http://pastebin.com/PhSPCuGi
Форма для торговли: http://pastebin.com/q5LXxwzk
 
Хотелось бы услышать от представителя разработчиков ответ, ситуации с нулевыми transactionId это баг или допустимое поведение?
 
Цитата
Денис X пишет:
Хотелось бы услышать от представителя разработчиков ответ, ситуации с нулевыми transactionId это баг или допустимое поведение?
Добрый день.
Да, это допустимое поведение.
 
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
 
Алгоритмы обработки зависят от решаемых задач, тут сложно подсказать универсальный рецепт. Насчет разных флагов - можно сказать точнее если знать параметры транзакции и ответ торговой системы
 
Michael Bulychev пишет:
Цитата
Насчет разных флагов - можно сказать точнее если знать параметры транзакции и ответ торговой системы
Какие именно параметры? Заявки выставлялись следующим кодом:
function onButtonBuyClick(sender)
       qt = getQuoteLevel2(secClass, secCode)
       bid = qt.bid[qt.bid_count+0].price;
       transaction={
                                       ["CLASSCODE"]=secClass,
                                       ["ACTION"]="NEW_ORDER",
                                       ["ACCOUNT"]=account,
                                       ["OPERATION"] = "B",
                                       ["SECCODE"] = secCode,
                                       ["PRICE"] = tostring(bid+0),
                                       ["QUANTITY"] = tostring(1)
                               }
       transaction.TRANS_ID = GetTransId();
       res = sendTransaction(transaction);
end
 
Понятнее не стало. Какой ответ был на транзакцию? на каком рынке совершалась операция?
В любом случае, заявка с нулевым trans_id допускается. Причины уже были описаны выше в этой ветке.
 
Цитата
Michael Bulychev пишет:
Алгоритмы обработки зависят от решаемых задач,
Задача - отслеживать состояние своих ордеров. Если более конкретно, есть библиотека S#, внутри нее информация об имеющихся ордерах и сообщения об их изменении сопоставляется между собой по transactionId. Соответственно, когда приходит сообщение с нулевым transactionId, оно не сопоставляется с нужным ордером.
 
Цитата
Денис X пишет:
Цитата
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.
 
Цитата
Денис X пишет:
Цитата
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?
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
для ордеров, начинающихся на "num:1394"
Это значит, что эти ордера были выставлены по другой бумаге, а не по SPBFUT RIU5.


Цитата
Денис X пишет:
А ситуация, когда дублирующее сообщение с проставленным transID_не_ придет возможна?
Сообщение в этой же ветке выше:
"В логе из первого сообщения - для ордеров, начинающихся на "num:1394" - всегда "transaction:0""
Денис X, наверное, это:
Цитата
Денис X пишет:
Хм, сам я на это не обратил внимание. Затрудняюсь сказать, что это значит. Возможно этот ордер и был выставлен руками..но остальные ордера с нулевым trans_id точно выставлялись моей программой через S#
Не? Возможно, вам стоит восстановить хронологию событий?
Надо делать так, как надо. А как не надо - делать не надо.
 
Ключевое слово здесь "Возможно". Может быть да, а может быть нет.
И поэтому в моем сообщении звучит вопрос "А ситуация, когда дублирующее сообщение с проставленным transID_не_ придет возможна? ", а не утверждение.
 
Цитата
Старатель пишет:
Как узнать, какие настройки на стороне брокера? Нужно к брокеру обращаться или можно выяснить экспериментальным путём?
Просто посмотреть как комментарий выглядит в таблице заявок.

Цитата
Старатель пишет:
Есть ли какие-то ограничения на содержание этого поля, кроме длины в 20 символов? Я так понимаю, что в поле CLIENT_CODE можно указать тот же Trans_ID?
там можно что угодно написать. с учетом ограничения 20 символов
 
Цитата
Sergey Gorokhov пишет:
Биржа ничего не знает про TRANS_ID, его проставляет сервер QUIK, связывая номер заявки с тем что получен в ответе на транзакцию.
В некоторых случаях тело заявки бывает получено раньше ответа на транзакцию.
Тогда сервер просто не знает какой TRANS_ID ей указать и отправляет пользователю как есть.
Позже, когда ответ на транзакцию получен, сервер проставляет на заявке TRANS_ID.
На всякий случай, цитата из описания интерфейса биржи

http://s019.radikal.ru/i605/1509/5a/3df31570cf9d.png
 
Цитата
user пишет:
На всякий случай, цитата из описания интерфейса биржи
ext_id, судя по описанию, очень похож на TRANS_ID. Так про что там биржа не знает?
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель пишет:
Цитата
user пишет:
На всякий случай, цитата из описания интерфейса биржи
ext_id, судя по описанию, очень похож на TRANS_ID. Так про что там биржа не знает?
а кто сказал что ext_id это trans_id?
к тому же QUIK не только с ФОРТС умеет работать
 
Как получить доступ к ext_id?
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель пишет:
Как получить доступ к ext_id?
Доступа к этому полю нет. И не будет.
 
Цитата
Денис X пишет:
А ситуация, когда дублирующее сообщение с проставленным transID_не_ придет возможна?
Сообщение в этой же ветке выше:
"В логе из первого сообщения - для ордеров, начинающихся на "num:1394" - всегда "transaction:0""
Денис X, видимо, проще самостоятельно проверить: уточните, по какой именно бумаге подавались транзакции с "num:1394", повыставляйте заявки через S#/Lua по этой бумаге и посмотрите, приходят ли вообще по этой бумаге OnOrder с проставленным trans_id.
Надо делать так, как надо. А как не надо - делать не надо.
 
Да, пожалуй, так и сделаю. Спасибо за совет.
 
Цитата
Sergey Gorokhov пишет:
Цитата
Антонов К. пишет:
Цитата
Michael Bulychev пишет:
Понятнее не стало. Какой ответ был на транзакцию? на каком рынке совершалась операция?
В любом случае, заявка с нулевым trans_id допускается. Причины уже были описаны выше в этой ветке.
Столкнулся с аналогичной проблемой. Иногда для заявок приходят подрят несколько раз колбэки с нулевой транзакцией. Затем снова нормально. Затем опять. Рынок ФОРТС. Инструменты фДолларРубль
Биржа ничего не знает про TRANS_ID, его проставляет сервер QUIK, связывая номер заявки с тем что получен в ответе на транзакцию.
В некоторых случаях тело заявки бывает получено раньше ответа на транзакцию.
Тогда сервер просто не знает какой TRANS_ID ей указать и отправляет пользователю как есть.
Позже, когда ответ на транзакцию получен, сервер проставляет на заявке TRANS_ID.
А какое решение вы предлагаете? Игнорировать при нуле? В этом случае теряются заявки, введенные в терминал руками.
 
вообще не обращать внимание на TRANS_ID
для идентификации заявок используйте brokerref
 
Цитата
Николай Камынин пишет:
вообще не обращать внимание на TRANS_ID
для идентификации заявок используйте brokerref
А почему вы думаете, что не будет аналогичной проблемы?
 
Цитата
Антонов К. пишет:
Цитата
Николай Камынин пишет:
вообще не обращать внимание на TRANS_ID
для идентификации заявок используйте brokerref
А почему вы думаете, что не будет аналогичной проблемы?
Потому, что у меня ее нет.
 
Вопрос актуальный. Как отслеживать состояние заявки.
 
Цитата
Антонов К. пишет:
Вопрос актуальный. Как отслеживать состояние заявки.
Вы можете использовать примечание для решение задачи.
Оно в отличии от TRANS_ID содержится в поле BROKERREF которое транслирует биржа, а значит оно точно не потеряется.
То есть чтобы робот писал в примечание какой-либо спец признак.
Примечание указывается в параметре транзакции CLIENT_CODE после кода клиента,
в качестве разделителя добавляется признак "/" или "//" (зависит от настроек на стороне брокера)
если в правах только один код клиента, можно его не указывать, а сразу писать примечание.
 
Цитата
Антонов К. пишет:
Вопрос актуальный. Как отслеживать состояние заявки.
Добрый день.

Как уже сказал Николай, можно использовать для отслеживания заявок - brokerref
 
Цитата
Egor Zaytsev пишет:
Цитата
Антонов К. пишет:
Вопрос актуальный. Как отслеживать состояние заявки.
Добрый день.

Как уже сказал Николай, можно использовать для отслеживания заявок - brokerref
Это какой то хак. А почему нельзя заполнять какой-то нормальное поле ввиде номера транзакции?

Заметил еще один баг. Номер транзакции не нулевой, но и не равен регистрации. Какое-то сверх-малое число (от 1 до 200).
 
Цитата
Антонов К. пишет:
Цитата
Egor Zaytsev пишет:
Цитата
Антонов К. пишет:
Вопрос актуальный. Как отслеживать состояние заявки.
Добрый день.

Как уже сказал Николай, можно использовать для отслеживания заявок - brokerref
Это какой то хак. А почему нельзя заполнять какой-то нормальное поле ввиде номера транзакции?

Заметил еще один баг. Номер транзакции не нулевой, но и не равен регистрации. Какое-то сверх-малое число (от 1 до 200).
Добрый день.

Потому что другой возможности нет.

Код
 Заметил еще один баг. Номер транзакции не нулевой, но и не равен регистрации. Какое-то сверх-малое число (от 1 до 200).

Более подробно можете пояснить и привести пример.
 
Цитата
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 пишет:
Цитата
Антонов К. пишет:
Цитата
Egor Zaytsev пишет:
Более подробно можете пояснить и привести пример.
Иногда trans_id в колбэкэ OnOrder возвращает заведомо неправильное значение. Тоесть даже не 0, а нечто сверх малое (в диапазоне от 0 до 200). Случается редко (на 1000 заявок всего несколько раз). Но баг сервера Квика не лицо. Где-то ошибка синхронизации данных.

Насчет номера транзакции в комментарии. Данный аргумент ограничен 20 символами, и в этот аргумент передается так же код клиента. Тоесть в некоторых случаях просто невозможно его использовать как признак идентификации транзакции. Как же все таки с т.з. Луа рекомендуется идентифицировать транзакции?
Добрый день.

Вопрос про нулевой trans_id уже обсуждался в этой ветке, посмотрите выше ответы Michael Bulychev ,
он отвечал по этому поводу.
Егор, конечно же я читал ответ. Поэтому и привел вопрос с тем, как быть, если номер транзакции не вмещается из-за слишком длинного кода клиента. Получается это не гарантированное решение, и еще нужно тщательно взвесить, что лучше (нулевая транзакция или же потенциально маленькое поле).

Но многократно хуже ситуация, когда приходит левый номер. Это не ноль, который может отбросить. А совсем левая транзакция. Это 100% баг.
 
Цитата
Антонов К. пишет:
Поэтому и привел вопрос с тем, как быть, если номер транзакции не вмещается из-за слишком длинного кода клиента
Не видим в этом какой-либо проблемы
Зачем в комментарий записывать именно номер транзакции. Пишите буквы+цифры, например в шестнадцатиричной системе. Таким образом можно сжать любой номер до нескольких символов.
Цитата
Антонов К. пишет:
Но многократно хуже ситуация, когда приходит левый номер. Это не ноль, который может отбросить. А совсем левая транзакция. Это 100% баг.
Да так не должно быть.
Для анализа нам нужен конкретный пример.
От Вас требуется сообщить кто Ваш брокер, через какой сервер работаете и Ваш UID
Воспроизвести проблему и сообщить нам все параметры транзакции которые отправлялись со стороны Lua (например можно добавить логирование)
И точное время отправки транзакции.
Мы в свою очередь получив эту информацию, свяжемся с Вашим брокером и посмотрим что происходило с транзакцией со стороны сервера. После чего сообщим причин и примем меры.

Если Вы считаете запрошенную информацию конфиденциальной, можно сообщить ее нам на адрес quiksupport@arqatech.com
 
Цитата
Sergey Gorokhov пишет:
Цитата
Антонов К. пишет:
Вопрос актуальный. Как отслеживать состояние заявки.
Вы можете использовать примечание для решение задачи.
Оно в отличии от TRANS_ID содержится в поле BROKERREF которое транслирует биржа, а значит оно точно не потеряется.
То есть чтобы робот писал в примечание какой-либо спец признак.
Примечание указывается в параметре транзакции CLIENT_CODE после кода клиента,
в качестве разделителя добавляется признак "/" или "//" (зависит от настроек на стороне брокера)
если в правах только один код клиента, можно его не указывать, а сразу писать примечание.

Заявки, переставляемые транзакцией "MOVE_ORDERS", таскают за собой параметр brokerref от самой первой заявки. Это нормальная ситуация?
Надо делать так, как надо. А как не надо - делать не надо.
 
Здравствуйте,
MOVE_ORDERS является биржевой транзакцией
brokerref является биржевым параметром.
В связи с чем, раз биржа переносит brokerref значит биржа считает это нормальной ситуацией.
За комментариями к специалистам биржи.
Страницы: 1 2 След.
Читают тему
Наверх