Wer hat schon das Signals-Abo ausprobiert, um den ATC 2012-Teilnehmern auf den Fersen zu sein? - Seite 5
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Denken Sie auch an die Milchmädchen.
Rent a Signal ist entleert...
Haben Sie eine Ahnung, warum?
Darüber hinaus gibt es noch einige andere Fragen zu klären:
Wir haben das System absichtlich auf ein einziges Signal vereinfacht, um die schlimmsten Folgen zu vermeiden. Insbesondere unter Berücksichtigung der Tatsache, dass die meisten Transaktionen höchstwahrscheinlich über den Trusted Execution Token-Mechanismus von Cloud-Servern abgewickelt werden, was die Verzögerung beim Kopieren von Signalen auf einige Millisekunden reduzieren wird.
Moment mal, haben Sie nicht die Architektur entwickelt? Jetzt sind Sie derjenige, der über die Verwechslung von Positionen und Kreuzungen durch Symbole schreibt.
Es gibt einen handelsunabhängigen Mechanismus für die Replikation von Geschäften, es gibt keinen Verbindungsverlust, kein Synchronisationsproblem nach einer erneuten Verbindung (stellen Sie sich 15 Minuten oder 2 Stunden ohne Verbindung vor) und es kann zu 100 % kontrolliert werden. Außerdem gibt es den MetaTrader 4 ohne Netting.
Wir haben das System absichtlich auf ein einziges Signal vereinfacht, um die schlimmsten Folgen zu vermeiden. Zumal die meisten Transaktionen wahrscheinlich über den Trusted Execution Token-Mechanismus der Cloud-Server abgewickelt werden, wodurch die Latenzzeit für die Signalkopie auf wenige Millisekunden reduziert wird.
Bislang haben Sie keine Lösungen für die Probleme vorgelegt, sondern lediglich erklärt, dass "Sie wenig zu tun haben und die Aufgabe im Allgemeinen ein Kinderspiel ist".
Bedenken Sie, dass wir uns schon viel länger den Kopf über das Problem zerbrechen. Und wir sind nicht beim ersten Schritt stehen geblieben: "Ja, theoretisch ist das möglich".
Die Essenz all Ihrer Kommentare war eigentlich ein "Gib und basta, es ist theoretisch möglich, also leugne nicht, und ich bin zu faul, über den ersten Schritt der Ausarbeitung hinauszugehen".
Bezeichnenderweise wurden alle konstruktiven Äußerungen in meinem vorherigen Beitrag ignoriert.)
Leider gab es von Ihrer Seite aus keinerlei konstruktiven Beitrag. Es gab nur "Geben und Nehmen" und einseitige Aussagen.
Das heißt, Sie haben nicht beschrieben, wie der Konflikt zwischen mehreren Signalen zu lösen ist, und Sie haben keine Antwort auf die Frage gegeben, wie man einen Verbindungsverlust beheben kann.
Außerdem gehen Sie überhaupt nicht auf die Verantwortung für drohende Konflikte ein, die mit einer Wahrscheinlichkeit von 100 % auftreten. Ich habe nicht umsonst darauf hingewiesen, dass die Lösung "Ich kann das für mich machen, ich bringe das in Ordnung" für den Massendienst nicht möglich ist.
Was das Thema anbelangt, so kann ich aus eigener Erfahrung sagen, dass das Problem sehr komplex ist und nicht durch einfache Replikation gelöst werden kann. Konventionell kann sie in drei Komponenten unterteilt werden:
All dies ist in der Praxis nur sehr schwer zu bewerkstelligen und würde zudem eine erhebliche Änderung der bestehenden Architektur erfordern.
Moment mal, haben Sie nicht die Architektur entworfen? Jetzt schreiben Sie selbst, dass sich Position und Charakter überschneiden.
Ich stelle fest, dass sich nur wenige Menschen wirklich Gedanken über die Umsetzung der Verarbeitung gemacht haben.
Allerdings kann man den Gedankengang aus der Aussage "Gib mir eine Lösung, der Händler braucht sie, speichere die Zustände auf dem Server" verstehen. Es ist verständlich, dass man die meisten Probleme auf andere überträgt, sich nicht darum kümmert und - wenn etwas schief geht - sie für die schlechte Umsetzung kritisiert.
Aber wenn man das Problem von der Seite des Brokers, des Systemanbieters, der Netzwerkinfrastruktur und erst dann des Händlers betrachtet, wird man feststellen, dass die vorgeschlagene Lösung der Signalmischung keine vernünftige und sichere Lösung darstellt.
Leider gibt es überhaupt keine konstruktive Haltung. Es gab nur "Geben und Nehmen" und einseitige Aussagen.
Mit anderen Worten: Sie haben nicht beschrieben, wie Konflikte bei mehreren Signalen gelöst werden können, und Sie haben auch nicht die Frage beantwortet, wie ein Kommunikationsverlust behoben werden kann.
Außerdem gehen Sie überhaupt nicht auf die Verantwortung für drohende Konflikte ein, die mit einer Wahrscheinlichkeit von 100 % auftreten. Ich habe nicht umsonst darauf hingewiesen, dass die Lösung "Ich kann das für mich machen, ich bringe das in Ordnung" für den Massendienst nicht möglich ist.
Und was können unabhängige Entwickler Ihrer Meinung nach tun? MT5 ist streng monolithisch. Das Beste, was sie tun können, ist, eine andere Krücke zu erfinden und sie in dem entsprechenden Artikel zu beschreiben. Man kann kein Qualitätssystem schreiben, ohne es in ein Produkt zu integrieren. Da ich das Problem aus erster Hand kenne, kann ich sagen, dass man auf die Speicherung von Zustandsdaten auf der Serverseite nicht verzichten kann. Und wie sollten Drittentwickler dieses Problem Ihrer Meinung nach lösen? Letztendlich tun sie das Beste, was sie können. Sie schaffen Krücken und Kombinationen von MQL5 <-> DLL <--> SQL, die schwer zu warten und für den Massenmarkt, den Sie so sehr loben, nicht geeignet sind.
Sie irren sich.
MQL5 ist so offen und funktional, dass Sie fast alles machen können. Es besteht keine Notwendigkeit, Krücken mit DLL und SQL zu machen, es genügt, Datei-Operationen zu verwenden und alles, was Sie brauchen, auf der Festplatte zu speichern. Die Datenbank der globalen Variablen ist sehr stabil und geht bei Neustarts oder Abstürzen nicht verloren.
Und die Zustandsspeicherung auf dem Server besteht aus Mediendateien und Kommentaren. Lernen Sie, sie sparsam einzusetzen.