FXP Timeout

I think it would be great to have a FXP Timeout setting.

For example, if you are FXPing some 10-15MB files between 100Mbit connections, there should be no reason your FXP should take more than 1 minute per file in normal circumstances.

Sometimes I end up FXPing a large queue, and it will end up FXPing on a file for hours (when in reality there is no longer even a valid connection to either FTP).

It would be great to be able to automatically reconnect/restart the FXP after a fixed amount of time.

Thanks for your consideration,
jcony

Hmm, i have a feeeling this occurs because the remote connections are lost on your end (if the servers were closing the connections they should be sending an indication that they are doing so). If your connection drops even for a second (enough to loose the connections) flashfxp wont know and so it will sit there waiting.

Anyway, if such a feature is introduced, it should be a site specific, and even then could be troublesom as you wont always be transferring from fast site 1 to fast site 2 (might queue stuff to somewhere slower and forget about the option) in which case you would get unnecersary transfer interuptions. If the recieving server it set to delete failed uploads or incomplete files, your queue wont get far.

Maybe fxp timeout setting with 'incoming' and 'outgoing' check boxes, designed to only work if source has outgoing checked and target has incoming checked? bit of a tricky one in terms of the best way to implement without interfering with the regular use of the program.

"if the servers were closing the connections they should be sending an indication that they are doing so"

While this is true, I'm sure you have seen instances where FlashFXP does not get the indication for one reason or another

I agree, this might not be good for a global setting, but rather site specific. I like your incomming/outgoing idea.

I would like to see some sort of solution to this problem. While this might seem like an ok solution, I don't think it's a very good one.

Regardless of the connection speed between the two sites there will always be something that could cause the transfer to take longer than expected.

The only time I've seen this type of behavior occur is when you actually unplug the network cable from the computer running FlashFXP. Although there maybe other ways there is no way to predict it.

Windows has a socket keep-alive feature however I believe the interval by default is insanely high, like an hour or something, perhaps even higher.

Well, I have personally seen FlashFXP FXPing a file for over 3 hours. It's kinda annoying to come back after the afternoon has passed to see that my transfer has not finnished and is only about half way done (even if the reason was an unplugged network cable). While this might not be the silver bullet solution, it would get the job done and that silver bullet solution may never exist.

Do you have any better suggestions?

Originally Posted by bigstar

The only time I've seen this type of behavior occur is when you actually unplug the network cable from the computer running FlashFXP.
Although there maybe other ways there is no way to predict it.

right,i can confirm this to. I can even confirm that this will 'sometimes' happand when you plug in a socks between two remote sites. When this socks goes offline for a reason or another? you get same results as jcony or "unplug network cable". ffxp will end up fxping for ouers, sometimes over 2-9 houers with same file. Thing is, even If this socks go online again,after a minute or two? ffxp will "sometimes" Not recognize this and keep hanging there till we do a manual abort, reconnect...

With 'some' other socks there are Much less problem. If proxy goes down, then ffxp also disconnects immediately and keep trying reconnect till socks are online again. In another config If 'one' remote site are hooked up through a socks, and the other site are not. If the socks goes down, ffxp keeps hanging there for several minutes up to several ouers, real annoying behavior. Manual abort, reconnect will do the trick (if Not proxy are offline for the moment) But, sometimes it will work like a charm, everytime when it goes down, ffxp disconnects immediately. this is Not speed related, same issue with gigabit pipeline as for 10mbit line. "send noops during transfer" does not help in this Case!! (just to let u know

i have seen this behavior with https proxy to... same issues... same timecycle


agree with DayCuts, it should definitly be site specific and even an "Must Have" options within "ProxyTab" for those who use such configuration?
The proxy Tab should include two: 'Global'(for all proxy in list) and 'socks/proxy specific'

keep up the good work!

This is certainly an irritating and complicated issue to find a solution for. Generally speaking this is always caused by the loss of the connection outside of flashfxp's control, often a power flicker on a router/modem can cause a 'virtual' cable/nic disconnection and severs all connections while flashfxp (and most other programs) remain unaware.

Is there any way for flashfxp to monitor and/or detect the outside loss/closure of the sockets dispite the the os keep-alive? (and thus it could handle them how it sees fit)

I conducted several tests and I've come to the following conclusion.

If you enable the "Send Noop during transfer" option then FlashFXP will detect the loss of connection (not immediately but within a couple minutes) and will attempt a reconnect. This works with normal and SSL connections.

Unforunitely "Send Noop during transfer" isn't the perfect solution since not all ftp servers can properly handle a NOOP during a file transfer, some ftp servers will disconnect, others will get confused and behave incorrectly.

In addition I discovered a bug in FlashFXP (builds 1183 and below) where "Send Noop during transfer" doesn't work properly during a FXP transfer if the ftp server on the left side doesn't have "Send Noop during transfer" checked. This has been addressed in build 1184.