Copiador de transacciones/señales de alta fiabilidad (discusión y desarrollo de la ideología)
Bien. Para empezar, tenemos que dividir las tareas(tipo de experto) en variante comercial (a través de la red), y condicionalmente no comercial (dentro del mismo sistema de OP).
Variante de la red - de forma inequívoca a través de un servidor adicional, para la seguridad y la gestión de los clientes.
Comunicación intra-sistema: mapeo, por su velocidad y fiabilidad.
Dado que el terminal mantendrá la libc hasta que se caiga o se cierre, será una indicación del estado de la propia MT (esclava).
Y el protocolo será algo así:
El maestro crea un mappu con nombre (cuyo nombre es conocido por todos los esclavos), y espera a que éstos den la señal para iniciar la ruta que será el manejador de la ventana del asesor (esclavo).
Después de intercambiar las señales, se crea otra en la que se pasan las señales de negociación y al mismo tiempo hay una orden para que cada esclavo actualice la ventana.
Una vez ejecutada la señal, el esclavo debe informar sobre su ejecución o se considerará congelado y se tomarán medidas para sacarlo a flote.
Si el esclavo se ha descargado (correctamente), debería informar.
A su vez, cualquiera de los esclavos puede supervisar el estado del maestro y tomar las medidas necesarias para levantarlo, o emitir una alarma.
En general, lo mismo.
Para la comunicación en red, véase más adelante.
Hacer una versión comercial y empujarla.
¿Me estás hablando a mí?
Una vez ejecutada la señal, el esclavo debe informar de la ejecución, o se considera que está congelada y se toman medidas para levantarla.
Si está descargado (correctamente), el esclavo debería informarlo.
Estas líneas me recuerdan la necesidad de discutir dos modos de funcionamiento
sincronización de órdenes en el nivel de órdenes maestro->cliente. Y la sincronización de señales a nivel maestro->cliente (¿necesitamos una base de datos de señales, acuse de recibo del cliente, etc.)
Creo que también deberíamos decidir qué sería más fiable y menos complicado en términos de sincronización y pérdida de señales.
Hacer una versión comercial y empujarla.
No quiero presionar nada y no lo haré. Estoy haciendo un medio, no un fin. Lo hago para todos.
estas líneas me recordaron la necesidad de discutir dos modos de funcionamiento
Sincronización de órdenes en el nivel de órdenes maestro->cliente. Y la sincronización de la señal en el nivel señal del maestro->señal del cliente (es necesario en una base de datos de señales, la confirmación de la recepción del cliente, etc.)
Creo que también deberíamos decidir qué sería más fiable y menos complicado en términos de sincronización y pérdida de señales.
No es necesario complicar las cosas, basta con enviar una señal de control al cliente en un determinado intervalo (digamos, una vez por segundo), y si no respondió, entonces actuar.
No quiero presionar nada y no lo haré. Yo hago los medios, no el fin. Lo hago para todos.
Respeto a la gente así, ¡¡¡sigue así!!!
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Usted acepta la política del sitio web y las condiciones de uso
- localmente
- a distancia
Estamos planeando hacer todo a la vez en un modo de un servidor - muchos clientes.
Habrá que prestar atención a aspectos como
- la opción de enlace (archivos, memoria para uno local; sockets, http, servidor intermedio, etc. para uno remoto)
- no hay carga en el canal de comunicación (especialmente en el caso de la sincronización remota)
- seguridad contra fallos (restablecimiento del canal en caso de pérdida)
- Reinicialización del propio Asesor Experto en caso de fallo del terminal/OS
- No se duplican/no se borran los tratos si se pierde/se restablece la conexión
etc.
También hay que tener en cuenta dos ideologías
- sincronización en el nivel de disponibilidad de los pedidos
- sincronización a nivel de envío de señales de apertura/cierre de órdenes
describir las ventajas e inconvenientes de esta variante para cada una de nuestras propuestas.
Me gustaría que el debate nos ayudara a encontrar la mejor solución para la fiabilidad/simplicidad del sistema.
Yo haré la codificación y las pruebas.
Los resultados pueden publicarse en codebase previo acuerdo.