Una conexión existente fue cerrada por la fuerza por el host remoto

Estoy trabajando con una aplicación comercial que arroja una SocketException con el mensaje,

Una conexión existente fue cerrada por la fuerza por el host remoto

Esto sucede con una conexión de socket entre el cliente y el servidor. La conexión está viva y bien, y se están transfiriendo montones de datos, pero luego se desconecta de la nada.

Alguien ha visto esto antes? ¿Cuáles podrían ser las causas? Puedo adivinar algunas causas, pero ¿hay alguna manera de agregar más a este código para determinar cuál podría ser la causa?

Cualquier comentario / ideas son bienvenidas.

... Lo último ...

Tengo algunos registros de un seguimiento de .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

Basado en otras partes del registro, he visto el hecho de que dice '0 # 0' significa que se está enviando un paquete de 0 bytes de longitud. Pero, ¿qué significa esto realmente?

Está ocurriendo una de dos posibilidades, y no estoy seguro de cuál,

1) La conexión se está cerrando, pero los datos se están escribiendo en el socket, creando así la excepción anterior. El 0 # 0 simplemente significa que no se envió nada porque el socket ya estaba cerrado.

2) La conexión aún está abierta y se está enviando un paquete de cero bytes (es decir, el código tiene un error) y el 0 # 0 significa que se está intentando enviar un paquete de cero bytes.

¿Que cuentas? Supongo que podría no ser concluyente, pero ¿tal vez alguien más ha visto este tipo de cosas?

Esto generalmente significa que el lado remoto cerró la conexión (generalmente enviando un RSTpaquete TCP / IP ). Si está trabajando con una aplicación de terceros, las causas probables son:

• Está enviando datos con formato incorrecto a la aplicación (que podría incluir el envío de una solicitud HTTPS a un servidor HTTP)
• El enlace de red entre el cliente y el servidor se cae por algún motivo
• Ha desencadenado un error en la aplicación de terceros que hizo que se bloqueara
• La aplicación de terceros ha agotado los recursos del sistema

Es probable que el primer caso sea lo que está sucediendo.

Puede encender Wireshark para ver exactamente lo que está sucediendo en el cable para reducir el problema.

Sin información más específica, es poco probable que alguien aquí realmente pueda ayudarlo mucho.

El uso de TLS 1.2 resolvió este error.
Puede forzar su aplicación usando TLS 1.2 con esto (asegúrese de ejecutarla antes de llamar a su servicio):

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 

Otra solución:
habilite la criptografía sólida en su máquina o servidor local para usar TLS1.2 porque de forma predeterminada está deshabilitada, por lo que solo se usa TLS1.0.
Para habilitar una criptografía sólida, ejecute estos comandos en PowerShell con privilegios de administrador:

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 

Debe reiniciar su computadora para que estos cambios surtan efecto.

Esto no es un error en su código. Proviene de la implementación de Socket de .Net. Si utiliza la implementación sobrecargada de EndReceive como se muestra a continuación, no obtendrá esta excepción.

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

Solución simple para este problema molesto común:

Simplemente vaya a su archivo " .context.cs" (ubicado debajo de " .context.tt" que se encuentra debajo de su archivo "* .edmx").

Luego, agregue esta línea a su constructor:

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

Espero que esto sea útil.

Tenía el mismo error. Realmente funcionó en caso de que el tráfico fuera enviado usando algún proxy (violinista en mi caso) .NET Framework actualizado de 4.5.2 a> = 4.6 y ahora todo funciona bien. La solicitud real fue:
new WebClient().DownloadData("URL");
La excepción fue:

SocketException: el host remoto cerró a la fuerza una conexión existente

Tengo esta excepción debido a la referencia circular en la entidad. En la entidad que se parece

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

Agregué [IgnoreDataMemberAttribute] a la propiedad Parent. Y eso resolvió el problema.

Si se ejecuta en un servicio .Net 4.5.2

Para mí, el problema se agravó porque la llamada se estaba ejecutando en un servicio .Net 4.5.2. Seguí la sugerencia de @willmaz pero recibí un nuevo error.

Al ejecutar el servicio con el registro activado, vi que el apretón de manos con el sitio de destino iniciaría correctamente (y enviaría el token del portador) pero en el siguiente paso para procesar la llamada de publicación, parecería que se cae el token de autenticación y el sitio responde con Unauthorized.

Resultó que las credenciales del grupo de servicio no tenían derechos para cambiar TLS (?) Y cuando puse mi cuenta de administrador local en el grupo, todo funcionó.

Para cualquiera que obtenga esta excepción mientras lee datos de la transmisión, esto puede ayudar. Estaba recibiendo esta excepción cuando leía el HttpResponseMessage en un bucle como este:

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

Después de un tiempo descubrí que el culpable era el tamaño del búfer, que era demasiado pequeño y no funcionaba bien con mi débil instancia de Azure. Lo que ayudó fue cambiar el código a:

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

El método CopyTo () tiene un tamaño de búfer predeterminado de 81920. El búfer más grande aceleró el proceso y los errores se detuvieron de inmediato, probablemente debido a que aumentaron las velocidades generales de descarga. Pero, ¿por qué la velocidad de descarga es importante para evitar este error?

Es posible que se desconecte del servidor porque las velocidades de descarga caen por debajo del umbral mínimo que el servidor está configurado para permitir. Por ejemplo, en caso de que la aplicación desde la que está descargando el archivo esté alojada en IIS, puede ser un problema con la configuración de http.sys:

"Http.sys es la pila de protocolos http que IIS utiliza para realizar la comunicación http con los clientes. Tiene un temporizador llamado MinBytesPerSecond que es responsable de eliminar una conexión si su velocidad de transferencia cae por debajo de un umbral de kb / seg. De manera predeterminada, ese umbral es establecido en 240 kb / seg. "

El problema se describe en este viejo blog del equipo de desarrollo de TFS y concierne específicamente a IIS, pero puede indicarle una dirección correcta. También menciona un error antiguo relacionado con este atributo http.sys: enlace

En caso de que use los servicios de aplicaciones de Azure y el aumento del tamaño del búfer no elimine el problema, intente escalar su máquina también. Se le asignarán más recursos, incluido el ancho de banda de conexión.

Tuve el mismo problema y logré resolverlo eventualmente. En mi caso, el puerto al que el cliente envía la solicitud no tenía un certificado SSL vinculante. Así que solucioné el problema vinculando un certificado SSL al puerto en el lado del servidor. Una vez hecho eso, esta excepción desapareció.

Este error ocurrió en mi aplicación con el protocolo CIP cuando no envié o recibí datos en menos de 10 segundos.

Esto fue causado por el uso del método abierto hacia adelante. Puede evitar esto trabajando con otro método o instalando una tasa de actualización de menos de 10 segundos que mantenga su conexión abierta hacia adelante.