OrderSendAsync() function - page 8
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Because broken packets, dropped connections, etc. bullshit. Unreliable. Unreliable -- you have to disconnect.
Just in case, we will keep the queue of trade transactions for issuing to EAs and give them away.
Disconnects in execution are a problem, it is not clear how to handle them yet. In any case, we will be able to check all open positions after the reconnect.
Because broken packets, dropped connections, etc. bullshit. Unreliable. Unreliable -- you have to bounce back.
Let's keep the flies separate and the cutlets separate.
Broken packets are an abnormal situation for the terminal and should be handled by exceptions, including through history analysis.
But it's too expensive to parse history on every Trade. Trade's arrival is a normal situation and should be handled in a low-cost way.
Hi. Do you even know what asynchrony is?
As far as I understand, introducing this function for multicurrency EAs (for monocurrency EAs the initiative makes no sense), the only purpose is to save time by avoiding the delay in order execution on the server side. Correct me if I'm wrong.
Apart from that, there is only one time-critical portion of time left - the data packet transmission over the communication channels. Trying to push the "boundary of the unknown" to the level of "drop (packet) and run on", you have more problems than benefits. It is important to assess the problem holistically. A possible timeout, if there was one, is likely to affect not only the ability to trade on a particular instrument, but also, in principle, the lack of communication with the server.
In addition, it is not clear how to estimate from the Expert Advisor: was the trade order lost in the data transmission, or it is waiting for its turn on the server for such a long time? And that means there will be errors with duplicate trade orders, which will lead to violation of MM and, consequently, to higher risks. In my opinion any professional trader (Expert Advisor) should make sure that his trade order is accepted for execution by the server. Moreover, in order to clearly identify the state of a certain trade order (in OnTrade() function), you need a unique value received from the server to apply it to further processing (until the trade is executed (opening/closing a position).
It is similar to the OSI network model. We do not need to get into the channel or physical layer of trade order execution. Let the client (MT5) perform this transport function. Operate at the application layer.
Time saving due to no server-side delay in order execution. Correct me if I am wrong.
At the cost of not waiting for the results of the request. Generally speaking, yes. I.e. for orders and market execution it may be very useful.
Apart from this, there is only one time-critical section of time left - the transmission of the data packet over the communication channels. Trying to push the "boundary of the unknown" to the level of "drop (packet) and run on", you have more problems than benefits.
Well... no. You just have to use it when the benefits outweigh the problems.
In my opinion, any professional trader (advisor) needs to make sure that his trade order is accepted for execution by the server.
Then the asynchronous option is not suitable for you. Everything is solvable.
TheXpert
Let's go over it again, on our fingers. Roughly structuring the delays:
1. Time for the terminal to pre-check the trade order, "pack" it into the outgoing batch and put it into the "network queue".
2. Time of transmission of a data packet containing a trade order from the client to the server.
3. Time of receiving a trade order by the server and placing it in the processing pool and sending to the client a unique identifier of this ticket.
4. The time of pre-processing the correctness of the trade order and its placement on the trading floor.
If I have indicated something wrong, please correct. I understand that you do not want to wait after the first point? I, on the other hand, advocate the mandatory availability of the first three.
Two questions need to be answered for further discussion:
1. The proportional ratio of delays. That is, on average, how much time in percentage terms each of the above four items takes. If the distribution is, for example, "0.5%-1.0%-1.0%-97.5%" then it is not worth it.
2) Time-out and its impact on the trading strategy. Frankly speaking, I cannot name a single TS that does not require a clear understanding of whether an order has been sent to the server or not. This is relevant to both long term and multicurrency arbitrage. That is, the guarantee of execution of a trade order cannot be questioned. Please provide a counter-example if you disagree.
In my opinion, the easiest way to solve the execution problem on a break is to not create an execution queue (cancel the execution) and notify the user of the cancellation on reconnect. This way there will be less ambiguity.
A server ticket must be returned. This will ensure that the order reaches the server and is accepted for processing.
Building cunning waiting pools on the client side is not just an impractical solution, I'd call it a gross design flaw in the client-server architecture of MT5.
Cumbersome waiting pools on the client side is not an elegant solution.
This is what was asked for. No one is forcing you to use it if you don't have to.
TheXpert
Let's do it again, on the fingers. Roughly structuring the delays:
1. time for the terminal to pre-check the trade order, "pack" it in a dispatchable package and put it in the "network queue".
2. Time of sending a data packet containing a trade order from the client to the server.
Time of receiving a trade order by the server and placing it in the processing pool and sending to the client a unique identifier of this ticket.
4. Time of pre-processing the correctness of the trade order and placing it on the trading floor.
3 is better to separate
3.1 placement
3.2 sending uid.
If I indicated something wrong, please correct. I understand that you do not want to wait after the first item?
Yes.
I, on the other hand, am in favour of making the first three mandatory.
And if the ping is half a second? It's asynchronous. What's the point of using this mode at all?
This is what has been asked. No one is forcing you to use it if you don't have to.
You still haven't answered my question. Please give me a concrete example in which cases you can disregard the guarantee of trade order execution for the sake of speed of sending them to different characters?
You still haven't answered my question. Please give me a concrete example of when you can disregard trade order execution guarantees for the sake of speed of sending them to different symbols?
No problem - portfolio trading + market execution.