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

Страницы: 1
RSS
Перемещение заявки 2 транзакциями
 
Как известно, на основной секции биржи нельзя это сделать одной транзакцией (а жаль).
В итоге мы сначала снимаем старую заявку, потом создаем новую.
Проблема в том, что между этими транзакциями приходится ждать сколько-то много мс, иначе создание еще не понимает, что перед этим отправлена транзакция снятия. И выдает ошибки типа данный инструмент запрещен в шорт (считая, что продажа еще висит).
Сделайте вторую версию sendTransaction, которая бы не проверяла подобные локальные условия. Чтобы можно было вызывать 2 транзакции сразу друг за другом. Ну или с минимальной задержкой. Чтобы они пришли на биржу в том же порядке и обработались.
 
Андрей, Сколько заявок Вы посылаете в сутки? За каким лешим Вам нужны эти "много мс" - тем более, которые В ПРИНЦИПЕ нельзя обеспечить. Как и порядок следования, кстати.

Фрагмент из ТЗ на мой скрипт.
Неисполненные или частично исполненные заявки снимаются через три минуты активности (период отсчитывается с момента подачи заявки и продлевается после каждой совершённой сделке по этой заявке). Новые заявки по тикеру не открываются в режиме автоматической торговли, пока не закрыты все старые.
МИНУТЫ, блин!
 
Цитата
Владимир написал:
Андрей, Сколько заявок Вы посылаете в сутки? За каким лешим Вам нужны эти "много мс" - тем более, которые В ПРИНЦИПЕ нельзя обеспечить. Как и порядок следования, кстати.

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

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

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

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

Контроль достаточности средств клиента на Фондовом рынке МБ осуществляется сервером QUIK, а не биржей.
Разумеется, пока одна из транзакций пройдет проверку на сервере, будет отправлена на биржу, с биржи вернется соответствующий ответ и исходя из него будут изменены Ваши позиции, пройдет какое-то время (исчисляемое в миллисекундах).

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

В случае, если мы не совсем правильно Вас поняли, просьба подробнее описать, что имелось в виду под
Цитата
Андрей написал:
Либо надо уметь его отключать и пусть все идет на биржу, а там уже получать отказ, если дейтсвительно снятие не отработало.. либо при снятии прописывать инфо в пре-фильтр, чтобы он не ждал чего-то, что ждет сейчас
 
Цитата
Roman Azarov написал:
Андрей, добрый день!

Контроль достаточности средств клиента на Фондовом рынке МБ осуществляется сервером QUIK, а не биржей.
Разумеется, пока одна из транзакций пройдет проверку на сервере, будет отправлена на биржу, с биржи вернется соответствующий ответ и исходя из него будут изменены Ваши позиции, пройдет какое-то время (исчисляемое в миллисекундах).

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

В случае, если мы не совсем правильно Вас поняли, просьба подробнее описать, что имелось в виду под
Цитата
Андрей написал:
Либо надо уметь его отключать и пусть все идет на биржу, а там уже получать отказ, если дейтсвительно снятие не отработало.. либо при снятии прописывать инфо в пре-фильтр, чтобы он не ждал чего-то, что ждет сейчас
Когда речь о двух транзакциях 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) для данного особого (но практически полезного) случая, тем более что это не должно быть сложно.
 
Цитата
Андрей написал:
Сделать вторую версию ф-ции sendTransaction, которая пропускает "проверку достаточности средств на сервере", идет сразу на биржу. Таким образом отправленные 2 транзакции обработаются без проблем, если прийдут на биржу в таком же порядке. Это уже достаточный уровень функционала. В худшем случае биржа просто не обработает вторую транзакцию, Ведь ваша проверка на сервере Quik - это как пре(дварительный)фильтр. Без него ничего страшного тоже не произойдет - получим отказ от биржи в реплае.
С этим предложением, Андрей, вы погорячились.  :smile:  А, вообще, вам нужен прямой доступ на биржу без всякого этого, уж если вам скорость так критична.
 
Цитата
Андрей написал:
Проблема в том, что между этими транзакциями приходится ждать сколько-то много мс, иначе создание еще не понимает, что перед этим отправлена транзакция снятия.

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

Цитата
Андрей написал:
1) Сделать вторую версию ф-ции sendTransaction, которая пропускает "проверку достаточности средств на сервере", идет сразу на биржу.

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

Цитата
Андрей написал:
Ведь ваша проверка на сервере Quik - это как пре(дварительный)фильтр. Без него ничего страшного тоже не произойдет

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

Цитата
Андрей написал:
Без него ничего страшного тоже не произойдет - получим отказ от биржи в реплае.

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

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

Так что только самостоятельно, ручками в своём роботе каждому придётся решать эту задачку. Сообразно своему видению правильных путей разрешения краевых сценариев.
 
Событийная модель и приводит к тому, что создание ордера требует паузы в 100-300мс после снятия. Надо думать как обеспечить функционал, аналогичный MOVE_ORDERS срочного рынка. Почему там это есть, а здесь нет?

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

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

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

даже на срочном рынке, где транзакция move_orders исполняется по одному приказу, снятие заявок происходит последовательно. При этом возможны ситуации, когда одна заявка будет снята, а вторая не будет, а будет уже исполнена или частично исполнена.
 
Цитата
s_mike@rambler.ru написал:
Сделать снятие на бирже двух заявок "мгновенно" не может никто. Ни скрипт, ни сервер, ни даже биржа.

даже на срочном рынке, где транзакция move_orders исполняется по одному приказу, снятие заявок происходит последовательно. При этом возможны ситуации, когда одна заявка будет снята, а вторая не будет, а будет уже исполнена или частично исполнена.
О снятии 2 речи не идет. Мы про снятие+создание с оптимизацией контроля лимитов в этой операции.
Указанные особенности MOVE_ORDERS понятны и ничему не противоречат.
 
Как MOVE_ORDERS в режиме 1 и с 1 заполненной заявкой из двух.
 
Цитата
Андрей написал:
Событийная модель и приводит к тому, что создание ордера требует паузы в 100-300мс после снятия.

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

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

Цитата
Андрей написал:
Тогда я не совсем понимаю, чего ждет сервер QUIK от биржы на клиентский KILL_ORDER.

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

Цитата
Андрей написал:
Я никак не могу отправить изменение ордера за 20мс, хотя очевидно, что лимиты позволяют.

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

Цитата
Андрей написал:
Но без доплат )

Прикольный ты чувак :)
 
Цитата
Андрей написал:
В идеале предлагаю реализовать эмуляцию типа транзакции MOVE_ORDERS в системе QUIK, раз этого нет в биржевом интерфейсе.

Есть такой модель "алгоритмической торговли"
https://arqatech.com/ru/products/quik/modules/infrastructure-solutions/algorithmic-trading-module/

В описании move не вижу, но, думаю, по желанию заказчика смогут добавить для вас такую штуку.

Цитата
Андрей написал:
Это можно реализовать куда оптимальнее на вашей стороне, чем 2 транзакциями как сейчас.

Вы так пишете, как-будто это можно сделать как-то иначе, нежели 2-мя транзакциями на биржу.
 
100-300 это до первого onTransReply по trans_id KILL_ORDER. А ваши события можно получать как-то иначе? Если нет, то очевидно, что ничего быстрее событийная модель не обеспечивает. Зачем мириться, если все достижимо, надо только доработать алгоритм снятия лимитов при KILL_ORDER. Чтобы не ждал лишнего от биржи, а делал это авансом, грубо говоря. Всё там возможно. А иначе дело даже не в "на всю котлету". В первом сообщении я писал про ошибку изменения ордера продажи своих, не маржинальных, акций. В шорт их не дают. Соответственно, даже при свободных лимитах, переставить не получается. Без доплаты - а что тут прикольного? Это очевидная вещь - оптимизировать связку снятие+создание как единую логическую операцию.
 
Это не должно требовать прямого доступа на биржу )
 
Или вы про колбек OnMoneyLimit? Я не измерял насколько он раньше, чем 1й onTransReply, но экспериментально видел, что за 50мс отправлять создание не получается.
В любом случае связку снятие+создание (оптимизация расчета лимитов) можно и полезно реализовать, раз разработчики говорят, что снижекние задержки является приоритетом.
 
Господи, ну что вы всё время эти несчастные миллисекунды ловите? Сколько времени проходит не на само передвижения заявки, а период от её выставления до снятия, передвижения или срабатывания? Секунды, минуты, часы, а иногда даже дни (здесь встречались пожелания, чтобы выставленные заявки переносились на следующий день). Здесь уже писалось, что "реализовать описанное вами невозможно". Не знаю - может, и так. Но даже если это возможно, НЕ НУЖНО "дорабатывать алгоритм снятия лимитов"! Ничего, кроме новых глюков, это не принесёт.
 
И алгоритмически перемещение заявки должно выполняться именно как снятие и выставление новой! Зачем вы вообще подаёте заявку? Чтобы она сработала! А если она не сработала, значит, что-то пошло не так, и потому требуется именно СНЯТЬ эту неудачную заявку, а потом ПОДУМАТЬ, выставлять ли её снова, и если выставлять, то по какой цене и каким объёмом. Тем более, что заявки могут быть частично исполненными. Наконец, ни брокеру, ни бирже нет никакого дела до проблем юзера, и заставлять их менять свои алгоритмы по его капризам - что-то там откладывать, что-то не проверять - есть глупость несусветная.
 
Надо, Федя.. надо..
Вполне простая вещь - передвинуть заявку. Для клиента это по смыслу одна операция. Даже чисто технически это сложно сейчас сделать, разбивая на стадии, ожидая колбеки после снятия.. Ожидание разблокирования лимитов при KILL_ORDER можно и нужно оптимизировать. Как минимум в рамках вот такой пары - снятие+создание. Которую можно реализовать эмуляцией MOVE_ORDERS.
 
А кто говорит, что сложная? Снял старую заявку, посмотрел, чего надо, поставил новую.  :smile: Я же писал, что именно для клиента это по смыслу ДВЕ операции! Я вот не передвигаю заявки НИКОГДА. Точнее, я-то когда-то передвигал (хотя и это было давно), а вот мой скрипт - НИКОГДА! И что ещё за "ожидание колбеков после снятия"? Лично у меня есть только OnTrade, и ничего больше. Плевать мне на коллбеки после снятия! Подал заявку на снятие заявки - и пусть канает! А я уж сам у себя "разблокирую лимиты при KILL_ORDER", рассчитывая на то, что снять мою заявку по её номеру система в состоянии. А даже если не снимет (что бывает чрезвычайно редко) - не беда: либо снимется по окончанию торговой сессии, либо сработает как "левая" заявка. И ничего не надо оптимизировать. И я задал вопрос: "Сколько времени проходит не на само передвижения заявки, а период от её выставления до снятия, передвижения или срабатывания?"
 
Время ответа на транзакции - это не детерминированная величина. В ядро биржи уходят лимитные заявки. В ядре биржи всегда будут транзакции атомарны: снять, поставить.
При существенной нагрузке на сервера биржи и брокера ответ на команды может приходить совсем не быстро. Мой наблюдаемый рекорд - 12 минут.

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

Поэтому контроль перед подачей транзакции будет всегда.
 
Андрей, добрый день!

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

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

Цитата
Игорь М написал:
вам нужен прямой доступ на биржу
А кто в этом случае контролирует лимиты?
 
Цитата
Незнайка написал:
Цитата
Андрей написал:
ошибки типа данный инструмент запрещен в шорт
 
Цитата
Андрей написал:
Сделайте вторую версию sendTransaction, которая бы не проверяла подобные локальные условия. Чтобы можно было вызывать 2 транзакции сразу друг за другом.
Вы не подумали, что первая заявка может исполниться, пока транзакция на её снятие дойдёт до биржи?
Тогда, при исполнении второй заявки, получится как раз шорт.
А это нарушение. Брокер будет вынужден закрывать ваш шорт принудительно.

Цитата
Игорь М написал:
вам нужен прямой доступ на биржу
А кто в этом случае контролирует лимиты?Никаких нарушений не возникнет
Не парьтесь никаких нарушений не возникнет.
На бирже торгуете не Вы, а брокер.
Поэтому не важно будет шорт или нет.
У брокера достаточно средств клиентов и бумаг клиентов  для покрытия всех его ( т е его клиентов) сделок
За достаточностью средств у брокера следит биржа .
 
Цитата
nikolz написал:
Не парьтесь никаких нарушений не возникнет.
nikolz, наверное, и про УДС, НПР и пр. ничего не слышал.
Ещё и маржин-колл какой-то придумали. Не, не слышал...
 
Цитата
Roman Azarov написал:
Андрей, добрый день!

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

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

Цитата
Андрей написал:
Эмулировать - значит дать пользователю 1 вызов API, а в нем инкапсулировать KILL_ORDER и NEW_ORDER, с правильной и оптимальной реализацией ожидания между ними.
Для чего? Пока сервером не будет получен ответ от биржи о том, что заявка была успешно снята, транзакция на выставление новой заявки не пройдет контроль достаточности средств на сервере.

Цитата
Андрей написал:
Вот у меня вопрос - как в точности реализовано перемещение ордера мышкой в стакане?
Точно так же. Отправка KILL_ORDER, ожидание ответа от биржи, проверка NEW_ORDER на сервере, отправка NEW_ORDER на биржу.
Такую же логику Вы можете реализовать и в собственном скрипте.

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

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

Цитата
Андрей написал:
Эмулировать - значит дать пользователю 1 вызов API, а в нем инкапсулировать KILL_ORDER и NEW_ORDER, с правильной и оптимальной реализацией ожидания между ними.
Для чего? Пока сервером не будет получен ответ от биржи о том, что заявка была успешно снята, транзакция на выставление новой заявки не пройдет контроль достаточности средств на сервере.

Цитата
Андрей написал:
Вот у меня вопрос - как в точности реализовано перемещение ордера мышкой в стакане?
Точно так же. Отправка KILL_ORDER, ожидание ответа от биржи, проверка NEW_ORDER на сервере, отправка NEW_ORDER на биржу.
Такую же логику Вы можете реализовать и в собственном скрипте.

Повторимся, пауза между KILL_ORDER и NEW_ORDER (помимо минимальных сетевых задержек) обусловлена ожиданием ответа от биржи, исключить этот момент нельзя.
Во первых для того, что, как минимум, исключаются раундтрипы между клиентом и сервером квик, а это уменьшает общую задержку. Сервер "на коротке" общается с биржей. А вы замерьте, какой % от текущего сетевого ожидания занимает этот путь сервер-биржа. Далее, конкретно, вы ждете onTransReply на KILL_ORDER? Я попросил ответить максимально точно и детально, какого технического сигнала вы ждете. Тут справедливо замечают, что реплай приходит иногда и долше обычного. А перемещение ордера мышкой работает быстрее. Посмотрите точнее данную реализацию. Так же замечу, что реплай на KILL_ORDER почти всегда успешен. Можно было бы и подумать, как оптимизировать и допускать авансом разблокирование лимита. Но ладно, это отдельная тема, пока не об этом. А о том, что внутренние механизмы сигналов (даже не колбеки lua) и обработка связки удаление+создание на сервере дали бы, уверен, неплохое уменьшение задержки.
 
Цитата
Незнайка написал:
Цитата
Игорь М написал:
вам нужен прямой доступ на биржу
А кто в этом случае контролирует лимиты?
Биржа, а брокер в режиме post-trade.
 
Цитата
Андрей написал:
Или вы про колбек OnMoneyLimit? Я не измерял насколько он раньше, чем 1й onTransReply, но экспериментально видел, что за 50мс отправлять создание не получается.
Изначально речь не шла про "быстро". Речь шла про "ненадежно". Именно в этом разрезе я вам и пишу.
И т.к. нужна надежность - то хоть OnMoneyLimit, лимиты по нему меняются, как изменились лимиты - точно можно ставить заявку новую.
А может и OnOrder попробовать. Еще раз подчеркну: речь про надежность, а не про "быстрее".

А если надо быстрее - долбить на все эти события, где-то да пройдет "побыстрее".
 
поясню про быстрее.
Биржевая информация о сделках поступает простым клиентам с задержкой примерно 0.1 секунды.
Компьютер обработает ее и отправит заявку примерно через 0.01 сек  
Поэтому, если хотите быстрее, то используйте выделенный сервер в дата центре брокера.
Будет до 100 быстрее.
 
Цитата
Roman Azarov написал:
Максимально сократить это время - является одной из наших основных задач.
Цитата
Roman Azarov написал:
Пока сервером не будет получен ответ от биржи о том, что заявка была успешно снята, транзакция на выставление новой заявки не пройдет контроль достаточности средств на сервере.

Есть мнение, что лимиты в квике обновляются после получения уведомления по заявке.
Сократить время можно, если обновлять лимиты не только после получения уведомления по заявке, но и после ответа от биржи по транзакции.
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
Страницы: 1
Читают тему (гостей: 1)
Наверх