Yes, and I get the same result with BeginConnect. See the sample code:
' StopSignal is a ManualResetEvent parameter that I set when the user clicks my Cancel button.
myFTP.Timeout = Timeout
ar = myFTP.BeginConnect(Nothing, Nothing)
Dim SignalHandles(1) As WaitHandle
SignalHandles(0) = ar.AsyncWaitHandle
SignalHandles(1) = StopSignal
WaitIndex = WaitHandle.WaitAny(SignalHandles, Timeout + 1000)
If (WaitIndex = 0) Then
myFTP.EndConnect(ar)
If (myFTP.IsConnected) Then
Result = True
End If
Else
myFTP.Close(True)
End If
If the server I am trying to connect to is not even on the network, the Close(True) call will return immediately, but subsequent calls like any of the following lines (by themselves)
myFTP.Close()
RemoveHandler myFTP.CommandSent, AddressOf Me.LogFTPCommand
myFTP.Dispose()
will block until the original timeout used to try the connection expires. If I were to set a timeout of 2 minutes, the code blocks on any one of these calls for that 2 minutes even though I have canceled the connection with Close(True). I have also seen the same result while using an actual callback function.
My program actually tries to connect to multiple devices (100's), around 20-30 at a time, using multiple threads and instances of the SecureFTPConnection. Using the Asynchronous methods, I have had the program lock on shutdown, even after disposing of all the instances, like some of them are still active and trying to connect. Since the Asynchronous methods use the thread pool, I have also noticed that some of them seem to be delayed in actually starting their work, and seem slower in general, so I get more timeout errors using that approach as opposed to calling the synchronous version and managing my own threads.