Copiatore di transazioni/segnali altamente affidabile (discussione di ideologia e sviluppo)
Ok. Per cominciare, dobbiamo dividere i compiti(tipo di esperto) in variante commerciale (via rete), e variante condizionatamente non commerciale (all'interno dello stesso sistema OP).
Variante di rete - in modo univoco attraverso un server aggiuntivo, per la sicurezza e la gestione dei clienti.
Intra-sistema - comunicazione: mappatura, a causa della velocità e dell'affidabilità.
Dal momento che il terminale manterrà la libc fino a quando non cadrà o si chiuderà, sarà un'indicazione dello stato del MT (slave) stesso.
E il protocollo sarà qualcosa del genere:
Il master crea un mappu di nome (il cui nome è noto a tutti gli slave), e aspetta che questi segnalino di iniziare il percorso, questo sarà l'advisor (slave) window handle.
Dopo lo scambio dei segnali, ne viene creato un altro dove vengono passati i segnali di trading e allo stesso tempo viene dato il comando di aggiornamento della finestra ad ogni slave.
Dopo l'esecuzione del segnale, lo slave deve segnalare la sua esecuzione o sarà considerato come congelato e saranno prese misure per portarlo su.
Se lo slave si è scaricato (correttamente), dovrebbe fare rapporto.
A sua volta uno qualsiasi degli slave può monitorare lo stato del master e prendere le misure necessarie per sollevarlo, o per emettere un allarme.
Generalmente circa lo stesso.
Per la comunicazione in rete, vedere più avanti.
Fate una versione commerciale e spingetela.
Stai parlando con me?
Stai parlando con me?
Una volta che il segnale è stato eseguito, lo slave deve segnalarne l'esecuzione, altrimenti viene considerato congelato e vengono presi provvedimenti per sollevarlo.
Se è scaricato (correttamente), lo slave dovrebbe segnalarlo.
Queste righe mi ricordano la necessità di discutere due modalità di funzionamento
sincronizzazione degli ordini a livello di ordine master->cliente. E la sincronizzazione dei segnali a livello master->client (abbiamo bisogno di un database di segnali, riconoscimento della ricezione dal client, ecc.)
Penso che dovremmo anche decidere cosa sarebbe più affidabile e meno complicato in termini di sincronizzazione e perdita di segnali o si dovrebbe implementare entrambi i progetti contemporaneamente.
queste righe mi hanno ricordato la necessità di discutere due modalità di funzionamento
sincronizzazione degli ordini a livello di ordine master->cliente. E la sincronizzazione dei segnali a livello di segnale del master->segnale del cliente (c'è bisogno di un database di segnali, conferma della ricezione da parte del cliente, ecc.)
Penso che dovremmo anche decidere cosa sarebbe più affidabile e meno complicato in termini di sincronizzazione e perdita di segnali.
Non c'è bisogno di complicare le cose, è sufficiente inviare un segnale di controllo al cliente ad un certo intervallo (diciamo, una volta al secondo), e se non ha risposto, allora agire.
Non voglio spingere nulla e non lo farò. Io faccio i mezzi, non il fine. Lo faccio per tutti.
Rispetto le persone così, continuate così!!!
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Accetti la politica del sito e le condizioni d’uso
- loc loc localmente
- remotamente
Stiamo progettando di fare tutto in una volta in una modalità un server - molti clienti.
Dovremo prestare attenzione ad aspetti come
- l'opzione di collegamento (file, memoria per uno locale; socket, http, server intermedio, ecc. per uno remoto)
- nessun carico sul canale di comunicazione (particolarmente vero per la sincronizzazione remota)
- fail-safety (ripristino del canale in caso di perdita)
- Reinizializzazione dell'Expert Advisor stesso in caso di guasto del terminale/OS
- Nessuna duplicazione/nessuna cancellazione di affari se la connessione viene persa/ripristinata
ecc.
Bisogna anche considerare due ideologie
- sincronizzazione sul livello di disponibilità dell'ordine
- sincronizzazione a livello di invio di segnali per aprire/chiudere ordini
descrivere i vantaggi e gli svantaggi di questa variante per ciascuna delle nostre proposte.
Vorrei che la discussione ci aiutasse a trovare la soluzione migliore per l'affidabilità/semplicità del sistema.
Mi occuperò della codifica e dei test.
I risultati possono essere pubblicati in codebase previo accordo.