Ai-je besoin d'un heartbeat pour maintenir une connexion TCP ouverte ?

Question

J'ai deux composants qui communiquent via TCP/IP. Le composant A fait office de serveur/auditeur et le composant B est le client. Les deux doivent communiquer aussi rapidement que possible. Il ne peut y avoir qu'une seule connexion à la fois (bien que cela soit accessoire à cette question). Un développeur senior de mon entreprise m'a dit que je devais utiliser des battements de cœur au niveau de l'application entre les deux composants pour m'assurer que la connexion reste ouverte.

Je pensais que la connexion restait ouverte avec TCP/IP mais j'ai lu un certain nombre de blogs/sites disant que c'est une pratique assez standard de battre le cœur entre ces applications.

Je sais qu'une partie de la raison pour laquelle le composant A bat le cœur du composant B est qu'il peut informer le support s'il y a des problèmes de communication avec le composant B (soit la liaison est en panne, soit le composant B ne fonctionne pas). Les battements de cœur sont-ils nécessaires pour d'autres raisons ? Par exemple, pour s'assurer qu'il y a fréquemment quelque chose "dans le tuyau" pour le maintenir ouvert ?

Actuellement, le composant A envoie des battements de cœur au composant B toutes les 20 secondes et ferme la connexion si rien n'est reçu en retour du composant B dans les 120 secondes. Il reprend ensuite l'écoute des connexions en partant du principe que le composant B essaiera périodiquement de se reconnecter si le lien est rompu. Cela fonctionne avec succès.

Pour réitérer ma question : Les battements de cœur sont-ils nécessaires pour maintenir une connexion TCP/IP en vie ?

Answer 1

La connexion devrait restent ouvertes quoi qu'il en soit, mais il est fréquent de voir des protocoles implémenter un battement de cœur afin d'aider à détecter les connexions mortes. PING par exemple.

Answer 2

Comme beaucoup d'autres l'ont noté, la connexion TCP restera active si elle est laissée à elle-même. Cependant, si vous avez un dispositif au milieu de la connexion qui suit son état (comme un pare-feu), vous pouvez avoir besoin de keepalives afin d'empêcher l'expiration de l'entrée de la table d'état.

Answer 3

Si vos composants :

• sont dans un réseau filaire classique
• il n'y a pas de pare-feu ou de routeurs NAT entre eux.
• aucun des deux ne s'écrase

alors vous n'avez pas besoin d'avoir un battement de cœur.

Si l'une de ces hypothèses est fausse (je vous regarde, GPRS !), un coup de cœur s'impose assez rapidement.

Answer 4

Vous n'avez pas besoin d'envoyer vous-même des battements de cœur. La connexion TCP restera ouverte quelle que soit son utilisation.

Notez que TCP implémente une option keepalive qui peut être utilisé pour identifier une connexion fermée en temps voulu, plutôt que de vous demander d'envoyer des données à une date ultérieure et de découvrir seulement ensuite que la connexion est fermée.

Answer 5

Si vous utilisez Windows, soyez prudent avec le TCP Keep-alive. Par défaut, il est désactivé, sauf si vous l'activez globalement dans le registre Windows ou via setsockopt.

L'intervalle par défaut de la fonction "keep-alive" est de 2 heures.

http://msdn.microsoft.com/en-us/library/ms819735.aspx

Vous devrez peut-être mettre en œuvre votre propre rythme cardiaque et désactiver la fonction "keep-alive" de TCP sur Windows si la fonction "keep-alive" de 2 heures n'est pas souhaitable.