Discussione sull’articolo "Comunicare con MetaTrader 5 utilizzando pipe denominate senza utilizzare DLL"
I tubi funzionano nel tester?
Perché la comunicazione tra terminali diversi dovrebbe funzionare nel tester?
Se lo si fa tramite eventi, questi funzionano nel tester.
Perché la comunicazione tra terminali diversi dovrebbe funzionare nel tester?
Se lo fai tramite eventi, funzionano nel tester.
Cosa tramite eventi? Comunicazione tra terminali?
;)
Le pipeline nominate funzionano negli agenti locali, ma sono disabilitate nei cladi.
Cioè, sia i singoli test che gli agenti locali di massa possono connettersi a un server pip di terze parti (non solo locale).
Perché no? Vale la pena provare, non so perché. :)
cosa attraverso gli eventi? comunicazione tra terminali?
;)
Se una persona ha bisogno di comunicare tra i programmi nel tester, allora il compito di trasferire i dati tra i programmi in un terminale è ovvio, e questo può essere fatto attraverso gli eventi, omettendo tutte queste sciocchezze, la mia risposta è abbastanza logica.
A colpo d'occhio, ci sono due modi per utilizzarlo:
- copiare le operazioni da un conto all'altro (così come da MetaTrader 5 a MetaTrader 4 o viceversa)
- ottenere risultati di ottimizzazione al volo con un'elaborazione dinamica in un'altra applicazione.
E gli articoli su questo argomento saranno interessanti.
A colpo d'occhio, ci sono due modi per utilizzarlo:
- copiare le operazioni da un conto all'altro (così come da MetaTrader 5 a MetaTrader 4 o viceversa)
- ottenere risultati di ottimizzazione al volo con un'elaborazione dinamica in un'altra applicazione.
E gli articoli su questo argomento saranno interessanti.
Purtroppo questo è possibile solo per chi sa programmare in C per Windows, perché:
Si noti che si tratta di un supporto client e che i connettori server non possono essere creati nel terminale.
In altre parole, nelle tecnologie client-server due client non si vedono senza la mediazione del server. Ho esaminato l'argomento della creazione di canali con nome in altri linguaggi di programmazione, ma sfortunatamente nella maggior parte di essi è possibile creare un client per Windows con mezzi standard, anche se i canali per Unix vengono creati quasi ovunque senza problemi.
Abbiamo bisogno di gateway sotto forma di EXE-shell, che possano collegare due canali denominati full-duplex secondo l'algoritmo:
- Creare due canali denominati A e B
- Creare il primo sottoprocesso che ascolti il canale A per una connessione.
- Dopo che un client in attesa di un messaggio si connette al canale A, creare un secondo sottoprocesso che ascolta il canale B per una connessione.
- Il primo sottoprocesso viene attivato per trasferire un flusso di byte in un ciclo dal canale A al canale B.
- Non appena un client si connette al canale B, il secondo sottoprocesso viene avviato per leggere il flusso di byte in un ciclo dal canale B al canale A.
- Il secondo client inizia a trasmettere il primo messaggio dal canale B al canale A.
- e così via, fino a quando qualche client non cade, dopodiché entrambi i canali vengono distrutti e si passa al punto 1. 1
Naturalmente, negli script MQL a task singolo il full duplex non è necessario, perché i client non possono ricevere e trasmettere informazioni in modo asincrono. Ma l'half-duplex è adatto solo per quei casi in cui il server conosce il protocollo di scambio e può facilmente calcolare dove termina la ricezione-trasmissione da un client all'altro per passare alla modalità opposta. Se non lo sa, perché non ha capacità telepatiche, e lo sanno solo i client che scambiano tra loro utilizzando il protocollo noto solo a loro, allora è necessario un full duplex con due sottoprocessi. Un gateway di questo tipo è conveniente perché ogni client dispone di un solo canale di comunicazione con un altro client e la sequenza di connessione da parte del client non gioca alcun ruolo, se egli verificherà certamente la possibilità di connessione nel ciclo iniziale. L'algoritmo del gateway esclude la possibilità di connessione del client, che è il primo secondo il protocollo deve trasmettere un messaggio prima che il secondo client si connetta e la trasmissione al vuoto non avverrà.
In teoria, poiché il numero di canali denominati è illimitato, sarebbe possibile creare un gateway simplex a compito singolo secondo l'algoritmo:
- Viene creato un primo canale denominato per la trasmissione dal gateway al client.
- Dopo che il primo client si è connesso, viene creato un secondo canale per ricevere i messaggi dal client.
- Dopo che il client di trasmissione si è connesso al secondo canale, il processo esegue un loop del flusso di byte dal canale di ricezione al canale di trasmissione.
- Non appena un client si ritira, si rimuovono entrambi i canali e si passa al punto 1.
In questo caso sono necessari due gateway di questo tipo per collegare due client in half-duplex o uno se si usa solo il simplex. Lo svantaggio rispetto a un gateway full-duplex è che negli script MQL si dovranno scrivere due canali (per la ricezione e per la trasmissione) e in essi rispettare rigorosamente la sequenza di connessione: prima per la ricezione e poi per la trasmissione (altrimenti il secondo canale non verrà mai creato). L'algoritmo di questo gateway esclude anche la possibilità di connettere un client, che è il primo secondo il protocollo deve trasmettere un messaggio prima che il secondo client si connetta e la trasmissione al vuoto non avverrà.
Naturalmente, i gateway dovrebbero prevedere la possibilità di configurare i nomi dei canali in base alla sequenza di ricezione-trasmissione e connessione dei client, ad esempio attraverso la riga di comando all'avvio.
Se qualcuno che programma in C creasse tali gateway, li compilasse in EXE e li postasse qui, sarebbe facile creare connessioni tra script, Expert Advisor e indicatori utilizzando gli strumenti standard di MQL5 senza dover tamburellare in altri linguaggi di programmazione.
In teoria, si potrebbe anche scrivere un articolo su come connettere correttamente i clienti con tali gateway, in modo da non creare server in linguaggi diversi da MQL (probabilmente non sono l'unico a non saper programmare in C, giusto?) con esempi specifici in co-autorialità con un programmatore C. Cioè, da me il testo dell'articolo e gli esempi in MQL, e dal programmatore C-sh i sorgenti dei gateway in C e EXE-shniki. Il compenso è condiviso.
Il server è semplice, tutto in sorgenti, compreso il file exe compilato nella directory /release. I test possono essere ripetuti facilmente.
A proposito, gli esempi mostrano uno scambio full-duplex, in cui non è necessario attendere nessuno.
Il server è semplice, tutto in sorgenti, compreso il file exe compilato nella directory /release. I test possono essere ripetuti facilmente.
Non è questo il punto. Ho provato a eseguire il tuo esempio. Funziona. Ma non serve a nulla, cioè l'ho provato e basta, può essere cancellato perché non serve più.
Da un lato, ci si è sbarazzati della dll, ma dall'altro, ancora una volta, per l'uso dell'applicazione si ha bisogno di stampelle in altri linguaggi di programmazione.
Lo svantaggio del metodo proposto è che è adatto solo ai programmatori che sviluppano applicazioni in linguaggi diversi da MQL e che supportano le API di Windows. In altre parole, l'esempio proposto non è universale e non può essere adattato ad altri compiti senza modifiche. E ognuno ha compiti diversi. E questo significa che gli utenti dovranno creare anche uno scambio elementare di informazioni tra due script per studiare oltre a MQL un altro linguaggio, in modo da creare su di esso un server in cui è necessario scrivere parte della logica relativa al protocollo di scambio.
Propongo di creare i gateway una volta sola, compilarli e metterli a disposizione di tutti, in modo che qualsiasi utente possa creare connessioni, utilizzando solo gli strumenti standard di MQL.
Per esempio, per me non fa differenza se i file grezzi aperti o chiusi sono in C. Perché non scrivo nulla in C e ci vorrà tempo per risolvere i voli. Non posso nemmeno compilare questi stessi file grezzi. E in Pure Java, così come in molti altri linguaggi di programmazione, è possibile creare solo connessioni client tramite flussi di file utilizzando strumenti standard. Se ci fosse un gateway che collega due canali denominati almeno in simplex, non ci sarebbero problemi. Scriverei il protocollo di scambio nei client, mi collegherei attraverso un paio di gateway, eseguirei il debug e tutto funzionerebbe. Cioè non c'è bisogno di progettare e creare un server separato per ogni attività.
E al momento, cioè senza gateway, molte persone dovranno installare un ambiente di sviluppo per C, imparare un nuovo linguaggio di programmazione, ecc. ecc.
Il gateway se ne frega: ciò che riceve da un client lo invia a un altro. La logica è stupida, ma permette di unire due client senza stampelle aggiuntive e balla con il tamburello, cioè è universale e indipendente dal protocollo di scambio di informazioni e dalla conoscenza del linguaggio C.
Qui, come si dice, il nutrito non capisce l'affamato. Chi sviluppa qualcosa in C difficilmente riscontrerà problemi. E per il resto di noi, possiamo gestire questo sistema come vogliamo.
- 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
Il nuovo articolo Comunicare con MetaTrader 5 utilizzando pipe denominate senza utilizzare DLL è stato pubblicato:
Molti sviluppatori affrontano lo stesso problema: come accedere alla sandbox del terminale di trading senza utilizzare DLL non sicure. Uno dei metodi più semplici e sicuri consiste nell'utilizzare pipe denominate standard che funzionano come normali operazioni sui file.
Consentono di organizzare la comunicazione client-server interprocessore tra i programmi. Sebbene sia già stato pubblicato un articolo Una soluzione senza DLL per comunicare tra terminali MetaTrader 5 utilizzando pipe denominate su questo argomento, il che dimostra l'abilitazione dell'accesso alle DLL, utilizzeremo standard e caratteristiche del client terminal.
È possibile trovare ulteriori informazioni sulle pipe denominate nella libreria MSDN, ma passeremo ad esempi pratici in C++ e MQL5. Implementeremo server, client, scambio di dati tra loro e quindi prestazioni di benchmark.
Autore: MetaQuotes