FanDjango
commented
7 months ago My first thought, was to think about the initial connection to the server (and forgot about data connections later on in the session).
Current connection logic does not retry, it just fails. There is the "AutoDetect" logic, and yes, this does react to Auth failures in that it aborts further attempts to connect in different modes when ecnountering an Auth failure. So far so clear - you are saying that a Connect-Retry loop would be optionally a good thing.
make code less cumbersome (vs having to retry explicitly at the application level)
Yes, this is what I myself needed to code in one of my own applications.
Note that above, I have mixed "Connect" (initial connect to server) and "connect" (all connections, especially data connections). I understand the difference and see that the low level "connect" could be enhanced to optionally loop a number of retries, without any huge coding effort - simply to "hope for a suitable IP" - by the way, regardless of failure reason, even.
if they happen to exit the cloud provider through a different IP than that of the main connection
It is a bit of an edge case, but should be easy to do.
Any possibility you might want to look at the code (in FtpSocketStream.cs Connect(...)) yourself and make the changes?
This feature is to support some scenarios where a ftp client contacting a ftp server in passive mode is running inside a VPC/VNet whose exit to the internet doesn't have a single fixed exit IP. In these cases, new connections established by PASV commands will fail authentication if they happen to exit the cloud provider through a different IP than that of the main connection.
While normally an authentication failure is not retry-worthy (as it's unlikely the conditions causing the failure change between retries), in this case it would help. In a N availability zone config, commands have broadly speaking a 1/N prob of exiting through the same IP that the main connection did.
Allowing the existing retry mechanism to also (optionally) apply to this phase of the connection would help make code less cumbersome (vs having to retry explicitly at the application level).
Thanks