OnTradeTransaction

 
Interested in the developers answer - why is theOnTradeTransaction eventnot guaranteed ?
 
Alexey Oreshkin:
I am interested in the developers' answer - whyis OnTradeTransaction eventnot guaranteed?

The developers are probably tired of answering. I will try to answer it for them: OnTradeTransaction cannot be guaranteed by definition because it is an event. Even if the event is guaranteed to be sent, it cannot be guaranteed to be accepted. Imagine that when an event occurs, user terminal shuts down or the connection with the Internet is broken and this event cannot be handled. Probability is low, but not impossible.

Instead of analyzing the events, it is necessary to analyze the trade environment and only if the trade environment has changed, make the necessary decisions. OnTransaction can be used only in very limited cases, and it is usually better to work without it. Look at MetaTrader 4, it doesn't have OnTransaction and manages perfectly well without it.

 
Vasiliy Sokolov:

The developers are probably tired of answering. I will try to answer it for them: OnTradeTransaction cannot be guaranteed by definition because it is an event. Even if the event is guaranteed to be sent, it cannot be guaranteed to be accepted. Imagine that when an event occurs, user terminal shuts down or the connection with the Internet is broken and this event cannot be handled. Probability is low, but not impossible.

Instead of analyzing the events, it is necessary to analyze the trade environment and only if the trade environment has changed, make the necessary decisions. OnTransaction can be used only in very limited cases, and it is usually better to work without it. Look at MetaTrader 4, it does not have OnTransaction and everyone is doing fine without it.

Unlike mt5, it is much easier to manage positions in mt4 because of the absence of netting, so OnTransaction is good or bad there.
I.e. the event is not guaranteed only because of technical reasons? If everything works, then the terminal should 100% guarantee this event?

 
Alexey Oreshkin:

In MT4 it is much easier to manage positions unlike in MT5 due to the absence of netting. That is why OnTransaction is hot or cold in MetaTrader.
So the event is not guaranteed only because of technical reasons? If everything works, then the terminal should 100% guarantee this event?

Netting has no effect on the need for OnTradeTransaction.

The second question can only be answered by the developers themselves. All I've noticed is that OnTradeTransaction is extremely stable. No event receipt losses have been detected.

 
Vasiliy Sokolov:

Netting has no effect on the need for OnTradeTransaction.

Netting affects position accounting and is the reason for so many problems with such a simple question, while OnTradeTransaction is also needed for position accounting.

 
Alexey Oreshkin:

In MT4 due to absence of netting in general it is much easier to manage positions unlike in MT5, so OnTransaction is neither cold nor hot there.
I.e. the event is not guaranteed only because of technical reasons? If everything works, then the terminal should 100% guarantee this event?

Developers choose priority product properties. The priority property of MT4 was ease of use with MQL4.

With MT5, the obvious first level priority is speed (and flexibility). It is impossible to get all product features at maximum. This contradicts the theory.

The fastest product will inevitably require much more (knowledge, experience and effort) from the client programmer.


What the heck with these technical problems. Let's think about it soberly.

Suppose you are developing an MT5 and you have a task: to write a HFT block for trading actions.

On the one hand transaction records are queued from the server, on the other hand these records must be passed to XXX-expert.

In the XXX expert, inside the OnTradeTransaction() handler, the user can have any "pornography"!

It is absolutely unclear how long this function will be executed.

The queue can contain hundreds of records coming from the server but not yet transferred to XXX-expert.

What can you guarantee in this situation? Speed or completeness of data?

And is there any sense in "storing" deeply obsolete information for a function that, in its essence, contributes only to HFT?

 

Guys!

I read it and wonder...

OnTradeTransaction allows you to get the most up-to-date information without "digging" anywhere

on orders and trades!

You just don't know how to use this function.

 
Михаил:

Guys!

I read it and wonder...

OnTradeTransaction allows you to get the most up-to-date information without "digging" anywhere

on orders and trades!

You just don't know how to use this function.

You do not know how to use it either. You have already written dozens of pages about OnTradeTransaction, but you have not understood one thing: OnTradeTransaction is a service function for solving narrow specific tasks, you cannot use it in trading as you do. And then smart guys read your articles and create similar threads: "Why isn't OnTradeTransaction guaranteed?" - because an Expert Advisor should not create its trading environment through OnTradeTransaction, as you do, but rely only on what is available in the system, in particular in the orders and deals history.
 
Vasiliy Sokolov:
You do not know how to do it either. You have already written dozens of pages on the subject of OnTradeTransaction, but you haven't got one thing straight: OnTradeTransaction is a service function intended for solving narrow specific tasks, you cannot use it in trading as you do. And then smart guys read your articles and create similar threads: "Why isn't OnTradeTransaction guaranteed?" - because an Expert Advisor should not create its trading environment through OnTradeTransaction, as you do, but rely only on what is available in the system, in particular in the orders and deals history.

On the one hand, yes. On the other hand: what about cases where a request has been sent to the server, but the operation has not yet been executed? How can we tell what state we are in if we only have a list of orders and positions (and account history)?

There is no such a problem in MT4, because all trading operations there are synchronous. But as a result we get slower performance.

 
Игорь Герасько:

On the one hand, yes. On the other hand: what about cases where a request has been sent to the server, but the operation has not yet been executed? How can we tell what state we are in if we only have a list of orders and positions (and account history)?

There is no such a problem in MT4, because all trading operations there are synchronous. But as a result, we get slower performance.

If the time between sending an order and the next market entry signal exceeds the time of order execution, we will not need to do anything. The logic is simple: we send an asynchronous order, leave the thread and forget about it. We wait for the next moment to check for the signal. If at that moment the trading environment has not changed - the Expert Advisor searches for a signal to enter the market again and repeats the order to enter the market. If, on the contrary, everything went well and the order was executed, the Expert Advisor will realize that it has a position after analyzing the environment and will not open a new position again. I.e., in this approach, the Expert Advisor's condition is guaranteed to be consistent with the market environment.

The situation is more complicated in high-frequency trading, where a new signal can occur after a time comparable to the execution of an order (6-100 msec). In this case, you can not do without locking. The Expert Advisor should remember the time of the last order sending. If an error occurs in OnTransaction, the lockout is reset and the Expert Advisor can perform trades again.

It should be noted that OnTradeTransacton that so many people like to pray for does not help at HFT. A new entry signal can arrive faster than the response about successful execution of a transaction in OnTradeTransaction. Blocking is necessary whether you use OnTradeTransacton or not.

How, you may ask, can we control the errors arising in OnTradeTransaction? You can answer with a counter-question: How will you change the trading logic of the Expert Advisor on the fly when an error occurs? - You cannot. Errors occur if you do not make appropriate checks before (presence of money, volume, etc., etc.). But once it has occurred, you will not be able to correct it. Therefore the best thing you can do in OnTradeTransaction, is to print this error into log (to correct logic of Expert Advisor later), and remove the lock, if it is used. For this and nothing else, OnTradeTransaction must be used.

Now various adepts of Mikalas will come running in and start throwing tomatoes at me - let them. But I've always repeated that a reliable trading logic can be organized only if it is based on the trading environment of the terminal. Anything else will not work.

 
Alexey Oreshkin:
I am interested in the developers' answer - whyis OnTradeTransaction eventnot guaranteed?

OnTradeTransaction is the result of server's response to OrderSendAsinc request.

The OrderSendAsinc function itself is asynchronous, which is stated even in its name. This means that this function launched a request to the server and returned the response to the program about the sending results (whether the request was sent successfully or not).

That is according to the principle the rooster crowed and it won't dawn. This is why the server's reply inOnTradeTransaction is not guaranteed. You never know what may happen there.

There are two similar functions OrderSend and OrderSendAsinc.

The first one is synchronous and silently waits for reply from server no matter how long it takes (it returns the result of request processing by server).

The second one is asynchronous, it doesn't wait for server's response, but immediately returns the result of the operation (but returns the result of whether the request was sent to the server successfully or not).

OrderSendAsinc is needed when decisions need to be made quickly. Tests have shown that OrderSendAsinc can handle sending hundreds of requests per second (but this speed is due to the fact that it's not waiting for a response from the server).

Exactly for receiving of "delayed" reply the terminal generates OnTradeTransaction event (delayed conditionally because of the fact that program continued receiving reply, in fact, the lag is counted in seconds or milliseconds).

The difference from OrderSend is that OnTradeTransaction can be generated for one order several times notifying the terminal of the newly received information about how the request was processed by the server. It means that we can see the stages of order processing in OnTradeTransaction.

Order accepted by the server OnTradeTransaction

The order has been placed in the OnTradeTransaction queue

Order ... OnTradeTransaction

Order ... OnTradeTransaction etc.

All the events other than the first event on the order are signed with a ticket to identify exactly what order the response to the event OnTradeTransaction was received by.

The first event is signed by the ticket and request_id. The request_id is obtained by the user right after the order is submitted from the OrderSendAsinc function. Thus a specific OrderSendAsinc iteration is linked with the results obtained in OnTradeTransaction.

Reason: