Una connessione esistente è stata forzatamente chiusa dall'host remoto

Sto lavorando con un'applicazione commerciale che sta generando una SocketException con il messaggio,

Una connessione esistente è stata forzatamente chiusa dall'host remoto

Ciò accade con una connessione socket tra client e server. La connessione è viva e vegeta e un sacco di dati viene trasferito, ma poi viene disconnesso dal nulla.

Qualcuno l'ha mai visto prima? Quali potrebbero essere le cause? Posso indovinare alcune cause, ma c'è anche un modo per aggiungere altro in questo codice per capire quale potrebbe essere la causa?

Eventuali commenti / idee sono benvenuti.

... L'ultimo ...

Ho delle registrazioni da alcune tracce di .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

Sulla base di altre parti della registrazione ho visto che dice "0 # 0" significa che viene inviato un pacchetto di 0 byte di lunghezza. Ma cosa significa veramente?

Si sta verificando una delle due possibilità e non sono sicuro di quale,

1) La connessione viene chiusa, ma i dati vengono quindi scritti nel socket, creando così l'eccezione sopra. Lo 0 # 0 significa semplicemente che non è stato inviato nulla perché il socket era già chiuso.

2) La connessione è ancora aperta e viene inviato un pacchetto di zero byte (ovvero il codice ha un bug) e lo 0 # 0 significa che un pacchetto di zero byte sta tentando di essere inviato.

Cosa ne pensi? Potrebbe essere inconcludente, immagino, ma forse qualcun altro ha visto questo genere di cose?

Ciò significa generalmente che il lato remoto ha chiuso la connessione (di solito inviando un RSTpacchetto TCP / IP ). Se lavori con un'applicazione di terze parti, le cause probabili sono:

• Stai inviando dati non validi all'applicazione (che potrebbe includere l'invio di una richiesta HTTPS a un server HTTP)
• Il collegamento di rete tra client e server non funziona per qualche motivo
• È stato attivato un bug nell'applicazione di terze parti che ha causato l'arresto anomalo
• L'applicazione di terze parti ha esaurito le risorse di sistema

È probabile che il primo caso sia quello che sta succedendo.

Puoi accendere Wireshark per vedere esattamente cosa sta succedendo sul filo per restringere il problema.

Senza informazioni più specifiche, è improbabile che qualcuno qui possa davvero aiutarti molto.

L'uso di TLS 1.2 ha risolto questo errore.
È possibile forzare l'applicazione utilizzando TLS 1.2 con questo (assicurarsi di eseguirla prima di chiamare il servizio):

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 

Un'altra soluzione:
abilitare la crittografia avanzata nel computer o nel server locale per utilizzare TLS1.2 perché per impostazione predefinita è disabilitato, quindi viene utilizzato solo TLS1.0.
Per abilitare la crittografia avanzata, eseguire questi comandi in PowerShell con privilegi di amministratore:

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 

È necessario riavviare il computer per rendere effettive queste modifiche.

Questo non è un bug nel tuo codice. Viene dall'implementazione di .Net Socket. Se si utilizza l'implementazione sovraccarica di EndReceive come di seguito non si otterrà questa eccezione.

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

Soluzione semplice per questo fastidioso problema comune:

Basta andare al file " .context.cs" (situato sotto " .context.tt" che si trova sotto il file "* .edmx").

Quindi, aggiungi questa riga al costruttore:

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

spero che sia utile

Aveva lo stesso bug. In realtà ha funzionato nel caso in cui il traffico fosse inviato utilizzando un proxy (fiddler nel mio caso). Framework .NET aggiornato da 4.5.2 a> = 4.6 e ora tutto funziona bene. La richiesta effettiva era:
new WebClient().DownloadData("URL");
l'eccezione era:

SocketException: una connessione esistente è stata forzatamente chiusa dall'host remoto

Ho questa eccezione a causa del riferimento circolare nell'entità. Nell'entità che assomiglia

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

Ho aggiunto [IgnoreDataMemberAttribute] alla proprietà Parent. E questo ha risolto il problema.

Se in esecuzione in un servizio .Net 4.5.2

Per me il problema è stato aggravato perché la chiamata era in esecuzione in un servizio .Net 4.5.2. Ho seguito il suggerimento di @willmaz ma ho ricevuto un nuovo errore.

Durante l'esecuzione del servizio con la registrazione attivata, ho visualizzato l'handshaking con il sito di destinazione che avvierebbe ok (e inviava il token al portatore) ma nel passaggio successivo per elaborare la chiamata post, sembrerebbe eliminare il token di autenticazione e il sito avrebbe rispondere con Unauthorized.

Si è scoperto che le credenziali del pool di servizi non avevano i diritti per modificare TLS (?) E quando ho inserito il mio account di amministratore locale nel pool, tutto ha funzionato.

Per chiunque ottenga questa eccezione durante la lettura dei dati dallo stream, ciò può essere d'aiuto. Stavo ottenendo questa eccezione durante la lettura di HttpResponseMessage in un ciclo come questo:

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();
    }
}

Dopo qualche tempo ho scoperto che il colpevole era la dimensione del buffer, che era troppo piccola e non funzionava bene con la mia debole istanza di Azure. Ciò che ha aiutato è stato cambiare il codice in:

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

Il metodo CopyTo () ha una dimensione del buffer predefinita di 81920. Il buffer più grande ha accelerato il processo e gli errori si sono arrestati immediatamente, molto probabilmente perché la velocità di download complessiva è aumentata. Ma perché la velocità di download è importante nel prevenire questo errore?

È possibile disconnettersi dal server perché la velocità di download scende al di sotto della soglia minima consentita dal server. Ad esempio, nel caso in cui l'applicazione da cui si sta scaricando il file sia ospitata su IIS, può essere un problema con la configurazione di http.sys:

"Http.sys è lo stack di protocollo http utilizzato da IIS per eseguire la comunicazione http con i client. Ha un timer chiamato MinBytesPerSecond che è responsabile dell'uccisione di una connessione se la sua velocità di trasferimento scende al di sotto di una soglia di kb / sec. Per impostazione predefinita, tale soglia è impostato su 240 kb / sec. "

Il problema è descritto in questo vecchio blog post del team di sviluppo di TFS e riguarda specificamente IIS, ma potrebbe indirizzarti nella giusta direzione. Menziona anche un vecchio bug relativo a questo attributo http.sys: link

Nel caso in cui si stiano usando i servizi app di Azure e aumentare le dimensioni del buffer non elimini il problema, provare anche a ridimensionare il computer. Ti verranno assegnate più risorse inclusa la larghezza di banda della connessione.

Ho avuto lo stesso problema e alla fine sono riuscito a risolverlo. Nel mio caso, la porta a cui il client invia la richiesta non aveva un certificato SSL vincolante ad essa. Quindi ho risolto il problema associando un certificato SSL alla porta sul lato server. Fatto ciò, questa eccezione è scomparsa.

Questo errore si è verificato nella mia applicazione con il protocollo CIP ogni volta che non ho inviato o ricevuto dati in meno di 10 secondi.

Ciò è stato causato dall'uso del metodo open forward. Puoi evitarlo lavorando con un altro metodo o installando una frequenza di aggiornamento inferiore ai 10 che mantengono la tua connessione forward-open.