View Single Post
Old 08-31-2011, 03:59 PM  
Yil
Too much time...
 
Join Date: May 2005
Posts: 1,194
Default

Expand folder(s) while offline fixed, though I don't remember seeing a change notice to that effect.

I still have an issue with the list/stat timeout. I don't understand why it needs to be changed from v3.x and v4.0. I know ioFTPD has some speed issues the first time it opens a directory with a 1000+ subdirs, as does raidenFTPD, because we have to examine the permission info in each subdir before we can return the directory listing and this change is making that much more obvious and very annoying. This is also sometimes true even with drFTPD or glFTPD when nobody has used the server in a bit and it has to swap in a lot of memory and the disk is busy.

Here's the scenario I see. User has say a 1 login limit, they request a dir listing on a large fan-out dir that's going to take a minute or maybe even almost 2 minutes to open the first time. 4.1 will drop the control connection after 30 seconds. If they notice this and attempt to reconnect it's likely they'll be denied login because the server hasn't figured out the other login can be closed out because it's still busy processing the directory listing. When that does timeout they can relogin, but it's very annoying.

Some rough comparisons...

v4 timeout from LIST to first byte of directory listing is 2 minutes if plaintext, and 3 minutes if SSL/TLS, but v4.1 is 30 seconds. v4 timeout between data reception after the first packet for things like LIST -alR is 1 minute, v4.1 is 30 seconds. Hmm, the v4.0 test had the default 60 sec restart data policy (I just installed the 4.0 usb release to test) so it's possible those timeouts could be raised but I should have to double check that as I know it doesn't work that way in 4.1. v4.1 had a 600(!) second timeout for local testing, but it's ignored because it's a list...

I'm trying to find ways to prevent timeouts from happening in a future ioFTPD release and sending something every 30 seconds against a 2 minute (or 1 min) timeout seemed possible, but having to do so every 10 or 15 seconds against a 30 sec timeout will be much harder to do.

I think you fixed it so SITE commands can take the old 2 minute timeout which is great because I've finally gotten scripters to output something every 30 seconds

I can't think of any reason why shorter timeouts are a good thing. If a user is that impatient let them hit the disconnect button and then the reconnect button themselves, but with shorter timeouts people who DON'T want this behavior are stuck with it. It's doubly annoying if they have login limits, and insanely annoying (though their own fault) if they have a short reconnect timeout and manage to get themselves auto-banned from the server for a while because of connecting too often.
Yil is offline   Reply With Quote