Квик, андроид и импорт транзакций из файла.
Предистория:
По роду своей деятельности у меня нет возможности постоянно находиться у торгового
монитора и до недавнего времени использовал 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 заявки.