Fehler, Irrtümer, Fragen - Seite 2377
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
Ja. Jeder Druck von OnInit
Ich danke Ihnen. Interessant, wenn ich es nicht bemerken würde, wie wäre es dann möglich, es herauszufinden...
ZS Ich würde es nur für örtliche Agenten lassen. In der Cloud können Sie das Protokoll auf diese Weise leicht spammen.
Ich danke Ihnen. Interessant, wenn ich es nicht bemerken würde, wie wäre es dann möglich, es herauszufinden...
ZS Ich würde es nur für örtliche Agenten lassen. In der Cloud können Sie das Protokoll auf diese Weise leicht spammen.
Wenn Sie Genetik betreiben, optimieren Sie dann nach Ihren eigenen Kriterien?
Aus den Protokollen geht hervor, dass OnTester in allen Fällen 0 zurückgegeben hat.
Normalerweise optimiere ich nach meinen Kriterien, aber hier habe ich auch das benutzerdefinierte Kriterium ausprobiert. Das Ergebnis ist das gleiche.
OnTester gibt 0 zurück, deshalb werden in den Ergebnissen Nullen angezeigt - das ist verständlich. Die Frage ist, warum bei einem allgemeinen Durchlauf (Optimierung) "0" zurückgegeben wird, aber bei einem einzelnen Durchlauf von "Nullergebnissen" (mit denselben Parametern) ein normales Ergebnis, ein Diagramm usw. zurückgegeben wird? D.h. irgendetwas funktioniert nicht bei "Full overshoot" und trotzdem funktioniert die Genetik einwandfrei. Irgendwelche anderen Gedanken/Ideen?
Irgendwelche anderen Gedanken/Ideen?
Ziehen Sie alle Informationen des Optimierungspasses auf diese Weise
Forum für Handel, automatisierte Handelssysteme und Strategietests
MT5. STRATEGIE-TESTER. Divergenz von Test- und Optimierungsergebnissen.
fxsaber, 2017.08.22 11:06
Fügen Sie diese Zeilen in den EA ein
Und laufen Optimierung. Führen Sie dann einen nicht übereinstimmenden Einzellauf durch.
Vergleichen Sie dann die beiden gespeicherten Berichte des entsprechenden Laufs aus der Optimierung und des Einzellaufs.
Das Ergebnis des Vergleichs der beiden Berichte wird schnell die Ursachen aufdecken.
Das Ziel ist es, so viel wie möglich zu verbessern, was getan wird, ich bitte die Entwickler, sich nicht durch mögliche Kritik beleidigt zu fühlen.
1. Ich verstehe die Gründe für solch starke Unterschiede in den "Schnittstellen" für Socket-Read-Funktionen nicht gibt es überhaupt keinen solchen Parameter (durch separate Funktion SocketTimeouts eingestellt).
2. Der Name der Funktion SocketIsReadable hat nichts damit zu tun, was sie tatsächlich tut:
SocketIsReadable entspricht der Funktion ioctlsocket() mit FIONREAD-Flag in Ws2_32.dll
3. Wie kann ein Benutzer, der die Socket*-Funktionalität über eine nicht verschlüsselte Verbindung verwendet, eine Antwort von einem Server mit minimaler Zeitverzögerung erhalten, wenn der Server die Verbindung nach der Datenübertragung nicht unterbricht?
Ja, so wird es gemacht:4. socketIsReadable gibt falsche Informationen zurück.
Schalten Sie das Internet aus und führen Sie den obigen Code aus.
Als Ergebnis gibt SocketIsReadable den vernünftigen Wert 1 zurück. Wunder.
Es ist mir gelungen, etwa ein Drittel aller Fragen und Probleme im Zusammenhang mit Socket* zu beschreiben.
Leider brauchte ich sehr viel Zeit, um alles zu prüfen, zu beschreiben und noch einmal zu überprüfen... (so dass es nicht sicher ist, dass es eine Fortsetzung geben wird)
Der allgemeine Eindruck ist, dass entweder alles in großer Eile gemacht wurde, oder die Socket*-Funktionalität an den Nachwuchsentwickler gelangt ist.
In jedem Fall ist die derzeitige Lösung sehr grob und deckt einen recht engen Ansatz der Verwendung von Steckdosen ab.
Normalerweise optimiere ich nach meinen eigenen Kriterien, aber hier habe ich auch die Standardkriterien ausprobiert. Das Ergebnis ist das gleiche.
OnTester gibt 0 zurück, deshalb gibt es Nullen in den Ergebnissen - das ist verständlich. Die Frage ist, warum bei einem allgemeinen Durchlauf (Optimierung) "0" zurückgegeben wird, aber bei einem einzelnen Durchlauf von "Nullergebnissen" (mit denselben Parametern) ein normales Ergebnis, ein Diagramm usw. zurückgegeben wird? D.h. irgendetwas funktioniert nicht bei "Full overshoot" und trotzdem funktioniert die Genetik einwandfrei. Irgendwelche anderen Gedanken/Ideen?
Können Sie einen EA (ex5 in privat) und Optimierungsbedingungen teilen?
Wir möchten das von Ihnen erwähnte Problem reproduzieren.
Nach der Recherche wird der EA unwiderruflich gelöscht
Können Sie den EA (ex5 in einer privaten Nachricht) und die Optimierungsbedingungen mitteilen?
Wir möchten das von Ihnen erwähnte Problem reproduzieren.
Nach der Recherche wird der EA unwiderruflich gelöscht
Können Sie den EA (ex5 in einer privaten Nachricht) und die Optimierungsbedingungen mitteilen?
Wir möchten das von Ihnen erwähnte Problem reproduzieren.
EA wird nach der Forschung unwiederbringlich gelöscht
In einer privaten Nachricht geantwortet.
Im Rahmen des Kennenlernens der Socket*-Funktionalität ergaben sich eine Reihe von Fragen zur aktuellen Implementierung.
Das Ziel ist es, so viel wie möglich zu verbessern, was getan wird, ich bitte die Entwickler, sich nicht durch mögliche Kritik beleidigt zu fühlen.
1. Ich verstehe die Gründe für solch starke Unterschiede in den "Schnittstellen" für Socket-Read-Funktionen nicht gibt es überhaupt keinen solchen Parameter (durch separate Funktion SocketTimeouts eingestellt).
2. Der Name der Funktion SocketIsReadable hat nichts damit zu tun, was sie tatsächlich tut:
SocketIsReadable entspricht der Funktion ioctlsocket() mit FIONREAD-Flag in Ws2_32.dll
3. Wie kann ein Benutzer, der die Socket*-Funktionalität über eine nicht verschlüsselte Verbindung verwendet, eine Antwort von einem Server mit minimaler Zeitverzögerung erhalten, wenn der Server die Verbindung nach der Datenübertragung nicht unterbricht?
Ja, so wird es gemacht:4. socketIsReadable gibt falsche Informationen zurück.
Schalten Sie das Internet aus und führen Sie den obigen Code aus.
Als Ergebnis gibt SocketIsReadable den vernünftigen Wert 1 zurück. Wunder.
Es ist mir gelungen, etwa ein Drittel aller Fragen und Probleme im Zusammenhang mit Socket* zu beschreiben.
Leider brauchte ich sehr viel Zeit, um alles zu prüfen, zu beschreiben und noch einmal zu überprüfen... (so dass es nicht sicher ist, dass es eine Fortsetzung geben wird)
Der allgemeine Eindruck ist, dass entweder alles in großer Eile gemacht wurde, oder die Socket*-Funktionalität an den Nachwuchsentwickler gelangt ist.
In jedem Fall ist die derzeitige Lösung sehr grob und deckt einen recht engen Ansatz der Verwendung von Steckdosen ab.
1. dies ist die Schnittstelle.
TLS-Funktionen sind Hilfsfunktionen zur Unterstützung komplexer Fälle. Kein Problem mit der Einstellung von SocketTimeouts - diese sind am besten zu verwenden.
2. er seine Funktion korrekt ausführt.
Die Probleme mit der Erkennung von TCP-Verbindungsabbrüchen sind Ihnen sicher nicht bekannt. Es ist ziemlich schwierig (ressourcenintensiv auf Kosten zusätzlicher Anrufe) zu erkennen, dass eine Verbindung garantiert korrekt unterbrochen wird. Alle Netzimplementierungen leiden unter diesem Problem.
Unsere Implementierung von SocketIsReadible ist intelligent genug und verfügt über eine Brucherkennung. Wenn es eine saubere 0 Bytes erkennt, macht es die zusätzliche Arbeit, zu prüfen, ob die Buchse vollständig ist:
Da er die Anzahl der Bytes ohne Abbruchkennzeichen zurückgibt, gibt er 1 Byte aus, so dass ein nachfolgender/vorheriger SocketRead-Leseversuch normalerweise einen Fehler zurückgibt.
Warum ist dies richtig? Denn der größte Teil des Codes wird von Programmierern auf diese Weise geschrieben:
das tatsächliche Ergebnis der Operation wird bei einem direkten Leseversuch überprüft.
3. SocketIsReadible() muss vor dem eigentlichen Lesen ausgeführt werden, wenn Sie die genaue Größe der zu lesenden Daten nicht kennen.
Die SocketisReadible/SocketRead-Bindung gibt Ihnen die Möglichkeit, die Kontrolle über den Ausführungsablauf Ihres Programms nicht zu verlieren (minimieren Sie den Kontrollverlust auf nahezu Null). Dadurch werden Zeitüberschreitungen im Netz vermieden.
Ja, ein paar Zeilen mehr Code, aber Sie verlieren nicht für eine Millisekunde (ungefähr) die Kontrolle. Es liegt an Ihnen zu entscheiden, was Sie in den Zeiten tun, in denen keine Netzdaten vorhanden sind.
4. im zweiten Absatz erläutert.
Die Ausgabe von 1 um der Lese- und Ausgabestimulation willen ist ein Lesefehler.
Ihre Schlussfolgerungen sind falsch.
Dies liegt in der Natur des TCP/IP-Transports, bei dem es keinerlei Garantien gibt. Man kann auch bei Filtern/Firewalls in schwarze Löcher im Netzwerk geraten, wenn kein TCP-Signalisierungsteil vorhanden ist. Mit Raw Timeout und Datenflusskontrolle können Sie diese erkennen und die Verbindungen selbst beenden.
Wir haben eine Roh-/Direktzugriffsschnittstelle zu Netzwerkfunktionen, einschließlich TLS-Implementierungen, geschaffen. Wenn Sie sie verwenden, sind Sie derjenige, der die rohen Funktionen ordnungsgemäß in einen sicheren/kontrollierten SocketIsReadible/SocketRead-Handler verpacken muss.
Wenn Sie Anfragen auf hoher Ebene stellen möchten, ohne sich um die Details kümmern zu müssen, gibt es die WebRequest-Funktionen. Alle Schutzmechanismen sind dort eingebaut.