Copiador de transacciones/señales de alta fiabilidad (discusión y desarrollo de la ideología) - página 2

 
Integer:
Ya se ha pensado en todo, pero lo siento, no es desagradable.

Dima, lo sé, por supuesto, yo también tengo todo inventado y hecho, tanto a nivel local como a distancia en diferentes formas.

Pero sólo quiero discutir este tema tan manido, que, en mi opinión, no se ha planteado aquí en absoluto en este contexto.


Si tienes algo que decir sobre el tema, habla.

 

El cliente copia sus parámetros y crea una orden con un magik igual al billete original. de esta manera nos saltamos la doble configuración.

Después el cliente debe comprobar el estado de la orden e informar de la ejecución (si hay algo que ejecutar), o de su vivacidad si la petición es un control.

 
sergeev:

Al principio, todo se reduce al propio sistema de correo. Un servidor, muchos clientes. Si el sistema funciona, puedes cargar el resto en este esqueleto.

Cuando el cliente se conecta, envía una solicitud de conexión, el servidor devuelve una firma en un mensaje especial, mediante la cual controlará las respuestas. La firma no es válida hasta que el cliente no la devuelva con un mensaje especial. Cuando todo está en orden es posible empezar a comunicarse.

Así que tiene firmas de cada cliente emitidas por el servidor (por lo tanto, no repetidas). El servidor envía mensajes con números de contador (también debería almacenar el registro de mensajes a cierta profundidad por si alguno de los clientes necesita repetirlo), los clientes reciben el mensaje numerado y envían una copia firmada al servidor. De este modo, el servidor sabe qué cliente ha perdido el mensaje y puede reenviarlo. Después de x repeticiones, el servidor deja de enviar este mensaje, cierra la sesión con este cliente y comienza a esperar que el cliente solicite una nueva sesión.

 
Para qué tomarse tantas molestias, la clave variable se puede poner en el propio mensaje.
 
FAQ:

El cliente copia sus parámetros y crea una orden con un magik igual al billete original. de esta manera nos saltamos la doble configuración.

Vale. Un esquema clásico.

Después el cliente debe comprobar el estado de la orden e informar de la ejecución (si hay algo que ejecutar), o de su vivacidad si la petición es un control.

¿Y qué sentido tiene hacer esto? El servidor sigue sin poder afectar al cliente de ninguna manera.
 
FAQ:
Por qué esas complicaciones, la clave variable puede ponerse en el propio mensaje.
¿Entonces el servidor tiene que enviar las claves todo el tiempo? Esto aumentará el tráfico, pero ¿qué pasa con el tráfico, dónde está la garantía de que el mensaje será recibido? y eso significa que el lado del servidor necesitará el registro de claves variables para cada mensaje, el programador puede confundirse con todo esto.
 
Urain:

Al principio, todo se reduce al propio sistema de correo.
Aquí es donde la codificación es esencial; cuando el cliente se conecta, envía una solicitud de conexión

Pero, por favor, dinos qué tecnología se utiliza para enviar y recibir. ¿Dónde almacena el servidor los datos?

Creo que es un poco difícil utilizar las firmas. Basta con tener un nombre de usuario/contraseña del cliente, emitido una vez y comprobado durante las solicitudes.
 
sergeev:

OK. Esquema clásico.

¿Por qué hacer esto? El servidor no puede afectar al cliente de todos modos.

¿Por qué no? Puede. Reinicia la exp, la terminal. No hay problema.
 
sergeev:
Por favor, dígame qué tecnología se utiliza para enviar y recibir los datos y dónde los almacena el servidor.

No creo que sea fácil con las firmas. Es suficiente con tener un nombre de usuario/contraseña
El servidor envía los datos al servidor ftp y los clientes los obtienen de allí.
 
Urain:
¿dónde está la garantía de que el mensaje será recibido?
Una pregunta importante que se desprende de la respuesta es ¿qué método se utiliza para intercambiar datos?
Razón de la queja: