Diskussion zum Artikel "Communicating With MetaTrader 5 Using Named Pipes Without Using DLLs"

Neuer Kommentar
 

Neuer Artikel Communicating With MetaTrader 5 Using Named Pipes Without Using DLLs :

Many developers face the same problem - how to get to the trading terminal sandbox without using unsafe DLLs. One of the easiest and safest method is to use standard Named Pipes that work as normal file operations. They allow you to organize interprocessor client-server communication between programs. Take a look at practical examples in C++ and MQL5 that include server, client, data exchange between them and performance benchmark.

Ein Datenaustausch wird mittels den folgenden 4 simplen Funktionen organisiert:

  • CPipeManager::Send(void *data,size_t data_size)
  • CPipeManager::Read(void *data,size_t data_size)
  • CPipeManager::SendString(LPCSTR command)
  • CPipeManager::ReadString(LPSTR answer,size_t answer_maxlen)

Diese Funktionen ermöglichen das Senden und Empfangen von Daten als Binärdaten oder ANSI-Textfolgen, die mit MQL5 kompatibel sind. Darüber hinaus, da CFilePipe via MQL5 automatisch eine Datei im ANSI-Modus öffnet, werden die Zeichenketten während des Sendens und Empfangens automatisch in Unicode konvertiert. Falls Ihr MQL5-Programm eine Datei im Unicode-Modus (FILE_UNICODE) öffnet, dann kann es Unicode--Zeichenketten austauschen (mit BOM als Startsignatur).


Autor: MetaQuotes Software Corp.

 
Funktionieren die Pips im Testgerät?
 
Graff:
Funktionieren Leitungen im Prüfgerät?

Warum sollte die Kommunikation zwischen verschiedenen Terminals im Tester funktionieren?

Tun Sie es über Ereignisse, sie funktionieren im Tester.

 
Urain:

Warum sollte die Kommunikation zwischen verschiedenen Terminals im Tester funktionieren?

Warum nicht? Sie sollten es ausprobieren. Aber ich weiß nicht warum... :)


machen Sie es über Ereignisse, sie funktionieren im Tester.

Was über Ereignisse? Kommunikation zwischen Terminals?

;)

 

Benannte Pipelines funktionieren in lokalen Agenten, sind aber in Clades deaktiviert.

Das heißt, dass sowohl einzelne Tests als auch lokale Massenagenten eine Verbindung zu einem Pip-Server eines Drittanbieters (nicht nur lokal) herstellen können.

 
MetaDriver:
Warum nicht? Es ist einen Versuch wert. Ich weiß nicht warum. :)


was durch Ereignisse? Kommunikation zwischen Terminals?

;)

Um zum Kern der Frage vorzudringen, wenn eine Person Kommunikation zwischen Programmen im Tester braucht, dann ist die Aufgabe des Datentransfers zwischen Programmen in einem Terminal sichtbar, und es kann durch Ereignisse gemacht werden, wenn man all diesen Unsinn weglässt, ist meine Antwort ziemlich logisch.
 
Urain:
Wenn eine Person die Kommunikation zwischen Programmen im Tester benötigt, dann ist die Aufgabe der Datenübertragung zwischen Programmen in einem Terminal offensichtlich, und dies kann durch Ereignisse erfolgen, wenn man all diesen Unsinn weglässt, ist meine Antwort ziemlich logisch.
Ich habe mich darauf eingelassen, es schien mir, dass er nur daran interessiert ist, den Testprozess von einem externen Programm aus zu überwachen.
 

Auf den ersten Blick gibt es zwei Möglichkeiten, sie zu nutzen:

Und Artikel zu diesem Thema werden interessant sein.

 
Rosh:

Auf den ersten Blick gibt es zwei Möglichkeiten, sie zu nutzen:

Und Artikel zu diesem Thema werden interessant sein.

Leider ist dies nur für diejenigen möglich, die wissen, wie man in C für Windows programmiert, denn:

Renat:
Bitte beachten Sie, dass es sich hierbei um eine Client-Unterstützung handelt, und Server-Konnektoren nicht im Terminal erstellt werden können.

D.h. bei Client-Server-Technologien können sich zwei Clients ohne Server-Vermittlung nicht gegenseitig sehen. Ich habe mich mit dem Thema der Erstellung von benannten Kanälen in anderen Programmiersprachen beschäftigt, aber leider kann man in den meisten von ihnen einen Client für Windows mit Standardmitteln erstellen, obwohl Kanäle für Unix fast überall problemlos erstellt werden.

Wir brauchen Gateways in Form von EXE-Shells, die zwei Named Channels nach dem Algorithmus voll-duplex verbinden können:

  1. Erstellen Sie zwei benannte Kanäle A und B
  2. Erstellen Sie den ersten Unterprozess, der auf Kanal A auf eine Verbindung wartet.
  3. Nachdem ein Client, der auf eine Nachricht wartet, eine Verbindung zu Kanal A hergestellt hat, erstellen Sie einen zweiten Unterprozess, der auf Kanal B auf eine Verbindung wartet.
  4. Der erste Subprozess wird eingeschaltet, um einen Bytestrom in einer Schleife von Kanal A nach Kanal B zu übertragen.
  5. Sobald sich ein Client mit Kanal B verbindet, wird der zweite Subprozess gestartet, um den Bytestrom in einer Schleife von Kanal B nach Kanal A zu lesen.
  6. Der zweite Client beginnt mit der Übertragung der ersten Nachricht von Kanal B nach Kanal A.
  7. und so weiter und so fort, bis ein Client abfällt, woraufhin beide Kanäle zerstört werden und wir zu Punkt 1 übergehen. 1

In Single-Task-MQL-Skripten ist Vollduplex natürlich nicht erforderlich, da die Clients keine Informationen asynchron empfangen und senden können. Halbduplex eignet sich jedoch nur für die Fälle, in denen der Server das Austauschprotokoll kennt und leicht berechnen kann, wo der Empfangs- und Sendevorgang von einem Client zum anderen endet, um in den entgegengesetzten Modus zu wechseln. Wenn er dies nicht weiß, weil er nicht über telepathische Fähigkeiten verfügt, und dies nur den Clients bekannt ist, die sich untereinander mit dem nur ihnen bekannten Protokoll austauschen, dann ist ein Vollduplex mit zwei Teilprozessen erforderlich. Ein solches Gateway ist praktisch, weil jeder Klient nur einen Kanal für die Kommunikation mit einem anderen Klienten hat und die Reihenfolge der Verbindung von Seiten des Klienten keine Rolle spielt, wenn er die Möglichkeit der Verbindung im ersten Zyklus sicher überprüft. Der Gateway-Algorithmus schließt die Verbindungsmöglichkeit des Klienten aus, der laut Protokoll als erster eine Nachricht senden muss, bevor sich der zweite Klient verbindet, und die Übertragung ins Leere wird nicht stattfinden.

Da die Anzahl der benannten Kanäle theoretisch unbegrenzt ist, wäre es möglich, ein Single-Task-Simplex-Gateway nach dem Algorithmus zu erstellen:

  1. Ein erster benannter Kanal wird für die Übertragung vom Gateway zum Client erstellt.
  2. Nachdem der erste Client eine Verbindung hergestellt hat, wird ein zweiter Kanal erstellt, um Nachrichten vom Client zu empfangen
  3. Nachdem der sendende Client eine Verbindung zum zweiten Kanal hergestellt hat, wird der Bytestrom vom empfangenden Kanal zum sendenden Kanal in einer Schleife übertragen.
  4. Sobald ein Client die Verbindung abbricht, entfernen wir beide Kanäle und fahren mit Schritt 1 fort.

In diesem Fall werden zwei solcher Gateways benötigt, um zwei Clients im Halbduplexbetrieb zu verbinden, oder eines, wenn nur Simplex verwendet wird. Der Nachteil gegenüber einem Vollduplex-Gateway besteht darin, dass Sie in MQL-Skripten zwei Kanäle (für Empfang und Übertragung) schreiben und darin auch die Reihenfolge der Verbindung strikt einhalten müssen: erst für den Empfang und dann für die Übertragung (sonst wird der zweite Kanal nie erstellt). Der Algorithmus dieses Gateways schließt auch die Möglichkeit aus, einen Client zu verbinden, der laut Protokoll als erster eine Nachricht senden muss, bevor sich der zweite Client verbindet und die Übertragung ins Leere läuft.

Natürlich sollten die Gateways die Möglichkeit bieten, Kanalnamen in Abhängigkeit von der Reihenfolge der empfangenden, sendenden und sich verbindenden Clients zu konfigurieren, zum Beispiel über die Befehlszeile beim Start.

Wenn jemand, der in C programmiert, solche Gateways erstellt und in EXEs kompiliert und hier veröffentlicht, wäre es ein Leichtes, Verbindungen zwischen Skripten, Expert Advisors und Indikatoren mit Standard-MQL5-Tools zu erstellen, ohne in anderen Programmiersprachen herumtrommeln zu müssen.

Theoretisch können Sie auch einen Artikel darüber schreiben, wie man Clients richtig mit solchen Gateways verbindet, um keine Server in anderen Sprachen als MQL zu erstellen (ich bin wahrscheinlich nicht der Einzige, der nicht in C programmieren kann, oder?) mit konkreten Beispielen in Co-Autorenschaft mit einem C-Programmierer. Das heißt, von mir den Text des Artikels und Beispiele in MQL, und von der C-sh Programmierer Quellen von Gateways in C und EXE-shniki. Die Gebühr wird geteilt.

 
Die Beispiele zeigen übrigens einen Vollduplex-Austausch, bei dem man auf niemanden warten muss.

Der Server ist einfach, alles in den Quellen, einschließlich der kompilierten exe-Datei im /release-Verzeichnis. Die Tests können leicht wiederholt werden.
 
Renat:
Die Beispiele zeigen übrigens einen Vollduplex-Austausch, bei dem man auf niemanden warten muss.

Der Server ist einfach, alles in den Quellen, einschließlich der kompilierten exe-Datei im /release-Verzeichnis. Die Tests können leicht wiederholt werden.

Das ist nicht der Punkt. Ich habe versucht, Ihr Beispiel auszuführen. Es funktioniert. Aber es hat keinen Nutzen, d.h. ich habe es ausprobiert und das war's, es kann gelöscht werden, weil es nicht mehr gebraucht wird.

Einerseits ist man die dll los, aber andererseits braucht man für die Anwendung wieder Krücken in anderen Programmiersprachen.

Der Nachteil der vorgeschlagenen Methode ist, dass sie nur für Programmierer geeignet ist, die Anwendungen in anderen Sprachen als MQL entwickeln und die Windows-API unterstützen. Das heißt, das vorgeschlagene Beispiel ist nicht allgemeingültig und kann nicht ohne Änderungen an andere Aufgaben angepasst werden. Und jeder hat andere Aufgaben. Und das bedeutet, dass die Benutzer müssen auch eine elementare Austausch von Informationen zwischen zwei Skripten zu studieren, zusätzlich zu MQL eine andere Sprache, so dass auf sie, erstellen Sie einen Server, in dem Sie brauchen, um einige der Logik im Zusammenhang mit dem Austausch-Protokoll zu schreiben.

Ich schlage vor, Gateways einmal zu erstellen, zu kompilieren und für alle Ankömmlinge, so dass jeder Benutzer können Verbindungen erstellen, nur mit Standard-MQL-Tools.

Für mich macht es zum Beispiel keinen Unterschied, ob offene oder geschlossene Rohdateien in C sind. Denn ich schreibe nichts in C, und es wird einige Zeit dauern, Flüge zu sortieren. Ich kann die gleichen Rohdateien nicht einmal kompilieren. Und in Pure Java, wie auch in vielen anderen Programmiersprachen, kann man mit Standardwerkzeugen nur Client-Verbindungen über Dateistreams herstellen. Wenn es ein Gateway gäbe, das zwei benannte Kanäle zumindest per Simplex verbindet, gäbe es keine Probleme. Ich würde das Austauschprotokoll in die Clients schreiben, eine Verbindung durch ein paar Gateways herstellen, debuggen und alles funktioniert. D.h. es besteht keine Notwendigkeit, für jede Aufgabe einen eigenen Server zu entwerfen und zu erstellen.

Und im Moment, d.h. ohne Gateways, müssen viele Leute eine Entwicklungsumgebung für C installieren, eine neue Programmiersprache lernen, usw. usw.

Dem Gateway ist das völlig egal: Was es von einem Client erhält, sendet es an einen anderen. Die Logik ist dumm, aber sie erlaubt es, zwei Clients ohne zusätzliche Krücken zu vereinen und tanzt mit dem Tamburin, d.h. sie ist universell und unabhängig vom Protokoll des Informationsaustauschs und der Kenntnis der Sprache C.

Hier versteht, wie man so schön sagt, der Fresser den Hungrigen nicht. Diejenigen, die etwas in C entwickeln, werden wahrscheinlich keine Probleme sehen. Und der Rest von uns kann mit diesem System umgehen, wie er will.

1234567
Neuer Kommentar