Квик, андроид и импорт транзакций из файла.
Предистория:
По роду своей деятельности у меня нет возможности постоянно находиться у торгового
монитора и до недавнего времени использовал teamviewer в смартфоне, что не совсем удобно.
Задался целью сделать что-то попроще и понаглядней. В итоге смастерил програмулину под андроид,
которая выводит на экран смартфона любую таблицу из квик через DDE-сервер плюс вычисляемые поля.
И вот я уже слежу за рынком на рыбалке ))
В машине )))
на совещании )))
… ))))
И все-бы хорошо, да только нарисовалась одна проблема — быстрый сдвиг активной
заявки в ту или другую сторону. Раньше я транзакции отправлял через Trans2QUIK.dll.
но потом отказался, т.к. на разных компах с разными ОС возникали проблемы.
Железобетонно работал импорт транзакций из файла, пока я не попал в следующую ситуацию:
Сформировав 2 строки транзакции
-удалить старую заявку
-выставить заявку с новой ценой
Получил результат- сработала и старая и новая заявка. Для отладки я разделил пакет
заявок на 2 части 1-удаление, 2- ожидание нажатия клавиши и выставление.
Клавишу нажимаю после сообщения о снятии заявок. Файл транзакций читается каждые 2 сек.
И вот бывают ситуации когда заявка не снимается 2 и более секунд как будто подвисает.
Мне непонятно – как получается, что транзакция с меньшим идентификатором(TRANS_ID)
выполняется позже следующей за ней заявкой.
Уважаемые коллеги трейдеры-программисты.
Подскажите, куда копать, может кто сталкивался с такой бедой.
Уж очень хочется добить программу до конца.
П.с. картинки вставил для удержания внимания т.к. пост довольно нудный.
Сделано для того, чтобы робот отличал свои заявки от чужих.
TRANS_ID=33;CLASSCODE=TQBR;ACTION=KILL_ORDER;ORDER_KEY=14380977616;FIRM_ID=;STATUS=0;TRANS_NAME=«Снятие заявки по номеру»;
TRANS_ID=34;CLASSCODE=TQBR;ACTION=Ввод заявки; Торговый счет = L01-00000F00; К/П = Купля; Тип = Лимитная; Тип по цене = По разным ценам; Тип по остатку = Поставить в очередь; Тип ввода значения цены = По цене; Режим = TQBR; Инструмент = MTSS; Цена = 216,3; Лоты = 1; Примечание = **003346; STATUS=0;TRANS_NAME=«Ввод заявки»;
бывают ситуации когда вторая транзакция срабатывает раньше первой.можете сказать почему?
Игорь Семенов, а что при этом пишется в .tro файл?
Скорее всего дело в том, что квик отправляет заявки на сервер почти одновременно, одну за другой, а там уж как они обработаются — зависит от сервера брокера.
Для надёжности проверить .tro файл на появление строки с подтверждением выполнения первой транзакции (по TRANS_ID) и уже после этого кидать вторую.
как они обработаются — зависит от сервера брокера.
меня заинтересовала
помнится было такое понятие — обработка входного потока
ориентированного на запись и поток. Похоже что ID существует только в визуализации брокера а на биржу кидается пачка записей… хотя записи обрабатываются последовательно)))
ну вроде бы картина вырисовывается
Игорь Семенов, Вообще у меня подозрение, что TRANS_ID существует только для квика :)
По ним он определяет, какие транзакции уже выполнялись.
Вот цитата из документации:
но это уже совсем другая история
спасибо за консалтинг
… а ларчик просто открывался…
Потому, что общение с брокером и биржей идет не по одной транзакции, а пакетами раз в какое-то время. В этот пакет могут попасть сразу несколько транзакций. И от брокера на биржу уйти разбившись на другие пакеты и вторая транзакция может придти раньше. Транзакция выполнится первая та, которая первая придет на биржу.
Надо уточнять у брокера.
Я с этим столкнулся при обновлении стакана. Когда брокер высылает в терминал не каждое обновление, а изменения за 50 мсек. И они могут придти одной кучей.
Это конечно мои домыслы.
Вот у меня например функция OnOrder присылает одну и ту же информацию то 3, то 4 раза с одним статусом. В итоге с момента выполнения заявки и до обновления количество позиций по бумаге проходит какое-то время, за которое робот успевает подать еще несколько заявок. Пока пишу письмо в техподдержку квика.
сервер в каком либо виде наежней по связи и по питанию имхо
по надежности согласен — хотя сервер приложений с данными могу запускать и на домашнем и на рабочем и на семейном компе)))
вы просили совета я вам попытался советовать
время критический фактор в том смысле что при закрытии лонговой позиции можно ненароком открыть шортовую, например вместо закрытия лонга по 100 сдвигаю цену на 100.5.если заявка на 100 не удалилась моей транзакцией АП и сработали 2 заявки.