Copiadora de transações/sinais altamente confiável (discussão ideológica e desenvolvimento) - página 6
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
um esquema de troca simples: o gerador de sinais coloca um arquivo no servidor com todas as suas ordens e posições abertas, como no terminal. Se pelo menos um pedido ou posição tiver mudado, ele coloca um novo arquivo. Neste caso, o servidor envia uma nova versão do arquivo (ou uma mensagem com o conteúdo completo do arquivo), e o cliente responde que o recebeu (o servidor deve conter a lista de clientes conectados). O servidor também envia o arquivo para o cliente a qualquer momento.
Se o cliente for pego ou perder um pedido, ele pode facilmente se recuperar lendo o arquivo terminal do servidor. Se houver uma troca comando por comando, pode haver muitos acidentes e ambigüidades. O cliente pode ressincronizar para diagnóstico, por exemplo, uma vez por Xmin, se não houve mudança.
O tráfego não é elevado com este esquema. Assim você pode usar SSL ou https até mesmo.
Existem 3 tipos de mensagens: dar, receber, arquivar por si só.
um esquema de troca simples: o gerador de sinais coloca um arquivo no servidor com todas as suas ordens e posições abertas, como no terminal. Se pelo menos um pedido ou posição tiver mudado, ele coloca um novo arquivo. Neste caso, o servidor enviará uma nova versão do arquivo (ou uma mensagem com o conteúdo completo deste arquivo). Ele também envia este arquivo a qualquer momento, a pedido do cliente.
Se o cliente for pego ou perder um pedido, ele pode facilmente se recuperar lendo o arquivo terminal do servidor. Se houver uma troca comando por comando, pode haver muitos acidentes e ambigüidades. O cliente pode ressincronizar para diagnóstico, por exemplo, uma vez por Xmin, se não houve mudança.
O tráfego não é elevado com este esquema. Portanto, você pode usar SSL ou https até mesmo.
O esquema é inútil, pois o arquivo com o sinal comercial perde sua relevância muito rapidamente, pois as negociações têm de ser executadas a tempo. A opção mais rápida é que o cliente mantenha uma conexão constante com a tomada do servidor e aguarde o aparecimento de sinais comerciais. Uma conexão permanente não desperdiça o tráfego ao contrário dos pedidos sistemáticos e sua confiabilidade é bastante alta.
Como eu disse antes, também não são necessários comandos. Assim que um sinal comercial aparece, o servidor o envia para os clientes como uma única linha com o símbolo de terminação "\n" e espera pelo próximo. O cliente não tem que enviar nada para o servidor, ele apenas recebe sinais.
SSL e https não é de todo necessário. Primeiro, o proprietário do servidor terá que registrar um domínio e comprar um certificado e depois ele terá que prolongar tudo isso também não de graça para poder trabalhar com esses protocolos. E, em segundo lugar, estes protocolos são para criptografia de dados, para interceptar informações em um fluxo TCP que não poderiam ser decifradas. A carga no servidor será enorme se ele tiver muitos clientes, pois a criptografia não é halam balam, mas a operação de elevar grandes números inteiros a potências superiores modulo.
O esquema é inútil, pois o arquivo de sinais comerciais perde rapidamente sua relevância, já que as negociações precisam ser feitas a tempo. A opção mais rápida é que o cliente mantenha uma conexão constante com a tomada do servidor e aguarde o aparecimento dos sinais comerciais. Uma conexão permanente não desperdiça o tráfego, ao contrário dos pedidos sistemáticos, e sua confiabilidade é bastante alta.
Como disse antes, o cliente também não precisa de nenhum comando. Quando um sinal comercial aparece, o servidor o envia aos clientes como uma única linha e espera pela próxima. O cliente não tem que enviar nada para o servidor, apenas receber sinais.
Não há atraso, pois é enviado a todos os clientes imediatamente após o sinal aparecer.
A conexão comando a comando certamente economiza tráfego, mas a confiabilidade será ruim. O cliente deve ser capaz de obter todas as ordens (por exemplo, ordens pendentes ou modificações de ordens) mesmo que ele tenha perdido por algum motivo.
Não há atraso porque a mensagem é enviada imediatamente a todos os clientes depois que o sinal aparece.
Equipe por equipe, é claro, economiza tráfego, mas a confiabilidade será fraca. O cliente deve ser capaz de recuperar todos os pedidos (pedidos pendentes, por exemplo, ou modificações de pedidos), mesmo aqueles não atendidos por algum motivo.
Ok, faça uma corcunda. Só quem vai fazer tal bobagem - não é problema meu.
Meu trabalho é oferecer a melhor opção com o mínimo de carga e tráfego, você tem o direito de recusar.
SSL e https não são de forma alguma necessários. Em primeiro lugar, o proprietário do servidor deve registrar um domínio e comprar um certificado, e depois renová-lo permanentemente também não é de graça, para trabalhar com tais protocolos. E, em segundo lugar, estes protocolos de criptografia de dados, para interceptar informações em um fluxo TCP, não poderiam decifrá-las. A carga no servidor será enorme se ele tiver muitos clientes, pois a criptografia não é halam balam, mas a operação de elevar grandes números inteiros a potências superiores modulo.
Mas todos os sinais de servidor não autenticados existentes são quebrados em algumas horas. Embora a criptografia possa ser desnecessária))
Mas todos os sinais de servidor existentes sem autenticação são quebrados em algumas horas. A encriptação pode ser desnecessária)).
1. Não horas, mas milissegundos
2) Quem diabos precisa que seus sinais sejam abertos por outra pessoa? Anedota sobre o Elusive Joe.
Muito bem, faça uma corcunda. Mas quem vai fazer tal bobagem não é mais problema meu.
Meu trabalho é oferecer a melhor opção com o mínimo de carga e tráfego, você tem o direito de recusar.
1. Não horas, milissegundos.
2) Quem, porra, precisa de seus sinais para ser encoberto? Anedota sobre o Elusive Joe.
Eu não quero saber, mas as pessoas que vendem sinais por dinheiro ficam chateadas)) Mas se não for importante neste projeto - não há problema, não há necessidade de proteção
Se o cliente perdeu a conexão, ou reinicializou, e enquanto isso algumas ordens pendentes ou modificações de ordens passaram, como consertá-la com a troca de comandos telnet? Eu não sei, talvez você possa - é por isso que estou perguntando.
Eu já lhe disse que você não precisa de um telnet de comando, mas você está falando bobagens novamente.
Você deve duplicar os arquivos e carregá-los para alguma hospedagem barata usando o SendFTP(). E deixar o cliente ler os arquivos por FTP com o tempo de criação quando ele estava fora de contato.
Eu já lhe disse que você não precisa de um telnet de comando, mas você está falando bobagens novamente.
Você deve duplicar os arquivos e carregá-los para alguma hospedagem barata usando o SendFTP(). E deixar o cliente ler os arquivos via FTP com o tempo de criação fora de conexão.
Isto é, não é seu))
Reshetov:
Soquete sobre protocolo TCP/IP. Você pode transmitir sinais em forma de texto em uma linha por sinal, tais como "EURUSD Buy 1.0\n", como via Telnet, porque é a versão mais primitiva que não requer um procedimento de troca complexo, como nos protocolos http ou ftp com análise mínima.
Você está falando bobagens de novo - duplicar uma com a outra quando você pode fazer com uma)). Por que se preocupar em armazenar arquivos, quando um é suficiente - o último com o estado atual de todos os pedidos e posições? Combinar a troca sob demanda do servidor (quando algo mudou na conta principal) e sob demanda do cliente (quando ele teve problemas ou inconsistências), e não criar muletas adicionais. Você pode enviar não todo o arquivo de pedido a pedido do servidor, mas apenas o que mudou e será sua versão de "troca de comandos".