Détecter la perte de connexion pour réparer la passerelle? (Solution rapide)

Question

J'essaie de trouver un bon moyen de détecter une perte de connexion.

Mon adaptateur est implémenté en tant que Fix :: Application basé sur l'un des exemples. Il utilise un initiateur de socket pour se connecter à la passerelle de réparation.

Lorsque je débranche Internet, il faut environ 30 secondes pour que la méthode onLogout de Fix :: Application soit déclenchée. Il semble qu'une classe sous-jacente serait consciente du fait que le socket pose un problème beaucoup plus tôt. Y a-t-il un moyen rapide de s’y prendre?

Answer 1

Le meilleur moyen de résoudre ce problème serait probablement de réduire votre intervalle de pulsations cardiaques afin que vous sachiez plus tôt. Je ne connais aucun message qui déclenche une perte de connexion TCP, mais je ne pense pas que QuickFix écoute les événements du système d'exploitation non plus. Bien que l'événement fromAdmin soit probablement transmis s'il y avait un tel message.

Avez-vous posté votre question sur le QuickFix DL?

Answer 2

Il est possible que le moteur de correction que vous utilisez ne rappelle pas lorsque TCP est déconnecté, ou qu'il appelle autre chose que onLogout. Puisque vous utilisez un correctif, je suppose que cela force la déconnexion en raison des battements de cœur manqués.

La solution rapide consisterait à examiner le code et à vérifier où la fermeture de socket est gérée et quel chemin s’exécute lorsque cela se produit.

Answer 3

TCP lui-même est livré avec un mécanisme de pulsation natif appelé SO_KEEPALIVE . Le problème est que l'intervalle par défaut pour cette pulsation peut atteindre 2 heures. Ceci est configuré au niveau du système d'exploitation. Donc, en théorie, vous pouvez activer SO_KEEPALIVE, configurer un intervalle de pulsation raisonnable au niveau du système d'exploitation et être heureux. Toutefois, comme cela est très dépendant du système d’exploitation, la plupart des applications choisissent d’implémenter Heartbeating au niveau application, et FIX ne fait pas exception. Réduire votre intervalle de pulsations FIX est la solution, en particulier si vous comptez sur l'annulation à la déconnexion et que des secondes supplémentaires de perte de connexion non détectée peuvent entraîner des exécutions d'ordre non souhaitées. Une passerelle FIX implémentée au-dessus de tout moteur de correction doit prendre en charge une configuration immédiate. Regardez CoralGateway pour un exemple. (Avertissement: je suis l’un des développeurs de CoralGateway)