deisik (Все сообщения пользователя)

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


Кто ориентируется на заявки в начальной рассылке имейте этот нюанс в виду – список заявок в ней берется не с биржи и не с сервера, а из кеша терминала

Если в момент отправки транзакции происходит разрыв соединения, то эта транзакция может уйти уже после восстановления соединения – номер выставленной по ней заявки больше номера последней заявки, полученной в начальной рассылке


Я считаю такое поведение некорректным

Дополню свой предыдущий вопрос

Одна и та же ошибка приходит с разными кодами:
"Не найдена активная заявка для перестановки" – ошибка с кодом 6
"Ошибка перестановки заявок. [GW][50] "Не найдена заявка для перестановки." – ошибка с кодом 4

Неужели так трудно добавить подфункцию в коллбеке TRANS2QUIK_TRANSACTION_REPLY_CALLBACK, чтобы получить код ошибки биржи?

При перестановке заявок часто исполняется старая заявка и приходит сообщение "Не найдена активная заявка для перестановки". Это сообщение биржи, насколько я понимаю. Однако в этом случае в параметре nTransactionReplyCode возвращается значение 6 – "Транзакция не прошла проверку лимитов сервера QUIK"

О какой проверке лимитов сервера QUIK здесь идет речь и имеется ли вообще какая-нибудь взаимосвязь между статусами в nTransactionReplyCode и реальными ошибками, возвращаемыми биржей?

Спасибо за информацию

Правильно ли я понимаю, что ограничение устанавливается биржей для брокера в целом, а не для его клиентов по отдельности?

В первый раз столкнулся с такой ошибкой при реальной торговле – "Ошибка перестановки заявок. [GW] "Превышен лимит отправки транзакций для данного логина"

Соответственно, вопрос. Кем устанавливается это ограничение – брокером или биржей?

Еще вдогонку вопрос по этой же теме

Для чего нужен параметр nTransactionExtendedErrorCode (второй в колбеке TRANS2QUIK_TRANSACTION_REPLY_CALLBACK)? Согласно документации "в случае возникновения проблемы при выходе из функции обратного вызова в переменную может быть помещен расширенный код ошибки".

Что здесь понимается под "выходом из функции обратного вызова", и кто (что) помещает в эту переменную "расширенный код ошибки"? Если сам колбек, тогда почему в него передается значение, а не ссылка?

Окей

Если я правильно понимаю ваш ответ, частично исполненная заявка в любом случае (в начальной рассылке или непосредственно при частичном исполнении) передается в соответствующий колбек со статусом "Активная заявка" (1) до тех пор, пока она не будет полностью исполнена?

Добрый день

У меня вопрос, как в начальной рассылке передается частично исполненный ордер и в каком порядке, если он передается несколько раз (например, как исполненный и как активный)

250-300 тысяч

И можно сделать так, чтобы мне не загружать +200 тысяч старых заявок?

Второй раз наблюдаю повторную загрузку всех старых заявок после окончания начальной рассылки. Сегодня это было утром, а перед этим было пару недель назад перед вечерней сессией

При этом параметр nMode в колбеке TRANS2QUIK_ORDER_STATUS_CALLBACK имеет значение 0, т.е. это не повторная начальная рассылка. Сегодня начальная рассылка (nMode = 1) началась в 08:32:28 и закончилась в 08:38:10, а после этого опять начали приходить те же заявки из начальной рассылки, но уже как новые (nMode = 0)

Прошу прокомментировать эту ситуацию

Сколько у вас транзакций в день по одному инструменту?

Если -> Есть ли

Как отслеживать ошибки (например, описанную выше приостановку торгов) в TRANS2QUIK_TRANSACTION_REPLY_CALLBACK? Если какая-нибудь подфункция, которую можно вызвать внутри TRANS2QUIK_TRANSACTION_REPLY_CALLBACK через дескриптор ответа на транзакцию, чтобы получить код ошибки?

Ну и теперь более конкретно

Тестовый сервер:

Сначала идет вызов колбека TRANS2QUIK_TRANSACTION_REPLY_CALLBACK с транзакцией 443606 и заявкой 1892957001206697733, т.е. ответ на транзакцию уже получен и номер заявки сопоставлен номеру транзакции

Потом вызывается TRANS2QUIK_ORDER_STATUS_CALLBACK с транзакцией 0 и заявкой с тем же номером 1892957001206697733

Каким образом сервер не знает, что заявка 1892957001206697733 создана транзакцией 443606, если ранее вызывался TRANS2QUIK_TRANSACTION_REPLY_CALLBACK с этой транзакцией и этой заявкой?

При перестановке заявки сперва вызывается колбек TRANS2QUIK_TRANSACTION_REPLY_CALLBACK, а потом колбек TRANS2QUIK_ORDER_STATUS_CALLBACK

А теперь вопрос, как в TRANS2QUIK_ORDER_STATUS_CALLBACK может прийти ордер с TRANS_ID=0 (что и происходит на практике), если ранее в TRANS2QUIK_SET_TRANSACTIONS_REPLY_CALLBACK уже пришла транзакция с сопоставленным ей номером заявки?

Если колбек может вызываться из разных потоков, то, возможно, это у меня возникает race condition

Поглядим...

Уже несколько раз сталкиваюсь с зависанием моего торгового бота на реальном сервере, которое с большой долей вероятности вызвано проблемами в Trans2Quik.dll

Зависание происходит в интервале от нескольких часов до нескольких суток, не зависит от активности на бирже и происходит при практически одновременной асинхронной подаче двух разных заявок по изменению их цены (перестановка заявок).

То, что проблема именно с Trans2Quik.dll подтверждается следующим:
- возврат из функции TRANS2QUIK_SEND_ASYNC_TRANSACTION происходит со статусом 0 (TRANS2QUIK_SUCCESS) в обоих случаях, т.е. без ошибок (бот успевает записать заявки в лог после возврата из функции)
- обе заявки остаются активными в терминале Quik и их потом приходится снимать вручную – запрос до биржи не доходит ни по одной из заявок
- в самом Quik также ничего не происходит

Если нужна более детальная информация (что отправляется на сервер), могу предоставить ее в личку

Прошу разобраться в этой проблеме

Зачем тогда было вообще городить огород с типа "рыночными" заявками? Вместо решения псевдопроблемы вы создали условия для появления реальной проблемы

Я уже не говорю о введении в заблуждение -- "Такое поведение невозможно"

Это оказалась неправдой

Транзакция с рыночной заявкой на продажу по цене ниже лучшей на покупку (т.е. в любом случае заявка должна была выполниться сразу) пришла в функцию обратного вызова TRANS2QUIK_ORDER_STATUS_CALLBACK со статусом 1 (активная заявка) и сообщением "Заявка 1892956880947543031 успешно зарегистрирована"

Использовался тестовый сервер

Запрос: CLASSCODE=SPBFUT; ACTION=NEW_ORDER; ACCOUNT=SPBFUT000hd; TRANS_ID=233503; QUANTITY=1; TYPE=M; SECCODE=SiU3; OPERATION=S; PRICE=84294

Номер заявки: 1892956880947543031

Прошу пояснить эту ситуацию

Я описываю ситуацию, когда TRANS_ID задается пользователем, и отправляется вместе с "телом" заявки. Другими словами, сервер не может не знать TRANS_ID

При создании новой заявки функция TRANS2QUIK_ORDER_STATUS_CALLBACK вызывается два раза -- в первый раз с номером транзакции 0, а второй раз с номером, который был указан в заявке

Это ожидаемое поведение?

Окей, спасибо

Может ли статус рыночной заявки (TYPE=M), получаемый через функцию обратного вызова TRANS2QUIK_ORDER_STATUS_CALLBACK, принимать значение 1 (активная заявка)?

Дабы два раза не вставать, такие вопросы:

1. Можно ли сразу получить статус заявки (снята/выставлена/исполнена) через TRANS2QUIK_SEND_SYNC_TRANSACTION (TRANS2QUIK_SEND_ASYNC_TRANSACTION) без использования функции обратного вызова TRANS2QUIK_ORDER_STATUS_CALLBACK?

Такой вопрос возникает при отправке рыночной заявки, но с указанием цены лучшей покупки/продажи (или лимитированной зачвки FILL-OR_KILL). Например, цена может уйти и заявка снимается -- но из ответа TRANS2QUIK_SEND_SYNC_TRANSACTION я этого не могу определить (статус заявки всегда возвращается 3 -- "транзакция выполнена")

2. Можно ли одним вызовом отправить две заявки по разным бумагам с условием, если исполняется первая заявка (например, FILL-OR_KILL), то выставляется заявка по второй бумаге?


Заранее благодарю за дельные ответы и советы!

Можно ли узнать через api последнюю (текущую) цену по бумаге?