Criando um protocolo TCP assíncrono persistente

2

Eu tenho uma coleção de sites que precisam enviar mensagens sensíveis ao tempo para hospedar máquinas em toda a minha área metropolitana, cada uma em seu próprio IP geralmente dinâmico. Até agora, eu tenho feito isso do jeito do script kiddie:

  1. Cada máquina host executa um (s) servidor FTP, ou um servidor HTTP (s), e correspondentemente tem uma certa porta aberta por seu gateway.

  2. Cada máquina host executa um programa que assiste a uma determinada pasta e abre ou imprime automaticamente ou exec () s quando um novo arquivo de uma determinada extensão é exibido. Endereços IP dinâmicos são acomodados usando um serviço DNS dinâmico.

  3. Cada web site cURL ou fsockopen ou qualquer outra coisa e se comunica diretamente com seu destinatário conforme necessário.

Esta abordagem tem sido surpreendentemente confiável, no entanto, questões óbvias surgiram e a situação precisa ser abordada.

Como afirmado, essas mensagens são sensíveis ao tempo e as falhas precisam ser detectadas dentro de minutos após o envio pelos usuários finais. O que estou fazendo é construir um protocolo de mensagens. Ele será executado em uma máquina e conexão no meu controle. No que diz respeito ao serviço, não há distinção entre o site e a máquina host - há apenas um dispositivo enviando uma mensagem para outro dispositivo.

Então é aí que eu estou agora. Eu tenho um servidor esqueleto e um cliente esqueleto. Eles podem negociar autenticação e criptografia de alta qualidade. A conexão (TCP) é persistente e assíncrona, e pode manipular delimitado (ou seja, ler até \ r \ n ou qualquer outro) assim como prefixado por comprimento (isto é, ler exatamente n bytes) mensagens. A menos que alguém me dê uma ideia melhor, acho que vou lidar com mensagens como matrizes de bytes.

Estou procurando sugestões sobre como modelar o protocolo em si - no nível do aplicativo. Eu vou principalmente transferir arquivos do tipo XML e DLM, bem como controlar mensagens para coisas como "aperto de mão" e "é fulano on-line?" e assim por diante. Existe alguma coisa realmente estúpida na minha linha de pensamento? Ou qualquer coisa que eu deveria ler antes de começar? Coisas assim - por favor e obrigado.

Atualização:

@ A abordagem de mrdenny é a abordagem que acabei tendo, então ele recebe a resposta. A sugestão @ Henrik's ZeroMQ também foi aplicada, mas eu basicamente já codifiquei e mudar meu código para uma estrutura de terceiros não ajudou muito a projetar a camada de aplicação. No final, descobri o quão incrivelmente versátil o HTTP pode ser, e realmente não há necessidade de um protocolo roll-your-own. Basta deixar os sites da Web apresentarem o aplicativo / json do tipo de conteúdo (ou xml, se necessário) além do texto / html que já estavam fazendo e permitir que os destinatários façam solicitações da Web de saída em vez de ouvir e responder às atualizações do sistema de arquivos. Remove toda a sobrecarga "script kiddie" descrita acima, funciona de forma muito mais confiável, permite um tratamento de erros muito melhor, fácil de compilar e muito mais.

    
por dogglebones 24.06.2012 / 07:56

3 respostas

1

Qualquer motivo pelo qual você não pode simplesmente usar métodos da Web e chamadas HTTP (ou HTTPS) para transferir os dados entre as máquinas?

    
por 24.06.2012 / 18:21
4

ZeroMQ foi projetado como um protocolo assíncrono de transporte / mensagem.

Se um de seus nós falhar, ele restabelecerá o ZMQ-Socket e continuará enviando suas mensagens quando a rota para o terminal de destino for ativada. O desempenho é bom e, de acordo com seu canal de IRC, é bem testado o suficiente hoje em dia para usar WAN.

    
por 24.06.2012 / 18:43
0

Verifique o FIX (como o protocolo FIX) para ver um exemplo de como um protocolo pode ser. Você PODERIA apenas usar o FIX e uma biblioteca de código aberto e criar todas as definições de campo. FIX é usado para negociação financeira.

Mas isso deve lhe dar uma ideia decente. O FIX também pode / manipula itens como persistir mensagens no caso de uma conexão cair, se desejado.

    
por 24.06.2012 / 18:34