Copiador de transacciones/señales de alta fiabilidad (discusión y desarrollo de la ideología) - página 7
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
DE ACUERDO. Entonces propongo tomar la conexión de enchufes como modelo de trabajo.
Схема работы синхронизатора:
- El servidor creará conexiones de socket permanentes con los clientes (aún se está estudiando la cuestión de asignar a cada cliente su propio hilo).
- el cliente principal envía el estado actual de sus órdenes durante un evento comercial
- el servidor guarda este archivo y lo envía a todos los demás clientes inmediatamente (ya se ha establecido una conexión de socket)
- el cliente recibe el archivo y cambia el estado de la orden en función de los datos recibidos
- El último archivo guardado del asistente también se envía al cliente cuando se conecta un nuevo cliente. (para la sincronización inicial)
La principal ventaja de este sistema es el ahorro de tráfico:
- No requiere peticiones constantes por parte del cliente. Los recibirá del servidor en función de su disponibilidad
- Del mismo modo, el cliente maestro sólo enviará datos cuando se detecten cambios
Protección en caso de pérdida de conexión
- el cliente envía un paquete "Heartbeat" (por ejemplo, 2 bytes) cada 5 segundos para comprobar la comunicación con el servidor
- El cliente reinicia la conexión si el paquete se envía sin éxito (sin respuesta).
- servidor hace lo mismo. Si no se recibe ninguna respuesta del cliente en 10 segundos, la conexión del socket se cierra.
¿Existe alguna desventaja en esta conexión?
- Por ejemplo, ¿cuál es el número máximo posible de conexiones de socket disponibles?
Protección en caso de pérdida de conexión
- El cliente envía un paquete "Heartbeat" (por ejemplo, 2 bytes) cada 5 segundos para comprobar la comunicación con el servidor
Esto nunca se hace cuando se comunica a través del protocolo de transporte TCP/IP porque la comunicación se mantiene automáticamente en la capa de socket, es decir, por el sistema operativo. En caso de que se rompan las conexiones, se lanza una excepción en el cliente y su manejador tiene que especificar lo que hay que hacer exactamente en ese caso. En cuanto al servidor, le importa una mierda, porque si el cliente se desconecta, ya es problema del cliente.
- Por ejemplo, ¿cuál es el número máximo posible de conexiones de socket disponibles?
Si se rompen las conexiones y se lanza una excepción en el cliente, se debe lanzar una excepción en su manejador
¿A qué excepción se refiere?
Me refiero al WS2_32.dll. Los habituales sockets de Berkeley (aunque en su variante asíncrona). No he visto ninguna excepción. Sólo se puede detectar un fallo al intentar enviar/recibir.
¿cuántas conexiones de socket se pueden hacer en este puerto?
¿A qué excepción se refiere?
Bueno, sólo necesitas un puerto.Me refiero al WS2_32.dll. Los sockets ordinarios de Berkeley (aunque en versión asíncrona). No he visto ninguna excepción. Sólo se puede detectar un fallo al intentar enviar/recibir.
Me interesa saber cuántas conexiones de socket se pueden conectar a este puerto.
Sólo hay una conexión por puerto. Para que el cliente se conecte debe saber qué IP y número de puerto tiene asignado el servidor. Alternativamente, puedes especificar un nombre de dominio en lugar de la IP y el socket lo resolverá a una dirección IP vía DNS.
El socket del servidor escucha este mismo número de puerto para conectarse desde los clientes. Cuando el cliente se conecta, el socket le dará otro puerto del pool de puertos libres para mantenerlo conectado. A continuación, el puerto persistente se libera de nuevo y escucha las conexiones de otros clientes.
Así es como se realizan las conexiones del protocolo de transporte TCP/IP. Todo esto se hace en la capa de sockets, es decir, no es necesario programar el protocolo, ya que es estándar y ya está integrado en la biblioteca compartida del sistema operativo.
Cuando un cliente se conecta, el socket asignará otro puerto del pool de puertos libres al cliente para mantenerlo permanentemente conectado.
Yuri, gracias por lo básico, pero está fuera de lugar. Estás dando el conocimiento equivocado.
Y la asignada no tiene ningún sentido, lo siento. Tal vez esté aplicando conceptos portuarios en dos hipóstasis diferentes, pero entonces será mejor que trabaje en conceptos aceptados.
algo podría ser útil para el desarrollo
poco probable. poco profesional.
Y el resaltado es una tontería, lo siento. Tal vez esté aplicando conceptos portuarios en dos formas diferentes, pero entonces será mejor que trabaje en conceptos aceptados.
Como dicen, es tu problema cómo aplicas el concepto de puerto. Sólo he explicado cómo se utilizan los puertos en el protocolo TCP/IP. Una vez más, el protocolo es estándar, es decir, no lo he inventado yo.
No fui yo quien lo inventó.
Buena suerte.
¿Cuál es el orden del tamaño de la red, cuántos clientes se supone que son 1000-mil, 100-mil, 10-mil, 1-mil?
Porque tu servidor sí que va a quebrar con miles de clientes.
¿Cuál es el orden del tamaño de la red, cuántos clientes se supone que son 1000-mil, 100-mil, 10-mil, 1-mil?
Porque tu servidor sí que va a quebrar con miles de clientes.
Ese es el punto. Estoy tratando de pensar de manera integral. Por supuesto, al principio hay que poner mucha capacidad de ampliación. Es decir, el objetivo es hacer tanto como para 1.000h. Y no importa que sólo unas pocas personas lo utilicen después.
Por eso ahora estoy tratando de elegir y decidirme: o bien la velocidad y el microtráfico con enchufes. O http y mucho tráfico en la persecución constante de clientes para una nueva porción de información.