Función OrderSendAsync() - página 8
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
Porque los paquetes rotos, las conexiones caídas, etc. son una mierda. Poco fiable. Poco fiable... hay que desconectar.
Por si acaso, mantendremos la cola de transacciones comerciales para emitirlas a los EAs y regalarlas.
Las desconexiones en la ejecución son un problema, aún no está claro cómo manejarlas. En cualquier caso, podremos comprobar todas las posiciones abiertas después de la reconexión.
Porque los paquetes rotos, las conexiones caídas, etc. son una mierda. Poco fiable. Poco fiable... tienes que recuperarte.
Mantengamos las moscas separadas y las chuletas separadas.
Los paquetes rotos son una situación anómala para el terminal y deben ser tratados por excepción, incluso mediante el análisis del historial.
Pero es demasiado caro analizar la historia de cada comercio. La llegada del comercio es una situación normal y debe ser manejada de manera económica.
Hola. ¿Sabes siquiera lo que es la asincronía?
Por lo que entiendo, al introducir esta función para los EAs multidivisa (para los EAs monodivisa la iniciativa no tiene sentido), el único objetivo es ahorrar tiempo evitando el retraso en la ejecución de la orden en el lado del servidor. Corríjanme si me equivoco.
Aparte de eso, sólo queda una porción de tiempo crítica: la transmisión de paquetes de datos por los canales de comunicación. Intentar llevar el "límite de lo desconocido" al nivel de "soltar (el paquete) y seguir", tiene más problemas que beneficios. Es importante evaluar el problema de forma global. Un posible tiempo de espera, si lo hubiera, es probable que afecte no sólo a la capacidad de operar con un instrumento concreto, sino también, en principio, a la falta de comunicación con el servidor.
Además, no está claro cómo estimar desde el Asesor Experto: ¿se perdió la orden comercial en la transmisión de datos, o está esperando su turno en el servidor durante tanto tiempo? Y eso significa que habrá errores con la duplicación de órdenes comerciales, lo que llevará a violaciones del MM y, en consecuencia, a un aumento de los riesgos. En mi opinión, cualquier comerciante profesional (Asesor Experto) debe asegurarse de que su orden de comercio es aceptada por el servidor. Además, para identificar claramente el estado de una determinada orden comercial (en la función OnTrade()), se necesita un valor único recibido del servidor para aplicarlo al procesamiento posterior (hasta que se ejecute la operación (abrir/cerrar una posición).
Es similar al modelo de red OSI. No necesitamos entrar en el canal o en la capa física de la ejecución de órdenes comerciales. Deje que el cliente (MT5) realice esta función de transporte. Operar en la capa de aplicación.
Ahorro de tiempo debido a que no hay retraso en la ejecución de la orden por parte del servidor. Corríjanme si me equivoco.
A costa de no esperar los resultados de la solicitud. En general, sí. Es decir, para las órdenes y la ejecución del mercado puede ser muy útil.
Aparte de esto, sólo queda un tramo de tiempo crítico: la transmisión del paquete de datos por los canales de comunicación. Intentar llevar el "límite de lo desconocido" al nivel de "soltar (el paquete) y seguir", tiene más problemas que beneficios.
Bueno... no. Sólo hay que utilizarla cuando los beneficios superan a los problemas.
En mi opinión, cualquier comerciante profesional (asesor) necesita asegurarse de que su orden de comercio es aceptada para su ejecución por el servidor.
Entonces la opción asíncrona no es adecuada para usted. Todo tiene solución.
TheXpert
Repasémoslo de nuevo, con los dedos. Estructurar a grandes rasgos los retrasos:
1. Es el momento de que el terminal compruebe previamente la orden comercial, la "empaquete" en el lote de salida y la ponga en la "cola de la red".
2. Hora de transmisión de un paquete de datos que contiene una orden de negociación del cliente al servidor.
3. Momento en que el servidor recibe una orden de negociación y la coloca en el conjunto de procesamiento y envía al cliente un identificador único de este ticket.
4. El tiempo de preprocesamiento de la corrección de la orden de negociación y su colocación en el parqué.
Si he indicado algo incorrecto, por favor corrija. ¿Entiendo que no quiere esperar después del primer punto? Yo, en cambio, defiendo la disponibilidad obligatoria de los tres primeros.
Hay que responder a dos preguntas para seguir debatiendo:
1. La relación proporcional de los retrasos. Es decir, en promedio, cuánto tiempo en términos porcentuales lleva cada uno de los cuatro puntos anteriores. Si la distribución es, por ejemplo, "0,5%-1,0%-1,0%-97,5%", no vale la pena.
2) El tiempo de espera y su impacto en la estrategia de negociación. Francamente, no puedo nombrar una sola ST que no requiera saber claramente si una orden ha sido enviada al servidor o no. Esto es relevante tanto para el arbitraje a largo plazo como para el arbitraje multidivisa. Es decir, no se puede cuestionar la garantía de ejecución de una orden comercial. Por favor, proporcione un contraejemplo si no está de acuerdo.
En mi opinión, la forma más fácil de resolver el problema de la ejecución en una pausa es no crear una cola de ejecución (cancelar la ejecución) y notificar al usuario de la cancelación en la reconexión. Así habrá menos ambigüedad.
Hay que devolver un ticket del servidor. Esto garantizará que el pedido llegue al servidor y sea aceptado para su procesamiento.
Construir grupos de espera astutos en el lado del cliente no es sólo una solución poco práctica, yo lo llamaría un grosero defecto de diseño en la arquitectura cliente-servidor de MT5.
Los engorrosos grupos de espera en el lado del cliente no son una solución elegante.
Esto es lo que se pidió. Nadie te obliga a usarla si no tienes que hacerlo.
TheXpert
Hagámoslo de nuevo, en los dedos. Estructurar a grandes rasgos los retrasos:
1. tiempo para que la terminal compruebe previamente la orden comercial, la "empaquete" en un paquete despachable y la ponga en la "cola de la red".
2. Tiempo de envío de un paquete de datos que contiene una orden de negociación desde el cliente al servidor.
Momento en el que el servidor recibe una orden comercial y la coloca en el conjunto de procesamiento y envía al cliente un identificador único de este ticket.
4. Tiempo de preprocesamiento de la corrección de la orden de negociación y su puesta en el parqué.
3 es mejor separar
3.1 colocación
3.2 envío de uid.
Si he indicado algo incorrecto, por favor corrija. ¿Entiendo que no quiere esperar después del primer artículo?
Sí.
Yo, en cambio, estoy a favor de que los tres primeros sean obligatorios.
¿Y si el ping es de medio segundo? Es asíncrono. ¿Qué sentido tiene utilizar este modo?
Esto es lo que se ha pedido. Nadie te obliga a usarla si no tienes que hacerlo.
Todavía no has respondido a mi pregunta. Por favor, dame un ejemplo concreto en qué casos se puede prescindir de la garantía de ejecución de las órdenes comerciales en aras de la rapidez de su envío a diferentes personajes.
Todavía no has respondido a mi pregunta. Por favor, dame un ejemplo concreto de cuándo se puede prescindir de las garantías de ejecución de las órdenes comerciales en aras de la rapidez de su envío a diferentes símbolos.
No hay problema: negociación de cartera + ejecución de mercado.