¿Quién ha probado ya la suscripción a Señales para ponerse a la cola de los participantes en el ATC 2012? - página 5
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
Piensa también en las lecheras.
Rent a Signal se desinfla...
¿Alguna idea de por qué?
Además, hay otras cuestiones que hay que resolver:
Simplificamos a propósito el sistema hasta reducirlo a una sola señal, deshaciéndonos de las peores consecuencias. Sobre todo teniendo en cuenta que la mayoría de las transacciones probablemente pasarán por el mecanismo Trusted Execution Token de los servidores en la nube, lo que reducirá el retraso de la copia de la señal a unos pocos milisegundos.
Un momento, ¿no has desarrollado la arquitectura? Ahora eres tú el que escribe sobre el lío de las posiciones y la intersección por símbolos.
Hay un mecanismo no comercial para replicar las operaciones, no tiene pérdida de conectividad, no hay problemas de sincronización después de una reconexión (imagínese 15 minutos o 2 horas de ausencia de conectividad) y se puede controlar estrechamente el 100% del tiempo. Además, existe MetaTrader 4 sin red.
Simplificamos a propósito el sistema hasta reducirlo a una sola señal, deshaciéndonos de las peores consecuencias. Sobre todo porque es probable que la mayoría de las transacciones pasen por el mecanismo Trusted Execution Token de los servidores en la nube, lo que reducirá la latencia de la copia de la señal a unos pocos milisegundos.
Hasta ahora no has presentado ninguna solución a los problemas, sino que te limitas a afirmar que "tienes poco que hacer, y en general la tarea es pan comido".
Piensa que llevamos mucho más tiempo devanándonos los sesos con el problema. Y no nos quedamos en el primer paso "bueno, sí, en teoría se puede hacer".
En realidad, la esencia de todos tus comentarios se reducía a "da y basta, es teóricamente posible, así que no lo niegues, y me da pereza ir más allá del primer paso de la elaboración".
Característicamente, todo el lenguaje constructivo de mi post anterior fue ignorado )
Lamentablemente, no hubo ninguna aportación constructiva por su parte. Sólo hubo "toma y daca" + declaraciones unidireccionales.
Es decir, no has descrito cómo resolver el conflicto de múltiples señales y no has dado respuesta a la pregunta de cómo recuperarse de una pérdida de conexión.
Además, no abordas en absoluto la responsabilidad de que los conflictos inminentes tiendan al 100% de probabilidad. No he señalado en vano la imposibilidad de la solución de "yo lo hago por mí, lo arreglo, no pasa nada" para el servicio de masas.
En cuanto al tema, puedo decir por experiencia propia que el problema es muy complejo y no se puede resolver con una simple réplica. Convencionalmente puede dividirse en tres componentes:
Todo esto es muy difícil de organizar en la práctica, y además requeriría una seria modificación de la arquitectura existente.
Espera un momento, ¿no diseñaste la arquitectura? Ahora tú mismo escribes sobre la superposición de posiciones y caracteres.
Veo que poca gente ha pensado realmente en la aplicación del procesamiento.
Aunque se puede entender la línea de pensamiento de la afirmación "Dame una solución, el comerciante lo necesita, almacena los estados en el servidor". Es comprensible: trasladar el máximo de problemas a otros, no molestar, y si algo sale mal - criticarles por la mala ejecución.
Pero si se evalúa el problema desde el lado del corredor, del proveedor del sistema, de la infraestructura de la red, y sólo entonces del comerciante, se verá que la solución propuesta de mezcla de señales no tiene una solución razonable y segura.
Por desgracia, no ha habido ninguna actitud constructiva. Sólo hubo "toma y daca" + declaraciones unidireccionales.
En otras palabras, no has descrito cómo resolver los conflictos de múltiples señales ni has respondido a la pregunta de cómo recuperarse de la pérdida de comunicación.
Además, no abordas en absoluto la responsabilidad de que los conflictos inminentes tiendan al 100% de probabilidad. No he señalado en vano la imposibilidad de la solución de "yo lo hago por mí, lo arreglo, no pasa nada" para el servicio de masas.
¿Y qué cree que pueden hacer los desarrolladores independientes? MT5 es rígidamente monolítica. Lo mejor que pueden hacer es crear otra muleta y describirla en el artículo correspondiente. No se puede escribir un sistema de calidad sin integrarlo en un producto. Conociendo el problema de primera mano, puedo decir que no se puede prescindir de guardar registros de estados en el lado del servidor. ¿Y cómo cree que los desarrolladores de terceros deberían resolver este problema? Al final, lo hacen lo mejor que pueden. Crean muletas y combinaciones de MQL5 <-> DLL <--> SQL, difíciles de mantener e inaplicables al mercado masivo, que tanto alabas.
Te equivocas.
MQL5 es tan abierto y funcional que se puede hacer casi todo. No es necesario hacer muletillas con DLL y SQL, basta con utilizar operaciones de archivo y almacenar todo lo que se necesite en el disco. La base de datos de las variables globales es muy estable y no se pierde durante los reinicios o las caídas.
Y el almacenamiento del estado en el servidor es medgies y comentarios. Aprende a utilizarlos con moderación.