Äußerst zuverlässiger Transaktions-/Signalkopierer (Ideologiediskussion und Entwicklung) - Seite 6
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
ein einfaches Austauschschema: Der Signalgeber legt auf dem Server eine Datei mit allen seinen offenen Aufträgen und Positionen ab, wie im Terminal. Wenn sich mindestens ein Auftrag oder eine Position geändert hat, wird eine neue Datei angelegt. In diesem Fall sendet der Server eine neue Version der Datei (oder eine Nachricht mit dem vollständigen Inhalt der Datei), und der Client antwortet, dass er sie erhalten hat (der Server sollte die Liste der verbundenen Clients enthalten). Der Server kann die Datei auch jederzeit an den Client senden.
Wenn der Client aufgehalten wird oder einen Auftrag verpasst, kann er sich leicht wiederherstellen, indem er die Terminaldatei des Servers liest. Bei einem befehlsweisen Austausch kann es zu zahlreichen Abstürzen und Unklarheiten kommen. Der Client kann zur Diagnose z.B. einmal pro Xmin neu synchronisieren, wenn es keine Änderung gab.
Das Verkehrsaufkommen ist bei dieser Regelung nicht hoch. Sie können also auch SSL oder https verwenden.
Es gibt 3 Arten von Nachrichten: Geben, Empfangen, Datei selbst.
ein einfaches Austauschschema: Der Signalgeber legt auf dem Server eine Datei mit allen seinen offenen Aufträgen und Positionen ab, wie im Terminal. Wenn sich mindestens ein Auftrag oder eine Position geändert hat, wird eine neue Datei angelegt. In diesem Fall sendet der Server eine neue Version der Datei (oder eine Nachricht mit dem vollständigen Inhalt dieser Datei). Sie sendet diese Datei auch jederzeit auf Anfrage des Kunden.
Wenn der Client aufgehalten wird oder einen Auftrag verpasst, kann er sich leicht wiederherstellen, indem er die Terminaldatei des Servers liest. Bei einem befehlsweisen Austausch kann es zu zahlreichen Abstürzen und Unklarheiten kommen. Der Client kann zur Diagnose z.B. einmal pro Xmin neu synchronisieren, wenn sich keine Änderung ergeben hat.
Das Verkehrsaufkommen ist bei dieser Regelung nicht hoch. Daher können Sie auch SSL oder https verwenden.
Das Schema ist unbrauchbar, weil die Datei mit den Handelssignalen sehr schnell an Relevanz verliert, da die Trades rechtzeitig ausgeführt werden müssen. Die schnellste Möglichkeit ist, dass der Client eine ständige Verbindung zum Server-Socket hält und auf Handelssignale wartet. Bei einer permanenten Verbindung wird im Gegensatz zu systematischen Anfragen kein Datenverkehr verschwendet, und die Zuverlässigkeit ist recht hoch.
Wie ich bereits sagte, sind auch keine Befehle erforderlich. Sobald ein Handelssignal erscheint, sendet der Server es als eine einzige Zeile mit dem Beendigungssymbol "\n" an die Clients und wartet auf das nächste. Der Client muss nichts an den Server senden, er empfängt nur Signale.
SSL und https sind überhaupt nicht erforderlich. Zunächst muss der Eigentümer des Servers eine Domäne registrieren und ein Zertifikat kaufen, und dann muss er all diese Dinge verlängern, um mit diesen Protokollen arbeiten zu können, und zwar nicht kostenlos. Und zweitens sind diese Protokolle für die Datenverschlüsselung, um Informationen in einem TCP-Stream abzufangen nicht entschlüsseln konnte. Die Belastung des Servers wird enorm sein, wenn er viele Kunden hat, denn die Verschlüsselung ist nicht halam balam, sondern der Vorgang, große ganze Zahlen auf höhere Potenzen modulo zu erhöhen.
Das System ist nutzlos, weil die Handelssignaldatei schnell an Bedeutung verliert, da die Geschäfte rechtzeitig ausgeführt werden müssen. Die schnellste Möglichkeit ist, dass der Client eine ständige Verbindung zum Server-Socket hält und auf die Handelssignale wartet. Bei einer permanenten Verbindung wird im Gegensatz zu systematischen Anfragen kein Datenverkehr verschwendet, und die Zuverlässigkeit ist recht hoch.
Wie ich bereits sagte, braucht der Client auch keine Befehle. Wenn ein Handelssignal erscheint, sendet der Server es in einer einzigen Zeile an den Client und wartet auf das nächste Signal. Der Client muss nichts an den Server senden, sondern nur Signale empfangen.
Es gibt keine Verzögerung, da es sofort nach Erscheinen des Signals an alle Kunden gesendet wird.
Die Befehl-zu-Befehl-Verbindung spart zwar Datenverkehr, aber die Zuverlässigkeit ist gering. Der Kunde sollte in der Lage sein, alle Aufträge (z. B. anhängige Aufträge oder Auftragsänderungen) zu erhalten, auch wenn er sie aus irgendeinem Grund verpasst hat.
Es gibt keine Verzögerung, da die Nachricht sofort nach Erscheinen des Signals an alle Clients gesendet wird.
Die Aufteilung nach Teams spart natürlich Verkehr, aber die Zuverlässigkeit ist gering. Der Kunde sollte in der Lage sein, alle Aufträge (z. B. ausstehende Aufträge oder Auftragsänderungen) abzurufen, auch solche, die aus irgendeinem Grund nicht berücksichtigt wurden.
Ok, mach einen Buckligen. Nur wer so einen Blödsinn macht - das ist nicht mein Problem.
Meine Aufgabe ist es, die beste Option mit der geringsten Belastung und dem geringsten Verkehrsaufkommen anzubieten, Sie haben das Recht, dies abzulehnen.
SSL und https sind überhaupt nicht erforderlich. Um mit solchen Protokollen arbeiten zu können, muss der Eigentümer des Servers zunächst eine Domäne registrieren und ein Zertifikat kaufen, das er dann ständig erneuern muss, was ebenfalls nicht kostenlos ist. Und zweitens konnten diese Protokolle zur Datenverschlüsselung, um Informationen in einem TCP-Stream abzufangen, diesen nicht entschlüsseln. Die Belastung des Servers wird enorm sein, wenn er viele Kunden hat, denn die Verschlüsselung ist nicht halam balam, sondern der Vorgang, große ganze Zahlen auf höhere Potenzen modulo zu erhöhen.
Aber alle bestehenden unauthentifizierten Server-Signale sind in wenigen Stunden geknackt. Auch wenn eine Verschlüsselung möglicherweise unnötig ist))
Aber alle bestehenden Server-Signale ohne Authentifizierung sind in wenigen Stunden geknackt. Eine Verschlüsselung kann jedoch unnötig sein).
1. Nicht Stunden, sondern Millisekunden
2) Wer zum Teufel braucht Ihre Signale, um von jemand anderem geöffnet zu werden? Eine Anekdote über Elusive Joe.
Na gut, machen Sie einen Buckel daraus. Aber wer so einen Unsinn macht, ist nicht mehr mein Problem.
Meine Aufgabe ist es, die beste Option mit einem Minimum an Belastung und Verkehr anzubieten, Sie haben das Recht, diese abzulehnen.
1. Nicht Stunden, sondern Millisekunden.
2) Wer zum Teufel muss seine Signale verdecken? Eine Anekdote über Elusive Joe.
Mir ist das scheißegal, aber Leute, die Signale für Geld verkaufen, regen sich auf)) Aber wenn es für dieses Projekt nicht wichtig ist - kein Problem, kein Bedarf an Schutz
Wenn der Client die Verbindung verloren hat oder neu gestartet wurde und in der Zwischenzeit einige ausstehende Aufträge oder Änderungen von Aufträgen durchgelaufen sind, wie kann man das mit Telnet-Befehlsaustausch beheben? Ich weiß es nicht, vielleicht können Sie es - deshalb frage ich ja.
Ich habe Ihnen bereits gesagt, dass Sie den Befehl telnet nicht brauchen, aber Sie reden schon wieder Unsinn.
Sie sollten die Dateien duplizieren und sie mit SendFTP() auf ein billiges Hosting hochladen. Und lassen Sie den Kunden die Dateien per FTP mit dem Zeitpunkt der Erstellung lesen, wenn er nicht erreichbar war.
Ich habe Ihnen bereits gesagt, dass Sie den Befehl telnet nicht brauchen, aber Sie reden schon wieder Unsinn.
Sie sollten die Dateien duplizieren und sie mit SendFTP() auf ein billiges Hosting hochladen. Und lassen Sie den Client die Dateien über FTP mit der Erstellungszeit lesen, für die er nicht mehr erreichbar war.
D.h. es gehört nicht Ihnen))
Reschetow:
Socket über TCP/IP-Protokoll. Sie können Signale in Textform in einer Zeile pro Signal übertragen, wie z.B. "EURUSD Buy 1.0\n", wie über Telnet, weil es die primitivste Version ist, die keine komplexe Austauschprozedur erfordert, wie in http- oder ftp-Protokollen mit minimalem Parsing.
Sie reden schon wieder Unsinn - das eine mit dem anderen duplizieren, wenn es auch mit einem geht)). Warum sich die Mühe machen, Dateien zu speichern, wenn eine genügt - die letzte mit dem aktuellen Stand aller Aufträge und Positionen? Den Austausch auf Verlangen des Servers (wenn sich etwas auf dem Hauptkonto geändert hat) und auf Verlangen des Kunden (wenn er Probleme oder Unstimmigkeiten hatte) zu kombinieren, und nicht mit zusätzlichen Krücken zu kommen. Sie können auf Anfrage des Servers nicht die gesamte Auftragsdatei senden, sondern nur das, was sich geändert hat, und es wird Ihre Version des "Befehlsaustauschs" sein.