Äußerst zuverlässiger Transaktions-/Signalkopierer (Ideologiediskussion und Entwicklung)

 
In diesem Zusammenhang interessiere ich mich für die Möglichkeiten der Synchronisierung (Übermittlung von Aufträgen) von Terminals
- lokal
- aus der Ferne

Wir planen, alles auf einmal im Modus " ein Server - viele Clients" durchzuführen.

Wir müssen unter anderem auf folgende Aspekte achten
- die Verbindungsoption (Dateien, Speicher für eine lokale Verbindung; Sockets, http, Zwischenserver usw. für eine entfernte Verbindung)
- keine Belastung des Kommunikationskanals (insbesondere bei Fernsynchronisation)
- Ausfallsicherheit (Wiederherstellung des Kanals im Falle seines Verlusts)
- Neuinitialisierung des Expert Advisors selbst im Falle eines Terminal-/OS-Ausfalls
- Keine Duplizierung/keine Löschung von Geschäften, wenn die Verbindung unterbrochen/wiederhergestellt wird
usw.

Sie müssen auch zwei Ideologien berücksichtigen
- Synchronisierung auf der Ebene der Auftragsverfügbarkeit
- Synchronisierung auf der Ebene des Sendens von Signalen zum Öffnen/Schließen von Aufträgen

die Vor- und Nachteile dieser Variante für jeden unserer Vorschläge beschreiben.

Ich möchte, dass die Diskussion uns hilft, die beste Lösung für die Zuverlässigkeit und Einfachheit des Systems zu finden.

Ich werde die Kodierung und die Tests durchführen.

Die Ergebnisse können nach Absprache in der Codebase veröffentlicht werden.
 

Gut. Zunächst müssen wir die Aufgaben(Art der Experten) in eine kommerzielle (über das Netz) und eine fiktive nichtkommerzielle Variante (innerhalb desselben OP-Systems) unterteilen.

Netzwerkvariante - eindeutig durch zusätzlichen Server, für Sicherheit und Client-Management.

Intra-System-Kommunikation: Mapping, wegen der Geschwindigkeit und Zuverlässigkeit.

Da das Terminal die libc so lange hält, bis sie herunterfällt oder geschlossen wird, ist sie ein Hinweis auf den Zustand des MT (Slave) selbst.

Und das Protokoll wird in etwa so aussehen:

Der Master erstellt ein benanntes mappu (dessen Name allen Slaves bekannt ist) und wartet darauf, dass sie signalisieren, den Pfad zu starten, der das Fensterhandle des Beraters (Slaves) sein wird.

Nachdem die Signale ausgetauscht wurden, wird ein weiteres Fenster erstellt, in dem die Handelssignale weitergegeben werden, und gleichzeitig wird der Befehl zur Aktualisierung des Fensters an jeden Slave gegeben.

Nach der Ausführung des Signals sollte der Slave seine Ausführung melden, sonst wird er als eingefroren betrachtet und es werden Maßnahmen ergriffen, um ihn wieder aufzurichten.

Wenn der Slave (korrekt) entladen hat, sollte er sich zurückmelden.

Jeder der Slaves kann seinerseits den Status des Masters überwachen und die notwendigen Maßnahmen ergreifen, um ihn zu erhöhen oder einen Alarm auszulösen.

Im Allgemeinen etwa gleich viel.

Zur Netzwerkkommunikation siehe weiter unten.

 
Erstellen Sie eine kommerzielle Version und bringen Sie sie auf den Markt.
 
TheXpert:
Erstellen Sie eine kommerzielle Version und bringen Sie sie auf den Markt.

Sprechen Sie mit mir?
 
FAQ:
Sprechen Sie mit mir?
Wenn Sie der Themenstarter sind, ja :)
 
FAQ:

Sobald das Signal ausgeführt wurde, muss der Slave die Ausführung melden, andernfalls gilt es als eingefroren und es werden Schritte unternommen, um es wieder aufzuheben.

Wenn er (korrekt) entladen ist, sollte der Slave dies melden.

Diese Zeilen erinnern mich an die Notwendigkeit, zwei Arbeitsweisen zu diskutieren

Auftragssynchronisation auf der Ebene Master->Mandantenauftrag. Und Signalsynchronisation auf Master->Client-Ebene (brauchen wir eine Signaldatenbank, Empfangsbestätigung vom Client, etc.)

Ich denke, wir sollten auch entscheiden, was zuverlässiger und weniger kompliziert in Bezug auf die Synchronisation und den Verlust von Signalen wäre oder man sollte beide Projekte gleichzeitig implementieren.

 
TheXpert:
Erstellen Sie eine kommerzielle Version und bringen Sie sie auf den Markt.

Ich will nichts erzwingen und werde es auch nicht tun. Ich mache ein Mittel, nicht einen Zweck. Ich tue es für alle.
 
sergeev:

diese Zeilen erinnerten mich an die Notwendigkeit, zwei Arbeitsweisen zu diskutieren

Auftragssynchronisation auf Ebene Master->Mandantenauftrag. Und Signal-Synchronisation auf der Ebene Master-Signal->Client-Signal (gibt es eine Notwendigkeit in einer Signal-Datenbank, die Bestätigung des Empfangs vom Client, etc.)

Ich denke, wir sollten auch entscheiden, was in Bezug auf Synchronisierung und Signalverlust zuverlässiger und weniger kompliziert wäre.


Sie brauchen die Dinge nicht zu verkomplizieren, es reicht aus, in einem bestimmten Intervall (sagen wir, einmal pro Sekunde) ein Kontrollsignal an den Client zu senden, und wenn er nicht reagiert hat, dann zu handeln.
 
sergeev:

Ich will nichts erzwingen und werde es auch nicht tun. Ich mache die Mittel, nicht den Zweck. Ich tue es für alle.

Ich respektiere solche Leute, macht weiter so!!!
 
Es ist nicht nötig, die Sache kompliziert zu machen, es reicht aus, in einem bestimmten Intervall (z. B. einmal pro Sekunde) ein Kontrollsignal an den Client zu senden, und wenn der Client nicht antwortet, zu handeln. <br / translate="no">
Ist das alles, was Sie über ein Server-zu-Client-Signal sagen? Sie brauchen einen detaillierten Mechanismus, wie das Signal lebt und an den Empfänger übertragen wird. Ein solches System ist mir noch nie begegnet. Nur Kopien bestellen.
 
Es hat alles geklappt, aber leider nicht umsonst.