Funktion OrderSendAsync() - Seite 8

 
TheXpert:
Denn unterbrochene Pakete, abgebrochene Verbindungen usw. sind Blödsinn. Unzuverlässig. Unzuverlässig - man muss die Verbindung trennen.

Für den Fall der Fälle werden wir die Warteschlange der Handelstransaktionen für die Ausgabe an EAs aufbewahren und sie verschenken.

Verbindungsabbrüche bei der Ausführung sind ein Problem, und es ist noch nicht klar, wie man damit umgehen soll. In jedem Fall können wir nach der erneuten Verbindung alle offenen Positionen überprüfen.

 
TheXpert:
Denn unterbrochene Pakete, abgebrochene Verbindungen usw. sind Blödsinn. Unzuverlässig. Unzuverlässig - man muss sich wieder aufrappeln.

Wir sollten die Fliegen und die Koteletts getrennt halten.

Unterbrochene Pakete sind für das Terminal eine anormale Situation und sollten durch Ausnahmen behandelt werden, auch durch Verlaufsanalyse.

Aber es ist zu teuer, die Geschichte jedes einzelnen Handels zu analysieren. Die Ankunft des Handels ist eine normale Situation, die mit geringen Kosten abgewickelt werden sollte.

 
Urain:
Machen Sie, was Sie wollen, ich will niemanden aufhetzen.
 
TheXpert:
Hallo. Wissen Sie überhaupt, was Asynchronität ist?

Soweit ich verstanden habe, besteht der einzige Zweck der Einführung dieser Funktion für EAs mit mehreren Währungen (für EAs mit einer Währung macht die Initiative keinen Sinn) darin, Zeit zu sparen, indem die Verzögerung der Auftragsausführung auf der Serverseite vermieden wird. Korrigieren Sie mich, wenn ich falsch liege.

Ansonsten bleibt nur noch ein zeitkritischer Teil der Zeit übrig - die Übertragung der Datenpakete über die Kommunikationskanäle. Der Versuch, die "Grenze des Unbekannten" auf die Ebene des "Fallenlassens (des Pakets) und Weiterlaufens" zu verschieben, bringt mehr Probleme als Nutzen. Es ist wichtig, das Problem ganzheitlich zu betrachten. Eine eventuelle Zeitüberschreitung kann nicht nur die Möglichkeit beeinträchtigen, mit einem bestimmten Instrument zu handeln, sondern im Prinzip auch das Fehlen einer Kommunikation mit dem Server.

Außerdem ist nicht klar, wie der Expert Advisor abzuschätzen ist: Ist der Handelsauftrag bei der Datenübertragung verloren gegangen oder wartet er auf dem Server so lange, bis er an der Reihe ist? Und das bedeutet, dass es zu Fehlern bei doppelten Handelsaufträgen kommt, was zu Verstößen gegen das MM und folglich zu höheren Risiken führt. Meiner Meinung nach sollte jeder professionelle Händler (Expert Advisor) sicherstellen, dass sein Handelsauftrag vom Server zur Ausführung akzeptiert wird. Um den Status eines bestimmten Handelsauftrags (in der Funktion OnTrade()) eindeutig zu identifizieren, benötigen Sie außerdem einen eindeutigen Wert, den Sie vom Server erhalten haben, um ihn für die weitere Verarbeitung zu verwenden (bis der Handel ausgeführt wird (Eröffnung/Schließung einer Position).

Es ist dem OSI-Netzwerkmodell ähnlich. Wir müssen uns nicht mit dem Kanal oder der physischen Ebene der Auftragsausführung befassen. Lassen Sie den Kunden (MT5) diese Transportfunktion ausführen. Auf der Anwendungsebene operieren.

 
voix_kas:

Zeitersparnis, da keine serverseitige Verzögerung bei der Auftragsausführung. Korrigieren Sie mich, wenn ich falsch liege.

Der Preis dafür ist, dass man nicht auf die Ergebnisse der Anfrage warten muss. Im Großen und Ganzen, ja. D.h. für Aufträge und Marktausführung kann sie sehr nützlich sein.

Ansonsten bleibt nur noch ein zeitkritischer Abschnitt übrig - die Übertragung des Datenpakets über die Kommunikationskanäle. Der Versuch, die "Grenze des Unbekannten" auf die Ebene des "Fallenlassens (des Pakets) und Weiterlaufens" zu verschieben, bringt mehr Probleme als Nutzen.

Na ja... Nein. Man muss sie nur einsetzen, wenn die Vorteile die Probleme überwiegen.

Meiner Meinung nach muss jeder professionelle Händler (Berater) sicherstellen, dass sein Handelsauftrag vom Server zur Ausführung akzeptiert wird.

Dann ist die asynchrone Option für Sie nicht geeignet. Alles ist lösbar.

 

TheXpert

Gehen wir es noch einmal durch, mit den Fingern. Grobe Strukturierung der Verzögerungen:

1. Zeit für das Terminal, den Handelsauftrag vorzuprüfen, ihn in den ausgehenden Stapel zu "packen" und in die "Netzwerkwarteschlange" zu stellen.

2. Zeitpunkt der Übertragung eines Datenpakets, das einen Handelsauftrag enthält, vom Client zum Server.

3. Zeitpunkt des Empfangs eines Handelsauftrags durch den Server, der diesen in den Verarbeitungspool einstellt und dem Kunden eine eindeutige Kennung für dieses Ticket übermittelt.

4. Die Zeit der Vorverarbeitung der Korrektheit des Handelsauftrags und seine Platzierung auf dem Börsenparkett.

Wenn ich etwas falsch angegeben habe, bitte ich um Korrektur. Ich verstehe, dass Sie nach dem ersten Punkt nicht mehr warten wollen? Ich hingegen plädiere für die obligatorische Verfügbarkeit der ersten drei.

Für die weitere Diskussion müssen zwei Fragen beantwortet werden:

1. Das proportionale Verhältnis der Verzögerungen. Das ist der durchschnittliche prozentuale Zeitaufwand für jeden der vier oben genannten Punkte. Wenn die Verteilung z.B. "0,5%-1,0%-1,0%-97,5%" ist, dann lohnt es sich nicht.

2) Time-out und seine Auswirkungen auf die Handelsstrategie. Ehrlich gesagt kann ich keinen einzigen TS nennen, bei dem nicht klar sein muss, ob ein Auftrag an den Server gesendet wurde oder nicht. Dies gilt sowohl für langfristige Arbitrage als auch für Arbitrage in mehreren Währungen. Das heißt, die Garantie der Ausführung eines Handelsauftrags kann nicht in Frage gestellt werden. Bitte nennen Sie ein Gegenbeispiel, wenn Sie anderer Meinung sind.

 
papaklass:
Meiner Meinung nach lässt sich das Ausführungsproblem bei einer Unterbrechung am einfachsten dadurch lösen, dass keine Ausführungswarteschlange erstellt wird (die Ausführung wird abgebrochen) und der Benutzer beim erneuten Verbinden über den Abbruch informiert wird. Auf diese Weise wird es weniger Unklarheiten geben.

Ein Server-Ticket muss zurückgegeben werden. So wird sichergestellt, dass die Bestellung den Server erreicht und zur Bearbeitung angenommen wird.

Der Aufbau raffinierter Wartepools auf der Client-Seite ist nicht nur eine unpraktische Lösung, sondern ein grober Konstruktionsfehler in der Client-Server-Architektur von MT5.

 
voix_kas:

Umständliche Wartepools auf der Client-Seite sind keine elegante Lösung.

Darum wurde gebeten. Niemand zwingt Sie, es zu benutzen, wenn Sie es nicht müssen.

voix_kas:

TheXpert

Machen wir es noch einmal, auf den Fingern. Grobe Strukturierung der Verzögerungen:

1. Zeit für das Terminal, den Handelsauftrag vorzuprüfen, ihn in ein versandfähiges Paket zu "verpacken" und in eine "Netzwerkwarteschlange" zu stellen.

2. Zeitpunkt des Versands eines Datenpakets, das einen Handelsauftrag enthält, vom Client zum Server.

Zeitpunkt des Empfangs eines Handelsauftrags durch den Server, der diesen in den Verarbeitungspool einstellt und dem Kunden eine eindeutige Kennung für dieses Ticket übermittelt.

4. Zeit für die Vorabprüfung der Korrektheit des Handelsauftrags und dessen Platzierung im Handelssaal.

3 ist besser zu trennen

3.1 Platzierung

3.2 uid senden.

Wenn ich etwas falsch angegeben habe, korrigieren Sie mich bitte. Ich verstehe, dass Sie nicht nach dem ersten Artikel warten wollen?

Ja.

Ich hingegen bin dafür, die ersten drei Punkte verbindlich vorzuschreiben.

Und wenn der Ping eine halbe Sekunde beträgt? Es ist asynchron. Welchen Sinn hat es, diesen Modus überhaupt zu verwenden?

 
TheXpert:
Das ist die Frage, die gestellt wurde. Niemand zwingt Sie, es zu benutzen, wenn Sie es nicht müssen.

Sie haben meine Frage immer noch nicht beantwortet. Nennen Sie mir bitte ein konkretes Beispiel, in welchen Fällen Sie die Garantie für die Ausführung von Handelsaufträgen zugunsten der Schnelligkeit der Übermittlung an verschiedene Stellen außer Acht lassen können.

Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Типы торговых операций
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Типы торговых операций
  • www.mql5.com
Стандартные константы, перечисления и структуры / Торговые константы / Типы торговых операций - Документация по MQL5
 
voix_kas:

Sie haben meine Frage immer noch nicht beantwortet. Nennen Sie mir bitte ein konkretes Beispiel dafür, wann Sie Garantien für die Ausführung von Handelsaufträgen zugunsten der Schnelligkeit, mit der sie an verschiedene Symbole gesendet werden, außer Acht lassen können.

Kein Problem - Portfoliohandel + Marktausführung.