Copiadora de transações/sinais altamente confiável (discussão ideológica e desenvolvimento) - página 7
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
OK. Então proponho tomar a conexão de soquete como um modelo de trabalho.
Схема работы синхронизатора:
- O servidor criará conexões de soquete permanentes com os clientes (a questão de atribuir a cada cliente seu próprio thread ainda está sendo considerada).
- o master-cliente envia o estado atual de suas ordens durante um evento comercial
- o servidor salva este arquivo e o envia a todos os outros clientes imediatamente (uma conexão socket já está estabelecida)
- o cliente recebe o arquivo e muda o estado do pedido de acordo com os dados recebidos
- O último arquivo salvo do assistente também é enviado para o cliente quando um novo cliente se conecta. (para sincronização inicial)
A principal vantagem deste sistema é a economia de tráfego:
- Não requer solicitações constantes do cliente. Ele os receberá do servidor sobre sua disponibilidade
- Da mesma forma, o master-cliente só enviará dados quando forem detectadas alterações
Proteção em caso de perda da conexão
- o cliente envia um pacote "Heartbeat" (por exemplo, 2 bytes) a cada 5 segundos para verificar a comunicação com o servidor
- O cliente reinicia a conexão se o pacote for enviado sem sucesso (sem resposta).
- servidor faz o mesmo. Se nenhuma resposta for recebida do cliente dentro de 10 segundos, a conexão do soquete é fechada.
Há alguma desvantagem nesta conexão?
- por exemplo, qual é o número máximo possível de conexões de tomadas disponíveis?
Proteção em caso de perda de conexão
- O cliente envia um pacote "Heartbeat" (por exemplo, 2 bytes) a cada 5 segundos para verificar a comunicação com o servidor
Isto nunca é feito quando a comunicação é feita através do protocolo de transporte TCP/IP porque a comunicação é mantida automaticamente na camada do soquete, ou seja, pelo sistema operacional. No caso de conexões quebradas, uma exceção é lançada sobre o cliente e seu manipulador tem que especificar o que exatamente precisa ser feito em tal caso. No que diz respeito ao servidor, isso não importa, porque se o cliente é desconectado, é problema do cliente.
- por exemplo, qual é o número máximo possível de conexões de tomadas disponíveis?
Se as conexões forem quebradas e uma exceção for aberta para o cliente, uma exceção deve ser aberta em seu manipulador
De que exceção você está falando?
Estou falando da WS2_32.dll. Tomadas normais de Berkeley (embora em variante assíncrona). Não vi aí nenhuma exceção. Você só pode detectar um acidente ao tentar enviar/receber.
quantas conexões de tomadas podem ser feitas nesta porta ?
De que exceção você está falando?
Bem, você só precisa de um porto.Estou falando da WS2_32.dll. Tomadas Berkeley comuns (embora em versão assíncrona). Não vi aí nenhuma exceção. Você só pode detectar um acidente ao tentar enviar/receber.
Estou interessado em quantas conexões de tomadas podem ser anexadas a esta porta ?
Há apenas uma conexão por porta. Para que o cliente possa se conectar, ele deve saber qual IP e número de porta é alocado no servidor. Alternativamente, você pode especificar um nome de domínio em vez de IP e o socket irá resolvê-lo para um endereço IP via DNS.
A tomada do servidor ouve este mesmo número de porta para conexão dos clientes. Quando o cliente se conectar, a tomada lhe dará outra porta da piscina de portas livres para mantê-la conectada. A porta persistente é então liberada novamente e escuta as conexões de outros clientes.
É assim que são feitas as conexões do protocolo de transporte TCP/IP. Tudo isso é feito na camada do soquete, ou seja, o protocolo não precisa ser programado - ele é padrão e já está ligado à biblioteca compartilhada no sistema operacional.
Quando um cliente se conecta, a tomada alocará outra porta do pool de portas livres para mantê-la permanentemente conectada.
Yuri, obrigado pelo básico, mas está fora de lugar. Você está dando o conhecimento errado.
E o alocado é um disparate, desculpe. Talvez você esteja aplicando conceitos portuários em duas hipostases diferentes, mas então é melhor trabalhar em conceitos aceitos.
algo pode vir a ser útil para o desenvolvimento
improvável. não-profissional.
E o destacado é um disparate, desculpe. Talvez você esteja aplicando conceitos portuários em duas formas diferentes, mas então é melhor trabalhar com conceitos aceitos.
Como eles dizem, é seu próprio problema como você aplica o conceito de porto. Expliquei apenas como as portas são utilizadas no protocolo TCP/IP. Mais uma vez, o protocolo é padrão, ou seja, eu não o inventei.
Não fui eu quem o inventou.
Boa sorte!
Qual é a ordem de tamanho da rede, quantos clientes devem ser 1000 mil, 100 mil, 10 mil, 1 mil?
Porque seu servidor realmente irá à falência com milhares de clientes.
Qual é a ordem de tamanho da rede, quantos clientes devem ser 1000 mil, 100 mil, 10 mil, 1 mil?
Porque seu servidor realmente irá à falência com milhares de clientes.
Esse é o ponto. Estou tentando pensar de forma abrangente. É claro que, inicialmente, você tem que colocar muita escalabilidade. Ou seja, o objetivo é fazer tanto quanto por 1.000h. E não importa que apenas algumas poucas pessoas o utilizem mais tarde.
É por isso que agora estou tentando escolher e me decidir - ou velocidade e microtráfico com tomadas. Ou http e muito tráfego em constante perseguição de clientes para uma nova porção de informação.