OrderSendAsync() function - page 3

[Yedelkin]

Technical message. Gathering interesting statements into one topic.

sergeev:

Yedelkin:
Which account property will be responsible for the limit of simultaneous orders in the execution queue? Will it be possible to find out this figure programmatically?

the result of the OrderSendAsync = false function will simply be

use it as a guide

[Mykola Demko]

Rosh:

Reread the thread with interest, and even tested it in practice, and here I discovered the blatant discrimination of automatic trading.

Here is the log of manual position closing: (understandable chronology from bottom to top)

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

What we see here: the order is sent, order is accepted, a ticket is assigned to the order, and finally the order is executed (there may be some shifts in interpretation, but that's about it). Everything is classic.

The only strange thing is that the Trades event knows for sure (within the terminal) by which category it was triggered, as well as by which order (for the last two categories); otherwise it would be impossible to output such comment, and the programmer would have to re-invent the wheel to obtain this information. And the situation with the OrderSendAsync function did not add any simplicity at all.

However, we should note that the speed of order execution has increased. Now we don't have time to notice the order being put in the queue, and it has already been executed.

---

So we have a pack of orders, each of which theoretically comes 4 Trades, in each of the Trades we would need to control each order.

Thus, we have 4*Number_Order*Number_Order control points, i.e. we have 400 for 10 orders and 40000 for 100. And God forbid, any order would have less amount of Trades than 4, then the entire control logic collapses, since waiting before sending a second order (if the first request is not executed) takes place exactly on number 4.

[Andrey Dik]

You have sent a stack of trade orders to the server.

For each order, do you need to keep a separate execution check? And how long do we wait for a response?

[---]

joo:

Does each order have to be monitored separately?

Yes

And how long do I have to wait for a response?

It varies from broker to broker. If STP, it is more a question for its liquidity provider.

[Mykola Demko]

sergeev:

yeah

They do not have the same function for different brokers. If STP, then it's more a question for their liquidity provider.

No, it's all guessing by coffee grounds. When you open the window manually, you press buy, wait for a requote or execution, press ok and you're done.

When you open in auto mode, there should also be a reference point, from which you have to send a second request or everything is OK.

SZS added to the post above, reread.

[---]

Urain:

No, it's all guesswork, when you manually open a window, press buy, wait for a requote or execution, press ok and you're done.

No. This is the case when the return code is DONE(10009).

But there are brokers who pass your trade on to the provider. And in this case they will return you immediately PLACED(10008). And by the way, if it was a market order, there will be no Deal ticket in this response. Only the order ticket.

And there won't even be a ticket for the order in case of OrderSendAsync.

In the auto mode, so should be the reference point, from which you want to send a second request, or everything is OK.

Well, what is the reference point at requotes even on MT4? You will not make an endless loop and wait for the deletion or opening of an order.

Everything is ticketype, with checks of saved states, etc.

[Yedelkin]

Tried to run the OrderSendAsync() function

//+------------------------------------------------------------------+
//|                                               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()");
     }
  }

It responded with

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

A quick question arises: how do we plan to trace the fate of a trade request when it is sent using the OrderSendAsync() function, if we don't even know the order ticket? The comment must be filled out by the broker.

[Renat Fatkhullin]

Asynchronous mode is designed for bulk batch order entry, but not for a single transaction. For a single transaction it is better to use synchronous mode - everything will execute at the same speed, and with full service.

Track the execution of asynchronous transactions in OnTrade. Yes, this is a more complicated path, but that is the price of asynchrony.

[Yedelkin]

Renat:
Asynchronous mode is designed for bulk batch order entry, but not for a single transaction. For a single transaction it is better to use synchronous mode - everything will be executed at the same speed and with full service.

Track the execution of asynchronous transactions in OnTrade. Yes, it's a more complicated way, but that's the price of asynchrony.

Ok, let me clarify a question: how is someone going to track the fate of five hundred trade requests in a mass batch sending of orders? Since any mass batch sending of orders consists of a lot of single transactions, will everyone use the principle of comparing the previous and the current state of history? Are there no other approaches?

[Renat Fatkhullin]

The root of the understanding is that asynchronous processes
1) does not guarantee timeliness or even availability of response
2) clearly requires separate queues of operations by the developer

In other words, we have to generate a list of orders and then check and fill them within OnTrade. This, of course, is excruciating.

For our part, we could transparently maintain asynchronous queues, fill them with answers and provide traders with convenient functions to check and retrieve processed entries from the queue. You can check the queues asynchronously in OnTrade or synchronously by polling in the loop right after sending a batch of orders.

We will think about such a mechanism - it would make life easier for EA developers by relieving them of their routine.