ForumKategorien

Fehler, Irrtümer, Fragen - Seite 2377

Neuer Kommentar
Slava:
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.

fxsaber:

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.

In der Cloud wird sie nicht angezeigt. Weil es keinen Grund dazu gibt.
Slava:

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?

Kuzmich:

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

#define  REPORT_TESTER // В тестере будут автоматически записываться отчеты
#include <Report.mqh>

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.

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
: a) Für verschlüsselte Verbindungen gibt es zwei Funktionen zum Lesen, und für unverschlüsselte - eine.
b) InSocketRead ist es notwendig,timeout_ms explizit anzugeben, und inSocketTlsRead undSocketTlsReadAvailable
gibt es überhaupt keinen solchen Parameter (durch separate Funktion SocketTimeouts eingestellt).
int  SocketTlsRead(int socket, uchar& buffer[], int buffer_maxlen);
int  SocketTlsReadAvailable(int socket, uchar& buffer[], int buffer_maxlen);

int  SocketRead(int socket, uchar& buffer[], int buffer_maxlen, uint timeout_ms);


2. Der Name der Funktion SocketIsReadable hat nichts damit zu tun, was sie tatsächlich tut:

bool  SocketIsWritable(const int  socket); // Return true if writing is possible, otherwise false.
uint  SocketIsReadable(const int  socket); // Number of bytes that can be calculated. In case of an error, 0 is returned.
bool  SocketIsConnected(const int socket); // New function without description. May be, it returns true if connection is not closed.

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?

- Die Funktion SocketIsReadable ohne explizite Verwendung einer Zeitverzögerung (z. B. ohne Sleep) gibt 0 zurück.
- die Funktion SocketRead weiß nicht, wie viel sie lesen soll, Sie gebenbuffer_maxlen mit einer Reserve an - Sie müssen auftimeout_ms warten

Ja, so wird es gemacht:

- Warte auf 1 Byte Daten in SocketRead;
- dann die Größe der gesamten Antwort mit SocketIsReadable herausfinden;
- die verbleibende Länge in SocketRead einlesen;
- Ergebnisse durch Kopieren von Arrays zusammenführen:

#define  PRINT(x) Print(#x, ": ", string(x))
                
void OnStart() {
   string domain = "www.mql5.com";
   int port = 80;
 
   string request = "GET / HTTP/1.1\r\nHost: " + domain + "\r\n\r\n";
   char req[];
   
   int socket = SocketCreate();
   PRINT(SocketConnect(socket, domain, port, 5000));
   int len=StringToCharArray(request,req)-1;
   PRINT(SocketSend(socket,req,len));
   
   
   
   uchar resp[];
   uchar result[];
   
   int resp_result;
   uint resp_len;
   int start_write;
   
   
   resp_len = 1;
   resp_result = SocketRead(socket, resp, resp_len, 5000);
   if (resp_result <= 0){
      PRINT(GetLastError());
      return;
   }
   start_write = ArraySize(result);
   ArrayResize(result, start_write + resp_result);
   ArrayCopy(result, resp, start_write);
   
   
   resp_len = SocketIsReadable(socket);
   resp_result = SocketRead(socket, resp, resp_len, 5000);
   if (resp_result <= 0){
      PRINT(GetLastError());
      return;
   }
   start_write = ArraySize(result);
   ArrayResize(result, start_write + resp_result);
   ArrayCopy(result, resp, start_write);
   
   
   PRINT(CharArrayToString(result));
};

Ist das nicht zu viel Code?


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.

MQL5\Include\Math\AlgLib\dataanalysis.mqh - CLinReg::LRLine funktioniert nicht für 1M oder mehr Werte?
Kuzmich:

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

Slava:

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

Würden Sie sich meinen EA ansehen? Ich habe ein ähnliches Problem - der Gewinn wird nicht gezählt, folglich funktioniert die Optimierung nicht.
Slava:

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.

Sergey Dzyublik:
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
: a) Für verschlüsselte Verbindungen gibt es zwei Funktionen zum Lesen, und für unverschlüsselte - eine.
b) InSocketRead ist es notwendig,timeout_ms explizit anzugeben, und inSocketTlsRead undSocketTlsReadAvailable
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?

- Die Funktion SocketIsReadable ohne explizite Verwendung der Zeitverzögerung (z. B. ohne Sleep) gibt 0 zurück.
- Die Funktion SocketRead weiß nicht, wie viel gelesen werden soll, wenn manbuffer_maxlen mit Reserve angibt - muss man auftimeout_ms warten

Ja, so wird es gemacht:

- Warte auf 1 Byte Daten in SocketRead;
- dann die Größe der gesamten Antwort mit SocketIsReadable herausfinden;
- die verbleibende Länge in SocketRead einlesen;
- Ergebnisse durch Kopieren von Arrays zusammenführen:

Ist das nicht zu viel Code?


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:

   //+------------------------------------------------------------------+
   //| Доступно для чтения?                                             |
   //+------------------------------------------------------------------+
   UINT32 IsReadible(void)
     {
      unsigned long size=1;    // специально, чтобы убиться при попытке чтения, если сокет мертв
      //--- проверка
      if(m_socket!=INVALID_SOCKET)
        {
         //--- считаем количество доступных для чтения байт
         if(ioctlsocket(m_socket,FIONREAD,&size)!=0)
           {
            Close();
            return(1);        // вернем 1, чтобы убиться при попытке чтения
           }
         //--- если нет данных, проверим сокет на завершенность
         if(size==0)
           {
            timeval wait_time;
            fd_set  fd;
            //--- ждём
            FD_ZERO(&fd);
            FD_SET(m_socket,&fd);

            wait_time.tv_sec =0;          // секунды
            wait_time.tv_usec=1000;       // микросекунды
            //--- ждём
            if(select(0,&fd,NULL,NULL,&wait_time)>0)
               return(1);                 // вернем 1, чтобы убиться при попытке чтения
           }
        }
      //--- размер
      return(size);
     }

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:

if(SocketIsReadible(...)>0)
  {
   if(SocketRead( )<1)
     return(false);
   ...
  }
... уходим на следующий круг ожидания

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.

1...237023712372237323742375237623772378237923802381238223832384...3184
Neuer Kommentar