Fehler, Irrtümer, Fragen - Seite 2706

Neuer Kommentar
 
Sergey Dzyublik:

Das ist das Problem, es gibt kein Logbuch für die Registerkarte "Fehler" in ME.

Meine Unaufmerksamkeit...

 

Was ist der Code 556?

30 Graphen mit EA, beim Kompilieren haben sich einige mit diesem Code nicht erholt, andere waren erfolgreich.

 
Igor Zakharov:

Was ist der Code 556?

30 Graphen mit EA, beim Kompilieren haben sich einige mit diesem Code nicht erholt, die anderen erfolgreich.

Fehler beim Öffnen der Datei dip.ex5

Vollständiges Protokoll anzeigen, nicht nur einen Teil des Screenshots

 
Orte zum Einfügen von Protokollen werden versuchen
 
Slava:

Fehler beim Öffnen der Datei dip.ex5

Vollständiges Protokoll anzeigen, nicht nur einen Teil des Screenshots

siehe Anhang.

Dateien:
20200415.zip  5 kb
 

Kann mir jemand sagen, wie man TLS-Sockets mit dem Echo-Server verbindet? Ich habe den Quellcode aus dem Beispiel genommen und die Kopfzeilen hinzugefügt. Auf Port 80 führt er ein Upgrade durch, aber auf 443 stellt er eine Verbindung her und erhält ein Zertifikat, kann dann aber nichts aus den Headern lesen. Bei der Ausführung mit dem Debugger können Sie sehen, dassSocketIsReadable eine ähnliche Zahl wie 245 zurückgibt, aber SocketTlsRead stürzt durch Timeout ab, ohne etwas zurückzugeben. Offenbar ist heiliges Wissen aus MQ erforderlich.

Dateien:
SocketExample.mq5  4 kb
 

Fehler ME (Build 2380) falsche Funktionsschablonen-Parametersignatur in Fehlerbeschreibung und Parameterinfo.

template<typename T>
class A{};

class B{
public:  
   template<typename T>
   static void test(A<T> &, A<int>* = NULL){
      int x = 1 / 0;                       //'0' - division by zero |  in template 'void B::test(B:: A<T>&,A<int>*)' specified with [T=long]
   }
};

void OnStart(){
   A<long> a;
   B::test(a);                             // Parameter info: void test([unknown] &, [unknown] *=NULL)
}
 
Stanislav Korotky:

Kann mir jemand sagen, wie man TLS-Sockets mit dem Echo-Server verbindet? Ich habe den Quellcode aus dem Beispiel genommen und die Kopfzeilen hinzugefügt. Auf Port 80 führt er ein Upgrade durch, aber auf 443 stellt er eine Verbindung her und erhält ein Zertifikat, kann dann aber nichts aus den Headern lesen. Bei der Ausführung mit dem Debugger können Sie sehen, dass SocketIsReadable eine ähnliche Zahl wie 245 zurückgibt, aber SocketTlsRead stürzt durch Timeout ab, ohne etwas zurückzugeben. Offenbar ist heiliges Wissen aus MQ erforderlich.

Es ist mir auch nicht gelungen, mit HTTPRecv ein Byte-Antwort-Array zu erhalten, um das Protokoll weiter zu parsen.
Schlägt bei Timeout fehl, weil Ping Pong nicht organisiert ist, aber um es zu organisieren, muss man zuerst eine Byte-Antwort vom Server erhalten, und dieHTTPRecv-Funktion selbstenthält Timeout.
Aber aus irgendeinem Grund parst HTTPRecv diese Byte-Antwort nicht.

 
Roman:

Es ist mir auch nicht gelungen, mit HTTPRecv ein Byte-Antwort-Array für das weitere Protokoll-Parsing zu erhalten.
Es scheitert an der Zeitüberschreitung, weil Ping Pong nicht organisiert ist, aber um es zu organisieren, muss man zuerst eine Byte-Antwort vom Server erhalten, und dieHTTPRecv-Funktion selbstenthält eine Zeitüberschreitung.
Aber aus irgendeinem Grund parst HTTPRecv diese Byte-Antwort nicht.

Es geht nur um die Verbindung selbst. Dort gibt es noch keinen Ping - das kann später im Websocket-Protokoll geschehen. Das Problem tritt im Antwort-Header des Servers auf, wenn er die Aktualisierung bestätigen muss. Wenn kein TLS verwendet wird, wird die Verbindung normal hergestellt. Aber auch mit TLS sieht es so aus, als ob der Header zum Terminal ankommt, aber nicht vonSocketTlsRead zurückkommt.

 
Stanislav Korotky:

Dies ist nur die Verbindung selbst. Dort gibt es noch keinen Ping - das kann später im Websocket-Protokoll geschehen. Das Problem tritt in der Kopfzeile der Serverantwort auf, wenn die Aktualisierung bestätigt werden muss. Wenn kein TLS verwendet wird, wird die Verbindung normal hergestellt. Aber auch bei TLS sieht es so aus, als ob der Header zum Terminal kommt, aber nicht von SocketTlsRead zurückgegeben wird.

Ja, ich verstehe, was ich meine.
Ja, in Ihrem Code ist es so, dass bei Port 80 der Header zurückkehrt, bei 443 jedoch nicht.
Ich habe mir Ihren Code noch einmal angesehen und die FunktionSocketTlsHandshake dort nicht gesehen.
Ihr Code führt keinen Handshake durch. Dies könnte der Grund sein.
In der Hilfe zu dieser Funktion steht zwar, dass sie nicht erforderlich ist, wenn Sie eine Verbindung über Port 443 herstellen.
Es ist also im Allgemeinen seltsam.

UPD:
Egal, wie ich den Request-Header setze, es kommt immer noch der Fehler

ERR_NETSOCKET_IO_ERROR 5273  Ошибка отправки/получения данных из сокета

Oder

HTTP/1.1 400 Bad Request

Vielleicht hat der Entwickler den Empfang des Upgrades auf TLS verboten?


UPD:
Kein Fehler im Header, aber auch kein Response-Header.
In derHTTPRecv-Funktion können Sie einen Ausdruck erstellen, um zu sehen, was ankommt.

result += CharArrayToString(rsp, 0, rsp_len, CP_UTF8);
Print(result);

Es wird nur ein Zeichen H
gedruckt. Dieses Zeichen lässt mich vermuten, dass es sich um den ersten Buchstaben der Kopfzeile der Antwort handelt,
, und der Rest der Kopfzeile wird aus irgendeinem Grund nicht gedruckt.

Liebe Entwickler, könnten Sie uns sagen, was wir tun sollen?
Handelt es sich um eine absichtliche Einschränkung oder um einen Fehler im TLS?
Ich kämpfe schon seit langem mit diesem Problem, ohne Erfolg.

1...269927002701270227032704270527062707270827092710271127122713...3184
Neuer Kommentar