Socket Dis-Connects à une extrémité, pare-feu?

Question

J'ai une application C# qui fonctionne correctement depuis plusieurs années. Il se connecte via une socket TCP/IP à une machine qui m'envoie des exécutions de trade de stock. Récemment, j'ai essayé de le déployer sur certaines machines dans un nouveau centre de données se trouvant derrière un pare-feu matériel, et j'ai commencé à voir des déconnexions bizarres.

Lorsqu'une déconnexion se produit, dans mon application (le côté client), je ne vois rien d'inhabituel sauf que je cesse de recevoir des données sur le socket. Wireshark confirme qu'aucune donnée n'atteint le socket et que le thread de réception de mon application bloque sur l'appel Receive() lorsque je l'arrête dans le débogueur. Le socket indique ESTABLISHED dans netstat.

Mais du côté serveur, il semble que mon client se déconnecte. En regardant leurs logs, il semble que le socket sur leur extrémité se termine généralement par (nRecvd = -1, errno = 104) ou (nRecvd = 0, errno = 11). (104 est la connexion réinitialisée par un pair).

La déconnexion ne semble se produire qu'après une période d'inactivité. J'ai résolu ceci pour l'instant en implémentant un battement de coeur entre mon client et leur serveur qui envoie juste un court message toutes les 20 secondes et obtient une réponse. Cela a provoqué la chute des disjoncteurs à 0 au cours des derniers jours. Au début, j'ai pensé que le pare-feu matériel était le problème. Cela provoquait l'arrêt du socket après l'activité. Mais la personne en charge du pare-feu prétend que le délai d'attente pour les connexions sur ce port (8887) est de 2160 minutes. Je cours Windows Server 2003 et .NET 3.5. Le serveur de trades est une machine linux (sles9 je crois bien que je ne suis pas sûr).

Des idées sur ce qui pourrait se passer? Que puis-je faire pour déboguer cela étant donné que je n'ai aucun accès aux journaux du pare-feu et aucune possibilité de changer le code sur le serveur de commerce?

Merci, Mike

Answer 1

Ce que vous décrivez est commun, et il est fréquent de mettre en œuvre un battement de coeur pour maintenir les sockets TCP en vie grâce à ces pare-feu/passerelles comme Tu l'as fait.

Ce matériel peut avoir des délais d'attente de 2 160 minutes (dans mon expérience, 20 à 30 minutes sont plus courantes), mais les connexions sont généralement abandonnées de manière beaucoup plus agressive en cas de charge. De tels pare-feux ont des ressources limitées, et lorsqu'ils ont besoin de plus de suivi de connexion, ils ont tendance à laisser tomber la connexion la plus ancienne suivie sans aucune activité, quel que soit le délai d'attente défini.

Si vous voulez déboguer ce plus, allez sniff sur le côté serveur du pare-feu et voir ce que, si anyting, se produit lorsque le serveur reçoit une déconnexion

Answer 2

Je wiresharp de configuration des deux côtés du pare-feu pour voir ce qui se passe sur TCP (et niveau inférieur). Et quand l'administrateur dit que le "timeout for connect" est quelque chose. Est-ce le délai d'attente pour une connexion inactive et établie? Rien d'autre n'a aucun sens, je suppose.

Également, utilisez-vous l'option KeepAlive pour TCP? Et est-ce transmis par le pare-feu ou non?

Comme je l'ai dit, vous voulez probablement lancer Wireshark des deux côtés du pare-feu ...