Solicitudes síncronas y asíncronas

Antes de entrar en detalles, recordemos que cada programa MQL se ejecuta en su propio hilo, y por lo tanto el procesamiento paralelo asíncrono de transacciones (y otros eventos) sólo es posible debido a que otro programa MQL lo estaría haciendo. Al mismo tiempo, es necesario garantizar el intercambio de información entre programas. Ya conocemos un par de formas de hacerlo: variables globales del terminal y archivos. En la Parte 7 del libro exploraremos otras características como recursos gráficos y bases de datos.

De hecho, imagine que un Asesor Experto similar a TradeTransactions.mq5 se ejecuta en paralelo con el Asesor Experto de trading y guarda las transacciones recibidas (no necesariamente todos los campos, sino sólo los selectivos que afectan a la toma de decisiones) en variables globales. A continuación, el Asesor Experto podría comprobar las variables globales inmediatamente después de enviar la siguiente solicitud y leer los resultados de los mismos sin salir de la función actual. Además, no necesita su propio manejador OnTradeTransaction.

Sin embargo, no es fácil organizar la ejecución de un Asesor Experto de terceros. Desde el punto de vista técnico, esto podría hacerse creando un objeto gráfico y aplicando una plantilla con un Asesor Experto de monitor de transacciones predefinido. Pero hay una manera más fácil. La cuestión es que los eventos de OnTradeTransaction se traducen no sólo en Asesor Experto, sino también en indicadores. A su vez, un indicador es el tipo de programa MQL más fácil de lanzar: basta con llamar a iCustom.

Además, el uso del indicador ofrece otra ventaja: puede describir el búfer del indicador disponible desde programas externos a través de CopyBuffer, y disponer en él un ring buffer para almacenar las transacciones procedentes del terminal (resultados de solicitudes). Por lo tanto, no hay necesidad de complicarlo con variables globales.

¡Atención! El evento OnTradeTransaction no se genera para los indicadores en el probador, por lo que sólo puede comprobar el funcionamiento del par Asesor Experto-indicador en línea.

Llamemos a este indicador TradeTransactionRelay.mq5 y describamos un búfer en él. Podría hacerse invisible porque escribirá datos que no pueden ser renderizados, pero lo dejamos visible para probar el concepto.

El manejador OnCalculate está vacío.

En el código, necesitamos un convertidor listo de double a ulong y viceversa, ya que las celdas del búfer pueden corromper valores ulong grandes si se escriben allí utilizando una conversión de tipos simple (véase Números reales).

Aquí está la función OnTradeTransaction.

Hemos decidido conservar únicamente los seis campos más importantes de la estructura MqlTradeResult. Si lo desea, puede ampliar el mecanismo a toda la estructura, pero para transferir el campo de cadena comment necesitará un array de caracteres para la que tendrá que reservar bastantes elementos.

Así, cada resultado ocupa ahora seis celdas de búfer consecutivas. El índice de la primera celda de estas seis se determina en función del ID de la solicitud: este número simplemente se multiplica por 6. Como puede haber muchas solicitudes, la entrada funciona según el principio de un búfer anular, es decir, el índice resultante se normaliza dividiendo con resto ('%') por el tamaño del búfer indicador, que es el número de barras redondeado a 6. Cuando los números de solicitud superen el tamaño, el registro irá en círculo a partir de los elementos iniciales.

Dado que la numeración de las barras se ve afectada por la formación de nuevas barras, se recomienda poner el indicador en marcos temporales grandes, como D1. Entonces, sólo al principio del día es probable (aunque bastante improbable) la situación en que la numeración de las barras en el indicador cambiará directamente durante el procesamiento de la siguiente transacción, y luego los resultados registrados por el indicador no serán leídos por el Asesor Experto (puede que una transacción se pase por alto).

El indicador está listo. Ahora vamos a empezar a aplicar una nueva modificación de la prueba Asesor Experto OrderSendTransaction3.mq5 (¡hurra!, esta es su última versión). Vamos a describir la variable handle para el controlador del indicador y a crear el indicador en OnInit.

Para leer los resultados de la consulta desde el búfer del indicador, vamos a preparar una función auxiliar AwaitAsync. Como primer parámetro, recibe una referencia a la estructura MqlTradeRequestSync. Si tiene éxito, los resultados obtenidos del búfer del indicador con handle se escribirán en esta estructura. El identificador de la solicitud que nos interesa ya debería estar en la estructura anidada, en el campo result.request_id. Por supuesto, aquí debemos leer los datos según el mismo principio, es decir, en seis barras.

Ahora que tenemos esta función, vamos a escribir un algoritmo de trading en un estilo asíncrono-síncrono: como una secuencia directa de pasos, cada uno de los cuales espera a que el anterior esté listo debido a las notificaciones del programa indicador paralelo mientras permanece dentro de una función.

Paso 1

Paso 2

Paso 3

Tenga en cuenta que las llamadas al método completed ahora no se realizan después de enviar la solicitud, sino después de que la función AwaitAsync reciba el resultado.

Por lo demás, todo es muy similar a la primera versión de este algoritmo, pero ahora se basa en llamadas a funciones asíncronas y reacciona a eventos asíncronos.

Probablemente no parezca significativo en este ejemplo concreto de una cadena de manipulaciones en una única posición. Sin embargo, podemos utilizar la misma técnica para enviar y controlar un lote de órdenes. Y entonces los beneficios serán evidentes. En un momento demostraremos esto con la ayuda de un Asesor Experto de cuadrícula y al mismo tiempo compararemos el rendimiento de dos funciones: OrderSend y OrderSendAsync.

Pero ahora mismo, mientras completamos la serie de Asesores expertos OrderSendTransaction, vamos a ejecutar la última versión y a ver en el registro de la ejecución regular y lineal de todos los pasos.

La sincronización con las demoras de la respuesta puede depender en gran medida del servidor, la hora del día y el símbolo. Por supuesto, parte del tiempo aquí no se dedica a una solicitud de operación con confirmación, sino a la ejecución de la función CopyBuffer. Según nuestras observaciones, no tarda más de 16 ms (dentro de un ciclo de un temporizador de sistema estándar, quienes lo deseen pueden perfilar programas que utilicen temporizadores de alta precisión GetMicrosecondCount).

Ignore la diferencia entre el estado (DONE) y la descripción de la cadena («Order placed»). El hecho es que el comentario (así como los campos ask/bid) permanece en la estructura desde el momento en que es enviado por la función OrderSendAsync, y el estado final en el campo retcode es escrito por nuestra función AwaitAsync. Para nosotros es importante que en la estructura con los resultados estén actualizados los números de los tickets (deal y order), el precio de ejercicio (price) y el volumen (volume).

Basándonos en el ejemplo anterior de OrderSendTransaction3.mq5, vamos a crear una nueva versión del Asesor Experto de cuadrícula PendingOrderGrid3.mq5 (la versión anterior se proporciona en la sección Funciones de lectura de propiedades de posición). Podrá establecer una cuadrícula completa de órdenes en modo síncrono o asíncrono, a elección del usuario. También detectaremos los tiempos de ajuste de la cuadrícula completa para comparar.

El modo se controla mediante la variable de entrada EnableAsyncSetup. Se asigna la variable handle para el manejador del indicador.

Durante la inicialización, en el caso del modo asíncrono, creamos una instancia del indicador TradeTransactionRelay.

Para simplificar la codificación, hemos sustituido el array bidimensional request por una unidimensional en la función SetupGrid.

Más adelante en el bucle a través del array, en lugar de llamadas del tipo request[i][1], utilizamos el direccionamiento request[i * 2 + 1].

Esta pequeña transformación era necesaria por las siguientes razones. Dado que utilizamos este array de estructuras para las consultas al crear la cuadrícula, y necesitamos esperar todos los resultados, la función AwaitAsync debería ahora tomar como primer parámetro una referencia a un array. Un array unidimensional es más fácil de manejar.

Para cada solicitud, su desplazamiento en el búfer indicador se calcula en función de su request_id: todos los desplazamientos se colocan en el array offset. A medida que se reciben confirmaciones de solicitudes, los elementos correspondientes del array se marcan como procesados escribiendo en ellos el valor -1. El número de solicitudes ejecutadas se cuenta en la variable done. Cuando es igual al tamaño del array, la cuadrícula entera está lista.

Volviendo a la función SetupGrid, vamos a ver cómo se llama a AwaitAsync después del bucle de envío de solicitudes.

Si se produce un tiempo de espera al configurar la cuadrícula (no todas las solicitudes recibirán confirmación dentro del tiempo asignado), devolveremos el código TRADE_RETCODE_ERROR, y el Asesor Experto intentará «deshacer» lo que consiguió crear.

Es importante tener en cuenta que el modo asíncrono sólo está pensado para configurar una cuadrícula completa cuando necesitamos enviar un lote de solicitudes. En caso contrario, se seguirá utilizando el modo síncrono. Por lo tanto, debemos poner la bandera MqlTradeRequestSync::AsyncEnabled a true antes del bucle de envío y volver a ponerla a false después. No obstante, preste atención a lo siguiente: pueden producirse errores dentro del bucle, debido a los cuales éste se termina prematuramente, devolviendo el último código del servidor. Por lo tanto, si colocamos un reset asíncrono después del bucle, no hay garantía de que se reinicie.

Para resolver este problema se añade una pequeña clase AsyncSwitcher al archivo MqlTradeSync.mqh. La clase controla la activación y desactivación del modo asíncrono desde su constructor y destructor. Esto se ajusta al concepto de gestión de recursos RAII que se expone en la sección Gestión de descriptores de archivos.

Ahora, para la activación temporal segura del modo asíncrono, podemos simplemente describir el objeto local AsyncSwitcher en la función SetupGrid. El código volverá automáticamente al modo síncrono al salir de la función.

El Asesor Experto está listo. Intentemos ejecutarlo dos veces: en modo síncrono y asíncrono para una cuadrícula suficientemente grande (10 niveles, paso de cuadrícula 200).

Para una cuadrícula de 10 niveles, obtendremos 20 consultas, por lo que a continuación se muestran algunos de los registros. En primer lugar, se ha utilizado un modo síncrono. Aclaremos que la inscripción sobre la disponibilidad de las solicitudes se muestra antes que los mensajes sobre las solicitudes porque estos últimos son generados por los destructores de la estructura cuando la función sale. La velocidad de procesamiento es de 51 ms por solicitud.

El centro de la cuadrícula coincidía con el precio de 1.10400. El sistema asigna números a las solicitudes en el orden en que se reciben, y su numeración en el array se corresponde con el orden en que cursamos las órdenes: desde el nivel base central, nos desviamos gradualmente hacia los lados. Por lo tanto, no se sorprenda de que después de un par de 1 y 2 (para el nivel 1.10200) viene 5 y 6 (1.10000), ya que 3 y 4 (1.10600) se enviaron antes.

En modo asíncrono, los destructores van precedidos de mensajes sobre la disponibilidad de determinadas solicitudes recibidas en AwaitAsync en tiempo real, y no necesariamente en el orden en que se enviaron las solicitudes (por ejemplo, las solicitudes 49 y 50 «adelantaron» a las 47 y 48).

Debido al hecho de que todas las solicitudes se ejecutaron en paralelo, el tiempo total de envío (234 ms) es sólo ligeramente superior al tiempo de una sola solicitud (aquí alrededor de 100 ms, pero usted tendrá su propio cronometraje). Como resultado, obtuvimos una velocidad de 11 ms por solicitud, que es 5 veces más rápida que con el método síncrono. Como las solicitudes se enviaron casi simultáneamente, no podemos saber el tiempo de ejecución de cada una, y los milisegundos indican la llegada del resultado de una solicitud concreta desde el momento del inicio general del envío en grupo.

Otros registros, como en el caso anterior, contienen todos los campos de consulta y resultado que se imprimen desde los destructores de estructuras. La línea «Order placed» no se modificó después de OrderSendAsync, ya que nuestro indicador auxiliar TradeTransactionRelay.mq5 no publica íntegramente la estructura MqlTradeResult del mensaje TRADE_TRANSACTION_REQUEST.

Hasta ahora, nuestro Asesor Experto de cuadrícula tenía un par de órdenes pendientes en cada nivel: Limit y Stop Limit. Para evitar esta duplicación, dejamos sólo las órdenes Limit. Esta será la versión final de PendingOrderGrid4.mq5, que también podrá ejecutarse en modo síncrono y asíncrono. No entraremos en detalle en el código fuente, sino que nos limitaremos a señalar las principales diferencias con respecto a la versión anterior.

En la función SetupGrid necesitamos un array de estructuras de tamaño igual a GridSize y no duplicado. El número de solicitudes también disminuirá 2 veces: los únicos métodos utilizados para ellas son buyLimit y sellLimit.

La función CheckGrid comprueba la integridad de la cuadrícula de una manera diferente. Anteriormente, la ausencia de una orden Stop Limit emparejada en el nivel en el que existe un límite se consideraba un error. Esto podía ocurrir cuando se activaba una orden Stop Limit en el servidor desde un nivel vecino. Sin embargo, este esquema no es capaz de restablecer la cuadrícula si se produce un fuerte movimiento bidireccional del precio (spike) en una barra: eliminará no sólo las órdenes Limit originales, sino también las nuevas generadas a partir de las Stop Limit. Ahora el algoritmo comprueba honestamente los niveles vacantes a ambos lados del precio actual y crea allí órdenes Limit utilizando RepairGridLevel. Esta función de ayuda coloca previamente órdenes Stop Limit.

Por último, el manejador OnTradeTransaction apareció en PendingOrderGrid4.mq5. La activación de una orden pendiente provocará la ejecución de una transacción (y un cambio en la configuración de la cuadrícula que debe corregirse), por lo que controlamos las transacciones por un símbolo y una magia determinados. Cuando se detecta una transacción, se llama instantáneamente a la función CheckGrid, además de que se sigue ejecutando al principio de cada barra.

Cabe señalar que la presencia de OnTradeTransaction no es suficiente para escribir Asesores Expertos que sean resistentes a influencias externas imprevistas. Por supuesto, los eventos le permiten responder rápidamente a la situación, pero no tenemos ninguna garantía de que el Asesor Experto no se apague (o se desconecte) por una razón u otra durante algún tiempo y se salte tal o cual transacción. Por lo tanto, el manejador OnTradeTransaction sólo debería ayudar a acelerar los procesos que el programa puede realizar sin él. En concreto, para restablecer correctamente su estado tras el arranque.

Sin embargo, además del evento OnTradeTransaction, MQL5 proporciona otro evento más sencillo: OnTrade.