timeouts infinitas ou “falhar rapidamente” no protocolo de rede personalizado?

Question

Considere protocolo de rede personalizado. Este protocolo personalizado pode ser usado para controlar periféricos robóticos mais de LAN de estação de trabalho baseado em .NET central. (Se for importante, o robô é fábricas móveis ocupados em ambiente de produção de chips).

• há apenas 2 partes em conversa: Estação .NET e tábua periférica robótico
• o lado robótico só pode receber solicitações e respostas de envio
• lado do .NET só pode iniciar solicitações e receber respostas
• que sempre deve ser exatamente uma resposta por solicitação
• as consequentes solicitações pode seguir imediatamente um após o outro sem esperar a resposta, mas nunca exceder o limite fixo de solicitações simultaneamente servido (por exemplo 5)

Eu tive discussão exaustiva com o meu amigo (que é dono do projeto, eu tenho discutido a coisa como um espectador) sobre todos os detalhes agradáveis ??e idéias. No final da discussão que tivemos forte desacordo sobre tempos de espera desaparecidas. O argumento de meu amigo é que o software em ambos os lados devem esperar indefinidamente. Meu argumento era de que tempos de espera são sempre necessários por qualquer protocolo de rede. Nós simplesmente nunca poderia concordar.

Um dos meu raciocínio é que, em caso de qualquer falha que você deve "falhar rapidamente" qualquer custo, porque se a falha já ocorrido de qualquer forma, o custo de recuperação continua a crescer proporcionalmente ao tempo gasto para receber uma informação sobre a falha. Digamos que depois de 1 minuto na LAN você definitivamente deve parar de esperar e apenas invocar algum alarme.

Mas seu argumento era que a recuperação deve incluir exatamente a reparação do que não (neste recuperação caso de conexão de rede) e, mesmo que é preciso para passar horas para descobrir que a rede foi perdida e fixo, o software deve apenas continuar transparente execução, imediatamente após reconectar os cabos de LAN.

Eu nunca iria pensar seriamente sobre protocolos intemporais, até que esta discussão.

De que lado do argumento é certo? A "falhar rapidamente" ou "nunca falha"?

Editar: Exemplo de falha é a perda de comunicação, normalmente detectada pela camada de TCP. Esta parte também foi discutido. Em caso de camada TCP retorno de erro, a camada de protocolo personalizado maior tentará envia e não há nenhuma discussão sobre isso. A pergunta é: por quanto tempo para permitir que o nível mais baixo para continuar tentando

Editar para resposta aceita: Resposta é mais complexa do que 2 opções: " A abordagem mais comum é nunca desistir conexão até tentativa real para envio falhar com a confirmação sólida essa conexão é muito tempo perdido Para calcular essa conexão é perdido há muito tempo de uso batimentos cardíacos, mas manter idade de. perda para esta confirmação, e não para alarme imediato ".

Exemplo:. Ao ter sessão telnet, você pode manter o seu até o terminal para sempre e você nunca sabe se entre pressionar Enter houve falhas detectáveis ??por rotinas de nível inferior

Answer 1

Eu prefiro o método "rápido falhar", mas como eu acho que você descobriu, isso é altamente preferencial.

equipamentos Cisco que eu trabalho com o trabalho de forma muito semelhante - você enviar um pedido, eles respondem. (Over telnet.) O problema é quando a rede falha: eu perder a conexão TCP. No entanto, nenhum dos lados irá fechar essa conexão até que um envio de dados é tentada, e desde o lado do cisco raramente faz isso, ele nunca fecha. Pior ainda, você pode ter apenas uma conexão de cada vez, por isso, se há falha de rede, você está trancado para fora. (Eles podem ser repostas, mas é um apenas um aborrecimento.)

Agora, para testar uma conexão de rede, você precisa de algum tipo de pingue, apenas um "você ainda está aí?" - muitos protocolos fazer isso, como o AIM e IRC. Mas esses pings custar largura de banda, dependendo de quantas vezes você enviá-los.

Assim, é o valor de detecção de erros o custo da largura de banda? Quão grande é que um ping realmente precisa ser? Eu diria que você deve ser capaz de fazê-lo <50 octetos / ping, e você pode executar ping como uma vez a cada 10s, 30s, 1m, algo assim, eu diria que é bem a pena. Quanto mais cedo você sabe que tem um problema, melhor. Se o próprio software pode então usar esses pings saber que perdeu a conexão e re-estabelecer contato automaticamente, eu diria que isso é ótimo, ao longo das linhas de "Computer, cura a ti mesmo", e faz para menos problemas para o operador.

Se você estiver usando TCP / IP, ele pode fazer isso automaticamente para você - veja TCP Keepalives. Alternativamente, você pode fazê-lo dentro do protocolo do aplicativo, como AIM e IRC fazer.

Answer 2

No cenário em que ...

• Controlador enviou um pedido
• Robot não recebeu o pedido
• Rede de falha

... então o pedido foi enviado, mas foi perdido e nunca vai chegar.

Portanto, quando a rede é restaurada, o controlador deve reenviar o pedido:. O controlador não pode simplesmente esperar para sempre para a resposta