Funzione OrderSendAsync() - pagina 8
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Perché i pacchetti rotti, le connessioni interrotte, ecc. sono una stronzata. Inaffidabile. Inaffidabile - devi disconnetterti.
Nel caso, terremo la coda delle transazioni commerciali per l'emissione agli EA e le daremo via.
Le interruzioni nell'esecuzione sono un problema, non è ancora chiaro come gestirle. In ogni caso, saremo in grado di controllare tutte le posizioni aperte dopo la riconnessione.
Perché i pacchetti rotti, le connessioni interrotte, ecc. sono una stronzata. Inaffidabile. Inaffidabile: devi rimbalzare.
Teniamo separate le mosche e le cotolette.
I pacchetti rotti sono una situazione anomala per il terminale e dovrebbero essere gestiti dalle eccezioni, anche attraverso l'analisi della storia.
Ma è troppo costoso analizzare la storia di ogni commercio. L'arrivo del commercio è una situazione normale e dovrebbe essere gestita in modo poco costoso.
Ciao. Sai almeno cos'è l'asincronia?
Per quanto ho capito, introducendo questa funzione per gli EA multicurrency (per gli EA monocurrency l'iniziativa non ha senso), l'unico scopo è quello di risparmiare tempo evitando il ritardo nell'esecuzione degli ordini sul lato server. Correggetemi se mi sbaglio.
A parte questo, rimane solo una porzione di tempo critica: la trasmissione dei pacchetti di dati sui canali di comunicazione. Cercando di spingere il "confine dell'ignoto" al livello di "drop (packet) and run on", si hanno più problemi che benefici. È importante valutare il problema in modo olistico. Un possibile time out, se ce ne fosse uno, è probabile che colpisca non solo la capacità di fare trading su un particolare strumento, ma anche, in linea di principio, la mancanza di comunicazione con il server.
Inoltre, non è chiaro come stimare dall'Expert Advisor: l'ordine di trading è stato perso nella trasmissione dei dati, o sta aspettando il suo turno sul server per un tempo così lungo? E questo significa che ci saranno errori con ordini di trading duplicati, che porteranno alla violazione della MM e, di conseguenza, a rischi maggiori. Secondo me ogni trader professionista (Expert Advisor) dovrebbe assicurarsi che il suo ordine di trading sia accettato per l'esecuzione dal server. Inoltre, per identificare chiaramente lo stato di un certo ordine di compravendita (nella funzione OnTrade()), avete bisogno di un valore unico ricevuto dal server per applicarlo a ulteriori elaborazioni (fino all'esecuzione della compravendita (apertura/chiusura di una posizione).
È simile al modello di rete OSI. Non abbiamo bisogno di entrare nel canale o nel livello fisico dell'esecuzione degli ordini commerciali. Lasciate che il client (MT5) esegua questa funzione di trasporto. Operare a livello di applicazione.
Risparmio di tempo grazie all'assenza di ritardo lato server nell'esecuzione dell'ordine. Correggetemi se mi sbaglio.
Al costo di non aspettare i risultati della richiesta. In generale, sì. Cioè per gli ordini e l'esecuzione del mercato può essere molto utile.
A parte questo, rimane solo una parte di tempo critica: la trasmissione del pacchetto di dati sui canali di comunicazione. Cercando di spingere il "confine dell'ignoto" al livello di "drop (packet) and run on", si hanno più problemi che benefici.
Bene... no. Bisogna solo usarlo quando i benefici superano i problemi.
Secondo me, ogni trader professionista (consulente) deve assicurarsi che il suo ordine di trading sia accettato per l'esecuzione dal server.
Allora l'opzione asincrona non è adatta a voi. Tutto è risolvibile.
TheXpert
Facciamolo di nuovo, sulle dita. Strutturazione approssimativa dei ritardi:
1. Tempo per il terminale di pre-controllare l'ordine di compravendita, "impacchettarlo" nel batch in uscita e metterlo nella "coda di rete".
2. Tempo di trasmissione di un pacchetto di dati contenente un ordine di compravendita dal client al server.
3. Tempo di ricezione di un ordine di compravendita da parte del server e di immissione nel pool di elaborazione e di invio al cliente di un identificatore unico di questo biglietto.
4. Il tempo di pre-elaborazione della correttezza dell'ordine di compravendita e il suo posizionamento sul piano di negoziazione.
Se ho indicato qualcosa di sbagliato, per favore correggete. Capisco che non volete aspettare dopo il primo punto? Io, invece, sostengo la disponibilità obbligatoria dei primi tre.
È necessario rispondere a due domande per un'ulteriore discussione:
1. Il rapporto proporzionale dei ritardi. Cioè, in media, quanto tempo in termini percentuali richiede ciascuno dei quattro elementi di cui sopra. Se la distribuzione è, per esempio, "0,5%-1,0%-1,0%-97,5%" allora non ne vale la pena.
2) Time-out e il suo impatto sulla strategia di trading. Francamente, non posso nominare un solo TS che non richieda di capire chiaramente se un ordine è stato inviato al server o no. Questo è rilevante sia per l'arbitraggio a lungo termine che per quello multicurrency. Cioè, la garanzia di esecuzione di un ordine commerciale non può essere messa in discussione. Si prega di fornire un controesempio se non si è d'accordo.
Secondo me, il modo più semplice per risolvere il problema dell'esecuzione su una pausa è quello di non creare una coda di esecuzione (annullare l'esecuzione) e notificare all'utente l'annullamento alla riconnessione. In questo modo ci sarà meno ambiguità.
Un biglietto del server deve essere restituito. Questo assicurerà che l'ordine raggiunga il server e sia accettato per l'elaborazione.
Costruire astuti pool di attesa sul lato client non è solo una soluzione poco pratica, la chiamerei un grossolano difetto di progettazione nell'architettura client-server di MT5.
Cumuli di attesa ingombranti sul lato client non è una soluzione elegante.
Questo è ciò che è stato chiesto. Nessuno vi obbliga ad usarlo se non siete obbligati.
TheXpert
Facciamolo di nuovo, sulle dita. Strutturazione approssimativa dei ritardi:
1. il tempo per il terminale di pre-controllare l'ordine di compravendita, "impacchettarlo" in un pacchetto spedibile e metterlo nella "coda di rete".
2. Tempo di invio di un pacchetto di dati contenente un ordine di compravendita dal client al server.
Tempo di ricezione di un ordine di compravendita da parte del server e di immissione nel pool di elaborazione e di invio al cliente di un identificatore unico di questo biglietto.
4. Tempo di pre-elaborazione della correttezza dell'ordine di compravendita e collocazione sul piano di negoziazione.
3 è meglio diviso.
3.1 posizionamento
3.2 invio di uid.
Se ho indicato qualcosa di sbagliato, per favore correggete. Ho capito che non volete aspettare dopo il primo articolo?
Sì.
Io, invece, sono favorevole a rendere obbligatori i primi tre.
E se il ping è di mezzo secondo? È asincrono. Che senso ha usare questa modalità?
Questo è ciò che è stato chiesto. Nessuno vi obbliga ad usarlo se non siete obbligati.
Non hai ancora risposto alla mia domanda. Per favore, datemi un esempio concreto in quali casi si può prescindere dalla garanzia di esecuzione dell'ordine di compravendita per amore della velocità di invio a diversi personaggi?
Non hai ancora risposto alla mia domanda. Per favore, datemi un esempio concreto di quando si possono ignorare le garanzie di esecuzione degli ordini commerciali in nome della velocità di invio a diversi simboli?
Nessun problema - trading di portafoglio + esecuzione di mercato.