Как получить список моих активных ордеров и список сделок по моим ордерам?

Страницы: 1
RSS
Как получить список моих активных ордеров и список сделок по моим ордерам?, TRANS2QUIK
 
Собственно вопрос в теме..
 
Цитата
Алексей написал:
Собственно вопрос в теме..
Добрый день.

По ссылке можете скачать наши примеры: http://arqatech.com/upload/iblock/80a/Trans2QuikAPI_1.3_x64.zip
В примере API_Tester_DLG_x64.exe
Далее подключиться к программе, указать код класса, бумагу и выполнить подписку на заявки и сделки командой Subscribe.
 
Спасибо, помогло. Но возник еще вопрос..
Функция TRANS2QUIK_START_ORDERS асинхронна? В течении какого времени гарантированно придут все активные ордера в CallBack???
 
Например если я сделаю вот так :

   TRANS2QUIK_SUBSCRIBE_ORDERS( "", "" );
   TRANS2QUIK_START_ORDERS();
   TRANS2QUIK_UNSUBSCRIBE_ORDERS();

CallBack отработает сколько должен? или не успеет из-за TRANS2QUIK_UNSUBSCRIBE_ORDERS???
 
И еще вопрос возник. Допустим я прикупил некий фьючерс, затем закрыл quik и мою торговую программу. Через неделю все включил. Как мне получить мой целиковый баланс ( свободные рубли, заблокированные на ордерах средства, фьючесы, акции )?


ps: сильно не пинайте, я просто начинающий
 
Поддержка, вы на мои вопросы  *  забили?
 
Цитата
Алексей написал:
Например если я сделаю вот так :

   TRANS2QUIK_SUBSCRIBE_ORDERS( "", "" );
   TRANS2QUIK_START_ORDERS();
   TRANS2QUIK_UNSUBSCRIBE_ORDERS();

CallBack отработает сколько должен? или не успеет из-за TRANS2QUIK_UNSUBSCRIBE_ORDERS???
Добрый день.


Да, должен получить все имеющиеся заявки/сделки.




Цитата
И еще вопрос возник. Допустим я прикупил некий фьючерс, затем закрыл quik и мою торговую программу. Через неделю все включил. Как мне получить мой целиковый баланс ( свободные рубли, заблокированные на ордерах средства, фьючесы, акции )?
Можно смотреть в таблице состояние счета. Пункт меню Создать окно, таблица Состояние счета.

Для просмотра фондового/срочного рынка необходимо будет открыть две такие таблицы и в настройках таблицы указать соответствующую фирму.
 
Описание TRANS2QUIK_UNSUBSCRIBE_ORDERS :
Цитата
Вызов функции прерывает работу функции
TRANS2QUIK_START_ORDERS и производит очистку
списка получаемых инструментов, сформированного
функцией TRANS2QUIK_SUBSCRIBE_ORDERS
Как мне ГАРАНТИРОВАННО получить список моих активных ордеров и список сделок по моим ордерам ИЗ DLL TRANS2QUIK?
 
Цитата
Alexey написал:
Описание TRANS2QUIK_UNSUBSCRIBE_ORDERS :
Цитата
Вызов функции прерывает работу функции
TRANS2QUIK_START_ORDERS и производит очистку
списка получаемых инструментов, сформированного
функцией TRANS2QUIK_SUBSCRIBE_ORDERS
Как мне ГАРАНТИРОВАННО получить список моих активных ордеров и список сделок по моим ордерам ИЗ DLL TRANS2QUIK?
Добрый день.
Получить свои заявки и сделки можно функциями: TRANS2QUIK_SUBSCRIBE_ORDERS, TRANS2QUIK_START_ORDERS и TRANS2QUIK_TRADE_STATUS_CALLBACK и TRANS2QUIK_START_TRADES
По ссылке можете воспользоваться готовым примером по работе функций: https://arqatech.com/upload/iblock/80a/Trans2QuikAPI_1.3_x64.zip
 
Цитата
Добрый день.
Получить свои заявки и сделки можно функциями: TRANS2QUIK_SUBSCRIBE_ORDERS, TRANS2QUIK_START_ORDERS и TRANS2QUIK_TRADE_STATUS_CALLBACK и TRANS2QUIK_START_TRADES
По ссылке можете воспользоваться готовым примером по работе функций: https://arqatech.com/upload/iblock/80a/Trans2QuikAPI_1.3_x64.zip

А вы пост то читали?
 
Цитата
Alexey написал:
Цитата
Добрый день.
Получить свои заявки и сделки можно функциями: TRANS2QUIK_SUBSCRIBE_ORDERS, TRANS2QUIK_START_ORDERS и TRANS2QUIK_TRADE_STATUS_CALLBACK и TRANS2QUIK_START_TRADES
По ссылке можете воспользоваться готовым примером по работе функций:  https://arqatech.com/upload/iblock/80a/Trans2QuikAPI_1.3_x64.zip

А вы пост то читали?
Да, в чем у Вас именно вопрос.
 
После вызова TRANS2QUIK_START_ORDERS, в течении какого времени гарантированно придут все активные ордера в CallBack???
 
Где ответ? Не делайте вид, что вопрос не читали.
 
Цитата
Alexey написал:
Где ответ?
Дык в новосибе ночь уже, тем более пятница. Теперь в понедельник ответ будет, ежли Егора бессонница не мучает. Если хотите рассуждений за вообще, то гарантированно все активные ордера не придут никогда. Рассмотрите ситуацию, квик отправляет заявку и немедленно теряет соединение. Рассмотрите другую, на маршруте между квиком и сервером сдох роутер и трафик идет со скоростью 1 кб/с, соединение при этом не теряется.
 
Цитата
Дык в новосибе ночь уже, тем более пятница. Теперь в понедельник ответ будет, ежли Егора бессонница не мучает. Если хотите рассуждений за вообще, то гарантированно все активные ордера не придут никогда. Рассмотрите ситуацию, квик отправляет заявку и немедленно теряет соединение. Рассмотрите другую, на маршруте между квиком и сервером сдох роутер и трафик идет со скоростью 1 кб/с, соединение при этом не теряется.
Ну тогда вся эта квик система г-но, а ее программеров следует разогнать. Неприход по причине обрыва, это исключительная ситуация которая может и должна быть обработана, а то что скорость низкая, это вообще не аргумент.. тем более, что все транзакции короткие, даже с учетом шифрации.
 
Цитата
Alexey написал:
Ну тогда вся эта квик система г-но
Я бы даже сказал, что это ее имманентное свойство и условие существования (для понимания "почему" см. тарифы мамбы на прямое подключение). Но это не значит, что надо до основанья а затем. Посмотрите на протокол фикс, например, там та же история, вид сбоку. Клиент отправляет запрос и все, он не может переспросить, типа "а я тут заявку номер икс отправлял, чо там с ней?", нет такого в протоколе. Отправил и жди, когда сервер ответит. Равно и квик, отправил и все, приедет ответ - пихнет его в таблицу и дернет колбек, не приедет - а что тут сделать-то, таймер поставить и по истечении его сделать что? И да, косяки тоже имеются, но тут, как говорится, см. пункт первый.
 
Отличным решением было бы информирование о получении всех ордеров в каллбэк (или не получении по истечении таймаута). Как сейчас, если я правильно понимаю, я даже не могу понять все пришло или ждать еще чего..
 
Вот смотрите, вы отправляете 10 заявок сразу, сервер их обрабатывает и посылает ответ "все заявки обработаны". Но пока этот ответ идет по сети, вы отправили еще одну. Тут вам приходит ответ "все заявки обработаны". Все 10 или все 11? Или наоборот, истек таймаут, квик дернул колбек "увы и ах" и тут начали сыпаться ответы. Куда их девать теперь, выбрасывать? Но заявки уже на бирже, часть уже может исполнилась, а ваш код думает, что таймаут истек. Простое решение только одно - сообщения о состоянии индивидуально по каждой транзакции, что квик и делает в меру сил.

В принципе, вы сами можете таймаут прикрутить. Отправляете заявку - ставите таймер, получаете ответ - сбрасываете таймер, если таймер таки сработал - вы не получили ответа за заданный интервал. Видите уже, что вам сделать придется? Ага, хранилище заявок с их состояниями. Более того, вам несколько сущностей понадобится, позиции, заявки, транзакции.
 
Цитата
Вот смотрите, вы отправляете 10 заявок сразу, сервер их обрабатывает и посылает ответ "все заявки обработаны". Но пока этот ответ идет по сети, вы отправили еще одну. Тут вам приходит ответ "все заявки обработаны". Все 10 или все 11? Или наоборот, истек таймаут, квик дернул колбек "увы и ах" и тут начали сыпаться ответы. Куда их девать теперь, выбрасывать? Но заявки уже на бирже, часть уже может исполнилась, а ваш код думает, что таймаут истек. Простое решение только одно - сообщения о состоянии индивидуально по каждой транзакции, что квик и делает в меру сил.

В принципе, вы сами можете таймаут прикрутить. Отправляете заявку - ставите таймер, получаете ответ - сбрасываете таймер, если таймер таки сработал - вы не получили ответа за заданный интервал. Видите уже, что вам сделать придется? Ага, хранилище заявок с их состояниями. Более того, вам несколько сущностей понадобится, позиции, заявки, транзакции.
Все не верно.

1. Не нужно разрешать отправлять заявки во время проверки и это было бы правильно.
2. Куда сыпяться заявки меня не волнует, в каллбеке они должны быть только тогда, когда я их там жду (в нашем контексте). Если программисты квика не знают как это сделать, я подскажу ( хотя это очень просто ).
3. Таймаут не у меня, а у квика, и квик должен меня о его истечении информировать.
4. Таймаут я прикрутить не могу, тк. не знаю все заявки пришли или нет.

5. Не оправдывайте не умение программировать и продумывать систему до мелочей. На моей основной работе за такое программирование в лучшем случае выгонят.
 
Истекший таймаут означает невозможность получения полной инф-ии о заявках, а не их отсутствие/наличие.
 
Цитата
Alexey написал:
1. Не нужно разрешать отправлять заявки во время проверки и это было бы правильно.
Откуда появилась проверка? Кем она была инициирована?
Цитата
4. Таймаут я прикрутить не могу, тк. не знаю все заявки пришли или нет.
Какие "все"? В каком месте вы начали атомарную транзакцию с группой заявок, чтобы требовать ее атомарного завершения?
Цитата
продумывать систему до мелочей
У них QuikFIX есть, чет тут вопросов о нем не видать. А квик продумывать уже поздно, ему больше 20 лет, уже и биржи нет, для которой он писался, и вообще чудо, что он до сих пор в строю. Напишите свой, до мелочей продуманный, может вытесните его с рынка.
Цитата
Истекший таймаут означает невозможность получения полной инф-ии о заявках, а не их отсутствие/наличие.
Тогда можно считать, что таймаут всегда является истекшим. Действительно, начните с этого предположения. Вы отправили что-то, таймаут истек. Ваши действия?
 
Выше и сейчас я пишу как должно быть, а не как есть. Итак.

Цитата
Откуда появилась проверка? Кем она была инициирована?
Эту проверку должен осуществлять квик. Сейчас ее нет. Сделать это можно (по крайней мере при проектировании это было можно).
Цитата
Какие "все"? В каком месте вы начали атомарную транзакцию с группой заявок, чтобы требовать ее атомарного завершения?
Нет никакой атомарной транзакции с группой. Под "все", имеются ввиду все заявки дошедшие до сервера (в тек. сессию). Соответственно все они должны прийти в каллбэк при нормальной работе.
Цитата
Тогда можно считать, что таймаут всегда является истекшим. Действительно, начните с этого предположения. Вы отправили что-то, таймаут истек. Ваши действия?
Нет, нельзя. Это исключительная ситуация. В случае ее возникновения, я делаю повторный запрос, и так до бесконечности. Если я регулярно не могу получить все ордера с сервера, система не работоспособна и требует ремонта/замены или смирения.
 
По-моему, вы мешаете в кучу несколько разных проблем и пытаетесь придумать решение всех их сразу одной серебряной пулей. Если говорить о косяке, когда вы можете вообще не получить никакого ответа на транзакцию, то это косяк, он должен решаться (на стороне квика) не таймаутами, таймаут тут был бы не более чем костылем, причем как раз таким, за который и уволить стоило бы. При условии наличия этого косяка возникает отдельная тема что с ним делать на стороне клиента, но это именно уже другая тема, к пряморукости арки отношения не имеющая.

Другой вопрос - о времени ответа на транзакцию, тут, с одной стороны, никто гарантий давать не будет, а с другой, если косяка, описанного выше, нет, то и дергаться незачем, когда-нибудь ответ придет (или будет разорвано соединение, что тоже своего рода ответ). То, что вы предлагаете, насколько я понял, - это "квик после отправки транзакции встает колом и висит до получения ответа сервера, но не дольше, чем (заданный) таймаут". Так себе решение.
 
Цитата
По-моему, вы мешаете в кучу несколько разных проблем и пытаетесь придумать решение всех их сразу одной серебряной пулей. Если говорить о косяке, когда вы можете вообще не получить никакого ответа на транзакцию, то это косяк, он должен решаться (на стороне квика) не таймаутами, таймаут тут был бы не более чем костылем, причем как раз таким, за который и уволить стоило бы. При условии наличия этого косяка возникает отдельная тема что с ним делать на стороне клиента, но это именно уже другая тема, к пряморукости арки отношения не имеющая.
Согласен.
Цитата
Другой вопрос - о времени ответа на транзакцию, тут, с одной стороны, никто гарантий давать не будет, а с другой, если косяка, описанного выше, нет, то и дергаться незачем, когда-нибудь ответ придет (или будет разорвано соединение, что тоже своего рода ответ). То, что вы предлагаете, насколько я понял, - это "квик после отправки транзакции встает колом и висит до получения ответа сервера, но не дольше, чем (заданный) таймаут". Так себе решение.
Нет, я предлагал не это. Я предлагал информировать меня об успешном завершении получения инф-ии или о невозможности успешного завершения по таймауту.


На самом деле моя задача проста, - получить все активные ордера на текущий момент. API Dll, как сейчас мне представляется, этого сделать не позволяет. И не позволяет по причине кривой реализации Dll и/или квика, и никакие мои костыли в этом не помогут.
 
О факте успешного получения информации как раз и говорит дернутый колбек, невозможность получения информации - это по-хорошему нонсенс, крэш соединения. А вот что рабочее место не всегда колбек дергает, это тот самый косяк. Более того, из неофициальных, тксть, источников, ответ-то от сервера оно при этом получает. Тупо где-то ветка кода упущена.
Цитата
Alexey написал:
API Dll, как сейчас мне представляется, этого сделать не позволяет.
А тут я согласен, и насчет костылей тоже, если говорить о работе чисто через апи. При наличии экспортируемых таблиц обойти можно, но в целом решение будет громоздким и неудобным для енд юзера, лучше сразу со стороны луа заходить. Там тоже не фонтан, только что возможностей для воркэраундов побольше.
 
Цитата
О факте успешного получения информации как раз и говорит дернутый колбек, невозможность получения информации - это по-хорошему нонсенс, крэш соединения. А вот что рабочее место не всегда колбек дергает, это тот самый косяк. Более того, из неофициальных, тксть, источников, ответ-то от сервера оно при этом получает. Тупо где-то ветка кода упущена.
Дернутый каллбэк говорит о конкретном ордере на сервере, но не говорит об их кол-ве или окончанию дерганья. Поэтому по факту невозможно получить все активные ордера на текущий момент.
 
Цитата
Alexey написал:
Поэтому по факту невозможно получить все активные ордера на текущий момент.
Не поэтому только, а по самой природе распределенной системы. Ровно в ту микросекунду, когда рабочее место дернуло ваш код с докладом обо всех заявках, на сервер может подъехать еще одна ваша заявка и опа у нас опять неконсистентность. Запретить отправлять до получения ответа, как вы выше писали, нельзя, это равно синхронной отправке заявок по одной, то есть плюс два пинга на заявку минимум, многие такого "улучшения" не оценят. Правильным решением было бы добавление сущности "группа заявок" с атомарной обработкой, но чета я сомневаюсь, что в народный квик перетащат весь фикс. Даже если арка решит слить свой другой продукт, мамба такого альтруизма может не понять. Впрочем, мы по кругу уже пошли.
 
Цитата
Не поэтому только, а по самой природе распределенной системы. Ровно в ту микросекунду, когда рабочее место дернуло ваш код с докладом обо всех заявках, на сервер может подъехать еще одна ваша заявка и опа у нас опять неконсистентность. Запретить отправлять до получения ответа, как вы выше писали, нельзя, это равно синхронной отправке заявок по одной, то есть плюс два пинга на заявку минимум, многие такого "улучшения" не оценят. Правильным решением было бы добавление сущности "группа заявок" с атомарной обработкой, но чета я сомневаюсь, что в народный квик перетащат весь фикс. Даже если арка решит слить свой другой продукт, мамба такого альтруизма может не понять. Впрочем, мы по кругу уже пошли.
То, что я отправил заявку до окончания ответа, это уже мои проблемы, ее может и не быть, это нормально. Но этой функциональности все равно нет. Что касается равенства синхронной отправке, это не так. Заявки можно отправлять без ожидания ответа, если ордера по ним пока не интересны. Это вообще не связанные вещи, сервер должен возвращать то, что есть на текущий момент, а чего еще нет, от него не требуют. Природа распределенной системы здесь ни причем, кривая реализация системы квик налицо.
 
Цитата
Alexey написал:
сервер должен возвращать то, что есть на текущий момент
Вот тут корень, похоже. О каком текущем моменте речь, как его идентифицировать? Давайте нарисуем фейковый лог.

> 10:30:22.555 sell GAZP 1 ...
> 10:30:22.666 buy RIZ9 1 ...
> 10:30:22.777 sell SBER 1 ...
- 10:30:22:888 первый пакет достигает сервера, заявка передана на мамбу, получено подтверждение о постановке в стакан
< 10:30:22.888 ok GAZP accepted 1 filled 0 ...
- 10:30:22.999 второй пакет достигает сервера, заявка передана на фортс, ответа еще нет
- 10:30:23.111 третий пакет достигает сервера, заявка передана на мамбу, получено подтверждение о постановке в стакан
< 10:30:23.111 ok SBER accepted 1 filled 0 ...
- 10:30:23.222 получено подтверждение с фортса об исполнении
< 10:30:23.222 ok RIZ9 accepted 1 filled 1 ...
и т.д.

Фортс в примере подтормозил и прислал ответ на вторую заявку позже, чем мамба на третью. Что должен был сделать сервер? Сериализовать заявки и отвечать в порядке их поступления? Или он все правильно сделал?
 
Речь малость не о том. Как я уже писал, моя задача проста, - получить все активные ордера на текущий момент. Я не отправляю никаких заявок (хотя это ничего не меняет), меня интересуют мои ордера на текущий момент. Я их запрашиваю посредством TRANS2QUIK_START_ORDERS, но принять не могу. Кто кого обогнал, или протормозил мне не важно. Мне важны мои активные ордера на текущий момент. Транзакции были давно, а те что недавно для меня не важны. Ордера должны возвращаться независимо от торможений, задержек и прочего.
 
Возвращаться за конечное, короткое время. Или квик меня должен проинформировать о невозможности получения полной информации об ордерах (истечение таймаута).  Это возможно, и так должно быть. Если это не так, то это лишь огрехи системы, возможно вследствие неправильного построения.
 
Ну то есть "когда рабочее место квик считать окончательно инициализированным после подключения к серверу". Ответ тут по форуму разбросан, в переводе на русский все это многословие звучит как "никогда". Никто не обещает, что после самого окончательного обновления инфы не придет еще более окончательное, никаких маркеров "вот это была история, а вот это реалтайм пошел" в квике нет. Никакой невозможности получения тоже нет, либо соединение потеряно, либо оно не потеряно и данные едут, быстро ли, медленно ли, как получится.
 
Цитата
Ну то есть "когда рабочее место квик считать окончательно инициализированным после подключения к серверу". Ответ тут по форуму разбросан, в переводе на русский все это многословие звучит как "никогда". Никто не обещает, что после самого окончательного обновления инфы не придет еще более окончательное, никаких маркеров "вот это была история, а вот это реалтайм пошел" в квике нет. Никакой невозможности получения тоже нет, либо соединение потеряно, либо оно не потеряно и данные едут, быстро ли, медленно ли, как получится.
Нет. Это текущий поток, это не совсем то.. Все инициализировано и работает. Работает, работает. Вдруг у меня (моей проги) возникла необходимость проанализировать все мои текущие ордера. Я делаю так :  TRANS2QUIK_SUBSCRIBE_ORDERS( "", "" ); TRANS2QUIK_START_ORDERS(); , а затем собираю их из калбека по одному. Но как мне понять, что я закончил принимать??? А как мне узнать, что я все принял??? Никак?  
 
Вот и говорю, на луа лучше перейти. Пройдетесь по таблице заявок и получите все, что там есть "на текущий момент" (но не факт, что через микросекунду там что-нибудь не поменяется и даже прямо в процессе прогулки по таблице).

Раз у вас такой довольно хакерский подход к длл, может пойти в хаченье дальше, выставить ордер гарантированно вне лимита и принять ответ о его отклонении? Как минимум, продавит то, что ползло до него по сети в обе стороны.
 
Цитата
Раз у вас такой довольно хакерский подход к длл, может пойти в хаченье дальше, выставить ордер гарантированно вне лимита и принять ответ о его отклонении? Как минимум, продавит то, что ползло до него по сети в обе стороны.
C квиковской длл по другому незя)))
 
Здравствуйте, Alexey.
Цитата
Alexey написал:
После вызова TRANS2QUIK_START_ORDERS, в течении какого времени гарантированно придут все активные ордера в CallBack???
Время, в течении которого все заявки будут переданы в callback при вызове TRANS2QUIK_START_ORDERS может варьироваться в широких пределах и зависит от многих факторов, среди которых: производительности/загруженности ПК в время получения данных, объёма обрабатываемых данных в таблице заявок рабочего места, особенностей исполняемого кода, изменений в таблице заявок во время получения заявок. Кроме того, производительность работы функции в предлагаемом Вами контексте отдельно не тестировалась. По этим причинам нет возможности с необходимой точностью указать период времени, за который все заявки "гарантировано" будут получены. Предлагаем Вам самостоятельно набрать необходимую статистику и ориентироваться на неё.
 
Печально конечно, но хотя бы ясность. На самом деле, даже не время критично, а неопределенность конца приема, то ли все, то ли еще будет..  Количества не хватает для контроля.
Страницы: 1
Читают тему
Наверх