A few facts I compiled since my original reply:
- This problem is not exclusive to flashfxp. Other fxp clients have the same problem (I tried smartftp with the same results).
- The noop method suggested earlier doesn't seem to work either.
- It is DEFINITELY caused by my router (a linksys). when i don't use it, that problem never occurs (or maybe its incidence is reduced so much i just never caught it)
It is thus my guess that the only solution to this is a workaround implemented in FlashFXP.
Flashfxp already estimates the time of the current transfer using the results of the last successfully sent file. so what bigbras suggested
Quote:
|
if xfer takes X% longer than expected, then restart' option.
|
seems to me like an excellent idea. Make this option available for each individual site and let the user define
X. i would personally go with something around 20-25% to allow for normal site slowdowns due to increased traffic.
Now, of course. this isn't a bug inherent fo flashfxp but to routers , network conditions or whatnot so I can understand why BigStar would be reluctant to try to solve a problem he didn't cause. Unfortunately, more and more people have Lans everyday and i just cannot spare my router. And it's a fact linksis is the leading brand. This problem will probably not go away in the near future but increase in proportions. If it's not too hard to code, I think it's worth a shot.
Thx bigstar
Threaded Mode
