G'day there, I've just posted a query to the Proftpd user list regarding badly behaved clients, and users, timing out when they try to do a long listing of a large number of files. (It's actually awaiting moderator input atm because I've only just signed up to that list).
Looking in modules/mod_ls.c at the functions dolist() and ls_nlst() I can see that the data connection is opened and the TimeoutStalled timer is started before the file data is gathered. In the case of one of our users, it takes around 20 minutes for an ls -l to complete at the command line so our TimeoutStalled value of 400 expires and the user's session is ended. N.B. We have had to set this timeout value of 400 because of previous problems with badly behaved users and ftp clients. I can understand why the data channel is opened at this point. If I am not going to be able to send the data to the remote side, then I sure don't want to waste my time doing (potentially lots of) work gathering the necessary data only to find that I crash and burn when I can't open a data connection to the remote user! Anyway, I have made a patch which now removes the timeout_stalled timer after the channel is opened and then adds a timeout_stalled timer back, just before we actually send the data. I might make this patch switchable via a config boolean, e.g. TimeoutStalledListTimer or TimeoutStalledTimerShift, etc. It's not an elegant approach but it does mean that a timeout_stalled timeout occurs because actual data transmission has stalled rather than it taking too long to gather my data to be sent. Anyone also come cross this issue as well? cheers, Rob ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ ProFTPD Developers List <[email protected]> https://lists.sourceforge.net/lists/listinfo/proftp-devel
