Le déclenchement du mécanisme de sécurité du WLangage avec le code 10054 peut se produire au cours d'échanges réseau entre une application ou un site, et sa base de données (HFSQL client/serveur, SQL SERVER, Oracle...). Il peut également s'agir d'échanges avec un autre processus qu'un serveur de données, avec différents protocoles (Requête HTTP, FTP, MQTT, Webservice, consommation SOAP, API REST…).

Le code erreur système 10054, correspond au message système suivant :

• "une connexion existante a dû être fermée par l'hôte distant",
• ou suivant la langue du système : "an existing connection was forcibly closed by the remote host"

Cette erreur se produit lors d'un échange par socket TCP entre deux processus, dès qu'il y a une perte de connexion durant l'attente de données sur une socket. L'application à l'origine d'une demande est en attente d'une réponse, mais la connexion est interrompue avant d'avoir obtenu la réponse.

Soit le processus contacté a été interrompu, soit un équipement réseau interfère et coupe la connexion avant que la réponse attendue ne puisse être récupérée.

S'il s'agit d'une interruption liée à une erreur du processus contacté (serveur de données ou autre), une information d'aide doit être consignée dans l'observateur d'événements de son système, et/ou dans ses propres logs.

S'il s'agit d'une interruption liée aux installations réseaux traversées, il faut se pencher sur la communication réseau, et l'application. En effet certaines caractéristiques de l'application peuvent la rendre plus sensible à des interruptions.

Il n'y a malheureusement pas de remède systématique et immédiat pour ce type de coupure. La cause réelle vient très souvent d'une combinaison de facteurs. Voici cependant une liste, non exhaustive, de vérifications à entreprendre :

• Vérifier l'observateur d'évènements du poste client, il peut avoir des données en relation avec l'interruption.
  
  
• antivirus, firewall :
  • vérifier que les antivirus, firewall (…) de toutes les installations traversées, ont bien toutes les exclusions requises pour autoriser les échanges entre l'application et le serveur.
  • vérifier le log des applications de sécurité. Il y a une forte probabilité qu'un faux-positif d'un firewall ou d'un antivirus qui aurait interrompu une entrée/sortie en trouvant une similitude entre des données échangées, une trame, et une signature d'un processus malveillant, soit à l'origine du défaut.
    
    
• Vérifier que l'application cliente est bien signée. Sans cela elle sera toujours une cible prioritaire des dispositifs de sécurité.
  
  

• Vérifier qu'il y a bien un chiffrement sur la connexion entre les processus.
  
  

• Vérifier que l'application est bien compilée en 64 bits afin d'être certain qu'elle va profiter des pilotes les plus récents du système.
  
  

• Vérifier que l'application est bien compilée dans une version suffisamment récente pour utiliser des couches de sécurité qui répondent aux exigences des systèmes actuels (OpenSSL 3...). Idem pour le serveur d'application ou le serveur de données.
  
  
• Si la perte de connexion se fait lors d'un échange avec la base ou l'application d'un éditeur particulier, faire la recherche Internet de "10054 <nom éditeur>", par exemple "10054 oracle", "10054 sql server",
  
  
• Vérifier que tous les équipements réseaux (switchs, box de l'opérateur qui fourni la connexion...) des installations sont à jour de leur firmeware.
  
  
• Vérifier (proxy, système de virtualisation...) qu'il n'y a pas de limitation sur les possibilités de transferts TCP entre le poste qui exécute l'application et le serveur (limitation de la taille des réponses, ou du délai de réponse...).
  
  
• Tester la même application depuis le même poste mais avec une autre connexion réseau, puis à l'inverse tester l'application avec la même connexion mais un autre poste. Cela permet de voir si l'instabilité de la connexion vient d'un poste, ou plutôt d'une connexion...

Un utilitaire d'analyse de trames tel que Wireshark permet de rechercher l'origine exacte de la fermeture de la socket lorsque l'on peut reproduire l'interruption, en recherchant un flag RST (= reset connection) dans une trame TCP.