Перемещение заявки 2 транзакциями

Андрей, Сколько заявок Вы посылаете в сутки? За каким лешим Вам нужны эти "много мс" - тем более, которые В ПРИНЦИПЕ нельзя обеспечить. Как и порядок следования, кстати.

Фрагмент из ТЗ на мой скрипт.
Неисполненные или частично исполненные заявки снимаются через три минуты активности (период отсчитывается с момента подачи заявки и продлевается после каждой совершённой сделке по этой заявке). Новые заявки по тикеру не открываются в режиме автоматической торговли, пока не закрыты все старые.
МИНУТЫ, блин!

Андрей, КОГДА ИМЕННО "нужно передвинуть заявку максимально быстро"? НЕ БЫВАЕТ таких ситуаций! Все эти глупости типа HFT означают фактически отсутствие нормального алгоритма торговли.

Программист (возможно) знает, что делает У СЕБЯ. Заявку он отдаёт в Квик, а у того могут быть свои соображения. У брокера - свои, у биржи свои. И никому из них нет ни малейшего дела до этого несчастного sleep и вообще до проблем скрипта и "знаний" программиста. Не хочет ждать квитанции - его проблемы! У меня тоже задержка через sleep (да и как тут ещё её сделаешь?), но задержка БОЛЬШАЯ, чтобы гарантированно пришли все эти долбаные прерывания, которые приходят по несколько штук на одну заявку и на каждую сделку по ней. И приходят тоже вразнобой.

Кстати, а какой смысл вообще передвигать заявки? Это же скрипт!

Андрей, Охренеть! У меня стакана вообще нет, ибо там время от времени творится чёрт знает что: циферки какие-то бегают со страшной скоростью, а сделок нет. Похоже, что там разные роботы пытаются обдурить друг друга. Но для заработка всё равно нужны реальные сделки. Какая разница, что там творится в стакане? Работают всё равно только BID и OFFER. Если ЭТА цена меня устраивает, я по ней заявку и выставляю. И в 9 случаях из 10 она срабатывает в течение пары секунд. И что за суета? Если я хочу что-то купить, должен найтись тот, кто мне это захочет продать, и наоборот. И если его нет, то хоть в наносекунды заявки выставлять/снимать/передвигать - не поможет.

Классика рулит: "Мы медленно-медленно спустимся вниз, перетрахаем всё стадо и медленно-медленно поднимемся наверх".  

Когда речь о двух транзакциях NEW_ORDER - все понятно. Но когда это по смыслу одна транзакция типа MOVE_ORDERS, которую приходится технически реализовывать двумя (KILL_ORDER, NEW_ORDER) - требуется доработка для этого особого случая. Чтобы эти транзакции можно было подавать одну за другой без паузы и это не приводило к вышеописанным проблемам с проверкой на сервере Quik.
Сходу приходят 2 пути решения:

1) Сделать вторую версию ф-ции sendTransaction, которая пропускает "проверку достаточности средств на сервере", идет сразу на биржу. Таким образом отправленные 2 транзакции обработаются без проблем, если прийдут на биржу в таком же порядке. Это уже достаточный уровень функционала. В худшем случае биржа просто не обработает вторую транзакцию, Ведь ваша проверка на сервере Quik - это как пре(дварительный)фильтр. Без него ничего страшного тоже не произойдет - получим отказ от биржи в реплае. Порядок будет практически обеспечен малейшей ручной задершкой в скрипте (много меньше текущих 100-300 мс).

2) Сделать проверку на сервере Quik более умной. Когда она получает KILL_ORDER, она уже обновляет предварительно допустимый лимит, чтобы последующая NEW_ORDER прошла проверку не дожидаясь ответа биржи на KILL_ORDER. За исключением вырожденных случаев, KILL_ORDER всегда исполняется биржей, поэтому такая оптимизация ожидания ответа на него - оправдана. Повторюсь, поскольку это префильтр, то его роль не критична. В худшем случае получим отбой от биржи вместо отбоя от сервера квик. Но зато обеспечим указанное эффективное редактирование ордера.

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

Вроде бы тут как раз должна пригодиться событийная модель QLua: отправлять вторую транзакцию по изменению состояния первой заявки на "снята".


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


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


Либо первая заявка "сыграет" за это время - что делать со второй?
Или сессия торговая закроется - что делать со второй заявкой? а в первой?

Однозначно "правильно" ответить на эти вопросы не представляется возможным, каждый видит приемлемый для себя вариант.

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

В идеале предлагаю реализовать эмуляцию типа транзакции MOVE_ORDERS в системе QUIK, раз этого нет в биржевом интерфейсе. Это можно реализовать куда оптимальнее на вашей стороне, чем 2 транзакциями как сейчас. Или как минимум сделать учет снятия мгновенным и действующим для последующих NEW_ORDER. Можно для этого как-то отдельно оформить вызов, если не хотите менять текущий механизм. Но это уже будет инструмент.

О снятии 2 речи не идет. Мы про снятие+создание с оптимизацией контроля лимитов в этой операции.
Указанные особенности MOVE_ORDERS понятны и ничему не противоречат.

После какого конкретно события 100-300мс?
(нет события "снятие заявки"; есть отправка транзакции, получения ответа на транзакцию, изменение состояния заявки, изменение состояние лимитов; давайте уже выражаться более точно, для лучшего понимания; "кто ясно мыслит <-> тот ясно излагает")

Потому что такой функционал предоставляет секция срочного рынка.
Пишите ваши пожелания на биржу, здесь про доработки биржевого ядра писать бесполезно.


Сервер QUIK ждет ответа на эту транзакцию. Впрочем, этот ответ ему до лампочки, он его просто транслирует на клиента.
А после, по другому каналу (дада, мир устроен сложнее, чем вам кажется), биржа отправляет информацию об изменении статуса заявки на "снято", в результате чего сервер QUIK уже разблокирует деньги на лимитах.
Одна беда: если не ошибаюсь, сначала изменение заявки рассылается, а уж потом разблокируются лимиты, но это не точно. Впрочем, пока до клиента по сети доедет сигнал об изменении состояния заявки - скорее всего на сервере лимиты уже будут разблокированы; именно поэтому я и предложил именно на это событие реагировать; не понял только из ваших рассуждений: вы попробовали такой вариант?


Возможно надо просто смириться с мыслью, что в рамках обычного клиента QUIK желаемые скорости недостижимы. И надо посмотреть какие еще есть варианты роботизированных подключений; а варианты эти есть.
И что значит "лимиты позволяют"? Не торгуйте на всю котлету, если хочется чудес, торгуйте на пол-котлеты, тогда второй половины будет хватать на все эти move.


Прикольный ты чувак :)

100-300 это до первого onTransReply по trans_id KILL_ORDER. А ваши события можно получать как-то иначе? Если нет, то очевидно, что ничего быстрее событийная модель не обеспечивает. Зачем мириться, если все достижимо, надо только доработать алгоритм снятия лимитов при KILL_ORDER. Чтобы не ждал лишнего от биржи, а делал это авансом, грубо говоря. Всё там возможно. А иначе дело даже не в "на всю котлету". В первом сообщении я писал про ошибку изменения ордера продажи своих, не маржинальных, акций. В шорт их не дают. Соответственно, даже при свободных лимитах, переставить не получается. Без доплаты - а что тут прикольного? Это очевидная вещь - оптимизировать связку снятие+создание как единую логическую операцию.

Или вы про колбек OnMoneyLimit? Я не измерял насколько он раньше, чем 1й onTransReply, но экспериментально видел, что за 50мс отправлять создание не получается.
В любом случае связку снятие+создание (оптимизация расчета лимитов) можно и полезно реализовать, раз разработчики говорят, что снижекние задержки является приоритетом.

И алгоритмически перемещение заявки должно выполняться именно как снятие и выставление новой! Зачем вы вообще подаёте заявку? Чтобы она сработала! А если она не сработала, значит, что-то пошло не так, и потому требуется именно СНЯТЬ эту неудачную заявку, а потом ПОДУМАТЬ, выставлять ли её снова, и если выставлять, то по какой цене и каким объёмом. Тем более, что заявки могут быть частично исполненными. Наконец, ни брокеру, ни бирже нет никакого дела до проблем юзера, и заставлять их менять свои алгоритмы по его капризам - что-то там откладывать, что-то не проверять - есть глупость несусветная.

А кто говорит, что сложная? Снял старую заявку, посмотрел, чего надо, поставил новую.   Я же писал, что именно для клиента это по смыслу ДВЕ операции! Я вот не передвигаю заявки НИКОГДА. Точнее, я-то когда-то передвигал (хотя и это было давно), а вот мой скрипт - НИКОГДА! И что ещё за "ожидание колбеков после снятия"? Лично у меня есть только OnTrade, и ничего больше. Плевать мне на коллбеки после снятия! Подал заявку на снятие заявки - и пусть канает! А я уж сам у себя "разблокирую лимиты при KILL_ORDER", рассчитывая на то, что снять мою заявку по её номеру система в состоянии. А даже если не снимет (что бывает чрезвычайно редко) - не беда: либо снимется по окончанию торговой сессии, либо сработает как "левая" заявка. И ничего не надо оптимизировать. И я задал вопрос: "Сколько времени проходит не на само передвижения заявки, а период от её выставления до снятия, передвижения или срабатывания?"

Андрей, добрый день!

Давайте попробуем изложить свой ответ подробнее.
В биржевом интерфейсе для фондового рынка нет транзакции MOVE_ORDERS. Соответственно, заменить заявку на бирже каким-либо иным образом, кроме как снять ее и затем выставить снова - невозможно. Что конкретно и на каком этапе Вы предлагаете "эмулировать", если биржевым интерфейсом поддерживаются только KILL_ORDER и NEW_ORDER?
Если Вы хотели бы видеть транзакцию для замены заявки, рекомендуем обратиться с подобным пожеланием на биржу.

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

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

Эмулировать - значит дать пользователю 1 вызов API, а в нем инкапсулировать KILL_ORDER и NEW_ORDER, с правильной и оптимальной реализацией ожидания между ними. Вот у меня вопрос - как в точности реализовано перемещение ордера мышкой в стакане? Вы понимаете, что я спрашиваю про паузу между KILL_ORDER и NEW_ORDER по большей части. Там самая оптимальная реализация?

Андрей,

Отдельно заметим, что терминал орудует именно биржевыми транзакциями.
Собирать собственный вариант транзакции, чтобы потом разбить его на сервере и по отдельности отправить на биржу точно также приведет хоть и к небольшим, но задержкам.

Биржа, а брокер в режиме post-trade.

поясню про быстрее.
Биржевая информация о сделках поступает простым клиентам с задержкой примерно 0.1 секунды.
Компьютер обработает ее и отправит заявку примерно через 0.01 сек  
Поэтому, если хотите быстрее, то используйте выделенный сервер в дата центре брокера.
Будет до 100 быстрее.

Возвращаясь к вопросу одинаковости перемещения ордера в стакане мышкой и серии снятие+создание.
Кто додумался в новой версии запретить перемещать на аукционах откр\закр? Чем обусловлено?
Видимо это перемещение реализовано не совсем как снятие+создание на стороне терминала. Иначе особо трудно мотивировать.
Так вы не ответили, как это перемещение технически реализовано. И вот теперь про мотивацию запрета его на аукционах.

Андрей, добрый день!


Можете, пожалуйста, подробнее описать проблему? Какую ошибку Вы получаете при попытке перенести (изменить) заявку в стакане?

Что имеется в виду под "не совсем как снятие+создание"? На сервер (и, в дальнейшем, на биржу) все также отправляется 2 транзакции - снять заявку, выставить заявку.

Чувак, разговаривай спокойнее, ты какой-то нервный, и воздержись от обсценной лексики, с женой так говори, а здесь не надо.