Función OrderSendAsync() - página 3

[Yedelkin]

Mensaje técnico. Reunir declaraciones interesantes en un tema.

sergeev:

Yedelkin:
¿Qué propiedad de la cuenta será responsable del límite de órdenes simultáneas en la cola de ejecución? ¿Será posible averiguar esta cifra de forma programada?

el resultado de la función OrderSendAsync = false será simplemente

utilícelo como guía

[Mykola Demko]

Rosh:

Releí el hilo con interés, e incluso lo probé en la práctica, y aquí descubrí la flagrante discriminación del trading automático.

Este es el registro del cierre manual de posiciones: (cronología comprensible de abajo a arriba)

2012.04.26 22:32:05     Trades  '686934': deal #9256820 sell 0.02 EURUSD at 1.32391 done (based on order #10091825)
2012.04.26 22:32:05     Trades  '686934': order #10091825 sell 0.02 / 0.02 EURUSD at 1.32391 done
2012.04.26 22:32:05     Trades  '686934': accepted instant sell 0.02 EURUSD at 1.32391
2012.04.26 22:32:04     Trades  '686934': instant sell 0.02 EURUSD at 1.32391

Lo que vemos aquí: se envía la orden, se acepta la orden, se asigna un ticket a la orden, y finalmente se ejecuta la orden (puede haber algunos cambios de interpretación, pero eso es todo). Todo es clásico.

Lo único extraño es que el evento Trades sabe a ciencia cierta (dentro del terminal) por qué categoría se disparó, así como por qué orden (para las dos últimas categorías); de lo contrario sería imposible emitir ese comentario, y el programador tendría que reinventar la rueda para obtener esta información. Y la situación con la función OrderSendAsync no añadía ninguna simplicidad.

Sin embargo, hay que señalar que la velocidad de ejecución de las órdenes ha aumentado. Ahora no tenemos tiempo de darnos cuenta de que la orden se ha puesto en la cola, y ya se ha ejecutado.

---

Así que tenemos un paquete de órdenes, cada una de las cuales viene teóricamente 4 Trades, en cada uno de los Trades necesitaríamos controlar cada orden.

Así, tenemos 4*Número_de_pedido*Número_de_pedido puntos de control, es decir, tenemos 400 para 10 pedidos y 40000 para 100. Y Dios no lo quiera, cualquier orden tendría menos cantidad de Operaciones que 4, entonces toda la lógica de control se colapsa, ya que la espera antes de enviar una segunda orden (si la primera solicitud no se ejecuta) tiene lugar exactamente en el número 4.

[Andrey Dik]

Has enviado una pila de órdenes comerciales al servidor.

Para cada orden, ¿es necesario llevar un control de ejecución por separado? ¿Y cuánto tiempo hay que esperar para una respuesta?

[---]

joo:

¿Hay que controlar cada pedido por separado?

Sí

¿Y cuánto tiempo tengo que esperar para recibir una respuesta?

Varía de un corredor a otro. Si se trata de STP, es más bien una cuestión de su proveedor de liquidez.

[Mykola Demko]

sergeev:

sí

No tienen la misma función para diferentes corredores. Si se trata de STP, entonces es más bien una cuestión para su proveedor de liquidez.

No, todo se adivina por los posos del café. Cuando abres la ventana manualmente, pulsas comprar, esperas una recotización o ejecución, pulsas ok y ya está.

Cuando se abre en modo automático, también debe haber un punto de referencia, desde el que hay que enviar una segunda solicitud o todo está bien.

SZS ha añadido al post anterior, releer.

[---]

Urain:

No, todo son conjeturas, cuando abres manualmente una ventana, pulsas comprar, esperas una recotización o ejecución, pulsas ok y listo.

No. Este es el caso cuando el código de retorno es DONE(10009).

Pero hay corredores que pasan su operación al proveedor. Y en este caso le devolverán inmediatamente PLACED(10008). Y por cierto, si era una orden de mercado, en esta respuesta no habrá ningún ticket de trato, sólo el ticket de la orden.

Y ni siquiera habrá un ticket para el pedido en caso de OrderSendAsync.

En el modo automático, así debe ser el punto de referencia, desde el que se quiere enviar una segunda petición, o todo está bien.

Bueno, ¿cuál es el punto de referencia en requotes incluso en MT4? No hará un bucle interminable y esperará a que se borre o se abra una orden.

Todo es ticketype, con controles de estados guardados, etc.

[Yedelkin]

He intentado ejecutar la función OrderSendAsync()

//+------------------------------------------------------------------+
//|                                               OrderSendAsync.mq5 |
//+------------------------------------------------------------------+
MqlTradeResult  res={0};
MqlTradeRequest req={0};
//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart()
  {
   req.action=TRADE_ACTION_PENDING;
   req.symbol=_Symbol;
   req.volume=1.0;
   req.price=3.0;
   req.type=ORDER_TYPE_BUY_STOP;
   req.type_filling=ORDER_FILLING_RETURN;
   switch(OrderSendAsync(req,res))
     {
      case  true:
         Print("retcode=",res.retcode,", order=",res.order,", deal=",res.deal);
         break;
      default: Print("Неудача при отправке запроса функцией OrderSendAsync()");
     }
  }

Respondió con

2012.05.02 21:12:33 OrderSendAsync (USDCHF,M1) retcode=10008, order=0, deal=0

Surge una pregunta rápida: ¿cómo pensamos rastrear el destino de una solicitud de operación cuando se envía mediante la función OrderSendAsync(), si ni siquiera conocemos el ticket de la orden? El comentario debe ser rellenado por el corredor.

[Renat Fatkhullin]

El modo asíncrono está diseñado para la entrada de pedidos por lotes, pero no para una sola transacción. Para una sola transacción es mejor utilizar el modo síncrono - todo se ejecutará a la misma velocidad, y con un servicio completo.

Seguimiento de la ejecución de las transacciones asíncronas en OnTrade. Sí, es un camino más complicado, pero ese es el precio de la asincronía.

[Yedelkin]

Renat:
El modo asíncrono está diseñado para la entrada de pedidos por lotes, pero no para una sola transacción. Para una sola transacción es mejor utilizar el modo síncrono: todo se ejecutará a la misma velocidad y con un servicio completo.

Seguimiento de la ejecución de las transacciones asíncronas en OnTrade. Sí, es una forma más complicada, pero ese es el precio de la asincronía.

Bien, permítanme aclarar una pregunta: ¿cómo va a seguir alguien el destino de quinientas solicitudes de comercio en un envío masivo de órdenes por lotes? Dado que cualquier envío masivo de pedidos por lotes se compone de un gran número de transacciones individuales, ¿utilizarán todos el principio de comparar el estado anterior y el actual del historial? ¿No hay otros enfoques?

[Renat Fatkhullin]

La raíz del entendimiento es que los procesos asíncronos
1) no garantiza la puntualidad o incluso la disponibilidad de la respuesta
2) requiere claramente colas de operaciones separadas por parte del promotor

En otras palabras, tenemos que generar una lista de órdenes y luego comprobarlas y llenarlas dentro de OnTrade. Esto, por supuesto, es insoportable.

Por nuestra parte, podríamos mantener de forma transparente colas asíncronas, llenarlas de respuestas y proporcionar a los operadores funciones convenientes para comprobar y recuperar las entradas procesadas de la cola. Puede comprobar las colas de forma asíncrona en OnTrade o de forma sincrónica mediante un sondeo en el bucle justo después de enviar un lote de órdenes.

Pensaremos en un mecanismo de este tipo: facilitaría la vida de los desarrolladores de EA al liberarlos de su rutina.