Diskussion zum Artikel "Websockets für MetaTrader 5" - Seite 2

[Roman]

Renat Fatkhullin:

Sie verstehen oder wissen einfach nicht, wie man diese Funktion nutzt.

Diese Funktion zeigt sofort die Anzahl der verfügbaren Bytes im Eingabepuffer an und sagt Ihnen nicht, dass der Socket aktiv ist. Die Funktion ist sehr wichtig und ermöglicht es Ihnen, nicht in das synchrone Warten zu gehen, sondern die Daten portionsweise auszulesen, ohne die Kontrolle über das Programm zu verlieren.

Und auch die TLS-Funktionen sind richtig - sie sind für geschulte Benutzer gedacht, die wissen, wie und in welcher Reihenfolge sie zu verwenden sind. Sie sind nicht für diejenigen gedacht, die "angerufen haben und das war's".

Nicht nur das, die Socket- und TLS-Funktionen sind in Reinform die gleichen, die das Terminal für raw/tls/https-Verbindungen verwendet. Das heißt, alles funktioniert einwandfrei. Die gleichen Implementierungen funktionieren auch in unseren Hochlastlösungen.

Rohe Netzwerkfunktionen sind nichts für Anfänger und nicht für naiven Gebrauch. Man sollte die Prinzipien und Eigenheiten der Netzwerkinteraktion gut genug verstehen. Und wenn wir über TLS sprechen, die Methoden und die Reihenfolge der Verarbeitung des Handshake-Prozesses.

Diese Funktion hat keinen Pufferparameter. Von welchem Eingabepuffer ist die Rede?
Ich weiß nicht, von welchem Verständnis Sie sprechen und für welche Benutzer Ilyas diesen Fehler gefunden und als Fehler aufgefasst hat.
Der Punkt ist, dass sich alle Benutzer an Beispielen aus der Socket-Dokumentation orientieren.
Und fortgeschrittene Benutzer schreiben Protokollspezifikationen, und Upgrades und Frame Parsing verstehen das alles.
Das Problem ist, dass die Funktion SocketIsReadable(socket) nicht klar ist, was sie zurückgibt, für wss: frame.

[Roman]

Stanislav Korotky:

Gibt es dafür eine Begründung? Was ist die magische Zahl und warum ist sie z.B. für eine Nachrichtenlänge von 256 oder 1500 in Ordnung?

Begründung? Ich weiß es nicht. Mit der Zahl in der Variablen lässt sich die Nachricht problemlos lesen. Die Länge wird auf die ungefähre maximale Größe des eingehenden Frames gesetzt.
Sie können sie auf das Maximum setzen, es hat keinen Einfluss.

string CWs::Recv()
{
   uchar   rsp[]; //, res[];
   string  result  = "";
   //uint timeout_check = GetTickCount() + timeout;

   //do
   //{
      uint len = 65536; //SocketIsReadable(socket);

      //if(len)
      //{
         int rsp_len = SocketTlsReadAvailable(socket, rsp, len);

         //if(rsp_len > 0)
         //{
            //ArrayInsert(res, rsp, ArraySize(res), 0); 
            //break;
         //} 
      //}
   //}
   //while(GetTickCount() < timeout_check && !IsStopped());

   if(rsp_len > 0) //(ArraySize(res) > 0)
      result = Unpack(rsp, ArraySize(rsp));
   
  
   return(result);
}

Und mit der Funktion SocketIsReadable(socket) weiß man, dass sie mit einem Fehler liest.

Was SocketIsReadable(socket) in len zurückgibt, passt nicht in SocketTlsRead() und SocketTlsReadAvailable()

[Renat Fatkhullin]

Roman:

Diese Funktion hat keinen Pufferparameter. Von welchem Eingabepuffer ist die Rede?
Ich weiß nicht, von welchem Verständnis du sprichst und für welche Benutzer, dieser Fehler wurde von Ilyas gefunden und ich denke, er hat ihn als Fehler angesehen.
Der Punkt ist, dass alle Benutzer sich an Beispielen aus der Dokumentation für Sockets orientieren.
Und fortgeschrittene Benutzer schreiben Protokollspezifikationen, und Upgrades und Frame Parsing verstehen das alles.
Das Problem ist, dass die Funktion SocketIsReadable(socket) nicht klar ist, was sie zurückgibt, für wss: frame.

Sie haben also überhaupt keine Ahnung von Sockets und ihren Puffern, aber Sie bringen uns Fehler bei.

Das Überprüfen der Größe der Rohdaten im eingehenden Puffer SocketIsReadable passt sicherlich nicht zu Tls-Funktionen, die mit verschlüsselten Daten umgehen, die in einer kleineren Größe empfangen werden.

Took it as a mistake" - die Leute schaffen es, jede saubere Antwort als Schuldeingeständnis zu verstehen. Zeigen Sie eine klare Antwort.

[Roman]

Renat Fatkhullin:
Sie haben also überhaupt keine Ahnung von Steckdosen und ihren Puffern, aber Sie bringen uns Fehler bei.

Die Überprüfung der Größe der Rohdaten im eingehenden Puffer SocketIsReadable passt sicherlich nicht zu Tls-Funktionen, die mit verschlüsselten Daten umgehen, die in einer kleineren Größe empfangen werden.

Die Frage bezog sich auf die Funktion SocketIsReadible, und die Tatsache, dass die Funktion einen internen Puffer hat, ist klar.
Sie schreiben über den Puffer der Funktion SocketIsReadible, aber es ist seltsam, ihn zu erwähnen, wenn er für den Benutzer nicht verfügbar ist.

[Renat Fatkhullin]

Lesen Sie den Artikel und sehen Sie sich den vorgeschlagenen Code an.

Es ist seltsam, Fehler bei einem nicht reproduzierbaren Stück Code von einigen Zeilen zu behaupten, wenn wir über die Qualität der Implementierung eines komplexen Protokolls sprechen.

[Renat Fatkhullin]

Roman:

Die Frage bezog sich auf die Funktion SocketIsReadible, und die Tatsache, dass die Funktion einen internen Puffer hat, ist klar.
Sie schreiben für den Puffer der Funktion SocketIsReadible, aber es ist seltsam, ihn zu erwähnen, wenn er für den Benutzer nicht verfügbar ist.

Ich wiederhole noch einmal: Sie verstehen Sockets nicht und kennen ihre Eigenheiten nicht.

Sie irren sich sogar über "interne" SocketIsReadable-Puffer, die es nicht gibt. Wem gehören die Puffer in Sockets? Wer verwaltet sie? Wie funktionieren sie und was sind ihre Eigenheiten?

Daher der Missbrauch mit Fehleraussagen, wenn die Realität von der naiven Wahrnehmung abweicht.

[Roman]

Renat Fatkhullin:

Taken for a mistake" - die Leute verstehen jede saubere Antwort als Schuldeingeständnis. Zeigen Sie mir eine klare Antwort.

.

[Renat Fatkhullin]

Roman:

.

Der erste Teil seiner Antwort ist richtig, er erklärt den Unterschied zwischen den Größen von Rohdaten und entschlüsselten Daten.

Aber die letzte Antwort ist ein privater Fall (feste Größe) in Form einer Krücke. Sie steht höchstwahrscheinlich vor dem Hintergrund eines anderen dreizeiligen Codestücks, bei dem nichts anderes als eine private Korrektur/Krücke angeboten werden kann.

Ilyas befasst sich nicht mit Sockets. Es gibt keine Fehlerquittierung.

Zur Information: Ich habe die Implementierung von Raw Sockets, tls, https und deren Derivate in MT5 geschrieben. Wie zuvor habe ich seit 1995 Dutzende von Implementierungen von Netzwerkprotokollen geschrieben.

Es ist also seltsam, mit mir zu argumentieren. Dutzende von Millionen von Geräten arbeiteten und arbeiten mit meinen Implementierungen.

[Roman]

Renat Fatkhullin:
Der erste Teil seiner Antwort ist richtig, er erklärt den Unterschied zwischen der Größe der Rohdaten und der entschlüsselten Daten.

Bei der letzten Antwort handelt es sich jedoch um einen privaten Fall (feste Größe) in Form einer Krücke. Höchstwahrscheinlich handelt es sich dabei um einen anderen dreizeiligen Code, bei dem nichts anderes als eine private Korrektur/Krücke angeboten werden kann.

Ilyas befasst sich nicht mit Sockets. Es gibt keine Fehlerquittierung.

Zur Information: Ich habe die Implementierung von Raw Sockets, tls, https und deren Derivate in MT5 geschrieben. Wie zuvor habe ich seit 1995 Dutzende von Implementierungen von Netzwerkprotokollen geschrieben.

Es ist also seltsam, mit mir zu streiten. Dutzende von Millionen von Geräten arbeiteten und arbeiten mit meinen Implementierungen.

Ich verstehe Ihre unbestrittene Erfahrung. Und niemand wollte nicht mit Ihnen streiten.
Aber der Artikel offenbart nicht die Frage, wie man wss: in MQL richtig verwendet!
Weil der Autor des Artikels diesen Punkt nicht versteht, ebenso wie alle anderen (auch fortgeschrittenen) Benutzer.
Deshalb verwende ich in meiner Implementierung, fixe Größe als Krücke.

Bitte zeigen Sie mir die korrekte wss: Frame-Lesung in MQL, unter Berücksichtigung der SocketIsReadable Pool, jeder wird nur sagen, danke.

[Renat Fatkhullin]

Roman:

Ich verstehe Ihre unbestrittene Erfahrung. Und niemand wollte Ihnen widersprechen.
Aber der Artikel klärt nicht die Frage, wie man wss: in MQL richtig einsetzt!
Weil der Autor des Artikels diesen Punkt nicht so gut versteht wie alle anderen (auch fortgeschrittenen) Benutzer.
Deshalb verwende ich in meiner Implementierung die feste Größe als Krücke.

Zeigen Sie mir bitte das korrekte wss:-Rahmenlesen in MQL, unter Berücksichtigung des SocketIsReadable-Pools, jeder wird nur Danke sagen.

Ich habe jetzt keine Zeit, aber ich sollte eine Reihe von CSocketRaw, CSocketTLS, CSocketHTTP Implementierungen in der Standard MQL5 Bibliothek machen.

Wenn ich 8 Stunden freie Zeit habe, werde ich es tun.