Copiatore di transazioni/segnali altamente affidabile (discussione di ideologia e sviluppo)

 
A questo proposito, sono interessato alle opzioni di sincronizzazione (trasmissione di ordini) dei terminali
- 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.
 

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.
 
TheXpert:
Fate una versione commerciale e spingetela.

Stai parlando con me?
 
FAQ:
Stai parlando con me?
Se sei il topicstarter, sì :)
 
FAQ:

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.

 
TheXpert:
Fate una versione commerciale e spingetela.

Non voglio spingere nulla e non lo farò. Sto facendo un mezzo, non un fine. Lo faccio per tutti.
 
sergeev:

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.
 
sergeev:

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ì!!!
 
Non c'è bisogno di complicarlo, è sufficiente inviare un segnale di controllo al client ad un certo intervallo (diciamo una volta al secondo), e se il client non risponde, allora agire. <br / translate="no">
stai parlando solo di un segnale da server a client? hai bisogno di un meccanismo dettagliato di come il segnale vive e viene trasmesso al ricevitore. Non ho mai incontrato un sistema simile prima d'ora. Solo l'ordine di copiatura.
 
Tutto si è risolto, ma mi dispiace, non gratis.