Errores, fallos, preguntas - página 2377
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Sí, cualquier impresión de OnInit
Gracias. Interesante, si no me di cuenta por casualidad, cómo sería posible descubrirlo...
ZS Yo lo dejaría sólo para los Agentes locales. En la Nube, se puede enviar fácilmente el registro de spam de esta manera.
Gracias. Interesante, si no me di cuenta por casualidad, cómo sería posible descubrirlo...
ZS Yo lo dejaría sólo para los Agentes locales. En la Nube, se puede enviar fácilmente el registro de spam de esta manera.
Cuando ejecuta la genética, ¿optimiza según su criterio personalizado?
Según los registros presentados, OnTester devolvió 0 en todos los casos
Suelo optimizar según mi criterio, pero aquí he probado también el criterio personalizado. El resultado es el mismo.
OnTester devuelve 0, por eso devuelve ceros en los resultados, es comprensible. La pregunta es ¿por qué devuelve "0" en la ejecución general (optimización) pero en la ejecución única de "resultados cero" (con los mismos parámetros) devuelve el resultado normal, el gráfico, etc.? Es decir, algo no funciona en "Superación total" y sin embargo la genética funciona bien. ¿Alguna otra idea?
¿Alguna otra idea?
Extraer toda la información de la optimización pasar de esta manera
Foro sobre trading, sistemas de trading automatizados y comprobación de estrategias
MT5. PROBADOR DE ESTRATEGIAS. Divergencia de los resultados de las pruebas y de la optimización.
fxsaber, 2017.08.22 11:06
Inserte estas líneas en el EA
Y corre la optimización. A continuación, ejecute una carrera individual no coincidente.
A continuación, compare los dos informes guardados de la ejecución correspondiente de Optimización y de la ejecución única.
El resultado de la comparación de los dos informes revelará rápidamente las causas.
El objetivo es mejorar en lo posible lo que se hace, pido a los desarrolladores que no se ofendan por las posibles críticas.
1. No entiendo las razones de las diferencias tan fuertes en las "interfaces" para las funciones de lectura de sockets no hay .
2. El nombre de la función SocketIsReadable no tiene nada que ver con lo que realmente realiza:
De hecho, SocketIsReadable es análoga a la función ioctlsocket() con la bandera FIONREAD en Ws2_32.dll
3. ¿Cómo puede un usuario que utiliza la funcionalidad Socket* a través de una conexión no encriptada obtener una respuesta de un servidor con un retraso mínimo, si el servidor no rompe la conexión después de la transferencia de datos?
Sí, así es como se hace:4. SocketIsReadable devuelve información falsa.
Apague el internet y ejecute el código anterior.
Como resultado, SocketIsReadable devuelve un valor sano de 1. Maravillas.
Conseguí describir aproximadamente un tercio de todas las preguntas y problemas relacionados con Socket*.
Por desgracia, he necesitado mucho tiempo para comprobar, describir y volver a comprobar todo... (para que no sea un hecho que habrá una secuela)
La impresión general es que, o bien todo se hizo con mucha prisa, o bien la funcionalidad de Socket* llegó al desarrollador junior.
En cualquier caso, la solución actual es muy rudimentaria y abarca un enfoque más bien limitado del uso de sockets.
Suelo optimizar según mis propios criterios, pero aquí he probado también los estándar. El resultado es similar.
OnTester devuelve 0, por eso hay ceros en los resultados, es comprensible. La pregunta es ¿por qué devuelve "0" en la ejecución general (optimización) pero en la ejecución individual desde "resultados cero" (con los mismos parámetros) devuelve el resultado normal, el gráfico, etc.? Es decir, algo no funciona en "Superación total" y sin embargo la genética funciona bien. ¿Alguna otra idea?
¿Puedes compartir un EA (ex5 en privado) y las condiciones de optimización?
Queremos reproducir el problema que mencionas.
Después de la investigación, el EA se borrará irremediablemente
¿Puedes compartir el EA (ex5 en un mensaje privado) y las condiciones de optimización?
Queremos reproducir el problema que mencionas.
Después de la investigación, el EA se borrará irremediablemente
¿Puedes compartir el EA (ex5 en un mensaje privado) y las condiciones de optimización?
Queremos reproducir el problema que mencionas.
La EA se borrará irremediablemente después de la investigación
Respondido en un mensaje privado.
En el marco de la familiarización con la funcionalidad de Socket* surgieron una serie de preguntas a la implementación actual.
El objetivo es mejorar en lo posible lo que se hace, pido a los desarrolladores que no se ofendan por las posibles críticas.
1. No entiendo las razones de las diferencias tan fuertes en las "interfaces" para las funciones de lectura de sockets no hay .
2. El nombre de la función SocketIsReadable no tiene nada que ver con lo que realmente realiza:
De hecho, SocketIsReadable es análoga a la función ioctlsocket() con la bandera FIONREAD en Ws2_32.dll
3. ¿Cómo puede un usuario que utiliza la funcionalidad Socket* a través de una conexión no encriptada obtener una respuesta de un servidor con un retraso mínimo, si el servidor no rompe la conexión después de la transferencia de datos?
Sí, así es como se hace:4. SocketIsReadable devuelve información falsa.
Apague el internet y ejecute el código anterior.
Como resultado, SocketIsReadable devuelve un valor sano de 1. Maravillas.
He conseguido describir aproximadamente un tercio de todas las preguntas y problemas relacionados con Socket*.
Por desgracia, he necesitado mucho tiempo para comprobar, describir y volver a comprobar todo... (para que no sea un hecho que habrá una secuela)
La impresión general es que, o bien todo se hizo con mucha prisa, o bien la funcionalidad de Socket* llegó al desarrollador junior.
En cualquier caso, la solución actual es muy rudimentaria y abarca un enfoque más bien limitado del uso de sockets.
1. Esta es la interfaz.
Las funciones TLS son auxiliares para soportar casos complejos. No hay problema con la configuración de SocketTimeouts - estos son los mejores para usar.
2. Realiza su función correctamente.
No debe ser consciente de los problemas de detección de ruptura de la conexión TCP. Es bastante difícil (requiere muchos recursos a costa de llamadas adicionales) detectar que una conexión está garantizada para que se rompa correctamente. Todas las implementaciones de la red sufren este problema.
Nuestra implementación de SocketIsReadible es lo suficientemente inteligente y tiene un detector de ruptura. Cuando detecta un 0 bytes limpio, hace el trabajo extra de comprobar que el socket está completo:
Dado que devuelve el número de bytes sin una bandera de terminación, emite 1 byte de modo que un intento de lectura posterior/imminente de SocketRead normalmente devolverá un error.
¿Por qué es esto correcto? Porque la mayor parte del código lo escriben los programadores de esta manera:
el resultado real de la operación se comprueba en un intento de lectura directa.
3. necesita hacer SocketIsReadible() antes de la lectura real, si no conoce el tamaño exacto de los datos a leer.
El bind SocketisReadible/SocketRead te da la posibilidad de no perder el control (minimizar a casi cero la pérdida de control) sobre el flujo de ejecución de tu programa. Esto evita que se produzcan tiempos muertos en la red.
Sí, unas cuantas líneas más de código, pero no perderás el control ni un milisegundo(aproximadamente). Tú decides qué hacer en los intervalos sin datos de la red.
4. explicada en el segundo párrafo.
Emitir 1 para la estimulación de la lectura y la salida como un error de lectura.
Sus conclusiones son erróneas.
Esta es la naturaleza del transporte TCP/IP, donde no hay ninguna garantía. Ahí también se puede entrar en agujeros negros de red en los filtros/firewalls cuando no hay parte de señalización TCP. El control del tiempo de espera y del flujo de datos le permite detectarlos y terminar las conexiones usted mismo.
Hemos dado una interfaz de acceso crudo/directo a las funciones de red, incluyendo las implementaciones de TLS. Si los utilizas, eres tú quien debe envolver adecuadamente las funciones raw en un manejador SocketIsReadible/SocketRead seguro/controlado.
Si quieres hacer peticiones de alto nivel sin tener que pensar en las minucias, existen las funciones WebRequest. Todas las protecciones están incorporadas.