Une connexion existante a été fermée de force par l'hôte distant

Je travaille avec une application commerciale qui lance une SocketException avec le message,

Une connexion existante a été fermée de force par l'hôte distant

Cela se produit avec une connexion socket entre le client et le serveur. La connexion est bien vivante et des tas de données sont transférées, mais elles se déconnectent alors de nulle part.

Est-ce que quelqu'un a déjà vu ça? Quelles pourraient être les causes? Je peux en quelque sorte deviner quelques causes, mais y a-t-il également un moyen d'en ajouter plus dans ce code pour déterminer quelle pourrait être la cause?

Tous les commentaires / idées sont les bienvenus.

... Le dernier ...

J'ai une journalisation à partir d'un traçage .NET,

System.Net.Sockets Verbose: 0 : [8188] Socket#30180123::Send() DateTime=2010-04-07T20:49:48.6317500Z

System.Net.Sockets Error: 0 : [8188] Exception in the Socket#30180123::Send - An existing connection was forcibly closed by the remote host DateTime=2010-04-07T20:49:48.6317500Z 

System.Net.Sockets Verbose: 0 : [8188] Exiting Socket#30180123::Send() -> 0#0

Sur la base d'autres parties de la journalisation, j'ai vu le fait qu'il dit «0 # 0» signifie qu'un paquet de 0 octets de longueur est envoyé. Mais qu'est-ce que cela signifie réellement?

L'une des deux possibilités se présente, et je ne sais pas laquelle,

1) La connexion est en cours de fermeture, mais les données sont ensuite écrites sur le socket, créant ainsi l'exception ci-dessus. Le 0 # 0 signifie simplement que rien n'a été envoyé car le socket était déjà fermé.

2) La connexion est toujours ouverte et un paquet de zéro octet est envoyé (c'est-à-dire que le code a un bogue) et le 0 # 0 signifie qu'un paquet de zéro octet tente d'être envoyé.

Qu'est-ce que tu en penses? Ce n'est peut-être pas concluant, je suppose, mais peut-être que quelqu'un d'autre a vu ce genre de chose?

Cela signifie généralement que le côté distant a fermé la connexion (généralement en envoyant un RSTpaquet TCP / IP ). Si vous travaillez avec une application tierce, les causes probables sont:

• Vous envoyez des données mal formées à l'application (ce qui peut inclure l'envoi d'une requête HTTPS à un serveur HTTP)
• La liaison réseau entre le client et le serveur est en panne pour une raison quelconque
• Vous avez déclenché un bogue dans l'application tierce qui l'a fait planter
• L'application tierce a épuisé les ressources système

Il est probable que le premier cas soit ce qui se passe.

Vous pouvez lancer Wireshark pour voir exactement ce qui se passe sur le fil pour affiner le problème.

Sans informations plus spécifiques, il est peu probable que quelqu'un ici puisse vraiment vous aider.

L'utilisation de TLS 1.2 a résolu cette erreur.
Vous pouvez forcer votre application à utiliser TLS 1.2 avec ceci (assurez-vous de l'exécuter avant d'appeler votre service):

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 

Une autre solution:
activez une cryptographie forte sur votre machine ou serveur local afin d'utiliser TLS1.2 car par défaut, il est désactivé, donc seul TLS1.0 est utilisé.
Pour activer la cryptographie forte, exécutez ces commandes dans PowerShell avec des privilèges d'administrateur:

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord 

Vous devez redémarrer votre ordinateur pour que ces modifications prennent effet.

Ce n'est pas un bogue dans votre code. Il provient de l'implémentation Socket de .Net. Si vous utilisez l'implémentation surchargée d'EndReceive comme ci-dessous, vous n'obtiendrez pas cette exception.

    SocketError errorCode;
    int nBytesRec = socket.EndReceive(ar, out errorCode);
    if (errorCode != SocketError.Success)
    {
        nBytesRec = 0;
    }

Solution simple pour ce problème ennuyeux courant:

Allez simplement dans votre fichier " .context.cs" (situé sous " .context.tt" qui se trouve sous votre fichier "* .edmx").

Ensuite, ajoutez cette ligne à votre constructeur:

public DBEntities() 
        : base("name=DBEntities") 
    { 
        this.Configuration.ProxyCreationEnabled = false; // ADD THIS LINE !
    }

espérons que cela est utile.

Eu le même bug. En fait, cela fonctionnait au cas où le trafic serait envoyé à l'aide d'un proxy (un violon dans mon cas). Mise à jour du framework .NET de 4.5.2 à> = 4.6 et maintenant tout fonctionne correctement. La demande réelle était:
new WebClient().DownloadData("URL");
L'exception était:

SocketException: une connexion existante a été fermée de force par l'hôte distant

J'ai cette exception en raison de la référence circulaire dans l'entité. Dans l'entité qui ressemble à

public class Catalog
{
    public int Id { get; set; }
    public int ParentId { get; set; }
    public Catalog Parent { get; set; }
    public ICollection<Catalog> ChildCatalogs { get; set; }
}

J'ai ajouté [IgnoreDataMemberAttribute] à la propriété Parent. Et cela a résolu le problème.

Si vous utilisez un service .Net 4.5.2

Pour moi, le problème a été aggravé parce que l'appel était en cours d'exécution dans un service .Net 4.5.2. J'ai suivi la suggestion de @willmaz mais j'ai eu une nouvelle erreur.

En exécutant le service avec la journalisation activée, j'ai vu que l'établissement de liaison avec le site cible lancerait ok (et enverrait le jeton du porteur) mais à l'étape suivante pour traiter l'appel de publication, il semblerait que le jeton d'authentification soit abandonné et le site répondre avec Unauthorized.

Il s'est avéré que les informations d'identification du pool de services n'avaient pas le droit de modifier TLS (?) Et lorsque j'ai mis mon compte d'administrateur local dans le pool, tout fonctionnait.

Pour quiconque obtient cette exception lors de la lecture des données du flux, cela peut aider. J'obtenais cette exception lors de la lecture du HttpResponseMessage dans une boucle comme celle-ci:

using (var remoteStream = await response.Content.ReadAsStreamAsync())
using (var content = File.Create(DownloadPath))
{
    var buffer = new byte[1024];
    int read;

    while ((read = await remoteStream.ReadAsync(buffer, 0, buffer.Length)) != 0)
    {
        await content.WriteAsync(buffer, 0, read);
        await content.FlushAsync();
    }
}

Après un certain temps, j'ai découvert que le coupable était la taille de la mémoire tampon, qui était trop petite et ne fonctionnait pas bien avec ma faible instance Azure. Ce qui a aidé, c'est de changer le code en:

using (Stream remoteStream = await response.Content.ReadAsStreamAsync())
using (FileStream content = File.Create(DownloadPath))
{
    await remoteStream.CopyToAsync(content);
}

La méthode CopyTo () a une taille de tampon par défaut de 81920. La plus grande mémoire tampon a accéléré le processus et les erreurs se sont arrêtées immédiatement, probablement parce que les vitesses de téléchargement globales ont augmenté. Mais pourquoi la vitesse de téléchargement serait-elle importante pour éviter cette erreur?

Il est possible que vous soyez déconnecté du serveur car les vitesses de téléchargement chutent en dessous du seuil minimum que le serveur est configuré pour autoriser. Par exemple, si l'application à partir de laquelle vous téléchargez le fichier est hébergée sur IIS, cela peut être un problème avec la configuration de http.sys:

"Http.sys est la pile de protocoles http qu'IIS utilise pour effectuer la communication http avec les clients. Il dispose d'un minuteur appelé MinBytesPerSecond qui est responsable de la suppression d'une connexion si son taux de transfert tombe en dessous d'un seuil de kb / s. Par défaut, ce seuil est réglé sur 240 kb / s. "

Le problème est décrit dans cet ancien article de blog de l'équipe de développement TFS et concerne spécifiquement IIS, mais peut vous orienter dans la bonne direction. Il mentionne également un ancien bogue lié à cet attribut http.sys: lien

Si vous utilisez les services d'application Azure et que l'augmentation de la taille de la mémoire tampon n'élimine pas le problème, essayez également de mettre à l'échelle votre ordinateur. Vous recevrez plus de ressources, y compris la bande passante de connexion.

J'ai eu le même problème et j'ai finalement réussi à le résoudre. Dans mon cas, le port auquel le client envoie la demande n'avait pas de liaison de certificat SSL. J'ai donc résolu le problème en liant un certificat SSL au port côté serveur. Une fois que cela a été fait, cette exception a disparu.

Cette erreur s'est produite dans mon application avec le protocole CIP chaque fois que je n'ai pas envoyé ou reçu de données en moins de 10 secondes.

Cela a été causé par l'utilisation de la méthode ouverte avant. Vous pouvez éviter cela en travaillant avec une autre méthode ou en installant un taux de mise à jour inférieur aux 10 qui maintiennent votre connexion avant-ouverte.