Chi ha già provato l'abbonamento Signals per mettersi alle calcagna dei partecipanti di ATC 2012? - pagina 5
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
Pensa anche alle lattaie.
Rent a Signal si sgonfia...
qualche idea del perché?
Inoltre, ci sono diverse altre questioni da risolvere:
Abbiamo volutamente semplificato il sistema fino a un solo segnale, eliminando le conseguenze peggiori. Soprattutto tenendo conto del fatto che la maggior parte delle transazioni passerà molto probabilmente attraverso il meccanismo Trusted Execution Token dei server cloud, che ridurrà il ritardo della copia del segnale a pochi millisecondi.
Aspetta un attimo, non hai sviluppato tu l'architettura? Ora sei tu che scrivi di pasticciare con le posizioni e l'intersezione per simboli.
C'è un meccanismo di non-trading per replicare i trade, non ha nessuna perdita di connettività, nessun problema di sincronizzazione dopo una riconnessione (immaginate 15 minuti o 2 ore di assenza di connettività) e può essere strettamente controllato il 100% del tempo. Inoltre, c'è MetaTrader 4 senza reti.
Abbiamo volutamente semplificato il sistema fino a un solo segnale, eliminando le conseguenze peggiori. Soprattutto perché la maggior parte delle transazioni passerà probabilmente attraverso il meccanismo Trusted Execution Token dei server cloud, che ridurrà la latenza della copia del segnale a pochi millisecondi.
Finora non avete presentato alcuna soluzione ai problemi, ma solo affermato che "avete poco da fare, e in generale il compito è una passeggiata".
Considerate che ci siamo scervellati sul problema per molto più tempo. E non ci siamo fermati al primo passo "beh, sì, in teoria si può fare".
In realtà, l'essenza di tutti i vostri commenti si è ridotta a "dare e basta, è teoricamente possibile, quindi non negare, e io sono troppo pigro per andare oltre il primo passo di elaborazione".
Caratteristicamente, tutte le cose costruttive del mio post precedente sono state ignorate )
Sfortunatamente, non c'è stato alcun input costruttivo da parte vostra. C'era solo un "dare e avere" + dichiarazioni a senso unico.
Cioè, non hai descritto come risolvere il conflitto di più segnali e non hai dato una risposta alla domanda come recuperare da una perdita di connessione.
Inoltre, non affronta affatto la responsabilità dei conflitti imminenti che tendono al 100% di probabilità. Non ho sottolineato per niente l'impossibilità della soluzione "posso farlo io per me, lo sistemo io, va bene così" per il servizio di massa.
Per quanto riguarda l'argomento, posso dire per esperienza personale che il problema è molto complesso e non può essere risolto con una semplice replica. Convenzionalmente può essere diviso in tre componenti:
Tutto questo è molto difficile da organizzare in pratica, e inoltre richiederebbe una seria modifica dell'architettura esistente.
Aspetta un attimo, non hai progettato tu l'architettura? Ora lei stesso sta scrivendo sulla sovrapposizione di posizione e carattere.
Vedo che poche persone hanno veramente pensato all'implementazione dell'elaborazione.
Anche se si può capire il treno del pensiero dall'affermazione "Dammi una soluzione, il commerciante ne ha bisogno, memorizza gli stati sul server". È comprensibile: trasferire il massimo dei problemi agli altri, non preoccuparsi, e se qualcosa va male - criticarli per una cattiva implementazione.
Ma se si valuta il problema dal lato del broker, del fornitore del sistema, dell'infrastruttura di rete, e solo allora del trader, si vedrà che la soluzione proposta di miscelazione del segnale non ha una soluzione ragionevole e sicura.
Purtroppo non c'è stato nessun atteggiamento costruttivo. C'era solo "dare e avere" + dichiarazioni a senso unico.
In altre parole, non avete descritto come risolvere i conflitti di segnali multipli o rispondere alla domanda su come recuperare la perdita di comunicazione.
Inoltre, non affronta affatto la responsabilità dei conflitti imminenti che tendono al 100% di probabilità. Non ho sottolineato per niente l'impossibilità della soluzione "posso farlo per me, lo sistemo io, va bene così" per il servizio di massa.
E cosa pensate che possano fare gli sviluppatori indipendenti? MT5 è rigidamente monolitico. Il meglio che possono fare è creare un'altra stampella e descriverla nell'articolo corrispondente. Non si può scrivere un sistema di qualità senza integrarlo in un prodotto. Conoscendo il problema in prima persona, posso dire che non si può fare a meno di salvare i record degli stati sul lato server. E come pensate che gli sviluppatori di terze parti dovrebbero risolvere questo problema? Alla fine, fanno il meglio che possono. Creano stampelle e combinazioni di MQL5 <-> DLL <--> SQL, che sono difficili da mantenere e inapplicabili al mercato di massa, che tu stai lodando così tanto.
Vi sbagliate.
MQL5 è così aperto e funzionale che si può fare quasi tutto. Non c'è bisogno di fare stampelle con DLL e SQL, è sufficiente usare le operazioni su file e memorizzare tutto ciò che serve su disco. Il database delle variabili globali è molto stabile e non viene perso durante i riavvii o i crash.
E l'immagazzinamento di stato sul server è medaglie e commenti. Imparate a usarli con parsimonia.