no delay if dns resolve failed

[tommywu]

if we not using ip address directly for server, and after we lost connection, the hostname resolve will be failure. FZ3 will try to reconnect immediately, no any delay.

I think this should have delay for OPTION_RECONNECTDELAY.

[Tim Kosse]

You mean FileZilla tries to _repeatedly_ reconnect without obeying OPTION_RECONNECTDELAY?

[tommywu]

yes.

I've very bad ADSL last week, it lost connection every 1-5 minutes. I've some files in queue, I found the items will move to failure queue in 10 seconds (the retry is 99 and delay is 10 in my setting).

You can make a simple test, just connect to any site, then add one file to download queue, exit FileZilla, then edit queue.xml, change the host name, make it can't be resolved, then open FZ3, process the queue, FZ3 won't make delay between connect, just retry immediately, then move it to failure queue in a short time.

[Tim Kosse]

There are two possible errors with hostname resolution:

• Host doesn't exist
• Nameserver not reachable

Neither current behavior nor always waiting for reconnect delay is correct.

[tommywu]

current behavior almost equal to move it to failure queue at first error.
but ususally, it's link problem, the host is exist and can reachable when we add the item to queue, when the link is back, it can do upload/download without problem.

Usually, when we donwload some large files, it may take half day to transfer the file, if we just let FZ3 to download them, and the link is down just for 5 minutes, all item in queue will move to failure queue even we tell FZ try to reconnect.

I think it's better to have some delay before we reconnect, that can avoid to interrupt transfer for a short link down time.

[Tim Kosse]

I've just performed some tests.

There is absolutely no difference in the behavior of the hostname resolving API functions of the OS. Both if a host does not exist and if the network is down a host-not-found error is returned.

Upon disconnect, FileZilla immediately tries to reconnect. But if a reconnect attempt fails it properly waits for OPTION_RECONNECTDELAY to pass before attempting again.

So basically everything is working exactly as it should be. Just increase your reconnect delay and number of retries settings.

[tommywu]

Sorry for my poor English.

You said, based on your testing, if the hostname could be resolving well, FZ3 will wait for OPTION_RECONNECTDELAY before retry?

I just download FZ 3.0.2-rc1 for testing. My reconnect rety counter is 99, and retry delay is 60 seconds.
Connect to some FTP site, add one file to queue, then exit FZ3, edit queue.xml.

1. Change the Host to any non-reachable ip address. Save it and execute FZ3 again, process the queue. This one will has delay after connect failed.

LOG BEGIN

Status: Connecting to 10.11.12.123:21...
Error: Connection timed out
Error: Could not connect to server
Status: Waiting to retry...
Status: Connecting to 10.11.12.123:21...
Error: Connection timed out
Error: Could not connect to server
Status: Waiting to retry...

LOG END

2. Change the Host to non-exist hostname. Save it and execute FZ3 again, process the queue. This one won't has any delay after connect failed. It will reach 99 errors in 1 seconds (no delay), then move to failed queue.

LOG BEGIN

Status: Resolving IP-Address for unknown.host.com.xx
Error: Invalid hostname or host not found
Error: Critical error
Error: Could not connect to server
Status: Resolving IP-Address for unknown.host.com.xx
Error: Invalid hostname or host not found
Error: Critical error
Error: Could not connect to server

LOG END

Based on my above testing, when FZ3 got host not found error, it won't has any delay, just retry immediately and almost immediately move it to failed queue.

[tommywu]

make delay when got invalid hostname while process queue

[tommywu]

This patch will make delay when got invalid hostname problem for queue process.
File Added: filezilla_3.0.3_delay_for_invalid_hostname.patch

[Tim Kosse]

The patch is broken. The engine may not make any assumption about the user interface.