it-swarm.com.de

Eine bestehende Verbindung wurde vom Remote-Host zwangsweise geschlossen

Ich arbeite mit einer kommerziellen Anwendung, die eine SocketException mit der Nachricht auslöst.

Eine bestehende Verbindung wurde vom Remote-Host zwangsweise geschlossen

Dies geschieht bei einer Socketverbindung zwischen Client und Server. Die Verbindung ist lebendig und in Ordnung, und es werden Haufen von Daten übertragen, die jedoch aus dem Nichts getrennt werden.

Hat jemand das schon mal gesehen? Was können die Ursachen sein? Ich kann ein paar Ursachen vermuten, aber gibt es auch eine Möglichkeit, diesem Code mehr hinzuzufügen, um herauszufinden, was die Ursache sein könnte?

Alle Kommentare/Ideen sind willkommen.

... Das Neueste ...

Ich habe etwas Protokollierung von einigen .NET-Tracing,

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

Basierend auf anderen Teilen der Protokollierung habe ich gesehen, dass '0 # 0' bedeutet, dass ein Paket mit einer Länge von 0 Byte gesendet wird. Aber was heißt das wirklich?

Es gibt zwei Möglichkeiten, und ich bin mir nicht sicher, welche

1) Die Verbindung wird geschlossen, es werden jedoch Daten in den Socket geschrieben, wodurch die obige Ausnahme erstellt wird. Die 0 # 0 bedeutet einfach, dass nichts gesendet wurde, da der Socket bereits geschlossen war.

2) Die Verbindung ist noch offen, und ein Paket mit null Bytes wird gesendet (d. H. Der Code hat einen Fehler), und 0 # 0 bedeutet, dass ein Paket mit null Bytes gesendet werden soll.

Was glaubst du? Ich denke, es ist vielleicht nicht schlüssig, aber vielleicht hat jemand anderes so etwas gesehen?

89
peter

Dies bedeutet im Allgemeinen, dass die Remote-Seite die Verbindung (normalerweise durch Senden eines TCP/IP-Paketes RST) geschlossen hat. Wenn Sie mit einer Drittanbieteranwendung arbeiten, sind die möglichen Ursachen die folgenden:

  • Sie senden fehlerhafte Daten an die Anwendung
  • Die Netzwerkverbindung zwischen Client und Server ist aus irgendeinem Grund unterbrochen
  • Sie haben einen Fehler in der Drittanbieteranwendung ausgelöst, der zum Absturz führte
  • Die Drittanbieteranwendung hat die Systemressourcen erschöpft

Es ist wahrscheinlich, dass der erste Fall das ist, was passiert.

Sie können mit Wireshark einschalten, um genau zu sehen, was auf dem Draht passiert, um das Problem einzugrenzen.

Ohne genauere Informationen ist es unwahrscheinlich, dass jemand hier wirklich viel helfen kann.

71
RarrRarrRarr

Mit TLS 1.2 wurde dieser Fehler behoben.
Sie können erzwingen, dass Ihre Anwendung TLS 1.2 verwendet (Sie müssen sie unbedingt ausführen, bevor Sie Ihren Dienst aufrufen): 

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 

Eine andere Lösung :
Aktivieren Sie starke Kryptografie auf Ihrem lokalen Computer oder Server, um TLS1.2 verwenden zu können, da diese standardmäßig deaktiviert ist und nur TLS1.0 verwendet wird.
Um eine starke Verschlüsselung zu aktivieren, führen Sie die folgenden Befehle in PowerShell mit Administratorrechten aus:

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 

Sie müssen Ihren Computer neu starten, damit diese Änderungen wirksam werden.

25
willmaz

Dies ist kein Fehler in Ihrem Code. Es kommt von der Socket-Implementierung von .Net. Wenn Sie die überladene Implementierung von EndReceive wie folgt verwenden, wird diese Ausnahme nicht angezeigt.

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

Hatte den gleichen Fehler. Eigentlich funktioniert, wenn der Datenverkehr über einen Proxy gesendet wurde (in meinem Fall Fiddler). .NET Framework von 4.5.2 auf> = 4.6 aktualisiert und jetzt funktioniert alles einwandfrei. Die eigentliche Anfrage war:
new WebClient().DownloadData("URL");
Die Ausnahme war:

SocketException: Eine bestehende Verbindung wurde vom Remote-Host zwangsweise geschlossen

9
0x49D1

Einfache Lösung für dieses häufig störende Problem: 

Gehen Sie einfach zu Ihrer " .context.cs" -Datei (unter "context.tt", die sich unter Ihrer "* .edmx" -Datei befindet). 

Fügen Sie dann diese Zeile Ihrem Konstruktor hinzu: 

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

hoffe das ist hilfreich. 

7
ayheber

Ich habe diese Ausnahme aufgrund eines Zirkelverweises in Entität. Entität, die so aussieht

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

Ich habe [IgnoreDataMemberAttribute] zur Parent-Eigenschaft hinzugefügt. Und das hat das Problem gelöst.

1

Ich traf diese Ausnahme, wenn die DateTime-Eigenschaft der Klasse nicht den Wert abruft.

public class PlanningBoardBO
    {
        ... Other Properties ...

        public DateTime? PickupDate { get; set; }

        ... Here changed DateTime to DateTime?
    }
0
UJS

Wenn in einem .Net 4.5.2-Dienst ausgeführt

Für mich wurde das Problem verschärft, da der Anruf in einem .NET 4.5.2-Dienst ausgeführt wurde. Ich folgte dem @willmaz-Vorschlag, bekam aber einen neuen Fehler. 

Beim Ausführen des Dienstes mit aktivierter Protokollierung habe ich festgestellt, dass das Handshaking mit der Ziel-Site ok initiiert wurde (und das Trägertoken gesendet wird). Im folgenden Schritt zur Verarbeitung des Post-Aufrufs scheint es jedoch, dass das Auth-Token gelöscht wird und die Site dies tun würde antworten Sie mit Unauthorized.

Es stellte sich heraus, dass die Berechtigungsnachweise des Service-Pools nicht zum Ändern von TLS (?) Berechtigt waren. Wenn ich mein lokales Administratorkonto in den Pool einrichtete, funktionierte alles.

0
ΩmegaMan

Ich hatte das gleiche Problem und konnte es schließlich beheben. In meinem Fall hatte der Port, an den der Client die Anforderung sendet, keine SSL-Zertifikatsbindung. Also habe ich das Problem behoben, indem ich ein SSL-Zertifikat an den Port auf der Serverseite gebunden habe. Sobald dies erledigt war, verschwand diese Ausnahme.

0
iefgnoix