Nuestros mejores investigadores agotaron sus depósitos de café, buscando noche y día por la resolución, hasta que Elías halló el hallazgo en Gogs así que hoy la comparte contigo.
Solución:
Al leer su pregunta, sospeché que esto tiene que ver con (o podría corregirse) configurando el KeepAlive a false. Mirando SO: esta pregunta hace referencia al mismo problema y también lo señala: https://stackoverflow.com/a/2071374/1803682
Intenta configurar:
request.KeepAlive = false;
Con KeepAlive ajustado a false su conexión se cerrará al final de cada solicitud. Si está transmitiendo muchos archivos, esto podría ser un problema, ya que lleva tiempo reenviar las credenciales, etc. La ventaja es que recrea la conexión en un estado conocido/inicial que debería resolver su problema (incluso si no es la raíz). porque).
Para ver qué está pasando, si puede habilitar el registro detallado en su servidor, debería ver el último comando emitido antes de que se devuelva este error. Esto debería darle una mejor idea de lo que está pasando. Encontré este hilo diciendo casi lo mismo.
Actualizar:
Si hubiera leído hasta el final del enlace que publiqué yo mismo, podría haber respondido aún mejor, el comando que probablemente se vuelve a emitir es una parte del proceso de inicio de sesión (es decir, USER username) y este es su problema probable:
La razón por la que las credenciales ya no pueden ser válidas es que WebRequest usa una concesión que caduca después de un cierto período de tiempo. Si no instancia explícitamente la concesión y define sus tiempos de espera, FtpWebRequest parece usar valores de tiempo de espera predeterminados. Creo que lo que sucede es que cuando el contrato de arrendamiento expire, FtpWebRequest intentará iniciar sesión nuevamente.
Así que mirando aquí con la búsqueda correcta:
produce que el tiempo de espera predeterminado para las solicitudes no es infinito como se especifica, sino que en realidad 10000 ms. Lo que parece una discrepancia bastante grande. Así que también puedes intentar configurar:
request.Timeout = -1;
Y a ver si corrige tu error.
Realmente no creo que este pueda ser tu problema, así que muévelo al final:
Además, compruebe que su request.ReadWriteTimeout es apropiado para la velocidad que ve para el archivo más grande. El valor predeterminado es 5 minutos, lo que sería bastante largo para 290k, por lo que espero que esta no sea la fuente de su error. Además, esperaría un error de conexión cerrada si este fuera el problema.
Yo también encontré la misma excepción con FTPWebRequest dentro de una tarea personalizada de MSBuild… afortunadamente, la tarea expuso una configuración UsePassive="false" (que establece la UsePassive propiedad en el FTPWebRequest objeto). Cambiando el valor a "true" arregló el problema ¡Espero que esto ayude!
- (Colocar
UsePassivea)falsesi el proceso de transferencia de datos de la aplicación cliente escucha una conexión en el puerto de datos; de lo contrario,truesi el cliente debe iniciar una conexión en el puerto de datos. El valor predeterminado estrue. - Configuración de la
UsePassivepropiedad atrueenvía el"PASV"comando al servidor. Este comando solicita al servidor que escuche en un puerto de datos y que espere una conexión en lugar de iniciar una al recibir un comando de transferencia. - Si
UsePassivese establece en true, es posible que el servidor FTP no envíe el tamaño del archivo y el progreso de la descarga siempre puede ser cero. SiUsePassivese establece enfalse, un firewall puede generar una alerta y bloquear la descarga del archivo.