Délais d'inactivité ou «échec rapide» dans le protocole réseau personnalisé

Question

Pensez au protocole réseau personnalisé. Ce protocole personnalisé peut être utilisé pour contrôler des périphériques robotiques sur un réseau local à partir d'un poste de travail .NET central. (Si cela est important, le robot est en train de déplacer des installations dans un environnement de production de puces).

• il n'y a que 2 parties en conversation: station .NET et carte périphérique robotique
• le côté robotique ne peut recevoir que des requêtes et envoyer des réponses
• le côté .NET peut uniquement initier des demandes et recevoir des réponses
• il devrait toujours y avoir exactement une réponse par demande
• les requêtes consécutives peuvent suivre immédiatement l'une après l'autre sans attente de réponse, mais ne jamais dépasser la limite fixée pour les requêtes servies simultanément (par exemple 5)

J'ai eu une discussion approfondie avec mon ami (à qui appartient le design, j'ai discuté de la chose en tant que spectateur) à propos de tous les détails et idées intéressants. À la fin de la discussion, nous étions fortement en désaccord sur les délais d'attente manquants. L'argument de mon ami est que les logiciels des deux côtés devraient attendre indéfiniment. Mon argument était que les délais d'attente sont toujours nécessaires par n'importe quel protocole réseau. Nous ne pourrions simplement jamais être d'accord.

L’un de mes arguments est que, en cas d’échec, vous devriez "échouer rapidement". quel que soit le coût, car si une défaillance a déjà eu lieu, le coût de la récupération continue de croître proportionnellement au temps passé à recevoir une information sur la défaillance. Supposons qu'après une minute sur le réseau local, vous devez absolument arrêter d'attendre et simplement déclencher une alarme.

Mais son argument était que la récupération devrait inclure exactement la réparation de ce qui a échoué (dans ce cas, la récupération de la connexion réseau) et même s'il faut des heures pour comprendre que le réseau a été perdu et réparé, le logiciel doit simplement continuer de manière transparente en cours de fonctionnement, immédiatement après avoir reconnecté les câbles LAN.

Je ne penserais jamais sérieusement aux protocoles intemporels, jusqu'à cette discussion.

De quel côté sont les arguments? Le " échec rapide " ou "n'échouez jamais" ?

Modifier: Exemple de défaillance: perte de communication, normalement détectée par la couche TCP. Cette partie a également été discutée. En cas d'erreur de renvoi de la couche TCP, la couche de protocole personnalisée supérieure réessayera les envois et il n'y aura aucun argument à ce sujet. La question est: pendant combien de temps pour permettre au niveau inférieur de continuer à essayer?

Modifier pour réponse acceptée: La réponse est plus complexe que deux choix: "" L'approche la plus courante consiste à ne jamais abandonner la connexion tant que la tentative d'envoi n'a pas échoué avec une confirmation solide que la connexion est perdue depuis longtemps. Pour calculer que cette connexion est perdue depuis longtemps, utilisez les pulsations, mais conservez l’âge de perte pour cette confirmation uniquement, pas pour une alarme immédiate ".

Exemple: lors d’une session telnet, vous pouvez garder votre terminal en permanence et vous ne savez jamais si, entre deux tentatives, appuyez sur Entrée, des défaillances ont été détectées par les routines de niveau inférieur.

Answer 1

Je préfère votre "échec rapide". méthode, mais comme je pense que vous avez découvert, ceci est très préférentiel.

Les équipements Cisco avec lesquels je travaille fonctionnent de manière très similaire: vous envoyez une demande, ils répondent. (Sur telnet.) Le problème survient lorsque le réseau échoue: je perd la connexion TCP. Toutefois, aucune des deux parties ne fermera cette connexion tant que l’envoi de données n’aura pas été tenté, et comme cisco le fait rarement, il ne se ferme jamais. Pire encore, vous ne pouvez avoir qu'une seule connexion à la fois, donc en cas de défaillance du réseau, vous êtes bloqué. (Ils peuvent être réinitialisés, mais c'est un problème.)

Désormais, pour tester une connexion réseau, vous avez besoin d’une sorte de ping: il vous suffit d’un "êtes-vous toujours là?" - de nombreux protocoles le font, tels que AIM et IRC. Mais ces pings coûtent de la bande passante, selon la fréquence à laquelle vous les envoyez.

La détection d'erreur en vaut-elle le coût en bande passante? Quelle doit être la taille d'un ping? Je dirais que vous devriez pouvoir atteindre 50 octets / ping et que vous pourriez faire un ping comme tous les 10, 30 ou 1 mètres, ce qui est bien, mais ça en vaut vraiment la peine. Plus tôt vous savez que vous avez un problème, mieux c'est. Si le logiciel lui-même peut alors utiliser ces pings pour savoir qu'il a perdu la connexion et rétablir automatiquement le contact, je dirais que c'est génial, dans la lignée de "Ordinateur, guérissez-vous", et simplifie la tâche de l'opérateur.

Si vous utilisez TCP / IP, il peut le faire automatiquement pour vous - voir TCP Keepalives. Alternativement, vous pouvez le faire dans le protocole de votre application, comme AIM & amp; IRC faire.

Answer 2

Dans le scénario où ...

• Le contrôleur a envoyé une demande
• Robot n'a pas reçu la demande
• échec du réseau

... alors la demande a été envoyée, mais a été perdue et n'arrivera jamais.

Par conséquent, lorsque le réseau est restauré, le contrôleur doit renvoyer la demande: le contrôleur ne peut tout simplement pas attendre indéfiniment la réponse.