OnTradeTransaction

 
Interessato alla risposta degli sviluppatori - perché l'eventoOnTradeTransaction non ègarantito?
 
Alexey Oreshkin:
Sono interessato alla risposta degli sviluppatori - perchél' eventoOnTradeTransaction non è garantito?

Gli sviluppatori sono probabilmente stanchi di rispondere. Cercherò di rispondere per loro: OnTradeTransaction non può essere garantito per definizione perché è un evento. Anche se l'evento è garantito per l'invio, non può essere garantito per l'accettazione. Immaginate che quando si verifica un evento, il terminale utente si spegne o la connessione con Internet si interrompe e questo evento non può essere gestito. La probabilità è bassa, ma non impossibile.

Invece di analizzare gli eventi, è necessario analizzare l'ambiente commerciale e solo se l'ambiente commerciale è cambiato, prendere le decisioni necessarie. OnTransaction può essere usato solo in casi molto limitati, e di solito è meglio lavorare senza. Guarda MetaTrader 4, non ha OnTransaction e gestisce molto bene senza di esso.

 
Vasiliy Sokolov:

Gli sviluppatori sono probabilmente stanchi di rispondere. Cercherò di rispondere per loro: OnTradeTransaction non può essere garantito per definizione perché è un evento. Anche se l'evento è garantito per l'invio, non può essere garantito per l'accettazione. Immaginate che quando si verifica un evento, il terminale utente si spegne o la connessione con Internet si interrompe e questo evento non può essere gestito. La probabilità è bassa, ma non impossibile.

Invece di analizzare gli eventi, è necessario analizzare l'ambiente commerciale e solo se l'ambiente commerciale è cambiato, prendere le decisioni necessarie. OnTransaction può essere usato solo in casi molto limitati, e di solito è meglio lavorare senza. Guarda MetaTrader 4, non ha OnTransaction e tutti stanno facendo bene senza.

A differenza di mt5, è molto più facile gestire le posizioni in mt4 a causa dell'assenza di netting, quindi OnTransaction è buono o cattivo lì.
Cioè l'evento non è garantito solo per motivi tecnici? Se tutto funziona, allora il terminale dovrebbe garantire al 100% questo evento?

 
Alexey Oreshkin:

In MT4 è molto più facile gestire le posizioni a differenza di MT5 a causa dell'assenza di netting. Ecco perché OnTransaction è caldo o freddo in MetaTrader.
Quindi l'evento non è garantito solo per motivi tecnici? Se tutto funziona, allora il terminale dovrebbe garantire al 100% questo evento?

Il netting non ha alcun effetto sulla necessità di OnTradeTransaction.

Alla seconda domanda possono rispondere solo gli sviluppatori stessi. Tutto quello che ho notato è che OnTradeTransaction è estremamente stabile. Non sono state rilevate perdite nella ricezione degli eventi.

 
Vasiliy Sokolov:

Il netting non ha alcun effetto sulla necessità di OnTradeTransaction.

Il netting influenza la contabilità delle posizioni ed è la ragione di tanti problemi con una domanda così semplice, mentre OnTradeTransaction è anche necessario per la contabilità delle posizioni.

 
Alexey Oreshkin:

In MT4 a causa dell'assenza di netting in generale è molto più facile gestire le posizioni a differenza di MT5, quindi OnTransaction è caldo o freddo lì.
Cioè l'evento non è garantito solo per motivi tecnici? Se tutto funziona, allora il terminale dovrebbe garantire al 100% questo evento?

Gli sviluppatori scelgono le proprietà prioritarie dei prodotti. La proprietà prioritaria di MT4 era la facilità di lavorare con MQL4.

Con MT5, l'ovvia priorità di primo livello è la velocità (e la flessibilità). È impossibile ottenere tutte le caratteristiche di un prodotto al massimo. Questo contraddice la teoria.

Il prodotto più veloce richiederà inevitabilmente molto di più (conoscenza, esperienza e sforzo) al programmatore del cliente.


Che diamine di problemi tecnici. Pensiamoci con sobrietà.

Supponiamo che tu stia sviluppando una MT5 e che tu abbia un compito: scrivere un blocco HFT per le azioni di trading.

Da un lato i record delle transazioni sono accodati dal server, dall'altro questi record devono essere passati a XXX-expert.

Nell'esperto XXX, all'interno del gestore OnTradeTransaction(), l'utente può avere qualsiasi "pornografia"!

Non è assolutamente chiaro per quanto tempo questa funzione verrà eseguita.

La coda può contenere centinaia di record provenienti dal server ma non ancora trasferiti a XXX-expert.

Cosa può garantire in questa situazione? Velocità o completezza dei dati?

E ha senso "conservare" informazioni profondamente obsolete per una funzione che, nella sua essenza, contribuisce solo all'HFT?

 

Ragazzi!

Lo leggo e mi chiedo...

OnTradeTransaction ti permette di ottenere le informazioni più aggiornate senza "scavare" da nessuna parte

su ordini e scambi!

Semplicemente non sai come usare questa funzione.

 
Михаил:

Ragazzi!

Lo leggo e mi chiedo...

OnTradeTransaction ti permette di ottenere le informazioni più aggiornate senza "scavare" da nessuna parte

su ordini e scambi!

Semplicemente non sai come usare questa funzione.

Nemmeno tu sai come usarlo. Avete già scritto decine di pagine su OnTradeTransaction, ma non avete capito una cosa: OnTradeTransaction è una funzione di servizio per risolvere compiti specifici ristretti, non potete usarla nel trading come fate voi. E poi i ragazzi intelligenti leggono i vostri articoli e creano thread simili: "Perché OnTradeTransaction non è garantita?" - perché un Expert Advisor non dovrebbe creare il suo ambiente di trading attraverso OnTradeTransaction, come fate voi, ma basarsi solo su ciò che è disponibile nel sistema, in particolare nella storia degli ordini e delle operazioni.
 
Vasiliy Sokolov:
Neanche tu sai come fare. Avete già scritto decine di pagine sull'argomento OnTradeTransaction, ma non avete capito una cosa: OnTradeTransaction è una funzione di servizio destinata a risolvere compiti specifici ristretti, non potete usarla nel trading come fate voi. E poi i ragazzi intelligenti leggono i vostri articoli e creano thread simili: "Perché OnTradeTransaction non è garantita?" - perché un Expert Advisor non dovrebbe creare il suo ambiente di trading attraverso OnTradeTransaction, come fate voi, ma basarsi solo su ciò che è disponibile nel sistema, in particolare nella storia degli ordini e delle operazioni.

Da un lato, sì. D'altra parte: che dire dei casi in cui una richiesta è stata inviata al server, ma l'operazione non è ancora stata eseguita? Come possiamo dire in che stato siamo se abbiamo solo una lista di ordini e posizioni (e la storia del conto)?

Non c'è un tale problema in MT4, perché tutte le operazioni di trading sono sincrone. Ma come risultato abbiamo prestazioni più lente.

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

Da un lato, sì. D'altra parte: che dire dei casi in cui una richiesta è stata inviata al server, ma l'operazione non è ancora stata eseguita? Come possiamo dire in che stato siamo se abbiamo solo una lista di ordini e posizioni (e la storia del conto)?

Non c'è questo problema in MT4, perché tutte le operazioni di trading sono sincrone. Ma come risultato, otteniamo prestazioni più lente.

Se il tempo tra l'invio di un ordine e il successivo segnale di entrata nel mercato supera il tempo di esecuzione dell'ordine, non dovremo fare nulla. La logica è semplice: inviamo un ordine asincrono, lasciamo il thread e ce ne dimentichiamo. Aspettiamo il prossimo momento per controllare il segnale. Se in quel momento l'ambiente di trading non è cambiato - l'Expert Advisor cerca un segnale per entrare di nuovo nel mercato e ripete l'ordine di entrare nel mercato. Se, al contrario, tutto è andato bene e l'ordine è stato eseguito, l'Expert Advisor si renderà conto di avere una posizione dopo aver analizzato l'ambiente e non aprirà più una nuova posizione. Cioè, in questo approccio, la condizione dell'Expert Advisor è garantita per essere coerente con l'ambiente di mercato.

La situazione è più complicata nel trading ad alta frequenza, dove un nuovo segnale può verificarsi dopo un tempo paragonabile all'esecuzione di un ordine (6-100 msec). In questo caso, non si può fare a meno di chiudere. L'Expert Advisor dovrebbe ricordare l'ora dell'ultimo invio dell'ordine. Se si verifica un errore in OnTransaction, il blocco viene resettato e l'Expert Advisor può eseguire nuovamente le operazioni.

Va notato che OnTradeTransacton che tanta gente ama pregare non aiuta a HFT. Un nuovo segnale di entrata può arrivare più velocemente della risposta sull'esecuzione riuscita di una transazione in OnTradeTransaction. Il blocco è necessario sia che usiate OnTradeTransacton o meno.

Come, vi chiederete, possiamo controllare gli errori che sorgono in OnTradeTransaction? Potete rispondere con una contro-domanda: come cambierete al volo la logica di trading dell'Expert Advisor quando si verifica un errore? - Non si può. Gli errori si verificano se non si fanno controlli appropriati prima (presenza di denaro, volume, ecc., ecc.). Ma una volta che si è verificato, non sarà possibile correggerlo. Perciò la cosa migliore che potete fare in OnTradeTransaction è stampare questo errore nel log (per correggere la logica di Expert Advisor più tardi), e rimuovere il blocco, se è usato. Per questo e per nient'altro, si deve usare OnTradeTransaction.

Ora vari adepti di Mikalas arriveranno di corsa e cominceranno a lanciarmi pomodori - lasciali fare. Ma ho sempre ripetuto che una logica di trading affidabile può essere organizzata solo se si basa sull'ambiente di trading del terminale. Qualsiasi altra cosa non funzionerà.

 
Alexey Oreshkin:
Sono interessato alla risposta degli sviluppatori - perchél' eventoOnTradeTransaction non è garantito?

OnTradeTransaction è il risultato della risposta del server alla richiesta OrderSendAsinc.

La funzione OrderSendAsinc stessa è asincrona, il che è dichiarato anche nel suo nome. Ciò significa che questa funzione ha lanciato una richiesta al server e ha restituito la risposta al programma sui risultati dell'invio (se la richiesta è stata inviata con successo o meno).

Questo secondo il principio che il gallo canta e non albeggia. Ecco perché la risposta del server inOnTradeTransaction non è garantita. Non si sa mai cosa può succedere lì.

Ci sono due funzioni simili OrderSend e OrderSendAsinc.

Il primo è sincrono e attende silenziosamente la risposta dal server, non importa quanto tempo ci voglia (restituisce il risultato dell'elaborazione della richiesta da parte del server).

Il secondo è asincrono, non aspetta la risposta del server, ma restituisce immediatamente il risultato dell'operazione (ma restituisce il risultato se la richiesta è stata inviata al server con successo o meno).

OrderSendAsinc è necessario quando le decisioni devono essere prese rapidamente. I test hanno dimostrato che OrderSendAsinc può gestire l'invio di centinaia di richieste al secondo (ma questa velocità è dovuta al fatto che non sta aspettando una risposta dal server).

Esattamente per la ricezione di una risposta "ritardata" il terminale genera l'evento OnTradeTransaction (ritardato condizionatamente per il fatto che il programma ha continuato a ricevere la risposta, infatti, il ritardo si conta in secondi o millisecondi).

La differenza con OrderSend è che OnTradeTransaction può essere generato per un ordine diverse volte notificando al terminale le nuove informazioni ricevute su come la richiesta è stata elaborata dal server. Significa che possiamo vedere le fasi di elaborazione dell'ordine in OnTradeTransaction.

Ordine accettato dal server OnTradeTransaction

L'ordine è stato inserito nella coda di OnTradeTransaction

Ordine ... OnTradeTransaction

Ordine ... OnTradeTransaction ecc.

Tutti gli eventi diversi dal primo evento sull'ordine sono firmati con un ticket per identificare esattamente da quale ordine è stata ricevuta la risposta all'evento OnTradeTransaction.

Il primo evento è firmato dal biglietto e dal request_id. Il request_id è ottenuto dall'utente subito dopo l'invio dell'ordine dalla funzione OrderSendAsinc. Così una specifica iterazione di OrderSendAsinc è legata ai risultati ottenuti in OnTradeTransaction.

Motivazione: