Discussion de l'article "Communiquer avec MetaTrader 5 en utilisant Named Pipes sans utiliser de DLL"
Les tuyaux fonctionnent-ils dans le testeur ?
Pourquoi la communication entre différents terminaux devrait-elle fonctionner dans le testeur ?
Faites-le par le biais d'événements, ils fonctionnent dans le testeur.
Pourquoi la communication entre différents terminaux devrait-elle fonctionner dans le testeur ?
le faire par le biais d'événements, cela fonctionne dans le testeur.
Qu'est-ce qui se passe via les événements ? la communication entre les terminaux?
;)
Les pipelines nommés fonctionnent dans les agents locaux, mais sont désactivés dans les clades.
En d'autres termes, les tests individuels et les agents locaux de masse peuvent se connecter à un serveur pip tiers (et pas seulement local).
Pourquoi pas ? Ça vaut le coup d'essayer, je ne sais pas pourquoi. :)
Qu'en est-il des événements ? de la communication entre les terminaux ?
;)
Si une personne a besoin de communiquer entre les programmes dans le testeur, alors la tâche de transfert de données entre les programmes dans un terminal est évidente, et cela peut être fait par le biais d'événements, en omettant toutes ces absurdités, ma réponse est tout à fait logique.
En un coup d'œil, il y a deux façons de l'utiliser :
- copier des transactions d'un compte à l'autre (ainsi que de MetaTrader 5 à MetaTrader 4 ou vice versa)
- obtenir des résultats d'optimisation à la volée grâce à un traitement dynamique dans une autre application.
Des articles sur ce sujet seront intéressants.
En un coup d'œil, il y a deux façons de l'utiliser :
- copier des transactions d'un compte à l'autre (ainsi que de MetaTrader 5 à MetaTrader 4 ou vice versa)
- obtenir des résultats d'optimisation à la volée grâce à un traitement dynamique dans une autre application.
Des articles sur ce sujet seront intéressants.
Malheureusement, cela n'est possible que pour ceux qui savent programmer en C pour Windows, car.. :
Notez bien qu'il s'agit d'un support client, et que les connecteurs serveur ne peuvent pas être créés dans le terminal.
En d'autres termes, dans les technologies client-serveur, deux clients ne se verront pas l'un l'autre sans la médiation du serveur. J'ai étudié la possibilité de créer des canaux nommés dans d'autres langages de programmation, mais malheureusement, dans la plupart d'entre eux, vous pouvez créer un client pour Windows par des moyens standard, bien que les canaux pour Unix soient créés presque partout sans aucun problème.
Nous avons besoin de passerelles sous la forme de shells EXE, qui pourraient connecter deux canaux nommés en duplex intégral selon l'algorithme :
- Créer deux canaux nommés A et B
- Créer le premier sous-processus qui écoute le canal A pour une connexion.
- Après qu'un client en attente d'un message se soit connecté au canal A, créez un second sous-processus qui écoute le canal B pour une connexion.
- Le premier sous-processus est activé pour transférer un flux d'octets en boucle du canal A au canal B
- Dès qu'un client se connecte au canal B, le deuxième sous-processus est lancé pour lire le flux d'octets en boucle du canal B vers le canal A.
- Le deuxième client commence à transmettre le premier message du canal B au canal A.
- et ainsi de suite, jusqu'à ce qu'un client se déconnecte, après quoi les deux canaux sont détruits et nous passons au point 1. 1
Bien entendu, dans les scripts MQL à tâche unique, le duplex intégral n'est pas nécessaire, car les clients ne peuvent pas recevoir et transmettre des informations de manière asynchrone. Mais le half-duplex ne convient que dans les cas où le serveur connaît le protocole d'échange et peut facilement calculer où se termine la réception-transmission d'un client à l'autre afin de passer au mode opposé. S'il ne le sait pas, parce qu'il n'a pas de capacités télépathiques, et que cela n'est connu que des clients qui échangent entre eux en utilisant le protocole qu'ils sont les seuls à connaître, alors un full duplex avec deux sous-processus est nécessaire. Une telle passerelle est pratique car chaque client n'a qu'un seul canal de communication avec un autre client et la séquence de connexion du côté du client ne joue aucun rôle, s'il vérifiera certainement la possibilité de connexion dans le cycle initial. L'algorithme de la passerelle exclut la possibilité de connexion du client qui, selon le protocole, est le premier à transmettre un message avant que le second client ne se connecte et que la transmission au vide n'ait pas lieu.
En théorie, le nombre de canaux nommés étant illimité, il serait possible de créer une passerelle simplex à tâche unique conformément à l'algorithme :
- Un premier canal nommé est créé pour la transmission de la passerelle au client.
- Une fois que le premier client a établi une connexion, un deuxième canal est créé pour recevoir les messages du client.
- Une fois que le client émetteur s'est connecté au second canal, le processus boucle le flux d'octets du canal de réception au canal d'émission.
- Dès qu'un client se déconnecte, nous supprimons les deux canaux et passons à l'étape 1.
Dans ce cas, vous aurez besoin de deux passerelles de ce type pour connecter deux clients en semi-duplex ou d'une seule passerelle si vous n'utilisez que le simplex. L'inconvénient par rapport à une passerelle full-duplex est que dans les scripts MQL, vous devrez écrire deux canaux (pour la réception et la transmission) et respecter strictement la séquence de connexion : d'abord pour la réception et ensuite pour la transmission (sinon le deuxième canal ne sera jamais créé). L'algorithme de cette passerelle exclut également la possibilité de connecter un client, qui est le premier selon le protocole à transmettre un message avant que le second client ne se connecte et que la transmission au vide ne se produise.
Naturellement, les passerelles devraient prévoir la possibilité de configurer les noms des canaux en fonction de la séquence de réception-transmission et de connexion des clients, par exemple, par le biais de la ligne de commande au démarrage.
Si quelqu'un programmant en C créait de telles passerelles, les compilait en EXE et les publiait ici, il serait alors facile de créer des connexions entre les scripts, les Expert Advisors et les indicateurs en utilisant les outils standard de MQL5 sans tambouriner dans d'autres langages de programmation.
Théoriquement, vous pouvez aussi écrire un article sur la façon de connecter correctement les clients avec de telles passerelles, afin de ne pas créer des serveurs dans des langages autres que MQL (je ne suis probablement pas le seul à ne pas savoir programmer en C, n'est-ce pas ?) avec des exemples spécifiques en co-écriture avec un programmeur C. C'est-à-dire, de ma part le texte de l'article et les exemples en MQL, et de la part du programmeur C-sh les sources des passerelles en C et EXE-shniki. Les frais sont partagés.
Le serveur est simple, tout est dans les sources, y compris le fichier exe compilé dans le répertoire /release. Les tests peuvent être répétés facilement.
D'ailleurs, les exemples montrent un échange en duplex intégral, où il n'est pas nécessaire d'attendre quelqu'un.
Le serveur est simple, tout en sources, y compris le fichier exe compilé dans le répertoire /release. Les tests peuvent être répétés facilement.
Là n'est pas la question. J'ai essayé d'exécuter votre exemple. Il fonctionne. Mais il n'est d'aucune utilité, c'est-à-dire que je l'ai essayé et c'est tout, il peut être supprimé parce qu'il n'est plus nécessaire.
D'une part, vous vous êtes débarrassé de la dll, mais d'autre part, une fois encore, pour l'utilisation de l'application, vous avez besoin de béquilles dans d'autres langages de programmation.
L'inconvénient de la méthode proposée est qu'elle ne convient qu'aux programmeurs développant des applications dans des langages autres que MQL et prenant en charge l'API Windows. En d'autres termes, l'exemple proposé n'est pas universel et ne peut être adapté à d'autres tâches sans modification. Or, chaque personne a des tâches différentes. Et cela signifie que les utilisateurs devront, pour créer ne serait-ce qu'un échange élémentaire d'informations entre deux scripts, étudier en plus de MQL un autre langage, afin de créer sur celui-ci un serveur dans lequel il faudra écrire une partie de la logique liée au protocole d'échange.
Je propose de créer les passerelles une seule fois, de les compiler et de les mettre à la disposition de tous, afin que n'importe quel utilisateur puisse créer des connexions, en n'utilisant que les outils standards de MQL.
Par exemple, pour moi, cela ne fait aucune différence que les fichiers bruts ouverts ou fermés soient en C. Parce que je n'écris rien en C et qu'il faudra du temps pour trier les vols. Je ne peux même pas compiler ces mêmes fichiers bruts. Et en Java pur, ainsi que dans de nombreux autres langages de programmation, vous pouvez créer uniquement une connexion client via des flux de fichiers à l'aide d'outils standard. S'il existait une passerelle qui relie deux canaux nommés au moins par simplex, il n'y aurait aucun problème. J'écrirais le protocole d'échange dans les clients, je me connecterais à travers quelques passerelles, je déboguerais et tout fonctionnerait. En d'autres termes, il n'est pas nécessaire de concevoir et de créer un serveur distinct pour chaque tâche.
Et à l'heure actuelle, c'est-à-dire sans passerelle, de nombreuses personnes devront installer un environnement de développement pour le langage C, apprendre un nouveau langage de programmation, etc.
La passerelle s'en moque : ce qu'elle reçoit d'un client, elle l'envoie à un autre. La logique est bête, mais elle permet d'unir deux clients sans béquilles supplémentaires et danse avec le tambourin, c'est-à-dire qu'elle est universelle et indépendante du protocole d'échange d'informations et de la connaissance du langage C.
Ici, comme on dit, le nourri ne comprend pas l'affamé. Ceux qui développent quelque chose en C ne verront probablement aucun problème. Quant aux autres, ils peuvent gérer ce système comme ils l'entendent.
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation
Un nouvel article Communiquer avec MetaTrader 5 en utilisant Named Pipes sans utiliser de DLL a été publié :
De nombreux développeurs sont confrontés au même problème : comment accéder au sandbox du terminal de trading sans utiliser de DLL non sécurisées. L'une des méthodes les plus simples et les plus sûres consiste à utiliser des Named Pipes standard qui fonctionnent comme des opérations de fichier normales. Ils vous permettent d'organiser la communication inter-processeur client-serveur entre les programmes. Regardez les exemples pratiques en C++ et MQL5 qui incluent le serveur, le client, l'échange de données entre eux et l'évaluation des performances.
Codons un serveur simple en C++. Un script du terminal se connectera à ce serveur et échangera des données avec lui. Le noyau du serveur possède l'ensemble de fonctions WinAPI suivant :
Une fois qu'un pipe nommé est ouvert, il renvoie un handle de fichier qui peut être utilisé pour des opérations de lecture/écriture de fichiers. Vous obtenez ainsi un mécanisme très simple qui ne nécessite aucune connaissance particulière en matière d'exploitation de réseau.
Les Named pipes ont une particularité : ils peuvent être à la fois locaux et en réseau. En d'autres termes, il est facile de mettre en œuvre un serveur distant qui acceptera les connexions réseau des terminaux clients.
Auteur : MetaQuotes