Discusión sobre el artículo "WebSocket para MetaTrader 5" - página 2

[Roman]

Renat Fatkhullin:

Simplemente no entiendes o no sabes cómo utilizar esta función.

Esta función da instantáneamente el número de bytes disponibles en el buffer de entrada, y no te dice que el socket está vivo. La función es muy importante y te permite no entrar en espera síncrona, sino leer los datos porción por porción sin perder el control sobre el programa.

Y las funciones TLS también son correctas - están dadas para usuarios entrenados que saben cómo y en qué secuencia usarlas. No son para los que "llaman y ya está".

No solo eso, las funciones socket y tls son en forma pura las mismas que usa terminal para conexiones raw/tls/https. Es decir, todo funciona bien. Estas mismas implementaciones funcionan en nuestras soluciones de alta carga.

Las funciones de red raw no son para principiantes ni para un uso ingenuo. Uno debe entender los principios y peculiaridades de la interacción de red lo suficientemente bien. Y si estamos hablando de TLS, los métodos y la secuencia de procesamiento del proceso de handshake.

Esta función no tiene ningún parámetro de búfer. ¿De qué buffer de entrada estamos hablando?
No sé de qué entendimiento estás hablando y para qué usuarios, Ilyas encontró este error y lo tomó como un error.
El punto es que todos los usuarios se orientan en ejemplos de la documentación de sockets.
Y los usuarios avanzados escriben la especificacion del protocolo, y las actualizaciones y el frame parsing entienden todo esto.
El problema es que la funcion SocketIsReadable(socket) no esta claro que devuelve, para wss: frame.

[Roman]

Stanislav Korotky:

¿Hay alguna razón para ello? ¿Cuál es el número mágico y por qué estaría bien para una longitud de mensaje de 256 o 1500, por ejemplo?

¿Razonamiento? No lo sé. Con el número en la variable, se lee sin problema. La longitud se ajusta al tamaño máximo aproximado de la trama entrante.
Puedes ponerlo al máximo, no afecta en nada.

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);
}

Y con la función SocketIsReadable(socket) sabes que lee con error.

Lo que SocketIsReadable(socket) devuelve en len no cabe en SocketTlsRead() y SocketTlsReadAvailable()

[Renat Fatkhullin]

Roman:

Esta función no tiene parámetro buffer. ¿De que buffer de entrada estamos hablando?
No se de que entendimiento estas hablando y para que usuarios, este error fue encontrado por Ilyas y creo que lo tomo como un error.
El punto es que todos los usuarios estan orientados en ejemplos de la documentacion para sockets.
Y los usuarios avanzados escriben la especificación del protocolo, y las actualizaciones y el parseo de tramas entienden todo esto.
El problema es que la función SocketIsReadable(socket) no está claro qué devuelve, para wss: frame.

O sea, que no tiene ni idea de sockets y sus buffers, pero nos enseña errores.

Comprobar el tamaño de los datos brutos en el buffer entrante SocketIsReadable ciertamente no encaja con las funciones Tls que tratan con datos encriptados recibidos en un tamaño menor.

'Lo tomé como un error' - la gente se las arregla para tomar cualquier respuesta clara como una admisión de culpa. Muestra una respuesta clara.

[Roman]

Renat Fatkhullin:
Así que no tienes ni idea de sockets y sus buffers, pero nos enseñas errores.

Comprobar el tamaño de los datos en bruto en el buffer entrante SocketIsReadable ciertamente no encaja con las funciones Tls que tratan con datos encriptados recibidos en un tamaño menor.

La pregunta era sobre la función SocketIsReadible, y el hecho de que la función tiene un buffer interno está claro.
Escribes sobre el buffer de la función SocketIsReadible, pero es extraño mencionarlo si no está disponible para el usuario.

[Renat Fatkhullin]

Lee el artículo y mira el código propuesto.

Es extraño alegar errores con un trozo de código irreproducible de varias líneas cuando estamos hablando de la calidad de implementación de un protocolo complejo.

[Renat Fatkhullin]

Roman:

La pregunta era sobre la función SocketIsReadible, y el hecho de que la función tiene un buffer interno está claro.
Escribes para el buffer de la función SocketIsReadible, pero es extraño mencionarlo si no está disponible para el usuario.

Una vez más repito - no entiendes de sockets y no conoces sus peculiaridades.

Incluso te equivocas con los buffers 'internos' de SocketIsReadable que no existen. ¿De quién son los buffers de los sockets? ¿Quién los gestiona? ¿Cómo funcionan y cuáles son sus peculiaridades?

De ahí el mal uso con declaraciones de error, cuando la realidad diverge de la percepción ingenua.

[Roman]

Renat Fatkhullin:

La gente confunde cualquier respuesta clara con una admisión de culpabilidad. Muéstrame una respuesta clara.

.

[Renat Fatkhullin]

Roman:

.

La primera parte de su respuesta es correcta, explica la diferencia entre los tamaños de los datos en bruto y los datos descifrados.

Pero la última respuesta es un caso privado (poner tamaño fijo) en forma de muleta. Lo más probable es que sea en el contexto de otro trozo de código de tres líneas en el que no se puede ofrecer nada más que una corrección/muletilla privada.

Ilyas no se ocupa de sockets. No hay reconocimiento de errores.

Para información: Escribí la implementación de raw sockets, tls, https y sus derivados en MT5. Como antes escribí docenas de implementaciones de protocolos de red desde 1995.

Así que es extraño discutir conmigo. Decenas de millones de dispositivos trabajaron y trabajan en mis implementaciones.

[Roman]

Renat Fatkhullin:
La primera parte de su respuesta es correcta, explica la diferencia entre el tamaño de los datos brutos y los datos descifrados.

Pero la última respuesta es un caso privado (poner tamaño fijo) en forma de muletilla. Lo más probable es que sea en el contexto de otro trozo de código de tres líneas en el que no se puede ofrecer nada más que una corrección/muletilla privada.

Ilyas no se ocupa de sockets. No hay reconocimiento de errores.

Para información: Escribí la implementación de raw sockets, tls, https y sus derivados en MT5. Como antes escribí docenas de implementaciones de protocolos de red desde 1995.

Así que es extraño discutir conmigo. Decenas de millones de dispositivos trabajaron y trabajan en mis implementaciones.

Entiendo su experiencia indiscutible. Y nadie no iba a discutir con usted.
Pero el artículo no revela la cuestión de cómo utilizar correctamente wss: en MQL!
Debido a que el autor del artículo no entiende este punto, así como todos los demás usuarios (incluso avanzados).
Es por eso que yo uso en mi implementación, fijar el tamaño como una muleta.

Por favor, muéstrame la lectura correcta de wss: marco en MQL teniendo en cuenta el SocketIsReadable piscina, todo el mundo va a decir sólo gracias.

[Renat Fatkhullin]

Roman:

Entiendo su experiencia indiscutible. Y nadie iba a discutir con usted.
Pero el artículo no revela la cuestión de cómo utilizar wss: en MQL correctamente!
Debido a que el autor del artículo no entiende este punto, así como todos los demás usuarios (incluso avanzados).
Es por eso que yo uso en mi aplicación el tamaño fijo como una muleta.

Por favor, muéstrame la correcta wss: lectura de trama en MQL, teniendo en cuenta el SocketIsReadable piscina, todo el mundo va a decir sólo gracias.

No tengo tiempo ahora, pero deberia hacer un conjunto de implementaciones CSocketRaw, CSocketTLS, CSocketHTTP en la libreria estandar MQL5.

Si tengo 8 horas de tiempo libre, lo haré.