Infraestructura, nube y rendimiento

No necesariamente. cTrader permite ejecutar cBots en la nube las 24 horas sin un VPS administrado por el usuario. Sin embargo, los cBots en la nube tienen restricciones técnicas: no admiten solicitudes HTTP y WebSocketClient solo funciona por el puerto 25345.

Registra marcas de tiempo para la señal o alerta, la recepción del webhook, el envío del conector, la solicitud a cTrader, la confirmación y la ejecución del bróker. Informa de la mediana y las latencias extremas, no solo del mejor valor.

La latencia del conector comprende la recepción, validación y reenvío de la señal. La latencia de ejecución del bróker aparece después de que la solicitud de trading alcance la parte de ejecución. Mídelas por separado.

La Open API permite que una aplicación externa acceda a cuentas y operaciones de cTrader; un cBot se ejecuta dentro de cTrader Algo. La autenticación, el alojamiento, las restricciones de la nube y la complejidad operativa determinan la mejor arquitectura.

cTrader Cloud ejecuta los cBots en Linux. Según la documentación oficial, las solicitudes HTTP no se envían en la nube y WebSocketClient solo funciona por el puerto 25345. Las dependencias exclusivas de Windows tampoco funcionan.

Elige entre PC local, VPS, cTrader Cloud y conector gestionado según la disponibilidad, el mantenimiento, las necesidades de integración y las restricciones técnicas. Resuelven partes diferentes del problema de alojamiento.

Utiliza una cuenta demo de cTrader y prueba deliberadamente rutas de éxito y error: entradas, salidas, entregas duplicadas, mensajes incorrectos, asignación de símbolos, mercados cerrados, desconexiones, SL/TP y recuperación tras reinicios.

Un registro de auditoría debe reconstruir una señal desde la activación en TradingView hasta el resultado final del bróker: ID, marcas de tiempo, comando normalizado, cuenta y símbolo de destino, validación, envío, resultado de cTrader y eventos de duplicado o reintento, sin guardar secretos.

Los backtests usan el emulador de bróker de TradingView y datos históricos de velas. Las órdenes en vivo de cTrader se enfrentan a precios bid/ask reales, spread, latencia, slippage, horarios de mercado y ejecución del bróker. No debe suponerse una igualdad exacta de precios.

El slippage es la diferencia entre el precio de ejecución esperado o de referencia y el precio obtenido realmente. Puede ser positivo o negativo y cobra especial importancia en órdenes de mercado, mercados rápidos y sistemas sensibles a la latencia.

Reintenta solo errores probablemente transitorios y mediante una política limitada y segura frente a duplicados. Los fallos de conexión o servicio temporal pueden justificarlo; un volumen o protección no válidos y un margen insuficiente suelen exigir cambiar la solicitud o el estado de la cuenta.

No reenvíes sin cambios rechazos deterministas como BadVolume, UnknownSymbol o InvalidStopLossTakeProfit. Repetir una solicitud inválida añade carga y puede causar un comportamiento imprevisible si las condiciones de la cuenta cambian después.

La lógica debe detectar la desconexión, detener envíos inseguros, restaurar autenticación y sesión, conciliar órdenes y posiciones abiertas y solo entonces reanudar comandos nuevos. Para Open API, cTrader recomienda heartbeats al menos cada diez segundos.

El mantenimiento necesita una política definida de recepción y ejecución: drenar o pausar, guardar de forma duradera los comandos aceptados, detenerse en un límite seguro, conciliar tras reiniciar y mantener los reintentos idempotentes.

Una página de estado debe separar la salud pública del servicio del estado privado de la cuenta. Muestra públicamente incidentes de webhook, enrutamiento o plataforma y, de forma privada, la conexión a cTrader y la ejecución de señales del usuario.

Las notificaciones de fallo deben ser accionables: ID de señal, símbolo, alias de cuenta, etapa, error exacto, hora y siguiente comprobación. Evita ruido por duplicados ignorados intencionadamente o estados transitorios ya recuperados.