Функция OrderSendAsync() - страница 3

[Yedelkin]

Техническое сообщение. Собираем интересные высказывания в одну тему.

sergeev:

Yedelkin:
Какое свойство счёта будет отвечать за лимит одновременных заявок в очереди исполнения? Будет ли возможность узнать программно этот показатель?

просто будет результат функции OrderSendAsync = false

по нему и ориентируйтесь

[Mykola Demko]

Rosh:

С интересом перечитал ветку, и даже проверил на практике, и вот обнаружил вопиющую дискриминацию автоматической торговли.

вот журнал закрытия позиции вручную: (понятно хронология снизу вверх)

2012.04.26 22:32:05     Trades  '686934': deal #9256820 sell 0.02 EURUSD at 1.32391 done (based on order #10091825)
2012.04.26 22:32:05     Trades  '686934': order #10091825 sell 0.02 / 0.02 EURUSD at 1.32391 done
2012.04.26 22:32:05     Trades  '686934': accepted instant sell 0.02 EURUSD at 1.32391
2012.04.26 22:32:04     Trades  '686934': instant sell 0.02 EURUSD at 1.32391

Что мы тут видим: ордер отправлен, ордер принят, ордеру присвоен тикет, и наконец ордер исполнен (возможны подвижки в интерпретации но как то так). Всё по классике.

Смущает только то, что событие Trades абсолютно точно знает (внутри терминала) по какой категории оно возбуждено, а также по какому ордеру (для двух последних категорий) иначе невозможно было бы вывести такой комментарий, а вот программисту нужно изобретать велосипед чтоб эту информацию получить. И ситуация с функцией OrderSendAsync совсем не добавила простоты.

Хотя нужно заметить что скорость исполнения ордеров увеличилась. Сейчас не успеваешь заметить постановку ордера в очередь а он уже исполнен.

---

ЗЫ Получается так, отправил пачку ордеров, по каждому из них теоретически придёт 4 Trades, в каждом из Trades нужно вести контроль по каждому ордеру.

Имеем на ровном месте 4*Количество_ордеров*Количество_ордеров точек контроля те для 10 ордеров это 400, для 100 это 40000. И не дай бог какой то ордер будет иметь меньшее количество Trades чем 4, тогда вся логика контроля сыпется, потому как именно на цифре 4 держиться ожидание перед отправкой повторного ордера (если первый запрос не исполнен).

[Andrey Dik]

Вот отправили пачку торговых приказов на сервер.

По каждому приказу нужно вести отдельный контроль исполнения? И сколько времени ждать ответа?

[---]

joo:

По каждому приказу нужно вести отдельный контроль исполнения?

да

И сколько времени ждать ответа?

У разных брокеров по разному. Если STP, то это вопрос больше к его провайдеру ликвидности.

[Mykola Demko]

sergeev:

да

У разных брокеров по разному. Если STP, то это вопрос больше к его провайдеру ликвидности.

Не не, это всё гадание на кофейной гуще, ты когда вручную открываешься есть окно, нажал бай дождался события реквот или исполнен, жмёшь ок и все дела.

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

ЗЫ добавил в пост выше перечитай.

[---]

Urain:

Не не, это всё гадание на кофейной гуще, ты когда вручную открываешься есть окно, нажал бай дождался события реквот или исполнен, жмёшь ок и все дела.

нет. Это ты описываешь случай при коде возврата DONE(10009).  так скажем синхронный вариант.

Но есть брокеры, которые передают твою сделку дальше на провайдера. И в этом случае они вернут тебе сразу PLACED (10008). И кстати, если это был маркет ордер, то в этом ответе тикета Deal не будет.  Только тикет ордера.

А в случае с OrderSendAsync - даже тикета ордера не будет.

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

Ну а какая например точка опоры при реквотах даже на МТ4? Не будешь же ты делать бесконечный цикл и ожидать удаление или открытие ордера.

Все потиково, с проверками запомненных состояний и т.д.

[Yedelkin]

Попробовал запустить функцию  OrderSendAsync()

//+------------------------------------------------------------------+
//|                                               OrderSendAsync.mq5 |
//+------------------------------------------------------------------+
MqlTradeResult  res={0};
MqlTradeRequest req={0};
//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart()
  {
   req.action=TRADE_ACTION_PENDING;
   req.symbol=_Symbol;
   req.volume=1.0;
   req.price=3.0;
   req.type=ORDER_TYPE_BUY_STOP;
   req.type_filling=ORDER_FILLING_RETURN;
   switch(OrderSendAsync(req,res))
     {
      case  true:
         Print("retcode=",res.retcode,", order=",res.order,", deal=",res.deal);
         break;
      default: Print("Неудача при отправке запроса функцией OrderSendAsync()");
     }
  }

В ответ  получил

2012.05.02 21:12:33 OrderSendAsync (USDCHF,M1) retcode=10008, order=0, deal=0

 

Сразу возник вопрос: а кто как собирается отслеживать дальнейшую судьбу торгового запроса при отправке функцией  OrderSendAsync(), если даже тикет ордера не известен? Комментарий - и тот брокером должен заполняться.

[Renat Fatkhullin]

Асинхронный режим предназначается для массовой пакетной засылке ордеров, но никак для одиночной транзакции. Для одиночной лучше использовать синхронный режим - все будет исполняться с такой же скоростью, да еще и с полным сервисом.

Отслеживать исполнение асинхронных операций нужно в OnTrade. Да, это более сложный путь, но такова цена асинхронности.

[Yedelkin]

Renat:
Асинхронный режим предназначается для массовой пакетной засылке ордеров, но никак для одиночной транзакции. Для одиночной лучше использовать синхронный режим - все будет исполняться с такой же скоростью, да еще и с полным сервисом.

Отслеживать исполнение асинхронных операций нужно в OnTrade. Да, это более сложный путь, но такова цена асинхронности.  

Хорошо, уточню вопрос: кто как собирается отслеживать дальнейшую судьбу пятисот торговых запросов при массовой пакетной засылке ордеров? Поскольку любая массовая пакетная засылка ордеров состоит из множества одиночных транзакций, то неужели все будут пользоваться принципом сравнения предыдущего и текущего состояний истории? Других подходов нет?

[Renat Fatkhullin]

Корень понимания в том, что асинхронность процессов
1) не гарантирует своевременность и даже наличия ответа
2) явно требует отдельных очередей учета операций со стороны разработчика

То есть, автор сам должен побеспокоиться об формировании списка заявок с последующей их перепроверкой и заполнением внктри OnTrade. Это конечно мучительно.

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

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