FTP Locks up

[bysky1000]

Using 9.2 (9.2.0.100) of WeBuilder 2008 and if I walk away from my computer and leave the ftp connection running (with or without open files) the program will not allow me to disconnect and I have to restart the program in order to use the ftp explorer again. I guess the ftp session times out and the builtin ftp explorer can't handle that and won't process a disconnect. It just sits there and says Busy... and the only way out is to restart the program. I've tried resetting the layout (it comes back busy still) and I can not find a way to get the ftp explorer back to where I can use it. I *CAN* use the open from FTP command under File and that works even though the ftp explorer is not working.

On another note: using Open by FTP, I can browse and select a file and open it, but I can not type in a file name and open it.

Using Vista

[EvilBMP]

Did you try to doubleclick on the ".." directory, when the connection was closed after a time-out? This works for me (v9.1.0.98). I get an alert message with "FTP connection gracefully closed..." or something like that. After that I can reconnect to the ftp server.

I know, those things are annoying, but the development of the ftp features are not as fast as some people may wish here - no top priority I hope this workarround works with 9.2 under Vista too.

Greets Evil

[Karlis]

The problem is that different FTP servers do things differently and many do NOT COMPLY with RCF standards so it is very difficult to process every special case, although we are getting there.

So as I understand it seems to be Busy... and all buttons (Connect/Disconnect etc.) are disabled?

[bysky1000]

Yes, That is what happens. When the ftp server (in this case IIs running on Win 2000 Advanced server) times out I have to reboot the WeBuilder to re-connect.

[EvilBMP]

same here with the buttons ... clickable, but nothing happens - but in my case i didn't have to reboot webuilder, just double click the ".."-dir and get the "connection gracefully closed" alert! then webuilder knows that the connection isn't available anymore and shows my ftp list again, so that i can reconnect by double-clicking on the ftp server in the list again

in my case the webservers are apaches and the ftp server is e.g. vsFTPd 2.0.5

maybe this helps a little - thx for your efforts

greets Evil

[Karlis]

I believe you have different problems. Click-able buttons and disabled are in different situations.

[kn8]

I believe I have the same problem as bysky1000.

I've been trying to use previous trial versions of web builder and recently purchased v9.4.0.102. The problem is still present in the program for a longer time now.

After longer inactivity on the FTP, when I try to open another file, or navigate to directory that is not cached, the FTP browser gets stuck (it will not accept any other commands). I can still use the editor though, even save the files I have opened from FTP (but only those, that are currently open). The only way to solve this problem now, is to completely restart webuilder. The problem seems to occur after the FTP session on server expires due to timeout, because it always happens when I'm not using the FTP explorer for a while. Webuilder still assumes it is connected, even though it's not. This probably leads to a command that is never completed, and GUI waiting for that command to complete indefinetely (or until application is restarted).

It would be great if we could have some sort of timeout in the FTP explorer, if an action (open file, read directory, etc) is not completed in let's say one minute, it would display an error, and terminate connection to FTP, allowing us to use it without restart. Another solution I can think of is to prevent the FTP timeouts (and probably this error) altogether. It can be done by keeping the FTP connection alive by sending a command to FTP server in specified time intervals. Total commander has this option, it can send NOOP, PWD or SYST command to FTP server in specified intervals, thus preventing the timeout. Maybe you can add keep-alive options in the FTP settings dialog, so we can configure it separately for different FTP sites (some have shorter timeout, some may have very long timeouts, so people may not want to use this option).

I don't know if any of these solutions are possible, but some solution would be nice, as this is the primary way I use webuilder (I almost never work locally).

[chrisjlocke]

kn8- What brand of FTP server are you connnecting to? If you connect to your FTP server via a DOS prompt (just type ftp x.x.x.x where x.x.x.x is the IP address). You should then get a welcome message, which (usually!) details the FTP server.

[kn8]

Most of the time I work with a standard Microsoft FTP service on Windows 2003 server running on IIS 6.

I'm not sure, the problem is tied to a specific server though, I will try to do some testing with other servers as well to specify if this is a global problem, or it only concerns microsoft FTP.

[Karlis]

WeBuilder does send some random FTP commands at random intervals (20 - 50 sec), but obviously it is not good enough for some FTP servers or they manage to crack that keep-alive is doing its job and drop the connection.

So now we have two problems:
1) What commands and intervals are best for implementing keep-alive to fool all FTP servers (Any ideas?)
2) We need to solve the problem with buttons being disabled and not allowing to drop dead connection

[kn8]

1) I use Total Commander for all FTP work (except coding, of course), so I can describe how keepalive option works there (and it works fine as far as I've noticed). TC lets you choose which command you want to send :

NOOP ("do nothing", but It's still a command, so server should notice you are alive)
PWD (print working directory - returns actual working directory)
SYST (returns system type)

I'm always using NOOP (default value) and never had a reason to change it, since it works. All of these commands should be fine, because they are not doing anything a user will notice (they do not change directories, etc.). As for the interval, default is 90 seconds, but it can be changed (I always keep this setting on default though). I never had to change this, in my experience, servers rarely have timeout < 90 seconds.

Maybe the best solution will be to let the user choose his command and interval, somewhere in Webuilder or FTP site settings.

2) Not my area here... So I don't know if this suggestion will be any good (or realistic):

Isn't it possible to add some kind of internal timer on all ftp operations? When a user will try to open a file or directory on FTP, timer will start. If the timer reaches lets say, 90 seconds, Webuilder will know something is wrong, and terminate the command/connection, or ignore the connection altogether, and restart the FTP window from scratch (so we would be back at the list of FTP sites). Maybe an error dialog should open, so a user knows that connection has been dropped and FTP window restarted.

[syrupcore]

1) What commands and intervals are best for implementing keep-alive to fool all FTP servers (Any ideas?)

Maybe have a peek at the source for Filezilla? http://filezilla-project.org/download.php?type=client

[NearZero]

Think sending a NOOP is propably the best way to go, it's pretty much what most FTP clients use.

Having an interval setting option would be good, say with a default of 20 seconds.

[Karlis]

The problem is, we had a NOOP only keep alive and it failed 50% of the time, many servers just ignore it and fight aggressively with software trying to keep alive the connection. Here is what we send - the actual code.

// random command just to fool FTP server
case Trunc(Random(5)) of
0: FFtpClient.RetrieveCurrentDir;
1: FFtpClient.ResumeSupported;
2: FFtpClient.List(nil, '', False);
3: FFtpClient.TransferType:= ftASCII;
4: FFtpClient.TransferType:= ftBinary;
end;

at 10 to 40 seconds

This should keep anything alive but apparently it does not. Will add NOOP and SYST in the mix, probably it helps.

Anyways, will be working on this.

[kn8]

Anyways, will be working on this.

Well, I'm really impressed on the support this product is getting. So thanks for all, for trying to solve this