OrderSendAsync() function - page 2

[Yedelkin]

hrenfx:

It should be clarified:

TRADE_RETCODE_PLACED for OrderSend is the server response.

TRADE_RETCODE_PLACED for OrderSendAsync is a terminal response.

Although the codes are identical, they have quite a different meaning. The developers will most likely fix this ambiguity.

That's why you should understand it:

must be understood in the appropriate context.

Then please explain under what conditions the server must return the TRADE_RETCODE_PLACED code when sending a trade request using the OrderSend function? Because according to the OrderSendAsync function's comment and Roche's answer, this very TRADE_RETCODE_PLACED code indicates only the successful sending of a request from the terminal to the server. So, it turns out that as soon as request reaches server and starts its processing/verification, server will be forced to generate other, "real" server's codes "based on processing results". So I don't really understand why server (namely server) must return TRADE_RETCODE_PLACED code if this code refers to life time stage of request, before request appeared on server? Or does the TRADE_RETCODE_PLACED code bear some other meaning in relation to OrderSend function?

[hrenfx]

OrderSend can receive a response from both the server and the terminal (in case the terminal filters fail).

OrderSendAsync always receives response from the terminal only. To receive response from the server you need to catch appropriate events in onTrade.

[Yedelkin]

hrenfx:

OrderSend can receive a response from both the server and the terminal (in case the terminal filters fail).

Do I understand correctly the following idea:

The terminal has checked the request from OrderSend and successfully sent it to the server, with the retcode receiving an intermediate value of TRADE_RETCODE_PLACED. At this point the connection is interrupted and all OrderSend can return is the TRADE_RETCODE_PLACED code stuck in the retcode field? Would this be the example where OrderSend returns TRADE_RETCODE_PLACED?

[hrenfx]

Yedelkin:

Did I get the following idea right:

The terminal has checked the request from OrderSend and successfully sent it to the server, with the retcode receiving the intermediate value TRADE_RETCODE_PLACED. At this point the connection is interrupted and all OrderSend can return is the TRADE_RETCODE_PLACED code stuck in the retcode field? Will this be that example when OrderSend returns TRADE_RETCODE_PLACED?

Maybe so, but I doubt it. Most likely it would be TRADE_RETCODE_TIMEOUT via TimeOut-time for such a break in communication.

Honestly, I don't understand what this nerfing is for in case of OrderSend. Perhaps the developers will explain more in the help.

P.S. I haven't written a single line in MQL5. Therefore, all my thoughts on the subject can be ignored.

[Yedelkin]

...Still, that's nonsense. The Client Terminal User Guide (January 2012) says that one of the order stages is the "set(placed) - dealer accepted order" stage.

I.e., according to the manual, the order is signaling the life stage of a trade request, when it has already successfully reached the server. And the description of the OrderSendAsync() function says just the opposite: the TRADE_RETCODE_PLACED code doesn't depend on the arrival to the server.

[Yedelkin]

hrenfx:

Honestly, I don't see why this nerdiness is necessary in the case of OrderSend.

Personally, I liked the idea of needing "return code processing" in my time. But in order to write such processing correctly, one must know what it is all about. I have been trying for a long time to understand what exactly TRADE_RETCODE_PLACED code is related to.

[hrenfx]

In general, anyone can write a serial MyOrderSend via OrderSendAsync:

1. Called OrderSendAsync.
2. Wait for the appropriate response from the server in onTrade.
3. Exited MyOrderSend with this response.

With this implementation MyOrderSend will be fully identical to the regular OrderSend (which can be simply eliminated from the API by implementing via OrderSendAsync in the regular library).

[Yedelkin]

hrenfx:

With this implementation MyOrderSend will be completely identical to the regular OrderSend (which can be simply eliminated from the API by implementing OrderSendAsync in the regular library).

An interesting idea for self-development. But as long as onTrade is not parameterized, any checks using onTrade in the staff library will probably be much slower than the OrderSend function itself. I could be wrong.

[hrenfx]

Generally, OrderSendAsync input is a historical event for Metatrader. In all the time the trading API has existed (starting with Metatrader3 (I haven't seen earlier ones)) Metatrader, albeit implemented via its own language, it has remained virtually unchanged in essence. OrderSendAsync is the first substantive change to the trading API from Metaquotes.

I sincerely congratulate the developers on this event and wish to bring the asynchronous model to adequate functionality!

[Yedelkin]

Technical message. Gathering interesting statements into one thread.

Renat:

Note that there are and will be limits on the number of simultaneous orders in the execution queue from one account. Right now it is 16 applications, if I am not mistaken.

Asynchronous operations will work carefully with the "window of the number of admissible orders", waiting for part of the previous batch to be executed before sending the next batch. In addition, there will be protections against stupid/test flooding. So far an error is received when the number of allowed applications overflows.

The new method of asynchronous operations through OrderSendAsync solves the main problem - it allows to make a dozen of operations instantly. This is a very powerful tool and should be used carefully and always with an eye to the possibility of a ban by the server and broker.