Connection not closed due to timeout / no reply.

Question

Hi,

I am using edtFTPNet/Free and it has been a very reliable solution.

But I am hitting a particular issue where connections to the FTP server are not being closed.
This is an issue because the FTP server restricts the number of connections from a given IP.

so, the snippet of code is below. The code is called repeatedly and reuses the connection between calls.
This works great 99% of the time, but every so often a timeout occurs on the 'Put'.
I have exception handling that catches this occurance, and it tries to reconnect to the server.
BUT, I cannot 'close' the old connection at this point. Once the exception happens on the Put it is not accesible (isConnected = False).
if 8 of these occur in 15 minutes I suddenly cannot FTP to the server at all.

Is there some way I should be closing the connection (other than using connection.quit)?

Thanks

If connection Is Nothing Then
connection = New FTPClient(SendFtpFile.SendFTP.host)
connection.StrictReturnCodes = False
connection.Login(SendFtpFile.SendFTP.username, SendFtpFile.SendFTP.password)
' log.Debug("Setting up passive, ASCII transfers")
connection.ConnectMode = FTPConnectMode.PASV
End If

If Not connection.IsConnected Then
connection.Connect()
connection.Login(SendFtpFile.SendFTP.username, SendFtpFile.SendFTP.password)
connection.ConnectMode = FTPConnectMode.PASV
End If

If SendFtpFile.binary Then
connection.TransferType = FTPTransferType.BINARY
Else
connection.TransferType = FTPTransferType.ASCII
End If

'set timeout
connection.Timeout = SendFtpFile.timeout

'put file.
connection.Put(SendFtpFile.sourceFile, SendFtpFile.desinationdirectory & "/" & SendFtpFile.filename)

Answer 1

Call QuitImmediately() in the exception handler before reconnecting.

Answer 2

Thanks, this does appear to have solved the problem.

I did know of this command, but the documentation steered me away from it.

Quit the FTP session immediately by closing the control socket without sending the QUIT command.

This implies that no command is sent to the server at all, which in turn indicated to me that it would leave the connection open.

it appears this is not the case though, maybe the doco could be updated to clarify.

Thanks again.