От выставления заявки до её исполнения. Правильное отслеживание заявок.

Новый комментарий
 

В момент успешного вызова OrderSend() мы имеем выставленную заявку. Еще нет ни ордера, ни его исполнения, ничего. В этот момент можно повторно вызвать функцию, без необходимости в этом. Мы же работаем в цикле, может и 30 раз за секунду!

Результат понятен - и это плохо. Нет нигде в мета трейдере возможности проверить, был ли подобный вызов на тике? Т.е. мгновенно. Потому что все работает слишком быстро и эта мгновенность ломает мозг. 

На брокере Открытие работает мой робот нормально. На Финаме в какой то момент дублируются две рыночные заявки. Хорошо хоть события частые. Что удалось их отследить. А если нет? Что оказалось:

В момент между TRADE_TRANSACTION_REQUEST где приходит retcode = 10009 и TRADE_TRANSACTION_DEAL_ADD вклинивается исполнение нового тика где и происходит повторный вызов. Сделки то еще нет! Но мое слежение говорит. Что ответ - исполнено. Я бы лучше смотрел на  TRADE_TRANSACTION_DEAL_ADD. Но заполнение структур то разное. И там нет того, что мне нужно. Почему нет нормального подхода к отслеживанию заявок? Потому что держать логику на OnTick() нельзя. Но увидеть нужно. Проблему то решаема. Но она должна описана быть на первом месте во всех инструкциях.

Как вы отслеживаете заявки, ордера, сделки, позиции?

Для одного робота все нормально, проблема решена. Он знает, что он делает. Но он не знает. Что делает его брат. И мое решение не надежное. Мне нужно видеть не  TRADE_TRANSACTION_DEAL_ADD или что либо другое. А сам вызов OrderSend() . Они же могут совершить два вызова  OrderSend(). И делают они это настолько быстро, что я даже примерно не вижу решения.

 

Робот помнит свои ордера, от отправки до попадания в историю.

А зачем ему знать про чужие?

 
JRandomTrader #:

Робот помнит свои ордера, от отправки до попадания в историю.

А зачем ему знать про чужие?

Пришлось создать защиту. Если пользователь двум роботам поставит одинаковые магик числа. И у них логика переворачивается. То они рыночно вращают позицию. Теперь считайте - 10 вращений в секунду с потерей 10 рублей за одно. Т.е. 10*10 (сек)*60(минута)*60(час) = 360 000 рублей. Это для одного лота! Нормально так потерять на этом? Это к слову. Что будет. Если ваш робот будет писать чайник. Потому что это же самое можно воспроизвести и на одном роботе.

 
vbymrf:


Как вы отслеживаете заявки, ордера, сделки, позиции?


Могу предположить, что необходимо вставить условие с задержкой по времени, типа - "Проверить открылся ли ордер, ещё раз проверить через 5 секунд (допустим), если нет, то выполнить отправку ордера ещё раз". 

 
vbymrf #:

Пришлось создать защиту. Если пользователь двум роботам поставит одинаковые магик числа. И у них логика переворачивается. То они рыночно вращают позицию. Теперь считайте - 10 вращений в секунду с потерей 10 рублей за одно. Т.е. 10*10 (сек)*60(минута)*60(час) = 360 000 рублей. Это для одного лота! Нормально так потерять на этом? Это к слову. Что будет. Если ваш робот будет писать чайник. Потому что это же самое можно воспроизвести и на одном роботе.

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

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

 
to_ha #:

Могу предположить, что необходимо вставить условие с задержкой по времени, типа - "Проверить открылся ли ордер, ещё раз проверить через 5 секунд (допустим), если нет, то выполнить отправку ордера ещё раз". 

Ага, щас. Вы это заказчику объясните, сеточника. Что нужно уснуть и дождаться времени спустя пару сотен тиков. Заказчик уже видит прибыль в кармане. А робот в этот момент проспал все. И входы и выходы. А если там Н количество этих заявок с наложением условий? Там даже логика ломается, как следить и в принципе понять. Правильно ли работает робот, или нет. Даже заказчик не всегда поймет.

Не в обиду сказано. Если робот должен исполнять что то по приходу бара - это все понятно. Ошибки здесь не будет. Упущено время - не столь значимо. Но мне нужно гарантированное универсальное решение.  
 
vbymrf:

В момент успешного вызова OrderSend() мы имеем выставленную заявку. Еще нет ни ордера, ни его исполнения, ничего. В этот момент можно повторно вызвать функцию, без необходимости в этом. Мы же работаем в цикле, может и 30 раз за секунду!

Результат понятен - и это плохо. Нет нигде в мета трейдере возможности проверить, был ли подобный вызов на тике? Т.е. мгновенно. Потому что все работает слишком быстро и эта мгновенность ломает мозг. 

На брокере Открытие работает мой робот нормально. На Финаме в какой то момент дублируются две рыночные заявки. Хорошо хоть события частые. Что удалось их отследить. А если нет? Что оказалось:

В момент между TRADE_TRANSACTION_REQUEST где приходит retcode = 10009 и TRADE_TRANSACTION_DEAL_ADD вклинивается исполнение нового тика где и происходит повторный вызов. Сделки то еще нет! Но мое слежение говорит. Что ответ - исполнено. Я бы лучше смотрел на  TRADE_TRANSACTION_DEAL_ADD. Но заполнение структур то разное. И там нет того, что мне нужно. Почему нет нормального подхода к отслеживанию заявок? Потому что держать логику на OnTick() нельзя. Но увидеть нужно. Проблему то решаема. Но она должна описана быть на первом месте во всех инструкциях.

Как вы отслеживаете заявки, ордера, сделки, позиции?

Для одного робота все нормально, проблема решена. Он знает, что он делает. Но он не знает. Что делает его брат. И мое решение не надежное. Мне нужно видеть не  TRADE_TRANSACTION_DEAL_ADD или что либо другое. А сам вызов OrderSend() . Они же могут совершить два вызова  OrderSend(). И делают они это настолько быстро, что я даже примерно не вижу решения.

Когда получили код 10009, проверили символ и магик, кто мешает включить флаг и выключить когда позиция уже открыта?

vbymrf #:

Пришлось создать защиту. Если пользователь двум роботам поставит одинаковые магик числа. И у них логика переворачивается. То они рыночно вращают позицию. Теперь считайте - 10 вращений в секунду с потерей 10 рублей за одно. Т.е. 10*10 (сек)*60(минута)*60(час) = 360 000 рублей. Это для одного лота! Нормально так потерять на этом? Это к слову. Что будет. Если ваш робот будет писать чайник. Потому что это же самое можно воспроизвести и на одном роботе.

Чтобы не получить одинаковые магики двух и более советников на одном инструменте достаточно задействовать 3-4 последних знака идентификатора графика на котором поставлен советник. Конечно это тоже не панацея, если остались открытые позиции и график был закрыт, то советник на другом графике его не определит как свой. В общем надо быть внимательным и не ставить советники с одним магиком на один символ. Сам поставил — сам виноват в потерях.

 
Alexey Viktorov #:

Когда получили код 10009, проверили символ и магик, кто мешает включить флаг и выключить когда позиция уже открыта?

Чтобы не получить одинаковые магики двух и более советников на одном инструменте достаточно задействовать 3-4 последних знака идентификатора графика на котором поставлен советник. Конечно это тоже не панацея, если остались открытые позиции и график был закрыт, то советник на другом графике его не определит как свой. В общем надо быть внимательным и не ставить советники с одним магиком на один символ. Сам поставил — сам виноват в потерях.

Нету позиции при неттинге. Есть история и итоговая ее. Крутить постоянно историю - не оптимально. Лучше забрать из транзакции. И вот ошибся - потому что не до конца понял. Что происходит. 

 

Отправляя ордер - запоминаешь его тикет.

При асинхронной - хуже, там тикета ещё нет, сохранять все параметры и потом сопоставлять, если по какой-то причине упустил транзакцию с request_id.

struct MTOrder
  {
   ulong id;
   ulong Ticket;
   datetime Time;
   datetime TimeNotFound;
   double   Price;
   double   Vol;
   double   VolInit;
   uint     request_id;
   ENUM_ORDER_TYPE   Type;
   ENUM_ORDER_STATE State;
   MT_ORD_STATE MTState;
   int      Reserved;
   bool     Idf; // Identified
  };
   MTOrder  Orders[]; // С начала массива - ордера на покупку, по убыванию цены,
                      // С конца - на продажу, по возрастанию
 
vbymrf #:

Нету позиции при неттинге. Есть история и итоговая ее. Крутить постоянно историю - не оптимально. Лучше забрать из транзакции. И вот ошибся - потому что не до конца понял. Что происходит. 

Ну так тикет ордера и магик по любому есть… А если заморочиться покруче, то можно использовать 

request_id

Идентификатор запроса, проставляемый терминалом при отсылке на торговый сервер
 
Alexey Viktorov #:

Ну так тикет ордера и магик по любому есть… А если заморочиться покруче, то можно использовать 

request_id

Идентификатор запроса, проставляемый терминалом при отсылке на торговый сервер

Если отправлять асинхронно, то тикета нет. Только ловить по request_id. А если вдруг пропустил эту транзакцию, то однозначной привязки отправленного запроса к ордеру просто нет.

При этом всё ещё хуже, TRADE_TRANSACTION_ORDER_ADD может придти (и обычно приходит) раньше, чем TRADE_TRANSACTION_REQUEST с request_id. В итоге получаем новый ордер, но пока не знаем, куда его приписать.

12
Новый комментарий