Copiador de transacciones/señales de alta fiabilidad (discusión y desarrollo de la ideología) - página 6
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
un esquema de intercambio simple: el generador de señales coloca un archivo en el servidor con todas sus órdenes y posiciones abiertas, como en el terminal. Si al menos una orden o posición ha cambiado, coloca un nuevo archivo. En este caso, el servidor envía una nueva versión del archivo (o un mensaje con el contenido completo del archivo), y el cliente responde que lo ha recibido (el servidor debe contener la lista de clientes conectados). El servidor también envía el archivo al cliente en cualquier momento.
Si el cliente se retrasa o pierde una orden, puede restablecerse fácilmente leyendo el archivo terminal del servidor. Si hay un intercambio comando por comando, puede haber muchos choques y ambigüedades. El cliente puede resincronizar para diagnosticar, por ejemplo, una vez por Xmin si no hubo cambios.
El tráfico no es alto con este esquema. Así que puedes usar SSL o https incluso.
Hay 3 tipos de mensajes: dar, recibir, archivo propio.
un esquema de intercambio simple: el generador de señales coloca un archivo en el servidor con todas sus órdenes y posiciones abiertas, como en el terminal. Si al menos una orden o posición ha cambiado, coloca un nuevo archivo. En este caso, el servidor enviará una nueva versión del archivo (o un mensaje con el contenido completo de este archivo). También envía este archivo en cualquier momento a petición del cliente.
Si el cliente se retrasa o pierde una orden, puede restablecerse fácilmente leyendo el archivo terminal del servidor. Si hay un intercambio comando por comando, puede haber muchos choques y ambigüedades. El cliente puede resincronizar para diagnosticar, por ejemplo, una vez por Xmin si no hubo cambios.
El tráfico no es alto con este esquema. Por lo tanto, puede usar SSL o https incluso.
El esquema es inútil, porque el archivo con la señal de comercio pierde su relevancia muy rápidamente, porque las operaciones tienen que ser ejecutadas a tiempo. La opción más rápida es que el cliente mantenga una conexión constante con el zócalo del servidor y espere a que aparezcan señales de negociación. Una conexión permanente no desperdicia tráfico, a diferencia de las solicitudes sistemáticas, y su fiabilidad es bastante alta.
Como he dicho antes, tampoco se necesitan comandos. En cuanto aparece una señal de negociación, el servidor la envía a los clientes como una sola línea con el símbolo de terminación "\n" y espera la siguiente. El cliente no tiene que enviar nada al servidor, sólo recibe señales.
SSL y https no es necesario en absoluto. En primer lugar, el propietario del servidor tendrá que registrar un dominio y comprar un certificado y luego tiene que prolongar todo esto también de forma no gratuita para poder trabajar con estos protocolos. Y en segundo lugar, estos protocolos son para el cifrado de datos, para interceptar la información en un flujo TCP no podría descifrar. La carga del servidor será enorme si tiene muchos clientes, porque la encriptación no es halam balam, sino la operación de elevar enteros grandes a potencias mayores modulo.
El esquema es inútil, porque el archivo de señales de negociación pierde rápidamente su relevancia, ya que las operaciones deben realizarse a tiempo. La opción más rápida es que el cliente mantenga una conexión constante con el zócalo del servidor y espere a que aparezcan las señales de negociación. Una conexión permanente no desperdicia tráfico, a diferencia de las solicitudes sistemáticas, y su fiabilidad es bastante alta.
Como he dicho antes, el cliente tampoco necesita ningún comando. Cuando aparece una señal de operación, el servidor la envía al cliente como una sola línea y espera la siguiente. El cliente no tiene que enviar nada al servidor, sólo recibir señales.
No hay retraso, porque se envía a todos los clientes inmediatamente después de que aparezca la señal.
La conexión comando por comando ciertamente ahorra tráfico, pero la fiabilidad será escasa. El cliente debe poder obtener todas las órdenes (por ejemplo, las órdenes pendientes o las modificaciones de órdenes) incluso las que se le hayan pasado por alguna razón.
No hay retraso porque el mensaje se envía inmediatamente a todos los clientes tras la aparición de la señal.
Equipo por equipo, por supuesto, ahorra tráfico, pero la fiabilidad será escasa. El cliente debe poder recuperar todas las órdenes (órdenes pendientes, por ejemplo, o modificaciones de órdenes), incluso las que se hayan perdido por alguna razón.
Bien, haz una joroba. Sólo que quien haga tales tonterías - no es mi problema.
Mi trabajo es ofrecer la mejor opción con el mínimo de carga y tráfico, usted tiene derecho a negarse.
SSL y https no son necesarios en absoluto. En primer lugar, el propietario del servidor debe registrar un dominio y comprar un certificado, y luego renovarlo permanentemente tampoco es gratuito, para trabajar con dichos protocolos. Y en segundo lugar, estos protocolos de encriptación de datos, para interceptar la información en un flujo TCP no podrían descifrarla. La carga del servidor será enorme si tiene muchos clientes, porque la encriptación no es halam balam, sino la operación de elevar enteros grandes a potencias superiores modulo.
Pero todas las señales de servidor no autenticadas existentes se descifran en un par de horas. Aunque la codificación puede ser innecesaria))
pero todas las señales de servidor existentes sin autenticación pueden ser descifradas en un par de horas. Sin embargo, el cifrado puede ser innecesario)).
1. No horas, sino milisegundos
2) ¿Quién demonios necesita que sus señales sean abiertas por otra persona? Anécdota sobre Elusive Joe.
Muy bien, haz un jorobado. Pero quién va a hacer esas tonterías ya no es mi problema.
Mi trabajo es ofrecer la mejor opción con un mínimo de carga y tráfico, usted tiene derecho a negarse.
1. No horas, milisegundos.
2) ¿Quién coño necesita que se tapen sus señales? Anécdota sobre Elusive Joe.
Me importa una mierda, pero la gente que vende señales por dinero se molesta)) Pero si no es importante en este proyecto - no hay problema, no hay necesidad de protección
Si el cliente ha perdido la conexión, o se ha reiniciado, y mientras tanto han pasado algunas órdenes pendientes o modificaciones de órdenes, ¿cómo solucionarlo con el intercambio de comandos telnet? No sé, tal vez puedas - por eso te lo pregunto.
Ya te he dicho que no necesitas un comando telnet, pero vuelves a decir tonterías.
Deberías duplicar los archivos y subirlos a algún hosting barato usando SendFTP(). Y que el cliente lea los archivos por FTP con la hora de creación cuando estaba fuera de contacto.
Ya te he dicho que no necesitas un comando telnet, pero vuelves a decir tonterías.
Deberías duplicar los archivos y subirlos a algún hosting barato usando SendFTP(). Y dejar que el cliente lea los archivos a través de FTP con el tiempo de creación que estaba fuera de conexión.
Es decir, no es tuyo))
Reshetov:
Protocolo de socket sobre TCP/IP. Puede transmitir señales en forma de texto en una línea por señal, como "EURUSD Comprar 1,0\n", como a través de Telnet, porque es la versión más primitiva que no requiere un procedimiento de intercambio complejo, como en los protocolos http o ftp con un mínimo de análisis sintáctico.
Vuelves a decir tonterías: duplicar uno con otro cuando se puede hacer con uno)). ¿Por qué molestarse en almacenar archivos, cuando basta con uno, el último con el estado actual de todas las órdenes y posiciones? Combinar el intercambio a demanda del servidor (cuando algo ha cambiado en la cuenta principal) y a demanda del cliente (cuando tenía problemas o incoherencias), y no salir con muletas adicionales. Puede enviar no todo el archivo de la orden a petición del servidor, sino sólo lo que ha cambiado y será su versión de "intercambio de órdenes".