FluentFTP: AutoConnectAsync error: Timed out trying to read data from the socket stream!
busy trying to look at the source code to see if i can see why the below happens
Error Failed Timed out trying to read data from the socket stream!
System.TimeoutException: Timed out trying to read data from the socket stream!
at FluentFTP.FtpSocketStream.ReadAsync(Byte[] buffer, Int32 offset, Int32 count, CancellationToken token)
at FluentFTP.FtpSocketStream.ReadLineAsync(Encoding encoding, CancellationToken token)
at FluentFTP.FtpClient.GetReplyAsync(CancellationToken token)
at FluentFTP.FtpClient.HandshakeAsync(CancellationToken token)
at FluentFTP.FtpClient.ConnectAsync(CancellationToken token)
at FluentFTP.FtpClient.AutoDetectAsync(Boolean firstOnly, Boolean cloneConnection, CancellationToken token)
at FluentFTP.FtpClient.AutoDetectAsync(Boolean firstOnly, Boolean cloneConnection, CancellationToken token)
at FluentFTP.FtpClient.AutoConnectAsync(CancellationToken token)
trying to see the source code for GetReplyAsync cant see it/ find it
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 21 (8 by maintainers)
@Seabizkit
I would recommend closing this. The description “where is the implementation of GetReplyAsync” and the entire evolution of the documentation does not motivate well to understand the actual problem you are trying to solve.
Please reopen this as a new issue documenting what your real problem is, in a concise fashion.
Is the problem:
Connect does not work? Connect does not work if in debug mode? Test do not work?
I gave up after a while. Sometimes a fresh start will be the best way to succeed.
Ok. Lets be systematic.
If not in debug mode, AutoConnectAsync fails always.
Questions:
Only for this one server, or for many servers or for all servers?
Does AutoConnect (not async) work? I am assuming: yes.
Can you put together a minimum piece of code that tries to autoconnect, post this here and also the log?
Then you posted:
and an image
Question: Removing what? Are you saying: Removing the comments makes it work? Do you realize what that sounds like? Oh, I see, you mean you commented out those lines, and then it works (ASYNC, ALL THE TIME, EVEN IN DEBUG)?
Since there is a final
throwin there, shouldn’t there by an exception to be seen? Maybe it is caught further up the chain, so put a breakpoint on thatthrowand show us the actual exception that is happening? Are you saying it is a timeout?Using Debug and trying to step through the connect process is difficult due to timeout reasons. Consider putting temporary log statement in strategic locations.
If your server permits this, check that this is not connected to ssl, try an unencrypted connection. Also identify if the protocols chosen by AutoConnect might be unsuitable.
And finally, try commenting out only one of the specific catchers, first the cancel one, and then the timeout one. Which one is the “bad” one?
Then we can progress from there…
@Seabizkit You’re saying a lot of things, so I’m not sure exactly what you’re asking me to comment on. Also note that I’m not very familiar with this library, I’m just another user that wants to contribute back to the ecosystem.
await ReadAsync(buf, 0, buf.Length, token) > 0and(await ReadAsync(buf, 0, buf.Length, token)) > 0are semantically equivalent, the extra set of parentheses are not needed.I have two observations when skimming the implementation of
ReadLineAsync. Note that I haven’t dug further into it whether these observations are correct.ReadLinesAsyncread 1 byte at a time. Other places in the code usesCalculateTransferChunkSizeto dynamically determine the buffer size.Each call to
ReadAsynccreates a newCancellationTokenSource.So if I read 4k of data using
ReadLinesAsyncit will make 4k calls toReadAsynceach reading a single byte plus the overhead of constructing and disposing 4k instancesCancellationTokenSources.