Socket TCP ‘supprimé’ toutes les 6 minutes sous Windows Server 2012 R2

Nous devons migrer un système avec nos logiciels de Windows Server 2003 vers Windows Server 2012 R2. Lors de ce projet, nous avons simplement changé le matériel du serveur (en un serveur HP ProLiant), le système d’exploitation et la carte RNIS avec le pilote CAPI. Sur ce serveur, il existe une application C ++ qui filtre une chaîne de caractères de 30 octets sur le canal D RNIS et l’envoie via un socket TCP (localhost, port 30000) à une application JAVA. Le message arrive toutes les 30 secondes et a toujours le même format.

Le problème est le suivant: toutes les 6 minutes, le socket TCP est supprimé / effacé / ne fonctionne pas. Les deux applications enregistrent la communication brisée dans leurs fichiers journaux, créent et ouvrent à nouveau le socket et le jeu continue sans aucun problème pendant 6 minutes.

Sur l’ancien système, ce logiciel fonctionne pendant des années sans aucun problème sur Windows Server 2003 sur 9 sites.

Ce que nous avons déjà fait sans aucun effet positif:

• C ++ Multiconnection console de base serveur tchat Winsock2 Deuxième client ne recevant rien
• Le serveur reçoit-il un message du client, comment convertir le message en séquences de touches dans Active Window?
• Le client ne peut pas lire plus d’un message du serveur (C #)
• Le serveur Java attend que tous les clients soient prêts
• Connexion à Python Server via C # Client

• désactiver complètement le pare-feu
• changer le port en différents ports (30001, 30500, 16000, 997)
• utiliser la propre IP (10.16.58.30) à la place sur localhost
• placer plusieurs timeouts sur les parameters TCP du registre (par exemple KeepAliveTime)
• mettre à jour JAVA vers la dernière version
• installer toutes les mises à jour recommandées pour Windows Server 2012 R2
• dénudez les deux applications sur le seul socket pour vous assurer que le logiciel lui-même n’a aucun problème
• utiliser un message standard (‘1234567891234567890’) au lieu du message RNIS entrant pour exclure le dysfonctionnement des données d’entrée étranges
• vérifier la longueur du message pour exclure une longueur de 0
• vérifier tous les tampons des deux côtés pour exclure le débordement de tampon
• vérifier si d’autres logiciels sur le serveur utilisent «notre» port

Le problème n’apparaît pas si nous envoyons les messages à partir de manuels externes ou dans des cycles de messages différents avec un script bash sur le port du serveur de l’application JAVA.

Nous pensons maintenant que cela ne peut être qu’une sorte de mécanisme de vérification du système d’exploitation qui force notre socket à arrêter la communication. Des suggestions, qu’est-ce que cela pourrait être?

• Dois-je utiliser UDP ou TCP pour plus de 1200 clients
• Détecter les opérations d’écriture en cours sur un réseau
• Un processus par serveur client utilisant la mémoire partagée en C
• Terminer les connexions TCP à l’aide de PowerShell
• message du serveur ROSbridge au client