Discusión sobre el artículo "Comunicándonos con Meta Trader 5 usando conexiones designadas sin utilizar DLL"

Nuevo comentario
 

Artículo publicado Comunicándonos con Meta Trader 5 usando conexiones designadas sin utilizar DLL:

Muchos desarrolladores se enfrentan con el mismo problema: cómo llegar al módulo del terminal sin utilizar DLL poco seguras.

Una de los métodos más sencillos y seguros es utilizar conexiones designadas que funcionan como operaciones de archivo normales. Estos nos permiten organizar la comunicación cliente-servidor entre procesadores entre los programas. Aunque ya hay un artículo publicado sobre este tema (Una solución libre de DLL para la comunicación entre los terminales de Meta Trader 5 usando conexiones designadas) que muestra cómo habilitar el acceso a las DLL, usaremos las características estándar y seguras del terminal de cliente.

Puede encontrar más información sobre las conexiones designadas en la librería MSDN, pero nos iremos a ejemplos prácticos en C++ y MQL5. Implementaremos un servidor, un cliente y un intercambio de datos entre los mismos y luego calificaremos el rendimiento.

Autor: MetaQuotes Software Corp.

 
¿Funcionan las pepitas en el probador?
 
Graff:
¿Funcionan las tuberías en el comprobador?

¿Por qué debería funcionar en el comprobador la comunicación entre diferentes terminales?

Hazlo a través de eventos, funcionan en el probador.

 
Urain:

¿Por qué debería funcionar la comunicación entre terminales diferentes en el probador?

¿Por qué no? Deberías probarlo. Pero no sé por qué... :)


hacerlo a través de eventos, funcionan en el tester.

¿Qué a través de eventos? ¿Comunicación entre terminales?

;)

 

Los pipelines con nombre funcionan en agentes locales, pero están deshabilitados en clades.

Es decir, tanto las pruebas individuales como los agentes locales masivos pueden conectarse a un servidor pip de terceros (no sólo local).

 
MetaDriver:
¿Por qué no? Vale la pena intentarlo. No sé por qué. :)


¿a través de eventos? ¿comunicación entre terminales?

;)

Ir a la esencia de la pregunta, si una persona necesita la comunicación entre los programas en el probador, entonces la tarea de transferencia de datos entre los programas en un terminal es visible, y se puede hacer a través de eventos, omitiendo todas estas tonterías, mi respuesta es bastante lógico.
 
Urain:
Si una persona necesita la comunicación entre los programas en el probador, entonces la tarea de transferencia de datos entre programas en un terminal es obvia, y esto se puede hacer a través de eventos, omitiendo todas estas tonterías, mi respuesta es bastante lógica.
Me metí en ella, me pareció que sólo está interesado en el seguimiento del proceso de prueba de un programa externo.
 

A simple vista, hay dos formas de utilizarlo:

Y los artículos sobre este tema serán interesantes.

 
Rosh:

A simple vista, hay dos formas de utilizarlo:

Y los artículos sobre este tema serán interesantes.

Lamentablemente esto es posible sólo para aquellos que saben programar en C para Windows, porque:

Renat:
Sólo hay que tener en cuenta que esto es soporte cliente, y no se pueden crear conectores servidor en el terminal.

Es decir, en tecnologías cliente-servidor dos clientes no se verán sin mediación del servidor. He mirado el tema de la creación de canales con nombre en otros lenguajes de programación, pero por desgracia, en la mayoría de ellos se puede crear un cliente para Windows por medios estándar, aunque los canales para Unix se crean en casi todas partes sin problemas.

Necesitamos pasarelas en forma de EXE-shells, que puedan conectar dos canales con nombre full-duplex según el algoritmo:

  1. Crear dos canales con nombre A y B
  2. Crear el primer subproceso que escuche al canal A para una conexión.
  3. Después de que un cliente que está esperando un mensaje se conecte al canal A, crea un segundo subproceso que escuche al canal B en busca de una conexión.
  4. El primer subproceso se activa para transferir un flujo de bytes en bucle del canal A al canal B.
  5. Tan pronto como un cliente se conecta al canal B, el segundo subproceso se inicia para leer el flujo de bytes en un bucle desde el canal B al canal A.
  6. El segundo cliente comienza a transmitir el primer mensaje del canal B al canal A.
  7. Y así sucesivamente, hasta que algún cliente se desconecta, tras lo cual se destruyen ambos canales y pasamos al punto 1. 1

Por supuesto, en los scripts MQL de una sola tarea no es necesario el dúplex completo, porque los clientes no pueden recibir y transmitir información de forma asíncrona. Pero half-duplex es adecuado sólo para aquellos casos en los que el servidor conoce el protocolo de intercambio y puede calcular fácilmente dónde termina la recepción-transmisión de un cliente a otro para cambiar al modo opuesto. Si no lo sabe, porque no tiene capacidades telepáticas, y esto sólo lo saben los clientes que intercambian entre sí utilizando el protocolo que sólo ellos conocen, entonces es necesario un dúplex completo con dos subprocesos. Tal pasarela es conveniente porque cada cliente tiene sólo un canal para la comunicación con otro cliente y la secuencia de conexión desde el lado del cliente no juega ningún papel, si ciertamente comprobará la posibilidad de conexión en el ciclo inicial. El algoritmo de pasarela excluye la posibilidad de conexión del cliente, que es el primero según el protocolo debe transmitir un mensaje antes de que el segundo cliente se conecte y la transmisión al vacío no se producirá.

Teóricamente, dado que el número de canales con nombre es ilimitado, sería posible crear una pasarela simplex de una sola tarea según el algoritmo:

  1. Se crea un primer canal con nombre para la transmisión desde la pasarela al cliente.
  2. Una vez que el primer cliente se ha conectado, se crea un segundo canal para recibir mensajes del cliente.
  3. Después de que el cliente transmisor se haya conectado al segundo canal, el proceso hace un bucle con el flujo de bytes desde el canal receptor hasta el canal transmisor.
  4. En cuanto un cliente abandona, eliminamos ambos canales y volvemos al paso 1.

En este caso se necesitan dos pasarelas de este tipo para conectar dos clientes en half-duplex o una si sólo se utiliza simplex. La desventaja en comparación con una pasarela full-duplex es que en los scripts MQL tendrás que escribir dos canales (para recepción y transmisión) y en ellos también observar estrictamente la secuencia de conexión: primero para recepción y luego para transmisión (de lo contrario el segundo canal nunca se creará). El algoritmo de esta pasarela también excluye la posibilidad de conexión de un cliente, que es el primero según el protocolo debe transmitir un mensaje antes de que el segundo cliente se conecte y la transmisión al vacío no se producirá.

Naturalmente, las pasarelas deberían prever la posibilidad de configurar los nombres de los canales en función de la secuencia de recepción-transmisión y conexión de los clientes, por ejemplo, a través de la línea de comandos en el arranque.

Si alguien programando en C creara tales pasarelas y las compilara en EXEs y las colgara aquí, sería fácil crear conexiones entre scripts, Asesores Expertos e indicadores utilizando herramientas estándar MQL5, sin necesidad de panderetear en otros lenguajes de programación.

Teóricamente, también se puede escribir un artículo sobre cómo conectar correctamente clientes con dichas pasarelas, para no crear servidores en lenguajes distintos a MQL (seguramente no soy el único que no sabe programar en C, ¿verdad?) con ejemplos concretos en coautoría con un programador en C. Es decir, por mi parte el texto del artículo y ejemplos en MQL, y por parte del programador en C fuentes de pasarelas en C y EXE-shniki. La cuota es compartida.

 
Por cierto, los ejemplos muestran intercambio full-duplex, donde no necesitas esperar a nadie.

El servidor es simple, todo en fuentes, incluyendo el archivo exe compilado en el directorio /release. Las pruebas se pueden repetir fácilmente.
 
Renat:
Por cierto, los ejemplos muestran intercambio full-duplex, donde no tienes que esperar a nadie.

El servidor es simple, todo en fuentes, incluyendo el archivo exe compilado en el directorio /release. Las pruebas se pueden repetir fácilmente.

Ese no es el punto. He intentado ejecutar tu ejemplo. Funciona. Pero no sirve para nada, es decir, lo he probado y ya está, se puede borrar porque ya no es necesario.

Por un lado, te has librado de la dll, pero por otro, de nuevo, para el uso de la aplicación necesitas muletillas en otros lenguajes de programación.

La desventaja del método propuesto es que es adecuado sólo para los programadores que desarrollan aplicaciones en lenguajes distintos de MQL y que soportan la API de Windows. Es decir, el ejemplo propuesto no es universal y no se puede adaptar a otras tareas sin modificaciones. Y cada persona tiene tareas diferentes. Y esto significa que los usuarios tendrán que crear incluso un intercambio elemental de información entre dos secuencias de comandos para estudiar, además de MQL otro idioma, de modo que en él, crear un servidor en el que usted necesita para escribir parte de la lógica relacionada con el protocolo de intercambio.

Propongo crear pasarelas una vez, compilar y poner a cabo para todos los interesados, de modo que cualquier usuario puede crear conexiones, utilizando sólo herramientas estándar MQL.

Por ejemplo, para mí no hace ninguna diferencia si los archivos en bruto abiertos o cerrados están en C. Porque yo no escribo nada en C, y llevará tiempo resolver los vuelos. Ni siquiera puedo compilar estos mismos archivos en bruto. Y en Pure Java, así como en muchos otros lenguajes de programación, sólo se puede crear la conexión del cliente a través de flujos de archivos utilizando herramientas estándar. Si hubiera una pasarela que conectara dos canales con nombre al menos por simplex, no habría problemas. Escribiría el protocolo de intercambio en los clientes, conectaría a través de un par de pasarelas, depuraría y todo funcionaría. Es decir, no hace falta diseñar y crear un servidor distinto para cada tarea.

Y de momento, es decir, sin pasarelas, mucha gente tendrá que instalar un entorno de desarrollo para C, aprender un nuevo lenguaje de programación, etc., etc.

A la pasarela le importa un bledo: lo que recibe de un cliente lo envía a otro. La lógica es tonta, pero permite unir dos clientes sin muletas adicionales y baila con pandereta, es decir, es universal e independiente del protocolo de intercambio de información y del conocimiento del lenguaje C.

Aquí, como se suele decir, el alimentado no entiende al hambriento. Los que desarrollen algo en C probablemente no verán ningún problema. Y para el resto de nosotros, podemos tratar con este sistema como queramos.

1234567
Nuevo comentario